What’s new in Varnish? on Varnish Cache

Changes in Varnish 4.1

Mon, 16 Mar 2026 00:00:00 +0000

Varnish 4.1 is the continuation of the new streaming architecture seen in Varnish 4.0.

Proactive security features

New in 4.1 is support for different kinds of privilege separation methods, collectively described as jails.

On most systems, the Varnish parent process will now drop effective privileges to normal user mode when not doing operations needing special access.

Changes in Varnish 5.0

Mon, 16 Mar 2026 00:00:00 +0000

Varnish 5.0 changes some (mostly) internal APIs and adds some major new features over Varnish 4.1.

Separate VCL files and VCL labels

Varnish 5.0 supports jumping from the active VCL’s vcl_recv{} to another VCL via a VCL label.

The major use of this will probably be to have a separate VCL for each domain/vhost, in order to untangle complex VCL files, but it is not limited to this criteria, it would also be possible to send all POSTs, all JPEG images or all traffic from a certain IP range to a separate VCL file.

Changes in Varnish 5.1

Mon, 16 Mar 2026 00:00:00 +0000

We have a couple of new and interesting features in Varnish 5.1, and we have a lot of smaller improvements and bugfixes all over the place, in total we have made about 750 commits since Varnish 5.0, so this is just some of the highlights.

Probably the biggest change in Varnish 5.1 is that a couple of very significant contributors to Varnish have changed jobs, and therefore stopped being active contributors to the Varnish Project.

Changes in Varnish 5.2

Mon, 16 Mar 2026 00:00:00 +0000

Varnish 5.2 is mostly changes under the hood so most varnish installations will be able to upgrade with no modifications.

New VMODs in the standard distribution

We have added three new VMODs to the varnish project.

VMOD blob

We have added the variables req.hash and bereq.hash to VCL, which contain the hash value computed by Varnish for the current request, for use in cache lookup. Their data type is BLOB, which represents opaque data of any length – the new variables contain the raw binary hashes.

Changes in Varnish 6.0

Mon, 16 Mar 2026 00:00:00 +0000

Usually when we do dot-zero releases in Varnish, it means that users are in for a bit of work to upgrade to the new version, but 6.0 is actually not that scary, because most of the changes are either under the hood or entirely new features.

The biggest user-visible change is probably that we, or to be totally honest here: Geoff Simmons (UPLEX), have added support for Unix Domain Sockets, both for clients and for backend servers.

Changes in Varnish 6.1

Mon, 16 Mar 2026 00:00:00 +0000

This release is a maintenance release, so while there are many actual changes, and of course many bugfixes, they should not have little to no impact on running Varnish installations.

Nothing to see here, really

Since new users often forget to vcl.discard their old VCLs, we have added a warning when you have more than 100 VCLs loaded. There are parameters to set the threshold and decide what happens when it is exceeded (ignore/warn/error).

Changes in Varnish 6.2

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 6.2.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Cache lookups have undergone a number of optimizations, among them reduction in lock contention, and to shorten and simplify the critical section of lookup code. We expect that this will improve performance and scalability.

Changes in Varnish 6.3

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 6.3.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Parameters

A new pipe_sess_max parameter allows to limit the number of concurrent pipe transactions. The default value is zero and means unlimited, for backwards compatibility.

Changes in Varnish 6.4.0

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 6.4.0.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

bugs

Numerous bugs have been fixed.

Changes in Varnish 6.5.0

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 6.5.0.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Access Control Lists (ACLs)

The VCL compiler now emits warnings if network numbers used in ACLs do not have an all-zero host part (as, for example, "192.168.42.42"/24). By default, such ACL entries are fixed to all-zero and that fact logged with the ACL VSL tag.

Changes in Varnish 6.6

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 6.6.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Arguments

varnishd now supports the -b none argument to start with only the builtin VCL and no backend at all.

Parameters

The validate_headers parameter has been added to control header validation

Changes in Varnish 7.0

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.0.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

PCRE2

One major change for this release is the migration of the regular expression engine from PCRE to PCRE2. This change should be mostly transparent anywhere regular expressions are used, like VCL, ban expressions, VSL queries etc.

Changes in Varnish 7.1

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.1.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Parameters

A new kind of parameters exists: deprecated aliases. Their documentation is minimal, mainly referring to the actual symbols they alias. They are not listed in the CLI, unless referred to explicitly.

Changes in Varnish 7.2

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.2.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Extensions

