https://adminsforum.com/ Sat, 24 Oct 2026 21:46:55 +0000 MyBB https://adminsforum.com/Thread-varnish-cache-for-aapanel-0-6-2-multi-webserver-test-download Sun, 25 Oct 2026 02:29:24 +0800 DEV]]> https://adminsforum.com/Thread-varnish-cache-for-aapanel-0-6-2-multi-webserver-test-download Varnish Cache by Adminforum 0.6.2 — multi-webserver test download

Download Varnish Cache 0.6.2 and view its release history. This is a development test package for a disposable Linux aaPanel server. It binds one WordPress site selected by its aaPanel site ID. It is not yet a general production release.

Compatible test routes

• Nginx.
  
• Nginx + Apache, using aaPanel's existing Apache/PHP-FPM backend.
  
• Nginx + OpenLiteSpeed, using aaPanel's existing OLS/lsphp backend.
  

Nginx must remain the public frontend. Standalone Apache-only and OpenLiteSpeed-only frontends are not supported by this installer. Multi-webserver support describes the selected site's engine combination; this package does not manage multiple cached sites at once.

What changed
The addon reads the actual assigned backend and its loopback port, preserves native backend files and security locations, and adds a reversible Varnish route. If the dedicated cache stops, the combined routes fall back to the native backend. WordPress edits trigger cache invalidation. Existing cache layers and unknown custom configurations are checked before activation.

Verified results
Both combined modes passed 44 live checks each: 88/88 checks in total. These covered MISS then HIT, cookies/admin/query/Authorization bypass, WordPress update purging, protected purge, native fallback, exact route restoration, two real logged-in users, and configuration-conflict detection. Another 19 Linux installer safeguards and 18 adapter tests passed.

Test environment: Ubuntu 22.04.5, aaPanel 8.0.7, WordPress 7.1.3, Nginx 1.30.6, Apache 2.4.69, OpenLiteSpeed 1.8.5, PHP/lsphp 8.5.12 and privately extracted distro Varnish 6.6.1. The previously installed lab addon was preserved; the candidate was tested from an isolated review directory.

Install on your test server
1. Take a VM snapshot and confirm the chosen WordPress site works over trusted HTTPS. Keep it on its intended aaPanel engine combination. Use one hostname with /www/wwwroot/hostname as its document root.
2. Download and extract the ZIP from the release page. Read START-HERE.md inside it. Upload its af_varnish folder outside the website root, for example /root/af-varnish-test/af_varnish.
3. In aaPanel Terminal as root:

Code:Copy

cd /root/af-varnish-test/af_varnish bash install.sh install cd /www/server/panel/plugin/af_varnish /www/server/panel/pyenv/bin/python3 setup.py prepare-engine /www/server/panel/pyenv/bin/python3 setup.py list-sites

The installer refuses an existing addon installation instead of overwriting it. prepare-engine extracts Varnish from your configured signed apt repositories; it does not install the system Varnish service or start public listeners.

4. Replace 12 with your WordPress site's actual ID:

Code:Copy

/www/server/panel/pyenv/bin/python3 setup.py configure --site-id 12 /www/server/panel/pyenv/bin/python3 setup.py doctor

Configuration does not enable caching. If preflight refuses a custom route, preserve the error and report it; do not force changes past the checks.

5. Open the addon in aaPanel, select Websites and Enable the configured site. Repeat an anonymous request: a cacheable page should show X-AF-Cache: MISS and then HIT. Cookie/login/admin/query requests should bypass. In combined modes POST, Upgrade-header and event-stream-header requests route directly to the native backend.
6. Test a WordPress post edit, Purge and Disable. Disable must restore direct operation before stopping its cache dependencies. Follow START-HERE.md for removal; do not use the unverified App Store removal wrapper for this candidate.

Current limits
Use one cache layer: active WordPress page-cache drop-ins and active inner OLS page caching are refused. WooCommerce, clean-server installation, reboot/upgrade lifecycle, active engine switching, certificate renewal, WP Toolkit creation, WAF integration and arbitrary custom configurations remain unverified. Upgrade/event-stream request routing was checked; a complete WebSocket handshake or long-running stream was not demonstrated.

File verification
Filename: af-varnish-0.6.2-multi-localtest.zip
Size: 87,955 bytes
SHA-256:

Code:Copy

b5813a7abed5d442b8d748472c6d1035cfabf35e00510f9ae8c343ffbd74ee53

The archive includes installation instructions and a SHA256SUMS manifest. No Varnish engine binary is bundled.

Report your test results here
Include OS, aaPanel, webserver mode, PHP/lsphp and Varnish versions, whether the problem occurs on Enable/Purge/Disable, and relevant redacted error output. Do not post credentials, cookies or purge secrets.

Varnish guides and support]]> Varnish Cache by Adminforum 0.6.2 — multi-webserver test download

Download Varnish Cache 0.6.2 and view its release history. This is a development test package for a disposable Linux aaPanel server. It binds one WordPress site selected by its aaPanel site ID. It is not yet a general production release.

Compatible test routes

• Nginx.
  
• Nginx + Apache, using aaPanel's existing Apache/PHP-FPM backend.
  
• Nginx + OpenLiteSpeed, using aaPanel's existing OLS/lsphp backend.
  

Nginx must remain the public frontend. Standalone Apache-only and OpenLiteSpeed-only frontends are not supported by this installer. Multi-webserver support describes the selected site's engine combination; this package does not manage multiple cached sites at once.

What changed
The addon reads the actual assigned backend and its loopback port, preserves native backend files and security locations, and adds a reversible Varnish route. If the dedicated cache stops, the combined routes fall back to the native backend. WordPress edits trigger cache invalidation. Existing cache layers and unknown custom configurations are checked before activation.

Verified results
Both combined modes passed 44 live checks each: 88/88 checks in total. These covered MISS then HIT, cookies/admin/query/Authorization bypass, WordPress update purging, protected purge, native fallback, exact route restoration, two real logged-in users, and configuration-conflict detection. Another 19 Linux installer safeguards and 18 adapter tests passed.

Test environment: Ubuntu 22.04.5, aaPanel 8.0.7, WordPress 7.1.3, Nginx 1.30.6, Apache 2.4.69, OpenLiteSpeed 1.8.5, PHP/lsphp 8.5.12 and privately extracted distro Varnish 6.6.1. The previously installed lab addon was preserved; the candidate was tested from an isolated review directory.

Install on your test server
1. Take a VM snapshot and confirm the chosen WordPress site works over trusted HTTPS. Keep it on its intended aaPanel engine combination. Use one hostname with /www/wwwroot/hostname as its document root.
2. Download and extract the ZIP from the release page. Read START-HERE.md inside it. Upload its af_varnish folder outside the website root, for example /root/af-varnish-test/af_varnish.
3. In aaPanel Terminal as root:

Code:Copy

cd /root/af-varnish-test/af_varnish bash install.sh install cd /www/server/panel/plugin/af_varnish /www/server/panel/pyenv/bin/python3 setup.py prepare-engine /www/server/panel/pyenv/bin/python3 setup.py list-sites

The installer refuses an existing addon installation instead of overwriting it. prepare-engine extracts Varnish from your configured signed apt repositories; it does not install the system Varnish service or start public listeners.

4. Replace 12 with your WordPress site's actual ID:

Code:Copy

/www/server/panel/pyenv/bin/python3 setup.py configure --site-id 12 /www/server/panel/pyenv/bin/python3 setup.py doctor

Configuration does not enable caching. If preflight refuses a custom route, preserve the error and report it; do not force changes past the checks.

5. Open the addon in aaPanel, select Websites and Enable the configured site. Repeat an anonymous request: a cacheable page should show X-AF-Cache: MISS and then HIT. Cookie/login/admin/query requests should bypass. In combined modes POST, Upgrade-header and event-stream-header requests route directly to the native backend.
6. Test a WordPress post edit, Purge and Disable. Disable must restore direct operation before stopping its cache dependencies. Follow START-HERE.md for removal; do not use the unverified App Store removal wrapper for this candidate.

Current limits
Use one cache layer: active WordPress page-cache drop-ins and active inner OLS page caching are refused. WooCommerce, clean-server installation, reboot/upgrade lifecycle, active engine switching, certificate renewal, WP Toolkit creation, WAF integration and arbitrary custom configurations remain unverified. Upgrade/event-stream request routing was checked; a complete WebSocket handshake or long-running stream was not demonstrated.

