+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+---- Forum: aaPanel Addons & Plugins (https://adminsforum.com/Forum-aapanel-addons-plugins)
+----- Forum: Varnish Cache for aaPanel (https://adminsforum.com/Forum-varnish-cache-for-aapanel)
+----- Thread: Guide Configure Varnish Cache in aaPanel: Controls and Exclusions (/Thread-guide-configure-varnish-cache-in-aapanel-controls-and-exclusions)
Configure Varnish Cache in aaPanel: Controls and Exclusions - DEV - 10-20-2026
Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.
The current lab build caches eligible public WordPress homepage/post responses for up to 30 seconds. It uses a dedicated 32 MiB cache instance for the audited website. These are the tested native lab values, not user-adjustable controls demonstrated by this guide.
The WordPress template should be selected when adding the site. This native build has fixed audited exclusions. Custom exclusion editing, framework switching and the isolated fixture's settings must not be presented as working native-site controls.
1. Understand the status
Varnish: active
Meaning: Managed process and site route are verified
What to do: Check anonymous public content and your application workflows.
HIT
Meaning: This response was served from a reusable cached object
What to do: Confirm it is public content and contains no user-specific information.
MISS
Meaning: Varnish fetched a cacheable response from the origin
What to do: Repeat the same anonymous request before its lifetime expires.
BYPASS
Meaning: The request or response was deliberately not reused from cache
What to do: Expected for private sessions, writes and protected paths.
DIRECT
Meaning: The native origin served the response without Varnish
What to do: Expected while disabled; investigate if caching should be enabled.
Direct fallback / needs attention
Meaning: The site is online through its origin but cache verification failed
What to do: Inspect the managed service and recover or disable through the addon.
Not verified / configuration needs review
Meaning: The addon cannot establish a trustworthy state
What to do: Refresh and inspect the conflict before making changes.
A low hit rate on a quiet lab is not a tuning failure by itself. Health checks, deliberate privacy tests, recently purged objects and cold requests affect the ratio.
2. Verify a public page
Use a published post that is public and not password-protected. For this lab, replace your-public-post with an existing public test post:
Code:
curl -sS -D - -o /dev/null https://blog.adminslab.com/your-public-post/
curl -sS -D - -o /dev/null https://blog.adminslab.com/your-public-post/Inspect X-AF-Cache. After an exact-path purge or a genuinely cold request, the first response should normally be MISS and the next HIT. Use GET as above; do not assume HEAD exercises exactly the same application behavior. These commands retain certificate verification and send no login cookies.
The status request used to verify a purge can immediately warm the homepage again. A subsequent homepage HIT therefore does not prove that purge failed. Check changed content or use an exact public post path for a controlled cold test.
3. Confirm private requests bypass
The current policy bypasses requests with cookies, Authorization, query strings and writes. WordPress login/admin/API routes and common cart, checkout and account paths are excluded. Private/no-store responses and responses with Set-Cookie must not become reusable public objects.
Repeat the public-post check with a disposable cookie:
Code:
curl -sS -D - -o /dev/null \
-H 'Cookie: af_test=private' \
https://blog.adminslab.com/your-public-post/Expect BYPASS. Then test real sign-in and user-specific pages with two separate accounts. In our application test, both accounts completed real WordPress login requests and received their own uncached profile pages, including during 12 interleaved requests.
The /cart/, /checkout/ and /my-account/ paths bypassed in this lab. WooCommerce was not installed. This is route-exclusion evidence, not proof that a real shop's sessions, cart contents, payments, custom URLs or extensions work correctly. A live WooCommerce journey remains a release gate.
Varnish's general request/cache flow is documented in the official VCL tutorial; the values and exclusions above describe this addon build.
4. Verify automatic invalidation
1. Warm a disposable public post and confirm HIT.
2. Update its public content through WordPress.
3. Request the same post anonymously.
4. Confirm the updated content is visible immediately and the old content is absent.
5. Repeat and confirm HIT on the updated version.
6. Edit an approved disposable comment and repeat the cache check.
Our current run used WordPress's application APIs to publish/update/trash a disposable post and edit a real comment. The update invalidated the old cached content automatically, and a successful purge was recorded by the native integration. A browser editor and public comment-form journey were not exercised in this run.
Use Purge site cache in the Dashboard for a manual site purge. Its administration is private and authenticated. Public PURGE and BAN requests returned HTTP 405 during testing, and an invalid key at the private purge interface was rejected.
5. Read the Dashboard correctly
- **Requests, hits, misses and pass requests:** cumulative counters for the dedicated Varnish child. Pass is read from its own counter; it is not calculated by subtracting hits and misses.
- **Hit rate:** HIT / (HIT + MISS), excluding pass requests.
- **Live traffic:** rates calculated from successive counter observations. The Live button refreshes about every 10 seconds while the visible Dashboard is open and can be paused.
- **Memory:** allocated cache storage versus its capacity. Process RSS is reported separately and includes overhead/shared pages.
- **Service health:** version, cache uptime, origin requests, backend connection failures and cumulative session connections. Session connections are not the current number of visitors.
- **Managed website:** selected hostname, WordPress template, Nginx assignment and verified cache status.
The chart retains up to 30 minutes of readings in the open browser session. It is not persistent server history. A restart, missing counter or long observation gap breaks the line. Native static-file responses and direct fallback traffic are outside these Varnish counters. Internal health requests are included.
6. Tune from evidence
Before increasing memory or cache lifetime, determine whether misses come from expiry, deliberate exclusions, purges or insufficient storage. Compare the same public content, PHP configuration and request method. Keep privacy checks in place while measuring performance.
The lab's 32 MiB storage and 30-second lifetime are a controlled test configuration. The current native controls do not offer demonstrated production tuning for these values. Do not edit managed files to experiment: an external edit can trigger a conflict and make automatic recovery unsafe.
A cold MISS still runs the origin application. Varnish improves reusable public responses; it does not replace PHP/database optimization or make logged-in account pages cacheable.
7. Troubleshoot and recover
Every response bypasses: Cookies, query strings, authentication, protected paths, private Cache-Control and Set-Cookie.
A public post never becomes HIT: Confirm it is eligible public post content, check response headers, then test the same path anonymously before expiry.
Old content remains after editing: Verify the native MU integration is installed, inspect its last purge result, and use manual purge. Check for another cache/CDN layer.
Cache unavailable but site works: Confirm DIRECT fallback and the managed service state. Use the addon recovery/Enable action after reviewing the failure.
Native configuration changed: Preserve the newer configuration and investigate the conflict. Do not restore an old file blindly.
Native Logs or Activity appears unavailable: Those views are not yet connected for the native site. Use the site's aaPanel logs and the operator's private service/routing evidence.
For this lab only, the operator can inspect the managed service without changing it:
Code:
systemctl status af-varnish-native-11.service --no-pager
journalctl -u af-varnish-native-11.service -n 50 --no-pagerReview errors before sharing excerpts; do not publish keys, cookies, database credentials or private request details. Keep the original configuration and private transaction journals available for recovery.
Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.
Guide series: Installation | WordPress configuration | Measured results
Historical attachments dated 20 October below show the older isolated fixture interface. The instructions above describe the native WordPress lab build verified on 24 October.