From the very first days of Varnish, we have been talking about having an extension points for “more advanced stuff” and we did, by and large, keep a place ready for it in the overall architecture.

Changes in Varnish 7.3

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.3.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Parameters

There is a new parameter transit_buffer disabled by default to limit the amount of storage used for uncacheable responses. This is useful in situations where slow clients may consume large but uncacheable objects, to prevent them from filling up storage too fast at the expense of cacheable resources. When transit buffer is enabled, a client request will effectively hold its backend connection open until the client response delivery completes.

Changes in Varnish 7.4

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.4.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

HTTP/2 header field validation is now more strict with respect to allowed characters.

The VCL-steps manual page has been added to document the VCL state machines.

Changes in Varnish 7.5

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.5.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

Security

CVE-2023-44487

Also known as the HTTP/2 Rapid Reset Attack, or VSV 13, this vulnerability is addressed with two mitigations introducing several changes since the 7.4.0 release of Varnish Cache. The first one detects and stops Rapid Reset attacks and the second one interrupts the processing of HTTP/2 requests that are no longer open (stream reset, client disconnected etc).

Changes in Varnish 7.6

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish 7.6.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

Changes applying to most varnish-cache programs

The environment variable VARNISH_DEFAULT_N now provides the default “varnish name” / “workdir” as otherwise specified by he -n argument to varnishd and varnish* utilities except varnishtest.

Changes in Varnish Cache 9.0

Mon, 16 Mar 2026 00:00:00 +0000

This version is released under a new name, which implies a number of relevant changes to Varnish Cache deployments. We strongly recommend to read Upgrading to Varnish Cache 9.0 first.

A more detailed and technical account of changes in Varnish Cache, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Other changes in varnishd

Varnish Extensions (VEXTs) can now be loaded by specifying their basename as -E<name>. When <name> is not a path (does not contain /), a search in vmod_path is conducted for libvmod_<name>.so.

Changes in Varnish-Cache 7.7

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish-Cache 7.7.

NOTE: In this Varnish-Cache release, we changed how timestamps are taken for the http2 protocol, which could look like a performance regression, but is not. See http2 related timestamps.

A more detailed and technical account of changes in Varnish-Cache, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

Changes in Varnish-Cache 8.0

Mon, 16 Mar 2026 00:00:00 +0000

For information about updating your current Varnish deployment to the new version, see Upgrading to Varnish-Cache 8.0.

A more detailed and technical account of changes in Varnish, with links to issues that have been fixed and pull requests that have been merged, may be found in the change log.

varnishd

Parameters

Read only parameter can no longer be set through an alias.

Deprecated aliases for parameters can no longer be set read only, it should instead be done directly on the parameters they point to.

Upgrading to Varnish 4.0

Mon, 16 Mar 2026 00:00:00 +0000

Changes to VCL

The backend fetch parts of VCL have changed in Varnish 4. We’ve tried to compile a list of changes needed to upgrade here.

Version statement

To make sure that people have upgraded their VCL to the current version, Varnish now requires the first line of VCL to indicate the VCL version number:

Upgrading to Varnish 4.1

Mon, 16 Mar 2026 00:00:00 +0000

Changes to VCL

Data type conversion functions now take a fallback

Data type conversion functions in the std vmod now takes an additional argument fallback, which is returned if the conversion does not succeed.

Version statement is kept

The VCL syntax has not chanced significantly, and as such the Varnish 4.0 version marker is kept for Varnish 4.1.

Upgrading to Varnish 5.0

Mon, 16 Mar 2026 00:00:00 +0000

Changes to VCL

All VCL Objects should now be defined before used
- in particular, this is now required for ACLs. The error message for ACLs being used before being defined is confusing - see PR #2021:
```
Name <acl> is a reserved name
```
VCL names are restricted to alphanumeric characters, dashes (-) and underscores (). In addition, the first character should be alphabetic. That is, the name should match “[A-Za-z][A-Za-z0-9-]*”.
Like strings, backends and integers can now be used as boolean expressions in if statements. See vcl(7) for details.
Add support to perform matches in assignments, obtaining a boolean as result:
```
set req.http.foo = req.http.bar ~ "bar";
```
Returned values from functions and methods’ calls can be thrown away.

backends

Added support for the PROXY protocol via .proxy_header attribute. Possible values are 1 and 2, corresponding to the PROXY protocol version 1 and 2, respectively.

vcl_recv