File verification
Filename: af-varnish-0.6.2-multi-localtest.zip
Size: 87,955 bytes
SHA-256:

Code:Copy

b5813a7abed5d442b8d748472c6d1035cfabf35e00510f9ae8c343ffbd74ee53

The archive includes installation instructions and a SHA256SUMS manifest. No Varnish engine binary is bundled.

Report your test results here
Include OS, aaPanel, webserver mode, PHP/lsphp and Varnish versions, whether the problem occurs on Enable/Purge/Disable, and relevant redacted error output. Do not post credentials, cookies or purge secrets.

Varnish guides and support]]> https://adminsforum.com/Thread-guide-install-varnish-cache-in-aapanel-closed-lab-preview Sat, 24 Oct 2026 19:26:32 +0800 DEV]]> https://adminsforum.com/Thread-guide-install-varnish-cache-in-aapanel-closed-lab-preview Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.

This guide covers Varnish Cache by Adminforum 0.6.0-lab, the development build tested on our existing aaPanel lab. It explains how its control files are validated and how the audited WordPress website is added and enabled.

This is not a clean-server installation recipe. The current native integration is restricted in code to blog.adminslab.com, aaPanel site ID 11, using Nginx/PHP and the WordPress template. Its Varnish binaries and runtime dependencies were already prepared on this lab. Copying the control files to another server will not produce a supported working installation. A portable installer and the full aaPanel webserver matrix remain release gates.

1. Check the tested environment

Operating system: Ubuntu 22.04 lab VPS

aaPanel: 8.0.7; multi-webserver feature enabled

Website assignment: Nginx 1.30.6

WordPress PHP: 8.5.12

WordPress: 7.1.3

Varnish: 9.1.0

Dedicated cache capacity: 32 MiB

Having Apache or OpenLiteSpeed installed does not establish addon compatibility with those website assignments. aaPanel supports per-site server choices and proxy combinations; each requires its own integration tests. See aaPanel Multi-WebServer Hosting.

Before a closed test, retain a private copy of the plugin files and the site's native configuration. Confirm that WordPress works over valid HTTPS, that the website is assigned to the audited engine, and that the application/database can be recovered. Keep the lab's noindex and outgoing-mail guard in place.

2. Validate the installed control files

The current lab control directory is:

Code:Copy

/www/server/panel/plugin/af_varnish

For an operator already working in this prepared lab, the installation-validation command is:

Code:Copy

bash /www/server/panel/plugin/af_varnish/install.sh install

It validates the known control files and their permissions. It does not download or install the Varnish engine, prepare a fresh server, start caching or rewrite a registered website. On this test run, it completed while the existing native cache stayed enabled and its public route remained unchanged.

Use a reviewed build supplied for the specific lab. There is no public download link for the current native build in this guide. Do not substitute an older preview archive and assume it includes the current native controls.

3. Open the addon

1. Sign in as the primary aaPanel administrator.
2. Open **Home → Software → Varnish Cache by Adminforum**.
3. Confirm that the addon loads and website discovery completes.
4. If an update appears to use older code, reopen the addon. A panel-process refresh may be required by the operator after deployment; this is separate from rebooting the VPS or restarting website services.

4. Add the audited WordPress website

1. Choose **Add website**.
2. Select the existing `blog.adminslab.com` website from aaPanel.
3. Choose **WordPress** as the application template.
4. Choose **Add website** to save it in the addon workspace.

Adding a website does not enable caching. The template identifies the application; it does not mean that every application or server mode has a working adapter.

5. Enable caching and verify the route

For the audited lab website, open Websites and choose Enable caching in the managed WordPress control card. Wait for the operation and verification to finish.

The addon creates a dedicated private Varnish service and a site-specific origin handoff while retaining the native HTTPS frontend. It keeps an original-route backup and configuration fingerprints. It does not require a global webserver switch.

Successful activation shows Varnish: active. The green state requires both a verified managed process and a successful HTTPS response through the cache route. A website simply returning HTTP 200 is insufficient.

Open Dashboard to check request counters, hit rate, traffic readings, memory, version and uptime. Use a logged-out request to a cacheable public post to confirm a MISS followed by a HIT. See the configuration guide.

6. Disable safely before removal

Use Disable caching and wait for the native direct route to be restored. Only then remove the website from the addon list. Removing it from the addon list does not delete its aaPanel website, files or database.

The installer refused uninstall while the native cache was configured in our live test. The website route and plugin files remained intact. This verifies the active-cache safeguard, not a complete clean uninstall/reinstall lifecycle.

Do not delete runtime files or manually stop dependencies while a managed public route still needs them. If a native configuration has changed, preserve it and resolve the conflict; do not overwrite it with an older backup merely to force removal.

Installation troubleshooting

Addon opens but activation is unavailable: Confirm the exact supported site, engine and WordPress template. Other sites remain outside native activation scope.

Enable rolls back: Inspect the private routing journal, Nginx validation and PHP/site errors. Confirm the original website still works.

PHP cannot read addon configuration: Preserve open_basedir. The corrected bridge embeds its installed key in the PHP-readable MU plugin; it does not require relaxing the restriction.

Quick re-enable reports an occupied private port: Allow graceful listener retirement; identify a real port owner before retrying. Do not kill an unknown process.

Uninstall is refused: Disable the managed native cache first and confirm direct routing.

Public release still requires portable dependency installation, additional native engine adapters, mixed-engine tests and lifecycle validation. Until then, use this procedure only within the explicitly prepared closed lab.

Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.

Guide series: Installation | WordPress configuration | Measured results]]> Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.

This guide covers Varnish Cache by Adminforum 0.6.0-lab, the development build tested on our existing aaPanel lab. It explains how its control files are validated and how the audited WordPress website is added and enabled.

This is not a clean-server installation recipe. The current native integration is restricted in code to blog.adminslab.com, aaPanel site ID 11, using Nginx/PHP and the WordPress template. Its Varnish binaries and runtime dependencies were already prepared on this lab. Copying the control files to another server will not produce a supported working installation. A portable installer and the full aaPanel webserver matrix remain release gates.

1. Check the tested environment

Operating system: Ubuntu 22.04 lab VPS

aaPanel: 8.0.7; multi-webserver feature enabled

Website assignment: Nginx 1.30.6

WordPress PHP: 8.5.12

WordPress: 7.1.3

Varnish: 9.1.0

Dedicated cache capacity: 32 MiB

Having Apache or OpenLiteSpeed installed does not establish addon compatibility with those website assignments. aaPanel supports per-site server choices and proxy combinations; each requires its own integration tests. See aaPanel Multi-WebServer Hosting.

Before a closed test, retain a private copy of the plugin files and the site's native configuration. Confirm that WordPress works over valid HTTPS, that the website is assigned to the audited engine, and that the application/database can be recovered. Keep the lab's noindex and outgoing-mail guard in place.

2. Validate the installed control files

The current lab control directory is:

Code:Copy

/www/server/panel/plugin/af_varnish

For an operator already working in this prepared lab, the installation-validation command is:

Code:Copy

bash /www/server/panel/plugin/af_varnish/install.sh install

It validates the known control files and their permissions. It does not download or install the Varnish engine, prepare a fresh server, start caching or rewrite a registered website. On this test run, it completed while the existing native cache stayed enabled and its public route remained unchanged.

Use a reviewed build supplied for the specific lab. There is no public download link for the current native build in this guide. Do not substitute an older preview archive and assume it includes the current native controls.

3. Open the addon

1. Sign in as the primary aaPanel administrator.
2. Open **Home → Software → Varnish Cache by Adminforum**.
3. Confirm that the addon loads and website discovery completes.
4. If an update appears to use older code, reopen the addon. A panel-process refresh may be required by the operator after deployment; this is separate from rebooting the VPS or restarting website services.

4. Add the audited WordPress website

1. Choose **Add website**.
2. Select the existing `blog.adminslab.com` website from aaPanel.
3. Choose **WordPress** as the application template.
4. Choose **Add website** to save it in the addon workspace.

Adding a website does not enable caching. The template identifies the application; it does not mean that every application or server mode has a working adapter.

5. Enable caching and verify the route

For the audited lab website, open Websites and choose Enable caching in the managed WordPress control card. Wait for the operation and verification to finish.

