Varnish拼写不可误为Vanish，正确安装命令因系统而异；需配置监听80端口并确保后端服务让出该端口；缓存失效主因是默认对含Cookie请求执行pass，须在vcl_recv中针对性处理静态资源或清理Cookie，并在vcl_backend_response中设置beresp.ttl。
varnish 不是 Vanish——这是第一个必须纠正的点。拼写错误会导致所有后续操作失败，比如 apt install vanish 或 yum install vanish 都不会找到包，实际命令是：
sudo apt install varnish # Debian/Ubuntu sudo yum install varnish # CentOS/RHEL 7 sudo dnf install varnish # CentOS/RHEL 8+
如果你搜到的文档里写的是 Vanish，基本可以判定内容过时或笔误，直接跳过。
怎么确认 varnish 正确监听了 HTTP 流量
varnish 默认不处理 80 端口，它自己监听 6081（管理端口 6082），而真实后端（如 nginx 或 apache）仍跑在 80 或 8080。缓存生效的前提是：用户请求先打到 varnish，再由它转发给后端。
- 检查
varnish监听地址：sudo ss -tlnp | grep :6081，应看到varnishd进程 - 修改
/etc/default/varnish（Debian）或/etc/varnish/varnish.params（RHEL），把-a :6081改成-a :80（需 root 权限且 80 未被占用） - 若已有
nginx占用 80，可改nginx到8080，再让varnish接管 80 —— 这是最常见、最稳妥的部署方式 - 重启后验证：
curl -I http://localhost，响应头中出现X-Varnish和X-Cache: hit或miss才算走通
为什么缓存没生效？重点看 vcl_recv 和 Cookie
默认 VCL（/etc/varnish/default.vcl）对带 Cookie 或 Authorization 的请求直接 pass，不缓存。这是最常被忽略的点：你首页明明没登录，但前端框架（如 React/Vue）发的请求带了 Cookie: _ga=... 或 X-Requested-With，varnish 就当动态内容处理。
-
varnish默认策略：只要请求头含非空Cookie，就跳过缓存（return (pass)） - 简单放行静态资源：在
vcl_recv中加判断：if (req.url ~ "\.(jpg|jpeg|png|gif|webp|css|js)$") { return (hash); } - 更安全的做法是清理无关 Cookie：
set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )+_[^=]+=[^;]+", "");，再判断是否留空 - 别忘了在
vcl_backend_response中设置beresp.ttl，否则即使 hash 成功，TTL=0 也会立刻失效
varnishlog 和 varnishadm 怎么快速定位问题
光看 systemctl status varnish 没用。varnish 的行为全由 VCL 控制，错误往往藏在逻辑分支里。
- 实时看请求流转：
sudo varnishlog -g request -q "ReqUrl ~ '^/'"，关注VCL_call字段（如RECV→HASH→HIT） - 查某次请求为何 miss：
varnishlog -g request -q "ReqUrl ~ '/article/123'" | grep -E "(VCL_call|VCL_return|BereqHeader)" - 在线重载 VCL：
sudo varnishadm vcl.load myvcl /etc/varnish/default.vcl && sudo varnishadm vcl.use myvcl - 清空某类缓存：
sudo varnishadm ban "req.url ~ '^/api/'"（注意不是purge，ban 是标记失效，更安全）
真正难的不是配置语法，而是理解每个 return 分支的实际含义，以及 req、bereq、beresp 这些对象在哪个阶段存在、能读写哪些字段。一个 return (pass) 写错位置，整条链路就绕过缓存。
