varnish要真正加速web动态内容，必须监听80端口、确保后端地址可连通、且default.vcl中删除return(pass)拦截逻辑；三者缺一不可，否则缓存失效、返回503或x-cache:miss。
直接上结论：Varnish 要想真正加速 Web 动态内容，必须满足三个硬性条件——监听 80 端口、后端地址可连通、default.vcl 里删掉默认的 return (pass) 拦截逻辑。缺一不可，否则你看到的全是 X-Cache: MISS，缓存形同虚设。
为什么 varnishd 启动后 curl localhost 总是 503？
这不是配置没生效，是后端根本连不上。Varnish 默认 backend 指向 127.0.0.1:8080，但你的应用很可能跑在 127.0.0.1:3000、192.168.10.20:80，甚至容器里根本不是 localhost。
- 先在 Varnish 服务器上手动测试后端连通性：
curl -I http://192.168.10.20:8080，能返回200 OK才算过关 - 别用域名起步，初期全写 IP + 明确端口，避免 DNS 或
/etc/hosts配错引入干扰 - 检查后端机器防火墙是否放行了 Varnish 服务器的 IP（比如
firewall-cmd --add-source=192.168.10.50 --permanent） -
default.vcl里 backend 块的.host和.port必须跟上面curl命令一致，一个字符都不能错
监听 80 端口失败：Address already in use 怎么办？
Varnish 默认监听 :6081，生产环境必须改 :80，但改完常卡在端口冲突。这不是 Varnish 的问题，是 nginx/httpd 正占着 80。
- Ubuntu/Debian：编辑
/etc/default/varnish，把DAEMON_OPTS="-a :6081"改成-a :80 - CentOS/RHEL/Rocky：编辑
/etc/sysconfig/varnish，把VARNISH_LISTEN_PORT=6081改成80 - 改完必须执行
sudo systemctl restart varnish，不能只 reload - 若报
Address already in use，立刻查谁在用 80：sudo ss -tulpn | grep ':80'，停掉nginx或httpd，或把它改到8080
vcl_recv 里 return(pass) 是缓存失效的最大元凶
很多教程照搬示例，在 vcl_recv 里写了 if (req.http.Cookie) { return (pass); }，结果所有带登录态的请求都绕过缓存——但 JS/CSS/图片也跟着被拖下水，完全违背加速初衷。
- 静态资源不该受 Cookie 影响：加判断
if (req.url ~ "\.(js|css|png|jpg|woff2)$") { return (hash); }，强制走缓存 - 动态接口和管理路径才该 pass：
if (req.url ~ "^/(admin|api/v1/pay|callback)") { return (pass); } - 别漏掉
return (hash)—— Varnish 6+ 已弃用return (lookup)，没这句就进不了缓存查找流程 - 临时验证：把
vcl_recv清空，只留一行return (hash);，再测curl -I https://yoursite.com/style.css，看X-Cache是否变成HIT
beresp.ttl = 0s 和 unset resp.http.X-Varnish 的安全陷阱
后端没返回 Cache-Control 时，Varnish 默认只缓存 120 秒；有人图省事写 set beresp.ttl = 0s，结果等于彻底禁用缓存——0 秒不是“不设限”，是“不缓存”。
- 延长缓存时间请用明确值：
set beresp.ttl = 1h;或set beresp.ttl = 10m; -
sub vcl_deliver里必须加unset resp.http.X-Varnish;和unset resp.http.Via;，否则响应头暴露 Varnish 版本，构成基础信息泄露 - 别信“默认就安全”——新版 Varnish 不会自动隐藏这些头，不 unset 就等于把缓存架构摊开给扫描器看