The addon creates a dedicated private Varnish service and a site-specific origin handoff while retaining the native HTTPS frontend. It keeps an original-route backup and configuration fingerprints. It does not require a global webserver switch.

Successful activation shows Varnish: active. The green state requires both a verified managed process and a successful HTTPS response through the cache route. A website simply returning HTTP 200 is insufficient.

Open Dashboard to check request counters, hit rate, traffic readings, memory, version and uptime. Use a logged-out request to a cacheable public post to confirm a MISS followed by a HIT. See the configuration guide.

6. Disable safely before removal

Use Disable caching and wait for the native direct route to be restored. Only then remove the website from the addon list. Removing it from the addon list does not delete its aaPanel website, files or database.

The installer refused uninstall while the native cache was configured in our live test. The website route and plugin files remained intact. This verifies the active-cache safeguard, not a complete clean uninstall/reinstall lifecycle.

Do not delete runtime files or manually stop dependencies while a managed public route still needs them. If a native configuration has changed, preserve it and resolve the conflict; do not overwrite it with an older backup merely to force removal.

Installation troubleshooting

Addon opens but activation is unavailable: Confirm the exact supported site, engine and WordPress template. Other sites remain outside native activation scope.

Enable rolls back: Inspect the private routing journal, Nginx validation and PHP/site errors. Confirm the original website still works.

PHP cannot read addon configuration: Preserve open_basedir. The corrected bridge embeds its installed key in the PHP-readable MU plugin; it does not require relaxing the restriction.

Quick re-enable reports an occupied private port: Allow graceful listener retirement; identify a real port owner before retrying. Do not kill an unknown process.

Uninstall is refused: Disable the managed native cache first and confirm direct routing.

Public release still requires portable dependency installation, additional native engine adapters, mixed-engine tests and lifecycle validation. Until then, use this procedure only within the explicitly prepared closed lab.

Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.

Guide series: Installation | WordPress configuration | Measured results]]> https://adminsforum.com/Thread-guide-install-varnish-for-wordpress-on-aapanel-tested-lab-guide Tue, 20 Oct 2026 15:56:55 +0800 DEV]]> https://adminsforum.com/Thread-guide-install-varnish-for-wordpress-on-aapanel-tested-lab-guide Tested 20 October 2026: real WordPress 7.1.3 with Varnish 9.1.0 on an Ubuntu 22.04 aaPanel lab.

This guide installs a separate WordPress/Varnish training stack using aaPanel's existing Nginx, PHP and database software. It shows package verification, installation, WordPress cache eligibility, exclusions, testing, manual invalidation and shutdown.

Scope matters: this is a manual, loopback-only lab setup. It does not enable caching on a registered aaPanel website, edit its vhost, install an aaPanel App Store plugin or create a production service. The AdminsForum addon preview remains a separate project. We are documenting a real WordPress test here rather than implying that selecting its WordPress template already connects a live site.



1. What you need before installation
- A disposable aaPanel training VPS or a recoverable lab snapshot, with root SSH access.
- Ubuntu 22.04 on amd64. These files deliberately target this declared environment, not every Linux distribution.
- Existing aaPanel Nginx at /www/server/nginx/sbin/nginx, PHP 8.5 with /tmp/php-cgi-85.sock, the panel Python environment and the MySQL/MariaDB client at /www/server/mysql/bin/mysql.
- Python 3, gpg/gpgv, dpkg-deb, gcc and the libraries required by the vendor's Ubuntu package. Our existing panel server already had them. Stop if package verification, dependency checks or config validation fail.
- Unused loopback ports 18190, 18191, 18192 and 18193, and sufficient disk/RAM for another test application. Our lab had 2 CPU cores and approximately 4 GB RAM; that is environment information, not a production sizing promise.

Keep the existing production sites and acceleration/WAF configuration in place. This exercise uses a separate process/configuration and does not need public DNS changes, firewall openings or moving aaPanel Nginx away from port 80/443.

2. Download and inspect the guide files

  wordpress-varnish-lab-guide-files-20261020.zip (Size: 9.79 KB / Downloads: 15)

The ZIP contains README.txt, setup-engine.py, setup-wordpress.py, runtime.py and verify-wordpress.py. Read them before running root commands. It contains no WordPress core archive, passwords, cookies, private keys, database dumps or existing-site configuration. It is example source for this training setup, not the preview addon's install ZIP.

Verify the downloaded ZIP locally or on the VPS:

Code:Copy

sha256sum wordpress-varnish-lab-guide-files-20261020.zip

Expected SHA-256:

Code:Copy

478b2b6e37034bcdabadd02c0ff6bd68d98c5663120a3446ccad05a6ec69e9aa

Extract it into a new private working folder and open README.txt. Keep all four scripts together. Do not rerun setup against an already-created lab or change only one hardcoded path: the scripts share the root /opt/af-wp-varnish-20261020, database name and port layout. An existing database or wp-config.php is a reason to stop and inspect, not to delete a working installation.

3. Install the supported Varnish engine privately
From the extracted guide folder, run:

Code:Copy

sudo python3 setup-engine.py

The script fetches the official vendor repository key, verifies its signed release metadata, verifies the package index checksum, then verifies the selected package checksum. It stages Varnish 9.1.0-2~jammy under the dedicated lab root using dpkg-deb extraction. It does not register a system package, start the distribution's default service or take over an existing listener.

Read the result: repository_signature_valid must be true and the version output must identify Varnish 9.1.0. This version was supported when this guide was checked. Recheck the official supported-release list when reproducing the exercise later; a pinned example is not an automatic security-update mechanism. Package extraction here intentionally keeps the panel's services independent.

Do not install the older Varnish 6.6.1 package used in our first synthetic addon benchmark just to match its screenshots. This WordPress exercise uses a newer, separately staged engine.

4. Prepare a separate WordPress application and database

Code:Copy

sudo python3 setup-wordpress.py

This downloads WordPress from wordpress.org, verifies its core file checksums against the WordPress API, and prepares a new application under the dedicated lab root. It creates only the named lab database af_wp_varnish_20261020 and a database user restricted to that database. To do this, it reads aaPanel's existing stored MySQL root credential locally; it does not print or send that credential to a website.

The script generates new random lab passwords and salts. The generated WordPress login details stay in the root-readable private-users.json on the VPS. Do not attach that file, wp-config.php or admin.secret to a support post. The lab disables outgoing WordPress mail and scheduled cron requests. Existing WordPress databases and users are not reused.

The setup result should report installed=true and the actual WordPress version. Our downloaded and verified version was 7.1.3. The script intentionally refuses to overwrite an existing configuration or an already-named database; resolve a failed/partial exercise by inspecting that dedicated lab, not by repeatedly rerunning setup blindly.

5. Generate and validate the isolated routing

Code:Copy

sudo install -m 0644 runtime.py /opt/af-wp-varnish-20261020/runtime.py sudo python3 /opt/af-wp-varnish-20261020/runtime.py prepare sudo python3 /opt/af-wp-varnish-20261020/runtime.py start

The start action validates Nginx and compiles VCL before starting the separate processes. The paths are:
- 127.0.0.1:18190: the front-end Nginx listener.
- 127.0.0.1:18192: Varnish cache.
- 127.0.0.1:18191: the origin Nginx, connected to aaPanel's PHP 8.5 socket and this WordPress installation.
- 127.0.0.1:18193: authenticated Varnish management. Its secret stays in the dedicated root; do not expose this listener.

The example allocates 64 MiB cache storage and small lab thread pools. Those are exercise settings, not production tuning recommendations. In this private example Varnish drops privileges to nobody/nogroup; a production service needs its own managed identity and lifecycle. No startup-on-reboot service is installed here.

6. Understand the WordPress configuration
WordPress is configured for http://127.0.0.1:18190. The small MU plugin added by setup explicitly permits short public caching only for anonymous front-page and post responses without query parameters. It does not mark every PHP response public.

The VCL passes requests with any cookie or Authorization header, non-GET/HEAD methods, queries, encoded paths and common WordPress administration/login/REST/cron/comment paths. Common cart, checkout and account paths also bypass. Responses with Set-Cookie, private/no-store/no-cache, errors or no positive explicitly public lifetime are not cached. Cached responses are capped at 60 seconds.

This conservative policy means a logged-in visitor bypasses even a normally public home page. Do not strip login or cart cookies to manufacture a better hit rate. Custom plugins, translated store paths, password-protected content, forms and personalized routes require application-specific review. WooCommerce was not installed in this test; the presence of cart-path exclusions is not a WooCommerce compatibility certification.

