Varnish Cache Setup: Cache WordPress and Magento at Server Level

Varnish cache setup moves Varnish to port 80 and the web server to 8080, then edits default.vcl so Varnish knows where to fetch from. Reload both services, curl one URL twice, and the second response should read HIT. Varnish does not terminate TLS, so a proxy keeps HTTPS in front of it.

Install Varnish and move the web server to port 8080

Varnish takes port 80 and Apache or Nginx moves to 8080, so every request passes through the cache before PHP runs. On Ubuntu or Debian the change is one package install, two file edits and two restarts.

1. Install and stop the service: sudo apt update && sudo apt install varnish, then sudo systemctl stop varnish.
2. Open /lib/systemd/system/varnish.service and set the listen address on the ExecStart line to -a :80.
3. On the same line, set the cache size, for example -s malloc,1G, and raise it to 2G on a busy server.
4. Move the origin web server to 8080: Listen 8080 in /etc/apache2/ports.conf and in each virtual host, or listen 8080; in each Nginx server block.
5. Run sudo systemctl daemon-reload, then restart both services: sudo systemctl restart apache2 varnish or nginx varnish.

Registration through the official package repository installs the current 6.0 LTS build instead of the older one in the distribution. If you skip the repository step, check the version before you tune anything.

Point default.vcl at the backend and set the cache TTL

default.vcl names the server Varnish fetches from and how long it keeps each object. The backend block is 127.0.0.1 on port 8080, and the TTL is set in vcl_backend_response.

Varnish keeps an object for 120 seconds by default. A five-minute TTL suits a brochure or blog, while a shop should let the application send its own Cache-Control; Varnish honours a shorter max-age from the backend, so the two settings do not fight.

Varnish resolves the backend hostname once, when it compiles the VCL. If the origin address changes, reload the VCL rather than waiting: DNS changes are not picked up on their own.

Terminate HTTPS in front of Varnish, which speaks plain HTTP

Varnish Cache does not handle TLS, so the certificate stays on Nginx, HAProxy or a load balancer in front, and Varnish listens behind it on port 80. The browser still sees https and a valid certificate.

The usual layout is Nginx on 443 for TLS, Varnish on 80, and Apache or Nginx on 8080 as the origin. Redirect http to https at the front proxy; otherwise a cached page can be served over plain http after the switch.

Check that Varnish owns port 80 and the site still loads

After the restart, varnishd should own port 80, the origin web server should own 8080, and the site should load without a 503. ss -ltnp shows which process holds each port.

• sudo ss -ltnp | grep :80 — varnishd should be the process listed.
• sudo ss -ltnp | grep :8080 — Apache or Nginx should be the process listed.
• systemctl status varnish — active (running), not restarting in a loop.
• The homepage loads in a private window, with no 503 Service Unavailable page.

A 503 here usually means the backend port in default.vcl and the port the web server listens on are different numbers. Fix the pair rather than disabling Varnish.

Confirm a cache HIT with curl and varnishlog

Add an X-Cache header in vcl_deliver, then request the same URL twice with curl -I. The second response should read HIT; a page that stays MISS is not cacheable.

varnishlog -g request shows the lookup and hit lines for one request. If the response carries a Set-Cookie header, Varnish will usually refuse to cache it, which is why login and cart pages stay dynamic by design.

Purge Varnish after publishing instead of restarting it

A restart empties the whole cache and sends every next request to PHP. A purge removes only the URLs that changed, which keeps the warm cache for everything else.

Two routes work: a controlled PURGE request allowed only from localhost and your own IP through an ACL in VCL, or varnishadm ban for a pattern such as one URL prefix. Keep the PURGE method closed to the public internet.

When a page-cache plugin beats a Varnish setup

On a single WordPress site on shared hosting, a page-cache plugin delivers most of the gain without touching ports or VCL. Varnish pays off on a VPS or dedicated server that runs several sites, or on a Magento 2 store, which ships a Varnish integration for production.

The PHP half of the same speed story is in the OPcache setup guide. If the server is the constraint rather than the cache, compare the VPS hosting range where you control ports and memory.