合理调整 proxy_read_timeout 的核心是精准匹配后端真实响应节奏，它仅控制后端返回响应头后等待响应体数据到达的最大空闲间隔；需按业务路径在 location 块中隔离配置，同步调优 proxy_send_timeout、send_timeout 和 upstream keepalive，并确保后端超时设为 nginx 值的 0.8 倍，流式接口还需关闭 proxy_buffering 并启用 chunked_transfer_encoding。
合理调整 proxy_read_timeout 的核心，是让它精准匹配后端真实响应节奏，而不是盲目拉长等待时间。它只管一件事：后端已返回响应头（如 HTTP/1.1 200 OK）之后，Nginx 等待后续响应体数据到达的**最大空闲间隔**。超了就断连、报 504；设太小，任务还在跑就被砍掉；设太大，连接僵死、资源堆积。
按业务路径单独配置，不搞全局一刀切
后端同时跑着登录接口和报表导出？不能全用一个值。必须用 location 块隔离：
-
普通 API 路径（如
/api/user、/api/order）：设proxy_read_timeout 10–20s。P99 通常 1–3 秒，留 5 倍余量足够，快速失败利于前端降级 -
明确长耗时路径（如
/api/export/、/api/submit-xml、/api/v1/report/query）：单独写location，值基于实测 P99 × 1.2～1.5。例如导出接口 P99 是 220 秒 → 设为 300 秒较稳妥；若波动大（30 秒～10 分钟），宁可略高，但避免填 86400
必须同步调这三项，单改无效
只动 proxy_read_timeout 就像加固门却忘了关窗：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
proxy_send_timeout≥ 你设的proxy_read_timeout：防止大请求体（如含 Base64 的 JSON 或上传文件）还没发完就被切断 -
send_timeout≥proxy_read_timeout：确保弱网用户下载导出文件时，Nginx 不会中途断开客户端连接 -
upstream 启用
keepalive：比如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;：启用分块传输，提升大响应兼容性 - 注意：
proxy_read_timeout在流式场景下，控制的是两次数据帧之间的最大静默间隔，不是会话总时长