7. Verify a first MISS and a repeat HIT
Run these on the VPS, without browser cookies:

Code:Copy

curl -sS -D - -o /dev/null http://127.0.0.1:18190/ curl -sS -D - -o /dev/null http://127.0.0.1:18190/

Check HTTP 200 and X-AF-WP-Cache. A new eligible page should be MISS first and HIT when repeated before expiry. If another test already filled it, it may already be HIT. BYPASS means the request or response was excluded; it is not automatically an error. These diagnostic headers belong to this guide's configuration, not to every Varnish deployment.

To view the actual WordPress lab from your computer, create an SSH tunnel in a local terminal using your normal SSH account:

Code:Copy

ssh -L 18190:127.0.0.1:18190 YOUR_SSH_USER@YOUR_VPS

Keep that tunnel open, then open http://127.0.0.1:18190/ locally. If your local port is busy, resolve the conflict first; these example URLs and WordPress settings use the same port. There is no need to expose the remote lab to the internet.


Original screenshot of the actual WordPress installation viewed through a private SSH tunnel.

8. Verify private requests and two-user isolation
Run the provided validation script from the extracted guide folder:

Code:Copy

sudo python3 verify-wordpress.py

It uses the generated disposable users, creates a private session-check endpoint, changes the demonstration post and verifies the configured cache path. It does not benchmark a customer's site. Our recorded results were:
- Anonymous home: 200 MISS, then 200 HIT.
- Cookie, Authorization, login, REST, search query and POST requests: BYPASS.
- Missing page: 404 BYPASS; anonymous private session endpoint: 401 BYPASS.
- Two real WordPress users: each received its own identity and nonce; both logged-in home requests bypassed.
- Changed public content: the older cached copy remained until manual invalidation, then the new copy returned MISS followed by HIT.
- Public HTTP PURGE: 405 rejected.

Separate follow-up checks also verified expiry after the 60-second window and a restart of the isolated stack. These are functional application checks. We did not run a new WordPress speed benchmark and do not apply the earlier synthetic response-time percentages to this site.

9. Invalidate changed content
This example does not install automatic WordPress purge hooks. For the exact home-page URL in this single-host test instance, use the private management interface:

Code:Copy

sudo env LD_LIBRARY_PATH=/opt/af-wp-varnish-20261020/engine/usr/lib:/opt/af-wp-varnish-20261020/engine/usr/lib/x86_64-linux-gnu /opt/af-wp-varnish-20261020/engine/usr/bin/varnishadm -T 127.0.0.1:18193 -S /opt/af-wp-varnish-20261020/admin.secret ban 'req.url == /'

This management command adds an exact-URL ban for / in this dedicated instance; it is not a whole-site purge or a recursive wildcard. Repeat the curl checks to refill and verify the updated response. Other changed URLs need their own invalidation, and the public HTTP PURGE method remains disabled. Never treat editing a WordPress post as proof that every cache layer was cleared.

10. Stop the lab and understand the production boundary

Code:Copy

sudo python3 /opt/af-wp-varnish-20261020/runtime.py stop

This stops only the checked lab process IDs. The WordPress files, separate database, generated credentials and staged engine remain for inspection. There is no automatic destructive cleanup.

Our existing registered aaPanel vhost hashes stayed unchanged. This exercise did not test public HTTPS, WooCommerce, a real-domain aaPanel vhost adapter, reboot persistence, panel-generated config changes, certificate renewal or live-site uninstall. Connecting an existing domain needs a separately validated integration with its actual routing, trusted TLS forwarding, backups and rollback. Do not move a working site's ports or replace its aaPanel-generated configuration using these loopback examples.

Related: Addon preview controls and exclusions; cache tuning and troubleshooting.

Primary references: Varnish's official Ubuntu installation source; supported Varnish releases; WordPress performance and caching guidance.

Copyright AdminsForum | adminsforum.com. Original lab evidence; scope and limitations are stated above.

  wordpress-varnish-architecture-20261020.png (Size: 123.21 KB / Downloads: 21)

  wordpress-varnish-site-20261020.jpg (Size: 109 KB / Downloads: 20) ]]> Tested 20 October 2026: real WordPress 7.1.3 with Varnish 9.1.0 on an Ubuntu 22.04 aaPanel lab.

This guide installs a separate WordPress/Varnish training stack using aaPanel's existing Nginx, PHP and database software. It shows package verification, installation, WordPress cache eligibility, exclusions, testing, manual invalidation and shutdown.

Scope matters: this is a manual, loopback-only lab setup. It does not enable caching on a registered aaPanel website, edit its vhost, install an aaPanel App Store plugin or create a production service. The AdminsForum addon preview remains a separate project. We are documenting a real WordPress test here rather than implying that selecting its WordPress template already connects a live site.



1. What you need before installation
- A disposable aaPanel training VPS or a recoverable lab snapshot, with root SSH access.
- Ubuntu 22.04 on amd64. These files deliberately target this declared environment, not every Linux distribution.
- Existing aaPanel Nginx at /www/server/nginx/sbin/nginx, PHP 8.5 with /tmp/php-cgi-85.sock, the panel Python environment and the MySQL/MariaDB client at /www/server/mysql/bin/mysql.
- Python 3, gpg/gpgv, dpkg-deb, gcc and the libraries required by the vendor's Ubuntu package. Our existing panel server already had them. Stop if package verification, dependency checks or config validation fail.
- Unused loopback ports 18190, 18191, 18192 and 18193, and sufficient disk/RAM for another test application. Our lab had 2 CPU cores and approximately 4 GB RAM; that is environment information, not a production sizing promise.

Keep the existing production sites and acceleration/WAF configuration in place. This exercise uses a separate process/configuration and does not need public DNS changes, firewall openings or moving aaPanel Nginx away from port 80/443.

2. Download and inspect the guide files

  wordpress-varnish-lab-guide-files-20261020.zip (Size: 9.79 KB / Downloads: 15)

The ZIP contains README.txt, setup-engine.py, setup-wordpress.py, runtime.py and verify-wordpress.py. Read them before running root commands. It contains no WordPress core archive, passwords, cookies, private keys, database dumps or existing-site configuration. It is example source for this training setup, not the preview addon's install ZIP.

Verify the downloaded ZIP locally or on the VPS:

Code:Copy

sha256sum wordpress-varnish-lab-guide-files-20261020.zip

Expected SHA-256:

Code:Copy

478b2b6e37034bcdabadd02c0ff6bd68d98c5663120a3446ccad05a6ec69e9aa

Extract it into a new private working folder and open README.txt. Keep all four scripts together. Do not rerun setup against an already-created lab or change only one hardcoded path: the scripts share the root /opt/af-wp-varnish-20261020, database name and port layout. An existing database or wp-config.php is a reason to stop and inspect, not to delete a working installation.

3. Install the supported Varnish engine privately
From the extracted guide folder, run:

Code:Copy

sudo python3 setup-engine.py

The script fetches the official vendor repository key, verifies its signed release metadata, verifies the package index checksum, then verifies the selected package checksum. It stages Varnish 9.1.0-2~jammy under the dedicated lab root using dpkg-deb extraction. It does not register a system package, start the distribution's default service or take over an existing listener.

Read the result: repository_signature_valid must be true and the version output must identify Varnish 9.1.0. This version was supported when this guide was checked. Recheck the official supported-release list when reproducing the exercise later; a pinned example is not an automatic security-update mechanism. Package extraction here intentionally keeps the panel's services independent.

Do not install the older Varnish 6.6.1 package used in our first synthetic addon benchmark just to match its screenshots. This WordPress exercise uses a newer, separately staged engine.

4. Prepare a separate WordPress application and database

Code:Copy

sudo python3 setup-wordpress.py

This downloads WordPress from wordpress.org, verifies its core file checksums against the WordPress API, and prepares a new application under the dedicated lab root. It creates only the named lab database af_wp_varnish_20261020 and a database user restricted to that database. To do this, it reads aaPanel's existing stored MySQL root credential locally; it does not print or send that credential to a website.

The script generates new random lab passwords and salts. The generated WordPress login details stay in the root-readable private-users.json on the VPS. Do not attach that file, wp-config.php or admin.secret to a support post. The lab disables outgoing WordPress mail and scheduled cron requests. Existing WordPress databases and users are not reused.

