Varnish探测后端健康却返回503错误求助

核心矛盾分析 #

后端健康探测通过，但Varnish实际请求返回503，直接curl后端正常，说明探测逻辑和实际请求的执行路径/环境存在差异，从以下几个方向逐步排查：

1. 核对VCL配置中探测与实际请求的差异 #

检查default.vcl里的后端定义和探测规则：

• 确认探测的路径、方法是否和实际请求一致：比如探测用/.well-known/health，但实际请求的是业务路径，后端可能对不同路径有不同权限/处理逻辑；默认探测用GET方法，若后端对HEAD请求兼容差但探测用了HEAD，也会出现探测通过但实际请求失败。
• 检查后端的端口、主机配置：比如误把端口设为443而非80，或者主机地址写错成内部IP而非外部域名。

2. 从Varnish日志定位具体错误 #

重点看varnishlog里的FetchError字段，对应不同错误有不同排查方向：

• Connection refused：Varnish连不上后端TCP端口。大概率是Fly.io网络策略限制（比如后端没开放80端口给Varnish所在网络），或者Express服务监听地址是127.0.0.1而非0.0.0.0（仅限容器内部访问，外部无法连接）。
• HTTP error 4xx/5xx：后端返回非2xx响应，Varnish判定为失败。此时查看BackendResponse的状态码，比如后端要求特定Host头，而Varnish默认发的是IP地址而非域名，导致返回404。
• Timeout：即使加了超时设置，可能是Fly.io内部网络延迟，或者实际请求（比如图片优化）比探测请求（轻量健康检查）耗时多很多。

3. 对比Varnish和直接curl的请求头差异 #

从varnishlog里提取BackendRequest的所有请求头，和你手动curl的头对比：

• 重点看Host、User-Agent、Accept-Encoding这些字段，很多后端服务依赖特定头才能正常响应。比如后端要求Host必须是外部域名，而Varnish默认发的是后端IP，就会触发错误。
• 如果是头的问题，在vcl_backend_fetch里强制设置正确的头：

sub vcl_backend_fetch {
    set bereq.http.Host = "img-optimizer-fragrant-cloud-4712.fly.dev";
}

4. 检查Fly.io网络与容器配置 #

• 若Varnish和Express是两个独立Fly应用，尽量用私有网络地址访问（比如img-optimizer.internal），而非外部域名，避免外部网络的解析或限制问题。
• 确认Express服务的监听地址必须是0.0.0.0：如果代码里写的是app.listen(80, '127.0.0.1')，只能容器内部访问，Fly网关或Varnish都连不上。
• 检查fly.toml里的端口配置：确保Express的80端口已暴露，且Varnish应用的出站规则允许访问该端口。

5. 测试Varnish容器内部访问后端 #

在Varnish容器里直接执行curl http://img-optimizer-fragrant-cloud-4712.fly.dev:80：

• 如果容器内curl失败，说明是网络或后端配置问题，和Varnish逻辑无关；
• 如果容器内curl成功，再用varnishadm手动发起请求，验证Varnish的缓存逻辑是否干扰了请求。

内容的提问来源于stack exchange，提问作者Felix Steiner