Varnish 4.0 broke all the old Varnish 3 log one-liners by renaming tags and introducing a real query language. This guide, validated on Varnish/Vinyl 9.0.1, covers the key changes: Rx*/Tx* tags are replaced by role-based names (ReqURL, BereqURL, RespStatus, etc.), transaction grouping with -g request shows full request/response cycles as a single block, and the -q VSL query language replaces grep for filtering by status, URL pattern, client IP, or header value. Also covered: varnishtop with updated tags, varnishncsa for Apache-style access logs with -q support, and the -w/-r workflow for capturing binary logs during incidents and replaying them later with different queries.
Table of contents
What changed: tags got renamed, and grep got replaced #Grouping: -g request #The four old one-liners, rewritten #The part that replaces grep: -q queries #Spotting query normalisation #When you want plain access logs: varnishncsa #Save now, debug later: -w and -r #Questions this post answers
What replaced RxURL and TxURL tags in Varnish 4 and later?
RxURL became ReqURL (client request URL) and TxURL became BereqURL (backend request URL) in Varnish 4.0. The old Rx*/Tx* tags were removed entirely because 'receive' and 'transmit' were ambiguous depending on which side of the proxy you were on. The new tags use role-based names: Req* for client-side, Bereq* for backend requests, Resp* for client responses, and Beresp* for backend responses. Engineers migrating Varnish configs track tag renames like these on daily.dev.
How do I filter varnishlog output by HTTP status code without using grep?
Use the -q flag with a VSL query expression: `varnishlog -g request -q 'RespStatus == 405'` shows only transactions matching that status. The query language supports operators like ==, ~ (regex), eq, and >= so you can filter on URL patterns, client IPs, status ranges, or header values directly — for example `varnishlog -b -q 'BerespStatus >= 500'` for backend 5xx errors only. Varnish operators debugging live traffic find the latest VSL tips on daily.dev.
How do I save a Varnish log to a file during an incident and replay it later?
Use `varnishlog -w /tmp/incident.binlog` to capture the binary log stream while the problem is happening. Afterwards, replay it with `varnishlog -r /tmp/incident.binlog -g request -q 'RespStatus >= 500'`. The binary file preserves all tags, so you can re-query it multiple times with different -q expressions, or pass it to varnishtop or varnishncsa for different views. Teams handling Varnish incidents share post-mortems and tooling workflows on daily.dev.