The setup result should report installed=true and the actual WordPress version. Our downloaded and verified version was 7.1.3. The script intentionally refuses to overwrite an existing configuration or an already-named database; resolve a failed/partial exercise by inspecting that dedicated lab, not by repeatedly rerunning setup blindly.

5. Generate and validate the isolated routing

Code:Copy

sudo install -m 0644 runtime.py /opt/af-wp-varnish-20261020/runtime.py sudo python3 /opt/af-wp-varnish-20261020/runtime.py prepare sudo python3 /opt/af-wp-varnish-20261020/runtime.py start

The start action validates Nginx and compiles VCL before starting the separate processes. The paths are:
- 127.0.0.1:18190: the front-end Nginx listener.
- 127.0.0.1:18192: Varnish cache.
- 127.0.0.1:18191: the origin Nginx, connected to aaPanel's PHP 8.5 socket and this WordPress installation.
- 127.0.0.1:18193: authenticated Varnish management. Its secret stays in the dedicated root; do not expose this listener.

The example allocates 64 MiB cache storage and small lab thread pools. Those are exercise settings, not production tuning recommendations. In this private example Varnish drops privileges to nobody/nogroup; a production service needs its own managed identity and lifecycle. No startup-on-reboot service is installed here.

6. Understand the WordPress configuration
WordPress is configured for http://127.0.0.1:18190. The small MU plugin added by setup explicitly permits short public caching only for anonymous front-page and post responses without query parameters. It does not mark every PHP response public.

The VCL passes requests with any cookie or Authorization header, non-GET/HEAD methods, queries, encoded paths and common WordPress administration/login/REST/cron/comment paths. Common cart, checkout and account paths also bypass. Responses with Set-Cookie, private/no-store/no-cache, errors or no positive explicitly public lifetime are not cached. Cached responses are capped at 60 seconds.

This conservative policy means a logged-in visitor bypasses even a normally public home page. Do not strip login or cart cookies to manufacture a better hit rate. Custom plugins, translated store paths, password-protected content, forms and personalized routes require application-specific review. WooCommerce was not installed in this test; the presence of cart-path exclusions is not a WooCommerce compatibility certification.

7. Verify a first MISS and a repeat HIT
Run these on the VPS, without browser cookies:

Code:Copy

curl -sS -D - -o /dev/null http://127.0.0.1:18190/ curl -sS -D - -o /dev/null http://127.0.0.1:18190/

Check HTTP 200 and X-AF-WP-Cache. A new eligible page should be MISS first and HIT when repeated before expiry. If another test already filled it, it may already be HIT. BYPASS means the request or response was excluded; it is not automatically an error. These diagnostic headers belong to this guide's configuration, not to every Varnish deployment.

To view the actual WordPress lab from your computer, create an SSH tunnel in a local terminal using your normal SSH account:

Code:Copy

ssh -L 18190:127.0.0.1:18190 YOUR_SSH_USER@YOUR_VPS

Keep that tunnel open, then open http://127.0.0.1:18190/ locally. If your local port is busy, resolve the conflict first; these example URLs and WordPress settings use the same port. There is no need to expose the remote lab to the internet.


Original screenshot of the actual WordPress installation viewed through a private SSH tunnel.

8. Verify private requests and two-user isolation
Run the provided validation script from the extracted guide folder:

Code:Copy

sudo python3 verify-wordpress.py

It uses the generated disposable users, creates a private session-check endpoint, changes the demonstration post and verifies the configured cache path. It does not benchmark a customer's site. Our recorded results were:
- Anonymous home: 200 MISS, then 200 HIT.
- Cookie, Authorization, login, REST, search query and POST requests: BYPASS.
- Missing page: 404 BYPASS; anonymous private session endpoint: 401 BYPASS.
- Two real WordPress users: each received its own identity and nonce; both logged-in home requests bypassed.
- Changed public content: the older cached copy remained until manual invalidation, then the new copy returned MISS followed by HIT.
- Public HTTP PURGE: 405 rejected.

Separate follow-up checks also verified expiry after the 60-second window and a restart of the isolated stack. These are functional application checks. We did not run a new WordPress speed benchmark and do not apply the earlier synthetic response-time percentages to this site.

9. Invalidate changed content
This example does not install automatic WordPress purge hooks. For the exact home-page URL in this single-host test instance, use the private management interface:

Code:Copy

sudo env LD_LIBRARY_PATH=/opt/af-wp-varnish-20261020/engine/usr/lib:/opt/af-wp-varnish-20261020/engine/usr/lib/x86_64-linux-gnu /opt/af-wp-varnish-20261020/engine/usr/bin/varnishadm -T 127.0.0.1:18193 -S /opt/af-wp-varnish-20261020/admin.secret ban 'req.url == /'

This management command adds an exact-URL ban for / in this dedicated instance; it is not a whole-site purge or a recursive wildcard. Repeat the curl checks to refill and verify the updated response. Other changed URLs need their own invalidation, and the public HTTP PURGE method remains disabled. Never treat editing a WordPress post as proof that every cache layer was cleared.

10. Stop the lab and understand the production boundary

Code:Copy

sudo python3 /opt/af-wp-varnish-20261020/runtime.py stop

This stops only the checked lab process IDs. The WordPress files, separate database, generated credentials and staged engine remain for inspection. There is no automatic destructive cleanup.

Our existing registered aaPanel vhost hashes stayed unchanged. This exercise did not test public HTTPS, WooCommerce, a real-domain aaPanel vhost adapter, reboot persistence, panel-generated config changes, certificate renewal or live-site uninstall. Connecting an existing domain needs a separately validated integration with its actual routing, trusted TLS forwarding, backups and rollback. Do not move a working site's ports or replace its aaPanel-generated configuration using these loopback examples.

Related: Addon preview controls and exclusions; cache tuning and troubleshooting.

Primary references: Varnish's official Ubuntu installation source; supported Varnish releases; WordPress performance and caching guidance.

Copyright AdminsForum | adminsforum.com. Original lab evidence; scope and limitations are stated above.

  wordpress-varnish-architecture-20261020.png (Size: 123.21 KB / Downloads: 21)

  wordpress-varnish-site-20261020.jpg (Size: 109 KB / Downloads: 20) ]]> https://adminsforum.com/Thread-guide-fine-tune-varnish-cache-hit-rate-memory-and-troubleshooting Tue, 20 Oct 2026 15:31:53 +0800 DEV]]> https://adminsforum.com/Thread-guide-fine-tune-varnish-cache-hit-rate-memory-and-troubleshooting Measured tuning workflow for Varnish Cache by Adminforum 0.5.0 lab preview. Reviewed 20 October 2026.

Fine-tuning starts with correct content and repeatable measurements. A high hit percentage is not useful if someone receives the wrong account page, sees stale prices or loses access to a website. This guide explains the observations available now and separates them from settings planned for a later release.

Start here: Configuration, templates and exclusions walkthrough.

1. Know which settings are adjustable
In the current addon you can select a path template, add exclusions, enable or disable fixture caching, purge one exact URL and read the available counters/logs.

Cache allocation is fixed at 32 MiB. The maximum positive public-response lifetime is 60 seconds. Grace is explicitly zero. There is no memory, TTL, grace, worker-thread or timeout editor in this release. These values describe the synthetic fixture; they are not recommended production settings. Do not edit generated VCL or daemon arguments behind the addon and assume it will retain or validate those edits.

2. Record a baseline before changing policy
Use a repeatable, anonymous public page and a consistent client, concurrency and request headers. Record direct responses, cold misses and prefilled warm hits separately. Include errors and p95, not just the fastest response. Keep PHP/database/CDN changes out of the comparison so the cause is clear.

Our before-and-after lab report measured 1,440 successful requests. At concurrency 1, direct mean was 1.707 ms, cold MISS 2.651 ms and warm HIT 0.896 ms. At concurrency 4, direct mean was 5.906 ms, cold MISS 6.671 ms and warm HIT 3.350 ms. Compare within the same concurrency group. Those tiny loopback timings are not browser load times or production capacity estimates.

