Varnish服务器峰值时段间歇性返回503错误排查求助

流量峰值时段Varnish间歇性返回少量503响应，日志显示：

FetchError     HTC status -1
BackendClose   32 reload_2024-09-18T174244.ml1
BerespStatus   503
BerespReason   Service Unavailable
BerespReason   Backend fetch failed

后端为Flask+uWSGI应用，已增加后端进程/线程数但无改善，且这类5xx请求响应时间小于1毫秒，排除超时问题。

以下是具体排查思路：

• 排查Varnish后端健康检查配置
  HTC status -1通常与后端连接或健康检查异常相关。检查VCL中是否配置了合理的probe规则，包括健康检查间隔、超时阈值，确认是否因健康检查误判导致后端被临时摘除，峰值时无可用后端返回503。可执行varnishadm backend.list命令查看后端实时健康状态，验证峰值时段是否有后端被标记为不健康。

• 检查Varnish与后端的连接数限制
  即使后端进程/线程充足，Varnish自身的后端连接池可能达到上限，或uWSGI的监听队列溢出。查看Varnish后端配置的max_connections参数，同时检查uWSGI的listen队列长度：用netstat -anp | grep uwsgi查看是否存在大量SYN_RECV状态的连接，或查看uWSGI日志是否有listen queue overflow报错——这类情况会导致Varnish无法快速建立连接，瞬间返回503。

• 捕获更详细的Varnish请求日志
  HTC status -1表示Varnish在与后端交互的早期阶段（连接建立、请求发送或响应接收初期）失败。执行varnishlog -g request -q "BerespStatus == 503"捕获完整的请求流程，查看是否有BackendOpen失败、ReqError等更具体的日志条目，定位是TCP连接失败、后端拒绝连接还是HTTP协议异常。

• 排查后端socket的可用性
  检查uWSGI监听的socket（文件socket或TCP端口）：若为文件socket，确认Varnish进程是否有读写权限，uWSGI的chmod-socket参数是否正确设置；若为TCP端口，检查是否被其他进程占用，峰值时段是否出现端口波动。

• 检查系统层面的资源限制
  系统文件描述符限制可能导致Varnish或uWSGI无法创建新连接。用ulimit -n查看进程的文件描述符上限，确保Varnish和uWSGI的进程已设置足够的nofile限制（可通过修改/etc/security/limits.conf或启动参数调整）。同时检查系统net.core.somaxconn参数，确保其值足够大以避免监听队列溢出。

• 验证后端负载均衡策略
  若使用两台后端，检查VCL中的负载均衡规则（如round-robin）是否存在隐性问题。可临时将流量切至单台后端测试，若503消失，说明其中一台后端存在偶发故障（如特定请求处理失败），导致Varnish转发时瞬间返回错误。

内容的提问来源于stack exchange，提问作者Sourabh Ojha