proxy_read_timeout仅控制Nginx收到响应头后等待响应体数据到达的最大空闲时长，超时即断连返回504；需按路径用location隔离配置，同步调大proxy_send_timeout、send_timeout及upstream keepalive，并确保后端超时设为该值的0.8倍。
proxy_read_timeout 本身不解决响应延迟问题，它只负责在后端已返回响应头的前提下，控制 Nginx 等待后续响应体数据到达的最大空闲时长。真正耗时长的业务（如报表导出、AI 推理、批量同步）若被默认 60 秒打断，用户看到的是 504，但根源不是“Nginx 慢”，而是超时配置与业务节奏不匹配。
要让 proxy_read_timeout 发挥作用，关键在于精准设值 + 协同调优，而不是单纯拉高数值。
按业务路径隔离配置，避免一刀切
后端同时跑登录接口和导出任务？不能共用一个 timeout。必须用 location 显式区分：
- 普通 API（如
/api/user,/health）：保持proxy_read_timeout 20;，快速失败利于前端降级 - 长耗时路径（如
/api/export/,/downloads/.*\.(xlsx|pdf)）：单独写location块，设更高值 - 参考真实监控数据：取该路径近 7 天 P99 耗时 × 1.2～1.5。例如 P99 是 230 秒 → 设
300；若波动大（30 秒～8 分钟），宁可略高，但避免填86400
同步调这三项，否则单改无效
只动 proxy_read_timeout 就像加固门却忘了关窗：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
proxy_send_timeout≥ 你设的proxy_read_timeout：确保大请求体（如带 token 的导出参数、XML 文件）能完整发给后端 -
send_timeout≥proxy_read_timeout：防止弱网用户下载慢，Nginx 在转发响应体时提前断开客户端连接 -
upstream块启用keepalive 32;，并配proxy_http_version 1.1;和proxy_set_header Connection '';：否则每次请求都重建 TCP 连接，再长的 timeout 也没意义
后端超时必须比 Nginx 小，留出缓冲
Nginx 和后端超时要错开，避免互相“等死”：
- 若
proxy_read_timeout设为300秒，Tomcat 的connectionTimeout或 Spring Boot 的server.tomcat.connection-timeout应设为240秒左右（0.8 倍） - 太接近（如后端设
295秒）→ Nginx 还没超时，后端先断，结果报502或504 - 太宽松（如后端设
600秒）→ Nginx 先超时，后端还在跑，浪费资源且无预警
流式接口要关缓冲、支持分块
对导出 Excel、SSE、实时日志等流式响应：
- 加
proxy_buffering off;：避免 Nginx 缓存整块响应再吐给客户端，导致“卡住假超时” - 可加
chunked_transfer_encoding on;：提升大响应兼容性 - 注意：WebSocket 或 SSE 场景下，
proxy_read_timeout控制的是两次数据帧之间的最大静默间隔，不是会话总时长
不复杂但容易忽略
