Linux配置Varnish缓存方法详解

本文深入剖析了Linux环境下Varnish缓存配置的核心要点与常见陷阱：从必须定义backend并合理配置.probe健康检查以避免503错误，到精准修改default.vcl中vcl_recv、vcl_backend_response和vcl_deliver三处关键逻辑以实现高效、安全、可控的缓存策略；同时澄清了buff/cache占用高属Linux内存管理正常行为，强调应调低vm.swappiness而非盲目清缓存，并系统梳理了缓存未命中的三大高频原因——后端响应头限制、客户端请求头干扰及HTTPS未卸载导致协议解析失败，直击运维实践中最易踩坑的底层细节。

怎么配后端服务器（backend）和健康检查

Varnish 不是装上就能缓存，它得知道往哪儿转发请求——这个“哪儿”，就是 backend。不配 backend，varnishd 启动会报错：VCL compilation failed，或者请求直接 503。

• 必须定义至少一个 backend，哪怕只有一台 Web 服务器；.host 和 .port 缺一不可，IP 写错或端口被防火墙拦住，健康检查就永远失败
• 生产环境强烈建议加 .probe：它让 Varnish 主动发 HEAD 请求检测后端是否存活。没配 probe，后端挂了你还以为缓存里有旧内容，实际用户看到的是 503 或超时
• .window 和 .threshold 别乱设成 1/1——这会让一次偶发抖动就踢掉后端；推荐 .window = 8; .threshold = 6;，即最近 8 次探测中成功 6 次才算健康

示例：

backend app1 {
  .host = "192.168.10.20";
  .port = "8080";
  .probe = {
    .url = "/health";
    .timeout = 1s;
    .interval = 3s;
    .window = 8;
    .threshold = 6;
  }
}

default.vcl 里最该改的三处配置

刚装完 Varnish，/etc/varnish/default.vcl 是个空壳模板，不改它，所有请求都走默认 backend，且几乎不缓存动态内容（比如带 Set-Cookie 或 Cache-Control: private 的响应）。

• sub vcl_recv 里删掉对 Cookie 的粗暴 pass：默认配置常含 if (req.http.Cookie) { return (pass); }，这会让带 Cookie 的请求全 bypass 缓存——登录态页面可以 bypass，但静态资源（JS/CSS/图片）不该受此影响，应单独判断 req.url ~ "\.(js|css|png|jpg)$"
• sub vcl_backend_response 中控制缓存时长：后端没返回 Cache-Control 时，Varnish 默认只缓存 120 秒。加一句 set beresp.ttl = 1h; 可强制延长，但注意别设成 beresp.ttl = 0s，那等于禁用缓存
• 别漏掉 sub vcl_deliver 里的 unset resp.http.X-Varnish 和 unset resp.http.Via：否则响应头暴露 Varnish 版本，有安全风险；也方便前端调试时快速识别是否命中缓存（看有没有 X-Cache: HIT）

为什么 free -m 看到 buff/cache 高得吓人？要不要清

执行 free -m 发现 buff/cache 占了 3GB，而 available 只剩 200MB，第一反应是“内存爆了”，其实大概率是假警报。

• Linux 把空闲内存自动当磁盘缓存用，这不是泄漏，是内核在帮你加速后续读写；Varnish 自身申请的内存（由 -s malloc,2G 或 -s persistent 控制）属于“主动分配”，和 buff/cache 互不抢占
• 真正要调的是 vm.swappiness：默认值 60 会让内核倾向 swap 而非回收 cache。对 Varnish 这种吃内存大户，应设为 vm.swappiness = 1（sysctl -w vm.swappiness=1），避免关键缓存页被换出到慢速磁盘
• 别信 echo 3 > /proc/sys/vm/drop_caches——它清的是 pagecache/buffer，不影响 Varnish 自己的内存池，反而可能让下一轮请求变慢

缓存没命中？先查这三件事

curl 测试返回 X-Cache: MISS，但你确信内容该被缓存——问题往往不在 VCL 写错，而在更底层的 HTTP 语义或部署链路。

• 后端响应头是否含 Cache-Control: no-cache、private 或 max-age=0？Varnish 默认尊重这些指令；若需强制缓存，得在 vcl_backend_response 里覆盖：unset beresp.http.Cache-Control; set beresp.ttl = 10m;
• 客户端请求是否带 Cookie 或 Authorization 头？默认 VCL 常把它们视为不可缓存依据；如需缓存（比如 CDN 场景），必须显式清理：unset req.http.Cookie;，但注意这会丢失登录态，请确保只对静态资源做
• 是不是 HTTPS 流量直连 Varnish？Varnish 4.0+ 原生不支持 TLS 终止；如果前端没配 Nginx/Traefik 做 SSL 卸载，Varnish 收到的是加密二进制流，根本解析不了 URL 和 header，自然无法缓存

缓存行为高度依赖 HTTP 协议细节，而不是“开了 Varnish 就自动快”。很多问题卡在响应头语义、TLS 卸载位置、或 VCL 对 Cookie 的过度敏感上——这些地方没对齐，配再复杂的 director 也没用。

终于介绍完啦！小伙伴们，这篇关于《Linux配置Varnish缓存方法详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！