Guide Install Varnish for WordPress on aaPanel: Tested Lab Guide - Printable Version +- AdminsForum (https://adminsforum.com) +-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels) +--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel) +---- Forum: aaPanel Addons & Plugins (https://adminsforum.com/Forum-aapanel-addons-plugins) +----- Forum: Varnish Cache for aaPanel (https://adminsforum.com/Forum-varnish-cache-for-aapanel) +----- Thread: Guide Install Varnish for WordPress on aaPanel: Tested Lab Guide (/Thread-guide-install-varnish-for-wordpress-on-aapanel-tested-lab-guide)

Install Varnish for WordPress on aaPanel: Tested Lab Guide - DEV - 10-20-2026 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.