3. Diagnose low hit rate before allocating more memory
Refresh Overview, then inspect Access Logs. Classify the outcome:
- Mostly BYPASS: inspect cookies, authorization, private-response headers, query strings and exclusions. Extra memory will not turn an intentionally private response into a cacheable page.
- Mostly MISS on distinct URLs: new objects need an initial fill. Repeating the same eligible URL is the first useful check.
- MISS after expiry, a purge or a rules update: this may be expected. Rules updates create a new cache namespace.
- Repeated MISS on the same URL before expected expiry: check response eligibility, variant headers, actual host/scheme, intervening restarts and evictions.
- No request rows: confirm caching is enabled, the request reaches the test instance and logs were refreshed. Direct routing does not appear in Varnish's request sample.

The displayed hit ratio uses HIT / (HIT + MISS), excluding bypassed traffic. For example, 80 hits and 20 misses gives 80%, even if another 900 requests bypassed. Do not describe that figure as the percentage of all website visitors served from cache. Counters reset when the Varnish child restarts; compare counter differences over a known interval rather than unrelated totals.

4. Read memory and eviction figures correctly
Open Storage after starting the fixture. Read allocated storage, limit, cached objects and evictions together.


These figures belong to the dedicated test instance. They are not per-domain disk usage.

The 32 MiB cache allocation is not a cap on total process memory. Process RSS is shown separately and includes more than cached response bodies. Leave room for the operating system, PHP workers, database, webserver and Varnish overhead when planning a later deployment. Varnish's storage documentation explains the additional allocations and allocator overhead; choosing a cache size equal to all free RAM is not a sizing method.

A growing eviction counter means objects have been evicted to make room. Record the increase during a representative workload. If useful frequently requested objects are evicted before reuse, capacity or the cached object mix deserves investigation. A single nonzero lifetime counter is not proof that the cache is too small. If objects expire before being reused, simply increasing capacity may not help.

5. Balance freshness with cache lifetime
TTL is the period a cached object can normally remain fresh. A longer value can reduce origin fetches but can also keep old public content visible longer unless it is invalidated. Determine how quickly a changed article, price, availability or announcement must appear before choosing a policy.

In this preview, successful explicitly public responses need a positive lifetime and are capped at 60 seconds. The addon does not give you a field to increase it. Test a changed public response with the exact-URL purge control and confirm that the next request gets the new content. A full-site purge and automatic WordPress invalidation are not implemented. Do not promise immediate updates across a whole site from a single-path purge.

6. Understand grace before requesting it
Varnish supports grace: eligible stale content can be served for an additional period while a fresh version is fetched. Keep has a different purpose: retaining an object for conditional revalidation. These are content-freshness choices, not universal speed switches. This addon currently sets grace to zero; it does not expose or validate a production stale-content policy. Consider such a feature only after its behavior and acceptable staleness have been tested for the application.

7. Tune the origin when misses are slow
If direct and MISS requests are slow while HIT is fast, investigate the work still required at the origin. Correlate the same time window with PHP slow requests, database slow queries, CPU, available RAM, swap activity and storage I/O. A Varnish HIT avoids that work for an eligible cached response; it does not repair slow authenticated pages or unsafe application queries.

Do not apply a universal PHP worker count or database buffer size from this guide. Measure the application's worker memory, database working set and server capacity first. Make one change at a time and compare the same workload, including errors. If direct requests are already fast, cold-cache overhead may exceed any benefit for a rarely reused URL.

8. Use errors and logs to choose the next action
- 4xx: check the requested path, access restrictions and application response. Do not disable private-page rules to hide an authorization error.
- 5xx: check the origin and relevant web/PHP error logs, then correlate with addon Activity. The addon Error Logs tab is a sample, not the full server log.
- Online - fallback / Needs attention: disable fixture caching, verify direct routing, then investigate the cache service. Availability and active caching are separate checks.
- Template did not save: read the validation message, correct unsupported path syntax, then apply and refresh. Do not assume a failed save changed the active policy.

9. Re-test privacy after each policy change
Check anonymous public pages, logged-in pages, two independent test users, cart/account/checkout pages, APIs, query-string URLs and responses that set cookies. Use disposable sessions and never publish their headers. Our existing fixture checks prove synthetic bypass behavior; real WordPress/WooCommerce and Laravel session isolation remain release gates. Template names alone are not proof of compatibility.

10. Keep a small change record

Code:Copy

Date and component versions: Test scope and application: One setting changed: Direct / cold MISS / warm HIT: Requests, concurrency, errors, mean and p95: HIT/MISS/BYPASS counts and interval: Objects, allocation, eviction increase and RSS: Privacy and content-update checks: Rollback result:

Retain the change only when it improves the intended workload without correctness or availability regressions. Stop the isolated test website after the exercise. Public deployment also needs a supported engine, tested installer, real-site routing and recovery; this preview is not that release.

References: Varnish storage backends; grace and keep.

Original AdminsForum lab screenshot. Copyright AdminsForum | adminsforum.com.

  varnish-guide-storage-20261020.jpg (Size: 103.83 KB / Downloads: 17) ]]> Measured tuning workflow for Varnish Cache by Adminforum 0.5.0 lab preview. Reviewed 20 October 2026.

Fine-tuning starts with correct content and repeatable measurements. A high hit percentage is not useful if someone receives the wrong account page, sees stale prices or loses access to a website. This guide explains the observations available now and separates them from settings planned for a later release.

Start here: Configuration, templates and exclusions walkthrough.

1. Know which settings are adjustable
In the current addon you can select a path template, add exclusions, enable or disable fixture caching, purge one exact URL and read the available counters/logs.

Cache allocation is fixed at 32 MiB. The maximum positive public-response lifetime is 60 seconds. Grace is explicitly zero. There is no memory, TTL, grace, worker-thread or timeout editor in this release. These values describe the synthetic fixture; they are not recommended production settings. Do not edit generated VCL or daemon arguments behind the addon and assume it will retain or validate those edits.

2. Record a baseline before changing policy
Use a repeatable, anonymous public page and a consistent client, concurrency and request headers. Record direct responses, cold misses and prefilled warm hits separately. Include errors and p95, not just the fastest response. Keep PHP/database/CDN changes out of the comparison so the cause is clear.

Our before-and-after lab report measured 1,440 successful requests. At concurrency 1, direct mean was 1.707 ms, cold MISS 2.651 ms and warm HIT 0.896 ms. At concurrency 4, direct mean was 5.906 ms, cold MISS 6.671 ms and warm HIT 3.350 ms. Compare within the same concurrency group. Those tiny loopback timings are not browser load times or production capacity estimates.

3. Diagnose low hit rate before allocating more memory
Refresh Overview, then inspect Access Logs. Classify the outcome:
- Mostly BYPASS: inspect cookies, authorization, private-response headers, query strings and exclusions. Extra memory will not turn an intentionally private response into a cacheable page.
- Mostly MISS on distinct URLs: new objects need an initial fill. Repeating the same eligible URL is the first useful check.
- MISS after expiry, a purge or a rules update: this may be expected. Rules updates create a new cache namespace.
- Repeated MISS on the same URL before expected expiry: check response eligibility, variant headers, actual host/scheme, intervening restarts and evictions.
- No request rows: confirm caching is enabled, the request reaches the test instance and logs were refreshed. Direct routing does not appear in Varnish's request sample.

The displayed hit ratio uses HIT / (HIT + MISS), excluding bypassed traffic. For example, 80 hits and 20 misses gives 80%, even if another 900 requests bypassed. Do not describe that figure as the percentage of all website visitors served from cache. Counters reset when the Varnish child restarts; compare counter differences over a known interval rather than unrelated totals.

4. Read memory and eviction figures correctly
Open Storage after starting the fixture. Read allocated storage, limit, cached objects and evictions together.


These figures belong to the dedicated test instance. They are not per-domain disk usage.

The 32 MiB cache allocation is not a cap on total process memory. Process RSS is shown separately and includes more than cached response bodies. Leave room for the operating system, PHP workers, database, webserver and Varnish overhead when planning a later deployment. Varnish's storage documentation explains the additional allocations and allocator overhead; choosing a cache size equal to all free RAM is not a sizing method.

A growing eviction counter means objects have been evicted to make room. Record the increase during a representative workload. If useful frequently requested objects are evicted before reuse, capacity or the cached object mix deserves investigation. A single nonzero lifetime counter is not proof that the cache is too small. If objects expire before being reused, simply increasing capacity may not help.

5. Balance freshness with cache lifetime
TTL is the period a cached object can normally remain fresh. A longer value can reduce origin fetches but can also keep old public content visible longer unless it is invalidated. Determine how quickly a changed article, price, availability or announcement must appear before choosing a policy.

