Varnish Command-Line Utilities. Tips and Tricks

varnishlog

The varnishlog utility allows you to get requests as they arrive or fetch some recent ones from memory.
It produces log entries in a very detailed format. This helps with debugging how things are being processed by Varnish.

Log 5xx requests

Some HTTP status codes typically indicate an error response. The 500 status code, in particular, is common for application errors.
To monitor for all responses where the status code falls between 500 and 599, you can use a regular expression query:

varnishlog -q "RespStatus ~ '5[0-9][0-9]'"

Log all PURGE and BAN requests

To continuously monitor for these request as they arrive, run:

varnishlog -g request -q 'ReqMethod eq "PURGE" or ReqMethod eq "BAN"'

If you want to take a look at recent PURGE requests which already took place (stored in memory), then add the -d switch:

varnishlog -d -g request -q 'ReqMethod eq "PURGE"'

Log all client requests to a specific website (virtual host) continuously

Requests in Varnish are logged separately for client-side connections and backend connections.
To view client-side requests, run:

varnishlog -q "ReqHeader ~ '^Host: (www\.)?example.com'"

Log all backend requests from Varnish (to nginx)

To monitor only requests to backend, run:

varnishlog -q "BereqHeader ~ '^Host: (www\.)?example.com'"

Similarly to earlier examples, you can add -d switch to view previous requests, which already took place and were not yet pruned from the shared memory log.

Armed with varnishlog, you can solve the "Backend fetch failed" errors easily!

varnishncsa

So you have tried varnishlog and you see that it’s more targeted towards debugging requests, and the logging is very detailed.
If you want to see requests coming to your Varnish instance in a compact form that is similar to Apache or nginx logs, meet varnishncsa.

It accepts all the same arguments as varnishlog. Example:

varnishncsa -g request -q 'ReqMethod eq "PURGE"'

Filter specific User-Agent requests

E.g. you may want to check how W3TC WordPress plugin sends purge requests to Varnish:

varnishlog -q "ReqHeader ~ '^User-Agent: W3 Total Cache'"

Show requests behind SSL terminator

You’d mostly always use Varnish behind an SSL terminator, e.g. nginx. If you use varnishncsa, you’ll see that it shows nginx IP address (127.0.0.1) instead of the actual visitor’s IP address. Here’s a good way to “fix” the output of varnishncsa by showing the value of X-Forwarded-For header:

varnishncsa -F '"%{X-Forwarded-For}i" %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i"'

This is hard to memorise. So it’s better to create a permanent alias so you can just type varnishncsa to invoke the command with proper parameters:

cat << EOF > /etc/profile.d/varnishncsa.sh
alias varnishncsa='varnishncsa -F "'%{X-Forwarded-For}i' %l %u %t '%r' %s %b '%{Referer}i' '%{User-agent}i'"'
EOF
chmod 0644 /etc/profile.d/varnishncsa.sh
source /etc/profile.d/varnishncsa.sh

varnishtop

The following example displays a continuously updated list of the most commonly used user agents:

varnishtop -C -I ReqHeader:User-Agent

Clear Varnish cache for domain using command line

sudo varnishadm "ban req.http.host ~ www.mydomain.com"

Varnish and WordPress

If you put WordPress with Nginx behind Varnish, you will likely find JetPack not working.
This is the quick fix:

$_SERVER['SERVER_PORT'] = 80;

This is noted to be quick fix only. What you really should be doing is map port related variable for FastCGI configuration in PHP-FPM. (We got this covered in our server setup services).

If you got “Backend fetch failed” error when activating JetPack in WordPress, there is a fix for Varnish and Jetpack that we have covered in a separate post.

List all backends

The command allows to check for defined backends:

varnishadm backend.list

Example output:

Backend name                   Admin      Probe
boot.default                   probe      Healthy 5/5
boot.extras_getpagespeed_com   probe      Healthy 5/5
boot.wp_getpagespeed_com       probe      Healthy 5/5

So this shows related probe and it’s health status as well.

You may want to use result of the command to check if any backends are sick. Creative sysadmins may even want to add that as monitoring jobs for Monit to see if specific important backends are down:

varnishadm backend.list | grep Sick

Varnish Health Checks

In case you want to constantly monitor Varnish health checks in real-time, there’s a command for that too. The nice command to troubleshoot health probes:

varnishlog -g raw -i Backend_health

TIP: You can actually have both Apache and Varnish run on the same port 80. But for this trick you need to bind them to different interfaces, i.e. Apache to 127.0.0.1:80 while Varnish to 123.123.123.123:80

TIP for WordPress users: behind a load balancer (varnish) and/or at least with Nginx SSL termination, you may want to uncheck Page Cache in W3TC (W3TC won’t clear its own cache upon posting from WordPress.com because of a bug).

You can find more information about health probes, backend, and polling in:

• Saving a request.
• Backend polling
• Misbehaving servers

Further reading related to Varnish CLI utilities

• Logging Hits and Misses with varnishlog and varnishncsa