Added return (vcl(label)) to switch to the VCL labelled label.
The rollback function has been retired.

vcl_hit

Replace return (fetch) with return (miss).

vcl_backend_*

Added read access to remote.ip, client.ip, local.ip and server.ip.

vcl_backend_fetch

Added write access to bereq.body, the request body. Only unset is supported at this time.
We now send request bodies by default (see Request Body sent always / “cacheable POST”). To keep the previous behaviour add the following code before any return (..) statement in this subroutine:
```
if (bereq.method == "GET") {
 unset bereq.body;
}
```

vcl_backend_error

Added write access to beresp.body, the response body. This may replace synthetic() in future releases.

vcl_deliver

Added read access to obj.ttl, obj.age, obj.grace and obj.keep.

vcl_synth

Added write access to resp.body, the response body. This may replace synthetic() in future releases.

Management interface

To disable CLI authentication use -S none.
n_waitinglist statistic removed.

Changes to parameters

Added ban_lurker_holdoff.
Removed session_max. This parameter actually had no effect since 4.0 but might come back in a future release.
vcl_path is now a colon-separated list of directories, replacing vcl_dir.
vmod_path is now a colon-separated list of directories, replacing vmod_dir.

Other changes

varnishstat(1) -f option accepts a glob(7) pattern.
Cache-Control and Expires headers for uncacheable requests (i.e. passes) will not be parsed. As a result, the RFC variant of the TTL VSL tag is no longer logged.

Upgrading to Varnish 5.1

Mon, 16 Mar 2026 00:00:00 +0000

varnishd command-line options

If you have to change anything at all for version 5.1, then most likely the command-line options for varnishd in your start scripts, because we have tightened restrictions on which options may be used together. This has served mainly to clarify the use of options for testing purposes, for example using varnishd -C to check a VCL source for syntactic correctness. We have also added some new options.

Upgrading to Varnish 5.2

Mon, 16 Mar 2026 00:00:00 +0000

Varnish statistics and logging

There are extensive changes under the hood with respect to statistics counters, but these should all be transparent at the user-level.

varnishd parameters

The vsm_space and cli_buffer parameters are now deprecated and ignored. They will be removed in a future major release.

The updated shared memory implementation manages space automatically, so it no longer needs vsm_space. Memory for the CLI command buffer is now dynamically allocated.

Upgrading to Varnish 6.0

Mon, 16 Mar 2026 00:00:00 +0000

Unix domain sockets as listen addresses

The varnishd -a command-line argument now has this form, where the address may be a Unix domain socket, identified as such when it begins with / (see varnishd OPTIONS):

-a [name=][address][:port][,PROTO][,user=<user>][,group=<group>][,mode=<mode>]

For example:

varnishd -a /path/to/listen.sock,PROXY,user=vcache,group=varnish,mode=660

That means that an absolute path must always be specified for the socket file. The socket file is created when Varnish starts, and any file that may exist at that path is unlinked first. You can use the optional user, group and mode sub-arguments to set permissions of the new socket file; use names for user and group (not numeric IDs), and a 3-digit octal number for mode. This is done by the management process, so creating the socket file and setting permissions are done with the privileges of the management process owner.

Upgrading to Varnish 6.1

Mon, 16 Mar 2026 00:00:00 +0000

A configuration for Varnish 6.0.x will run for version 6.1 without changes. There has been a subtle change in the interpretation of the VCL variable beresp.keep under specific circumstances, as discussed below. Other than that, the changes in 6.1 are new features, described in the following.

varnishd parameters

We have added the max_vcl parameter to set a threshold for the number of loaded VCL programs, since it is a common error to let previous VCL instances accumulate without discarding them. The remnants of undiscarded VCLs take the form of files in the working directory of the management process. Over time, too many of these may take up significant storage space, and administrative operations such as vcl.list may become noticeably slow, or even time out, when Varnish has to iterate over many files.

Upgrading to Varnish 6.2

Mon, 16 Mar 2026 00:00:00 +0000

VCL

VCL programs for Varnish 6.1 can be expected to run without changes in the new version.

A VCL load will now issue a warning, but does not fail as previously, if a backend declaration uses the .path field to specify a Unix domain socket, but the socket file does not exist or is not accessible at VCL load time. This makes it possible to start the peer component listening at the socket, or set its permissions, after Varnish starts or the VCL is loaded. Backend fetches fail if the socket is not accessible by the time the fetch is attempted.

