Varnish Cache 503 Guru Meditation

Caching
Server
Debugging
Archive
A survival guide for debugging the dreaded Varnish 503 — from backend checks to timeout tuning to keepalive.
Author

B. Talvinder

Published

March 24, 2015

From the Archive

Originally published in 2015 on talvinder.com. Some technical details may be outdated, but this remains here as part of the archive.

The Varnish 503 “Guru Meditation” error is a frequent headache. It can mean anything from a misconfigured backend host to a timeout too short for a slow upstream, and the lack of on-disk logs makes it harder to diagnose than most web server errors. Here is what I found useful, working through it in order.

Before We Start

One of the most confusing (but cool) things about Varnish is that it does not store any logs on disk. All log entries go directly into memory. To view the logs:

varnishlog

Once running, load a page from your website and look for any errors.

Solution 1: General Check

Most of the time, Varnish 503 means Varnish cannot connect with your backend (Apache, Nginx, etc). Check that your backend is correctly configured.

Open your Varnish configuration file (mine was in /etc/varnish/user.vcl):

backend default {
  .host = "127.0.0.1";
  .port = "8888";
  .connect_timeout = 1s;
}

Verify the backend is responding on that port:

wget http://www.your-site.com:8888

Check if the HTML output matches your homepage.

Solution 2: Increase Timeouts

A frequent cause of 503 errors is timeouts. Add these lines to your Varnish config:

backend default {
  .host = "127.0.0.1";
  .port = "8888";
  .connect_timeout = 1s;
  .first_byte_timeout = 5s;
  .between_bytes_timeout = 2s;
}

The most important setting is first_byte_timeout. Play with these until you find the sweet spot.

Solution 3: Turn Keepalive Off

If timeouts don’t fix it, try disabling keepalive connections between Varnish and Apache/Nginx. In your VCL backend definition, set .max_connections to a low value or configure your Apache/Nginx backend to disable HTTP keepalive, so Varnish opens a fresh connection for each request rather than reusing a stale one. This resolved intermittent 503s for me when the timeout tuning alone was not enough.

Enjoyed this?

Get frameworks, build logs, and field notes in your inbox.

No spam. Unsubscribe anytime.