必须先做可控测试再改生产超时参数：用本地延迟服务模拟后端慢响应，分阶段验证proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，并结合Nginx日志与后端日志交叉确认超时原因。
直接在生产环境改超时参数风险高，必须先做可控测试。核心思路是：模拟后端延迟，观察 Nginx 行为是否符合预期，再结合日志和耗时字段交叉验证。
用 curl 模拟慢响应，验证 proxy_read_timeout
不依赖真实后端，用工具制造可控延迟：
- 启动一个本地延迟服务：python3 -m http.server 8000 --bind 127.0.0.1:8000（基础）；更推荐用 slowcgi 或 mock-server 支持毫秒级响应延迟
- 在 Nginx 的 upstream 中指向该地址，例如：upstream backend { server 127.0.0.1:8000; }
- 在 location 块中设置不同 proxy_read_timeout，比如 5s、15s、60s
- 用 curl 发起请求并计时：time curl -v http://localhost/api/test，观察返回状态码和实际耗时
抓取 access.log 和 error.log 对照看
单靠 curl 输出不够，要查日志确认 Nginx 内部判定逻辑：
- 在 access.log 中找对应请求的 $request_time 字段，它代表 Nginx 从收到请求到返回响应的总时间
- 在 error.log 中搜同一时间点的错误记录，看是否出现 upstream timed out while reading response header
- 如果 $request_time ≈ proxy_read_timeout 且 error.log 有超时日志，说明参数生效；如果 $request_time 明显小于该值但已返回 504，可能是后端提前断连或网络问题
分阶段压测，区分 connect/send/read 三类超时
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout 各管一段，需分别验证：
- 测 connect 超时：停掉后端服务，调小 proxy_connect_timeout 到 2s，curl 应快速返回 502，error.log 显示 connect() failed (111: Connection refused)
- 测 send 超时：用大 body 请求（如 10MB 文件），后端故意不读取 body，调小 proxy_send_timeout，观察是否在发送中途中断
- 测 read 超时：后端接受请求后 sleep 20s 再返回，设 proxy_read_timeout 10s，应触发 504；设为 30s，则应成功返回
配合后端日志，确认是真慢还是假超时
避免误判，一定要让后端也打日志：
- 后端在收到请求时记一条“start”，返回前记一条“end”，中间打时间戳
- Nginx 返回 504 时，去查后端日志：如果后端“end”时间晚于 Nginx 的 $request_time，说明确实是后端慢；如果后端“end”早于该时间，说明是网络传输或 Nginx 缓冲问题
- 特别注意 PHP-FPM 的 request_terminate_timeout 和 Java 的 GC STW，它们可能在 Nginx 超时前就杀掉了请求
