Nginx错误日志写着 upstream prematurely closed connection while reading response header from upstream，含义是代理还没读到完整响应头，上游连接就结束了。页面可能表现为502，但502只是结果，不等于Nginx本身坏了。
先看同一请求对应的上游应用日志，再区分进程崩溃、重启、请求超限和网络连接中断，不要立即把所有超时参数都调大。
先从错误日志取得上游地址
sudo tail -n 100 /var/log/nginx/error.log
sudo nginx -T日志里的 upstream 地址、请求URI和发生时间能帮助定位哪个服务提前断开。nginx -T 会输出生效配置，可能包含敏感内容，不要直接公开整份输出；先核对对应server/location中的 proxy_pass 或FastCGI配置。
检查应用进程是否重启或退出
到上游主机或容器查看同一时段的服务日志、退出码、重启次数与OOM记录。上游程序在发送HTTP响应头之前退出，代理端就可能记录提前断开的现象。若使用容器，应检查应用进程和容器生命周期，而非仅看端口是否开放。
先修复崩溃、内存不足或部署重启造成的请求中断。提高代理超时并不能让已退出的进程返回有效响应。
在同一网络路径直连上游验证
curl -v --connect-timeout 3 --max-time 15 http://127.0.0.1:8080/health把地址换成Nginx配置中的实际上游，尽量从Nginx所在主机或同一容器网络执行。比较直连与经过反向代理的表现，记录返回码和响应头。示例健康路径不一定存在于你的应用，测试前应选择已知的只读接口。
分清连接、读取和重试参数
Nginx官方模块文档区分 proxy_connect_timeout、proxy_read_timeout 与 proxy_next_upstream。读取超时衡量两次读取之间的间隔，不是整个请求的绝对时长；上游提前关闭连接与超时也不是同一个事件。
只有查明应用确实需要更长处理时间后才考虑调整超时。重试可能使非幂等请求产生重复操作，涉及写入的接口应先核对业务语义和Nginx重试限制。
核对协议和代理目标
对照 proxy_pass 使用的HTTP或HTTPS协议、目标端口、DNS解析和应用监听地址。若后端是PHP-FPM的FastCGI接口，相关参数属于 fastcgi_* 指令，不应把HTTP反向代理的配置照搬过去。
先确认代理指向真正的服务入口，再检查应用是否能完整写出响应头。服务升级时，旧端口或错误协议也可能使代理层的表象相似。
验证修复并保留回滚入口
修改配置后先运行 sudo nginx -t，再按发行版的服务管理方式重载。用原本触发问题的只读请求验证，观察同一时间段的Nginx错误日志及应用日志，确认没有新的提前关闭记录。
需要在隔离环境还原代理与应用拓扑，可分别使用 萤光云 和 LightNode 的测试主机；生产变更仍应先备份配置。验收看上游响应完成、用户请求正常以及错误日志不再增长。
FAQ
看到502就应该加大 proxy_read_timeout 吗？不应该。先确认上游是否退出，以及日志是否真的是读取超时。
直连上游正常为何代理仍报错？检查Nginx使用的目标地址、协议、网络路径和请求头是否与直连测试一致。
温馨提示
不要把一次随机请求成功当作修复完成。应覆盖出错时段的真实请求类型，并记录配置修改与回滚方式。