Upgrading to Varnish 6.3

Mon, 16 Mar 2026 00:00:00 +0000

For users of many and/or labeled VCLs

Users of the advanced mechanics behind the vcl.state CLI command (most likely used via varnishadm) should be aware of the following changes, which may require adjustments to (or, more likely, allow for simplifications of) scripts/programs interfacing with varnish:

The VCL auto state has been streamlined. Conceptually, it used to be a variant of the warm state which would automatically cool the vcl. Yet, cooling did not only transition the temperature, but also the state, so auto only worked one way - except that vcl.use or moving a label (by labeling another vcl) would also set auto, so a manual warm/cold setting would get lost.

Upgrading to Varnish 6.4.0

Mon, 16 Mar 2026 00:00:00 +0000

Upgrading to Varnish 6.4 from 6.3 should not require any changes to VCL.

This document contains information about other relevant aspects which should be considered when upgrading.

varnishd

The hash algorithm of the hash director was changed, so backend selection will change once only when upgrading.

Users of the hash director are advised to consider using the shard director instead, which, amongst other advantages, offers more stable backend selection through consistent hashing. See VMOD directors - Varnish Directors Module for details.

Upgrading to Varnish 6.5.0

Mon, 16 Mar 2026 00:00:00 +0000

varnishstat

The JSON output (-j option) changed to avoid having the timestamp field mixed with the counters fields. As such the schema version was bumped from 0 to 1, and a version top-level field was added to keep track of future schema changes. Counters are in a new counters top-level field.

Upgrading to Varnish 6.6

Mon, 16 Mar 2026 00:00:00 +0000

In general, this release should not come with relevant incompatibilities to the previous release 6.5.

VCL should continue to work as before except when rather exotic, partly unintended and/or undocumented features are used.

Header Validation

Varnish now validates any headers set from VCL to contain only characters allowed by RFC7230. A (runtime) VCL failure is triggered if not. Such VCL failures, which result in 503 responses, should be investigated. As a last resort, the validate_headers parameter can be set to false to avoid these VCL failures.

Upgrading to Varnish 7.0

Mon, 16 Mar 2026 00:00:00 +0000

PCRE2

The migration from PCRE to PCRE2 led to many changes, starting with a change of build dependencies. See the current installation notes for package dependencies on various platforms.

Previously the Just In Time (jit) compilation of regular expressions was always enabled at run time if it was present during the build. From now on jit compilation is enabled by default, but can be disabled with the --disable-pcre2-jit configure option. Once enabled, jit compilation is merely attempted and failures are ignored since they are not essential.

Upgrading to Varnish 7.1

Mon, 16 Mar 2026 00:00:00 +0000

varnishd

Varnish now has an infrastructure in place to rename parameters or VCL variables while keeping a deprecated alias for compatibility.

Parameters

There are plans to rename certain arguments. When this happens, aliases will not be listed by param.show [-j|-l] commands, but they will be displayed by param.show [-j] <param>. Systems operating on top of varnishadm or the Varnish CLI can be updated to anticipate this change with the help of the deprecated_dummy parameter added for testing purposes.

Upgrading to Varnish 7.2

Mon, 16 Mar 2026 00:00:00 +0000

varnishd

Parameters

The following parameters are deprecated:

vcc_allow_inline_c
vcc_err_unref
vcc_unsafe_path

They can still be set as individual boolean parameters. The deprecated aliases will be removed in a future release.

They are replaced by the vcc_feature bits parameter:

allow_inline_c
err_unref (enabled by default)
unsafe_path (enabled by default)

The following commands are equivalent:

param.set vcc_err_unref off
param.set vcc_feature -err_unref

Identity

The server identity must be a valid HTTP token, which may pose a problem to existing setups. For example varnishd -i "edge server 1" is no longer accepted. You can use something like varnishd -i "edge-server-1" instead.

Upgrading to Varnish 7.3

Mon, 16 Mar 2026 00:00:00 +0000

New VSL format

The binary format of Varnish logs changed to increase the space for VXIDs from 32 bits to 64. This is not a change that older versions of the Varnish logging utilities can understand, and the new utilities can also not process old logs.

There is no conversion tool from the old format to the new one, so this should become a problem only when raw logs are stored for future processing. If old binary logs need to remain usable, the only solution is to use a compatible Varnish version and at the time of this release, the 6.0 branch is the only one without an EOL date.

Upgrading to Varnish 7.4

