nginx仍向已下线后端转发请求，主因是健康感知与连接释放节奏未对齐：需确认max_fails/fail_timeout或active check是否启用，排查keepalive长连接未释放及ip_hash老连接残留，并验证运维操作闭环（如后端优雅停机、nginx reload后旧worker退出）。
后端节点已下线，Nginx 却还在往它转发请求——这不是配置没生效，而是“下线”和“Nginx 停止派发”的节奏没对齐。关键要区分：是 Nginx 根本没感知到下线，还是感知到了但老连接还在持续打过去。
确认节点是否真被标记为不可用
Nginx 不会主动轮询后端状态，它靠两种机制判断节点可用性：被动失败计数（max_fails/fail_timeout）或主动健康检查（需第三方模块）。若只改了后端服务状态而没配这些，Nginx 就当它一直在线。
- 检查 upstream 中每个 server 是否设置了 max_fails=2 fail_timeout=5s（短连接推荐值），且 location 块启用了 proxy_next_upstream error timeout http_502 http_504
- 若用 nginx_upstream_check_module，确认 check 指令已启用，且后端 /health 接口在下线前返回 503；查看 error_log 中是否有 "check failed" 或 "server ... is down" 日志
- 执行 nginx -T | grep -A 10 "upstream"，核对当前生效配置里该节点是否仍存在、有无 down 或 weight=0 标记
排查长连接未释放导致的“假存活”
HTTP/1.1 keepalive 或 gRPC 长连接可能让旧连接持续复用，即使节点已下线，Nginx 仍把新请求塞进已有连接通道，造成“明明停了还在收请求”的错觉。
- 在 access_log 中添加 $upstream_addr $connection_requests，观察同一客户端多次请求是否始终落到同一 IP，且 $connection_requests 持续增长（如从 1 到 87）→ 表明连接未重分配
- 在后端机器上运行 ss -tn state established | grep :端口 | wc -l，对比各节点 ESTABLISHED 连接数；若已下线节点仍有大量连接，说明它没真正关闭 socket
- 检查 Nginx 是否开了 keepalive 32，但没配 proxy_http_version 1.1 和 proxy_set_header Connection ""，导致连接复用失控
验证流量是否真的停止派发
别只看后端日志有没有新请求，要从 Nginx 侧确认请求是否还走向该节点。
- 临时开启 debug 级 error_log：error_log /var/log/nginx/debug.log debug;，然后 grep "upstream: ...192.168.1.10:8080"，看是否有 "connect() failed" 或 "no live upstreams" 等提示
- 用 curl 发起带唯一标识的请求：curl -H "X-Trace-ID: test-$(date +%s)" http://nginx/api/test，再查 access_log 中该 trace-id 对应的 $upstream_addr 是否还出现下线节点
- 若用 ip_hash，注意 down 节点会被跳过，但已有哈希绑定的老连接仍会继续打过去——这是设计行为，不是 bug
检查运维操作是否真正完成闭环
很多“下线后还有请求”源于操作断层：后端停了入口，但连接池没清空；Nginx reload 了，但 worker 进程还在处理旧连接。
- 后端下线时，是否先返回 503 并等待活跃连接自然关闭？Spring Boot 可调 /actuator/refresh 或 shutdown Tomcat connector；Netty 应调用 shutdownGracefully()
- Nginx 执行 nginx -s reload 后，老 worker 进程会继续处理完已有连接才退出，可通过 ps aux | grep nginx 观察是否存在旧进程
- 云环境要注意目标组注册状态（如 AWS ALB）、服务发现刷新延迟（如 Consul TTL）、容器网络策略（如 CNI 插件未及时更新 endpoint）
