2 hours ago
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
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:
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:
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:
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
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.
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:
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-sites4. Replace 12 with your WordPress site's actual ID:
Code:
/www/server/panel/pyenv/bin/python3 setup.py configure --site-id 12
/www/server/panel/pyenv/bin/python3 setup.py doctor5. 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:
b5813a7abed5d442b8d748472c6d1035cfabf35e00510f9ae8c343ffbd74ee53Report 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