In this preview, successful explicitly public responses need a positive lifetime and are capped at 60 seconds. The addon does not give you a field to increase it. Test a changed public response with the exact-URL purge control and confirm that the next request gets the new content. A full-site purge and automatic WordPress invalidation are not implemented. Do not promise immediate updates across a whole site from a single-path purge.

6. Understand grace before requesting it
Varnish supports grace: eligible stale content can be served for an additional period while a fresh version is fetched. Keep has a different purpose: retaining an object for conditional revalidation. These are content-freshness choices, not universal speed switches. This addon currently sets grace to zero; it does not expose or validate a production stale-content policy. Consider such a feature only after its behavior and acceptable staleness have been tested for the application.

7. Tune the origin when misses are slow
If direct and MISS requests are slow while HIT is fast, investigate the work still required at the origin. Correlate the same time window with PHP slow requests, database slow queries, CPU, available RAM, swap activity and storage I/O. A Varnish HIT avoids that work for an eligible cached response; it does not repair slow authenticated pages or unsafe application queries.

Do not apply a universal PHP worker count or database buffer size from this guide. Measure the application's worker memory, database working set and server capacity first. Make one change at a time and compare the same workload, including errors. If direct requests are already fast, cold-cache overhead may exceed any benefit for a rarely reused URL.

8. Use errors and logs to choose the next action
- 4xx: check the requested path, access restrictions and application response. Do not disable private-page rules to hide an authorization error.
- 5xx: check the origin and relevant web/PHP error logs, then correlate with addon Activity. The addon Error Logs tab is a sample, not the full server log.
- Online - fallback / Needs attention: disable fixture caching, verify direct routing, then investigate the cache service. Availability and active caching are separate checks.
- Template did not save: read the validation message, correct unsupported path syntax, then apply and refresh. Do not assume a failed save changed the active policy.

9. Re-test privacy after each policy change
Check anonymous public pages, logged-in pages, two independent test users, cart/account/checkout pages, APIs, query-string URLs and responses that set cookies. Use disposable sessions and never publish their headers. Our existing fixture checks prove synthetic bypass behavior; real WordPress/WooCommerce and Laravel session isolation remain release gates. Template names alone are not proof of compatibility.

10. Keep a small change record

Code:Copy

Date and component versions: Test scope and application: One setting changed: Direct / cold MISS / warm HIT: Requests, concurrency, errors, mean and p95: HIT/MISS/BYPASS counts and interval: Objects, allocation, eviction increase and RSS: Privacy and content-update checks: Rollback result:

Retain the change only when it improves the intended workload without correctness or availability regressions. Stop the isolated test website after the exercise. Public deployment also needs a supported engine, tested installer, real-site routing and recovery; this preview is not that release.

References: Varnish storage backends; grace and keep.

Original AdminsForum lab screenshot. Copyright AdminsForum | adminsforum.com.

  varnish-guide-storage-20261020.jpg (Size: 103.83 KB / Downloads: 17) ]]> https://adminsforum.com/Thread-guide-configure-varnish-cache-in-aapanel-controls-and-exclusions Tue, 20 Oct 2026 15:30:36 +0800 DEV]]> https://adminsforum.com/Thread-guide-configure-varnish-cache-in-aapanel-controls-and-exclusions 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:Copy

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:Copy

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:Copy

systemctl status af-varnish-native-11.service --no-pager journalctl -u af-varnish-native-11.service -n 50 --no-pager

Review 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.

  varnish-guide-overview-20261020.jpg (Size: 112.28 KB / Downloads: 27)

  varnish-guide-exclusions-20261020.jpg (Size: 138.26 KB / Downloads: 97)

  varnish-guide-controls-20261020.jpg (Size: 104.63 KB / Downloads: 24)

  varnish-guide-logs-20261020.jpg (Size: 118.15 KB / Downloads: 23) ]]> 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:Copy

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:Copy

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:Copy

systemctl status af-varnish-native-11.service --no-pager journalctl -u af-varnish-native-11.service -n 50 --no-pager

Review 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.

  varnish-guide-overview-20261020.jpg (Size: 112.28 KB / Downloads: 27)

  varnish-guide-exclusions-20261020.jpg (Size: 138.26 KB / Downloads: 97)

  varnish-guide-controls-20261020.jpg (Size: 104.63 KB / Downloads: 24)

  varnish-guide-logs-20261020.jpg (Size: 118.15 KB / Downloads: 23) ]]> https://adminsforum.com/Thread-guide-varnish-cache-before-and-after-aapanel-lab-test-results Tue, 20 Oct 2026 15:15:50 +0800 DEV]]> https://adminsforum.com/Thread-guide-varnish-cache-before-and-after-aapanel-lab-test-results Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.

On 24 October 2026, the current managed WordPress/Nginx lab integration passed 38 application checks, plus 3 installation-safeguard checks. The current-source backend suite passed 161 tests; the frontend suite passed 38 checks. These are separate suites, not counts of independent websites or server modes.

The website was left added and enabled after testing. The disposable application fixtures were moved to WordPress Trash, and the other Nginx/Apache website configuration files were unchanged. Postfix and Dovecot remained active; this checks service state, not end-to-end mail delivery.

Environment

Website: blog.adminslab.com — isolated test site

Operating system: Ubuntu 22.04 VPS, 2 CPU cores, approximately 4 GiB RAM

aaPanel: 8.0.7

Assigned website server: Nginx 1.30.6

PHP: 8.5.12

WordPress: 7.1.3

Varnish: 9.1.0

Cache policy: Public homepage/posts, up to 30 seconds; 32 MiB capacity

WooCommerce: Not installed

Before and after response times

Code:Copy

Local verified HTTPS Requests Median ms p95 ms Direct WordPress 30 142.298 171.835 Warm Varnish HIT 30 7.772 12.075 Cold Varnish MISS 10 132.968 156.915

Native WordPress, cache disabled
Requests: 30
Expected response: DIRECT
Median: 142.298 ms
p95: 171.835 ms

Varnish, warmed public post
Requests: 30
Expected response: HIT
Median: 7.772 ms
p95: 12.075 ms

Varnish, exact post purged before each request
Requests: 10
Expected response: MISS
Median: 132.968 ms
p95: 156.915 ms

Warm-cache median complete response time was 94.5% lower than the direct median in this sample. This is a local lab comparison, not a promise of the same reduction for visitors.

Measurement method

The test requested the same newly published public WordPress post through verified HTTPS on the VPS's loopback connection using the real hostname. Every measured request opened a new connection and read the complete response; timings include TLS setup. Requests were sequential. The p95 uses the nearest-rank method.

The direct phase disabled the managed route and verified the exact original configuration. The warm phase restored caching and warmed the public post before measuring. The cold phase purged that exact path before each request. Each measured response had to return HTTP 200 with the expected DIRECT, HIT or MISS marker. Dashboard live polling was paused during the measurements.

This is not an internet-latency, browser-rendering, throughput, sustained-load or high-concurrency benchmark. Test order and normal server variation can affect results. The slightly lower cold-MISS median than direct does not establish that misses are faster; both execute the origin application and their small difference needs broader controlled measurements.

Application and privacy results

Draft publication: Anonymous draft request was unavailable; published post returned MISS then HIT.

Content update: A real WordPress post update invalidated the old cached content automatically.

Comment edit: Editing a stored approved comment invalidated the post cache.

Public response headers: Cached public post did not carry Set-Cookie.

Two real accounts: Both existing test readers logged in and received their own uncached profile pages.

Concurrent identity isolation: 12 interleaved profile requests across two users and four workers retained the correct user identity. This is a small functional check, not a load benchmark.

Nonces: The two profile pages had distinct nonces.

Exclusions: Cookies, Authorization, search, REST API, admin, POST, cart/account/checkout paths bypassed.

Private content: A new private post was not exposed anonymously or served as a HIT.

Purge protection: Public PURGE/BAN were rejected; an invalid private purge key was rejected.

Trash invalidation: Trashing the disposable public post removed its cached public content.

Coexistence: Other checked Nginx/Apache vhost files stayed byte-identical; Nginx validation passed and mail services remained active.

Final state: The managed cache remained enabled and verified active.

The cart/account/checkout checks exercised excluded paths on a site without WooCommerce. They do not establish shopping-cart, payment or store-plugin compatibility.