Mon, 16 Mar 2026 00:00:00 +0000

Important VCL Changes

When upgrading from Varnish-Cache 7.3, there is only one breaking change to consider in VCL:

The Content-Length and Transfer-Encoding headers are now protected, they can neither be changed nor unset. This change was implemented to avoid de-sync issues from accidental, inadequate modifications of these headers.

For the common use case of unset (be)req.http.Content-Length to dismiss a request body, unset (be)req.body should be used.

Parameter Changes

The new varnishd parameter startup_timeout now specifically replaces cli_timeout for the initial startup only. In cases where cli_timeout was increased specifically to accommodate long startup times (e.g. for storage engine initialization), startup_timeout should be used.

Upgrading to Varnish 7.5

Mon, 16 Mar 2026 00:00:00 +0000

Logs

The optional reason field of BackendClose records changed from a description (for example “Receive timeout”) to a reason tag (for example RX_TIMEOUT). This will break VSL queries based on the reason field.

Using a tag should however make queries more reliable:

# before
varnishlog -q 'BackendClose ~ "Receive timeout"'

# after
varnishlog -q 'BackendClose[4] eq RX_TIMEOUT'

Such queries would no longer break when a description is changed.

Timeouts

The value zero for timeouts could mean either timing out immediately, never timing out, or not having a value and falling back to another. The semantic changed so zero always means non-blocking, timing out either immediately after checking whether progress is possible, or after a millisecond in parts where this can’t practically be done in a non-blocking fashion.

Upgrading to Varnish 7.6

Mon, 16 Mar 2026 00:00:00 +0000

In general, upgrading from Varnish 7.5 to 7.6 should not require any changes besides the actual upgrade.

The changes mentioned below are considered noteworthy nevertheless:

Noteworthy changes for container workloads

When varnishd runs in a different PID namespace on Linux, typically in a container deployment, VSM_NOPID must be added to the environment of other containers running programs attaching themselves to varnishd’s shared memory. This will otherwise fail liveness checks performed by VSM consumers.

Upgrading to Varnish Cache 9.0

Mon, 16 Mar 2026 00:00:00 +0000

This document only lists breaking changes that you should be aware of when upgrading from Varnish Cache 8.x to Varnish Cache 9.0. For a complete list of changes, please refer to the change log and Changes in Varnish Cache 9.0.

varnishd

VSV00018

The handling of HTTP/1.1 requests to an “absolute form” URI has been fixed to also cover the case where the absolute form has an empty path component:

Previously, a request with an empty path like GET http://example.com HTTP/1.1 would cause req.url to contain http://example.com and the Host: header to remain unchanged. This has now been fixed:

Upgrading to Varnish-Cache 7.7

Mon, 16 Mar 2026 00:00:00 +0000

In general, upgrading from Varnish 7.6 to 7.7 should not require any changes besides the actual upgrade.

Note, however, that some log messages and in particular timestamps have changed, see Changes in Varnish-Cache 7.7 and http2 related timestamps in particular. Here, we only summarize the changes:

We have changed how http/2 timestamps are taken.
Details of http/2 related log entries have changed.
The varnishncsa format Varnish:handling now also outputs hitmiss and hitpass.
varnishncsa now outputs headers as they are received and sent.
The CLI command backend.list -j now outputs IPs/port information.

Upgrade notes for VMOD developers

vmodtool.py now creates a file vmod_vcs_version.txt in the current working directory when called from a git tree. This file is intended to transport version control system information to builds from distribution bundles.

Upgrading to Varnish-Cache 8.0

Mon, 16 Mar 2026 00:00:00 +0000

This document only lists breaking changes that you should be aware of when upgrading from Varnish-Cache 7.x to 8.0. For a complete list of changes, please refer to the change log or Changes in Varnish-Cache 8.0.

varnishd

Unknown HTTP methods handling

In previous versions of Varnish, requests with an unknown/unsupported HTTP method were by default piped to the backend. Starting with Varnish 8.0, the default behaviour for such requests is to return a synthetic 501 response and close the connection. Handling of custom HTTP methods can of course still be implemented in your VCL.

Varnish 5.0 Release Note

Mon, 16 Mar 2026 00:00:00 +0000

This is the first Varnish release after the Varnish Project moved out of Varnish Software’s basement, so to speak, and it shows.

But it is also our 10 year anniversary release, Varnish 1.0 was released on September 20th 2006.

That also means that we have been doing this for 10 years without any bad security holes.