proxy_read_timeout需调大至360秒，因报表导出存在后端计算延迟导致首字节响应超时；须在location块中同步调整proxy_send_timeout、send_timeout，并检查client_max_body_size与缓冲区配置。
proxy_read_timeout 必须调大，否则 Nginx 会在后端还在生成报表时主动断开连接，前端收到 504 Gateway Timeout —— 这不是后端挂了，是 Nginx 先放弃了。
为什么默认 60 秒对报表导出完全不够用
默认值 proxy_read_timeout 60 指的是：Nginx 转发请求给后端后，**等待后端返回响应体第一个字节的最长时间**。注意，它不计算后端处理逻辑耗时，也不管响应体是否发完，只卡“首字节到达前”的空等时间。
但报表导出类场景（如导出 10 万行 Excel、聚合 24 小时日志 PDF）往往有明显两阶段：后端先花几十秒查库/计算，再流式写入响应体。这期间 Nginx 看不到任何数据，就直接触发超时。
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 典型错误现象：
upstream timed out (110: Connection timed out) while reading response header from upstream - 这个日志出现在
error.log，且时间点常早于后端实际完成时间 - 浏览器 Network 面板看到状态码是
504，Response Headers 里没有Content-Length或Transfer-Encoding: chunked
怎么设才合理：按业务最大耗时 + 安全余量
不能拍脑袋填 3600（1 小时），也不能盲目设成 0（禁用超时）。关键是匹配真实业务瓶颈，并留出缓冲。
- 先确认后端最长导出耗时：比如压测发现导出峰值报表平均 210 秒，P99 是 285 秒 → 基线取 300 秒
- 再加安全余量：网络抖动、DB 临时慢查询、GC 暂停都可能多拖 10–30 秒 → 建议 +60 秒
- 最终配置：
proxy_read_timeout 360;（单位秒，整数即可） - 必须同步检查
proxy_send_timeout（Nginx 向后端发请求的超时）和send_timeout（Nginx 向客户端发响应的超时），它们默认也是 60，同样要调大，否则可能在传输中途断连
别漏掉 location 粒度的覆盖和 client_max_body_size
报表导出接口通常走特定路径，比如 /api/v1/export 或 /report/download。如果只在 http 或 server 块设 proxy_read_timeout，可能被更细粒度的 location 块覆盖或忽略。
- 务必在对应
location块内显式设置：location /api/v1/export {<br> proxy_pass http://backend;<br> proxy_read_timeout 360;<br> proxy_send_timeout 360;<br> send_timeout 360;<br>} - 同时检查
client_max_body_size：某些导出请求带复杂筛选参数（如 JSON body），若超过默认 1MB，会直接返回413 Request Entity Too Large，和超时无关但容易混淆 - 如果用了
proxy_buffering off（常见于流式导出），更要确保proxy_buffer_size和proxy_buffers不过小，否则 Nginx 可能因缓冲区满而提前中断连接
真正难调的不是数值本身，而是判断“后端到底花了多久才吐出第一个字节”——建议在后端加日志打点，记录从收到请求到 response.writeHeader() 或 Response.flushBuffer() 的时间，再比对 Nginx error.log 的超时时间戳。两者差值大于 60 秒，基本就能锁定是 proxy_read_timeout 在作祟。
