Varnish Cache Setup: Cache WordPress and Magento at Server Level

Varnish is an HTTP reverse proxy that stores rendered pages in memory and answers repeat requests without touching PHP or MySQL — the first request is a MISS that fills the cache, the next is a HIT served from RAM. It pays off on a VPS or dedicated server running several sites, or on a Magento 2 store, which ships its own Varnish integration as the recommended production cache.

On a single WordPress site on shared hosting it is usually the wrong tool: you do not control the ports or the VCL there, and a page-cache plugin delivers most of the gain. Varnish adds a moving part you must purge, monitor and keep out of the login and cart flow — take it on when the origin, not the network, is the constraint. The PHP half of the speed story is in the OPcache setup guide.

VCL — the Varnish Configuration Language — is the file that names the server Varnish fetches from (the backend) and the rules for what it keeps; default.vcl holds it, and every setup edits the backend block first.

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_backend_response {
    # keep objects for five minutes when the app sends nothing
    if (beresp.ttl <= 0s) {
        set beresp.ttl = 300s;
    }
}

sub vcl_deliver {
    # make HIT/MISS visible in the response
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Three subroutines cover most needs: vcl_recv decides what to look up, vcl_backend_response sets TTLs and ESI, and vcl_deliver shapes headers. Varnish keeps an object 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 do not fight. One trap: Varnish resolves the backend hostname once, when the VCL compiles, so after a DNS change you reload the VCL rather than wait.

After the restart, varnishd should own port 80, the origin should own 8080, and the homepage should load with no 503 — then curl the same URL twice and read the X-Cache header you added in vcl_deliver.

• sudo ss -ltnp | grep :80 — varnishd is the process listed.
• sudo ss -ltnp | grep :8080 — Apache or Nginx is the process listed.
• systemctl status varnish — active (running), not restarting in a loop.
• curl -I https://your-site/ twice — the second response reads X-Cache: HIT.

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. varnishlog -g request shows the lookup and hit lines for one request; and if the response carries a Set-Cookie header, Varnish will not cache it, which is why login and cart pages stay dynamic by design.

Edge Side Includes let one cached page carry small dynamic fragments — a cart counter, a personalised greeting — fetched and stitched separately, so the page stays a HIT while the fragment stays live. Enable it in vcl_backend_response with set beresp.do_esi = true; and mark the fragment page uncacheable, then include it from the template with <esi:include src="/cart-count/"/>.

It is worth it when one fragment changes per visitor on an otherwise identical page; it is overkill when two versions of a page (logged-in and logged-out) would do the job with less machinery. Every ESI include is another request Varnish must assemble, so measure before adopting it sitewide.