How to Fix Varnish “Error 503 Backend Fetch Failed”

The Varnish page that says Error 503 Backend fetch failed and shows a Guru Meditation ID means one thing: Varnish asked your backend (Apache, NGINX, PHP-FPM, Node.js or another application) for a page and did not get a usable answer. Varnish itself is usually fine. The fix depends on why the fetch failed, and Varnish records the exact reason for every failure. This guide shows how to find it and how to fix the causes we see most often on production servers.

Step 1: find the reason in varnishlog

Leave this running and reproduce the error. It prints the full transaction for every request that ended in a 503:

sudo varnishlog -g request -q "RespStatus == 503"

Look for the FetchError line in the backend part of the output. Its text tells you which section below applies:

On older systems without the -g request grouping, varnishlog -q 'RespStatus == 503' works too. If you run Vinyl Cache, the new name of the open-source project from version 9.0, the tools are renamed from varnish* to vinyl* but work the same way.

Cause 1: the backend is too slow (first byte timeout)

By default Varnish waits 60 seconds for the first byte of a response. Slow reports, imports, exports or admin pages can exceed this. First check whether the slowness is real: run the same request directly against the backend with curl -w '%{time_starttransfer}\n' -o /dev/null -s http://127.0.0.1:8080/slow-page. If the page should be fast, fix the application or database. If it is legitimately slow, raise the timeout for that backend only:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 5s;
    .first_byte_timeout = 120s;
    .between_bytes_timeout = 60s;
}

Better still, route long-running admin or export URLs to return (pass) or to a separate backend so a few slow requests cannot tie up the timeouts for everyone.

Cause 2: the health probe marked the backend sick

If your VCL defines a probe, Varnish stops sending traffic to a backend that fails it, and every request returns 503 until the probe passes again. Check the current state:

sudo varnishadm backend.list

If the backend shows as sick, request the probe URL yourself. Common mistakes are a probe URL that redirects (a 301 is not a 200), a probe that hits a slow page, and a .timeout that is shorter than the page needs. Use a lightweight health endpoint that returns 200 quickly and does not depend on sessions or redirects.

Cause 3: the backend crashed or ran out of workers

http first read error: EOF and connection refused errors usually mean the backend dropped the request. Check the backend’s own logs at the same moment: PHP-FPM server reached pm.max_children, an out-of-memory kill in journalctl -k, or application crashes. Varnish is reporting the problem, not causing it. Raise worker limits only if the server has the memory for them, and cache more pages so fewer requests reach the backend at all.

Cause 4: response headers are too large

Applications that set many cookies, long Content-Security-Policy headers or large cache tags (Magento and some WordPress plugins do this) can exceed Varnish’s header limits. The default maximum size of a single response header line is 8 KB. Raise the limits with parameters, for example in the varnishd start options:

-p http_resp_hdr_len=65536 -p http_resp_size=98304 -p workspace_backend=131072

Raise them in proportion and test: these values reserve memory for every backend fetch. Magento’s own documentation recommends raising these limits for large cache tag headers.

Cause 5: the cache storage is full

Could not get storage together with a fast-growing MAIN.n_lru_nuked counter in varnishstat means the storage size is too small for your objects. Increase the -s malloc, size if the server has spare memory, or stop caching very large files in Varnish and serve them from a CDN or directly from disk.

Do not hide the error with retries

A return (retry) in vcl_backend_error or very long timeouts can make the error rarer while making the site slower for everyone. Grace mode is the better safety net: with a sensible beresp.grace, visitors keep getting the last good copy of a page while the backend recovers, instead of seeing a 503.

Stop it coming back

• Alert on the rate of 503 responses and on backend health, not just on Varnish being up
• Watch MAIN.backend_fail, MAIN.fetch_failed and MAIN.n_lru_nuked in your monitoring
• Keep VCL in version control and compile it with varnishd -C -f before loading it
• Load new VCL with vcl.load and vcl.use so the previous version stays available for an instant rollback

When to get help

If 503 errors return under load, the cause is usually capacity or architecture rather than a single setting. TechProvidence engineers diagnose and fix these as part of our Varnish support and cache tuning service, with 24/7 monitoring and an average response under 8 minutes. If NGINX sits in front of or behind Varnish, see our guide to NGINX 502 and 504 errors, or contact us for a complimentary Varnish review.