Installation safeguards

The installed control-file validation completed without changing the active public website route. Attempting uninstall while the native cache was configured returned the expected refusal. The plugin files and native route were preserved.

This tests a guard, not a successful clean uninstall/reinstall. The current build still depends on the prepared lab runtime.

Earlier on the same day, a separate 29-check managed lifecycle run passed exact direct-route restoration, re-enable, stopped-cache fallback and recovery. Those earlier lifecycle results are distinct from the new 38-check application run; they should not be presented as newly retested behavior where it was not repeated.

What remains before public beta

WordPress on this audited Nginx lab site: Application and managed lifecycle evidence available

Other Nginx sites / portable site onboarding: Not validated; current target is restricted in code

Native Apache, OpenLiteSpeed, Nginx + Apache, Nginx + OpenLiteSpeed: Adapters/live compatibility not established

Mixed-engine cached websites: Not established

WooCommerce cart/session/payment journey: Not tested; WooCommerce absent

Browser editor and public comment submission: Not exercised by this API-based application run

Native access/error log views and persistent traffic history: Not connected; live chart is a browser-session buffer

Clean-server install, upgrade, successful uninstall/reinstall: Not established by this run

Reboot, certificate renewal, native engine/PHP switching: Not exercised

Sustained traffic and resource-pressure testing: Not performed

Release decision: keep this build in the closed lab programme. The results support further development and targeted testing; they do not approve a general aaPanel beta release.

Evidence and reproduction

The companion sanitized results summary (the measured values are reproduced in this report) records the measured values, suite counts and limits. The reproducible test source and private raw timing evidence are retained with our lab records. The test is fixed to this lab; it is not a portable installer.

Private detailed results, raw timing samples and any diagnostics are retained on the lab under the operator's test-evidence directory. Credentials, cookies, nonces and private PHP errors are not included in this guide bundle.

Official architecture reference: aaPanel Multi-WebServer Hosting. This describes aaPanel's server choices, not compatibility certification for our addon.

Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.

Guide series: Installation | WordPress configuration | Measured results

Historical attachments dated 20 October below belong to the older synthetic fixture run. They are retained as earlier evidence and are not the raw samples for the 24 October WordPress measurements above.

  varnish-before-after-results-20261020.png (Size: 135.15 KB / Downloads: 23)

  varnish-before-after-data-20261020.zip (Size: 17.82 KB / Downloads: 15) ]]> Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.

On 24 October 2026, the current managed WordPress/Nginx lab integration passed 38 application checks, plus 3 installation-safeguard checks. The current-source backend suite passed 161 tests; the frontend suite passed 38 checks. These are separate suites, not counts of independent websites or server modes.

The website was left added and enabled after testing. The disposable application fixtures were moved to WordPress Trash, and the other Nginx/Apache website configuration files were unchanged. Postfix and Dovecot remained active; this checks service state, not end-to-end mail delivery.

Environment

Website: blog.adminslab.com — isolated test site

Operating system: Ubuntu 22.04 VPS, 2 CPU cores, approximately 4 GiB RAM

aaPanel: 8.0.7

Assigned website server: Nginx 1.30.6

PHP: 8.5.12

WordPress: 7.1.3

Varnish: 9.1.0

Cache policy: Public homepage/posts, up to 30 seconds; 32 MiB capacity

WooCommerce: Not installed

Before and after response times

Code:Copy

Local verified HTTPS Requests Median ms p95 ms Direct WordPress 30 142.298 171.835 Warm Varnish HIT 30 7.772 12.075 Cold Varnish MISS 10 132.968 156.915

Native WordPress, cache disabled
Requests: 30
Expected response: DIRECT
Median: 142.298 ms
p95: 171.835 ms

Varnish, warmed public post
Requests: 30
Expected response: HIT
Median: 7.772 ms
p95: 12.075 ms

Varnish, exact post purged before each request
Requests: 10
Expected response: MISS
Median: 132.968 ms
p95: 156.915 ms

Warm-cache median complete response time was 94.5% lower than the direct median in this sample. This is a local lab comparison, not a promise of the same reduction for visitors.

Measurement method

The test requested the same newly published public WordPress post through verified HTTPS on the VPS's loopback connection using the real hostname. Every measured request opened a new connection and read the complete response; timings include TLS setup. Requests were sequential. The p95 uses the nearest-rank method.

The direct phase disabled the managed route and verified the exact original configuration. The warm phase restored caching and warmed the public post before measuring. The cold phase purged that exact path before each request. Each measured response had to return HTTP 200 with the expected DIRECT, HIT or MISS marker. Dashboard live polling was paused during the measurements.

This is not an internet-latency, browser-rendering, throughput, sustained-load or high-concurrency benchmark. Test order and normal server variation can affect results. The slightly lower cold-MISS median than direct does not establish that misses are faster; both execute the origin application and their small difference needs broader controlled measurements.

Application and privacy results

Draft publication: Anonymous draft request was unavailable; published post returned MISS then HIT.

Content update: A real WordPress post update invalidated the old cached content automatically.

Comment edit: Editing a stored approved comment invalidated the post cache.

Public response headers: Cached public post did not carry Set-Cookie.

Two real accounts: Both existing test readers logged in and received their own uncached profile pages.

Concurrent identity isolation: 12 interleaved profile requests across two users and four workers retained the correct user identity. This is a small functional check, not a load benchmark.

Nonces: The two profile pages had distinct nonces.

Exclusions: Cookies, Authorization, search, REST API, admin, POST, cart/account/checkout paths bypassed.

Private content: A new private post was not exposed anonymously or served as a HIT.

Purge protection: Public PURGE/BAN were rejected; an invalid private purge key was rejected.

Trash invalidation: Trashing the disposable public post removed its cached public content.

Coexistence: Other checked Nginx/Apache vhost files stayed byte-identical; Nginx validation passed and mail services remained active.

Final state: The managed cache remained enabled and verified active.

The cart/account/checkout checks exercised excluded paths on a site without WooCommerce. They do not establish shopping-cart, payment or store-plugin compatibility.

Installation safeguards

The installed control-file validation completed without changing the active public website route. Attempting uninstall while the native cache was configured returned the expected refusal. The plugin files and native route were preserved.

This tests a guard, not a successful clean uninstall/reinstall. The current build still depends on the prepared lab runtime.

Earlier on the same day, a separate 29-check managed lifecycle run passed exact direct-route restoration, re-enable, stopped-cache fallback and recovery. Those earlier lifecycle results are distinct from the new 38-check application run; they should not be presented as newly retested behavior where it was not repeated.

What remains before public beta

WordPress on this audited Nginx lab site: Application and managed lifecycle evidence available

Other Nginx sites / portable site onboarding: Not validated; current target is restricted in code

Native Apache, OpenLiteSpeed, Nginx + Apache, Nginx + OpenLiteSpeed: Adapters/live compatibility not established

Mixed-engine cached websites: Not established

WooCommerce cart/session/payment journey: Not tested; WooCommerce absent

Browser editor and public comment submission: Not exercised by this API-based application run

Native access/error log views and persistent traffic history: Not connected; live chart is a browser-session buffer

Clean-server install, upgrade, successful uninstall/reinstall: Not established by this run

Reboot, certificate renewal, native engine/PHP switching: Not exercised

Sustained traffic and resource-pressure testing: Not performed

Release decision: keep this build in the closed lab programme. The results support further development and targeted testing; they do not approve a general aaPanel beta release.

Evidence and reproduction

The companion sanitized results summary (the measured values are reproduced in this report) records the measured values, suite counts and limits. The reproducible test source and private raw timing evidence are retained with our lab records. The test is fixed to this lab; it is not a portable installer.

Private detailed results, raw timing samples and any diagnostics are retained on the lab under the operator's test-evidence directory. Credentials, cookies, nonces and private PHP errors are not included in this guide bundle.

Official architecture reference: aaPanel Multi-WebServer Hosting. This describes aaPanel's server choices, not compatibility certification for our addon.

Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.

Guide series: Installation | WordPress configuration | Measured results

Historical attachments dated 20 October below belong to the older synthetic fixture run. They are retained as earlier evidence and are not the raw samples for the 24 October WordPress measurements above.

  varnish-before-after-results-20261020.png (Size: 135.15 KB / Downloads: 23)

  varnish-before-after-data-20261020.zip (Size: 17.82 KB / Downloads: 15) ]]>