<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Varnish on Support Tools</title><link>https://support.tools/tags/varnish/</link><description>Recent content in Varnish on Support Tools</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 23 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://support.tools/tags/varnish/index.xml" rel="self" type="application/rss+xml"/><item><title>Varnish Cache Tuning: VCL, Grace, Bans and Hit Rate</title><link>https://support.tools/post/enterprise-varnish-cache-performance-optimization-guide-2025/</link><pubDate>Sun, 25 May 2025 16:34:42 -0500</pubDate><guid>https://support.tools/post/enterprise-varnish-cache-performance-optimization-guide-2025/</guid><description>&lt;p&gt;Varnish ships with a built-in VCL that is deliberately conservative: any request with a &lt;code&gt;Cookie&lt;/code&gt; or &lt;code&gt;Authorization&lt;/code&gt; header goes straight to the backend, and any response with &lt;code&gt;Set-Cookie&lt;/code&gt; is not cached. On a real site, where every browser sends analytics cookies, that means the cache does almost nothing. This guide covers the VCL changes that actually move the hit rate, how to keep serving during backend outages, how to invalidate content safely, how to size storage, and how to prove each change with &lt;code&gt;varnishstat&lt;/code&gt; and &lt;code&gt;varnishlog&lt;/code&gt;.&lt;/p&gt;</description></item></channel></rss>