504 Gateway Time-out 表明 Nginx 等待后端响应超时，需按链路四阶段（客户端→Nginx→后端→依赖）定位瓶颈；重点调优 proxy_read_timeout（按 location 精准设置）、fastcgi_read_timeout（PHP 场景）、proxy_connect_timeout 和 proxy_send_timeout，避免全局设 0 或盲目延长。
504 Gateway Time-out 不是服务挂了，而是 Nginx 等后端响应等不及了。关键不是盲目拉长所有超时，而是按请求类型精准控制、上下游协同调优。
先定位真实瓶颈在哪一段
整个链路有四个阶段：客户端→Nginx→后端服务→（后端依赖，如数据库或第三方接口）。504 只说明“Nginx 在某一步卡住了”，但卡在哪得查清楚：
- 看 Nginx error.log，搜索 "upstream timed out"，它会明确写是 connect、send 还是 read 超时
- 如果日志里频繁出现 "connect() failed"，问题在连接建立阶段，重点看
proxy_connect_timeout - 如果报 "upstream sent no valid HTTP/1.0 header" 或直接断连，可能是后端根本没启动或端口不通，属于 502 范畴，不是 504
- 确认后端是否真在处理：登录后端服务器，用
curl -v http://localhost:8080/your-path直连测试耗时，排除网络和代理干扰
按 location 精准调大 proxy_read_timeout
proxy_read_timeout 是最常要改的参数，它控制 Nginx 等待后端返回第一个字节的最长时间。默认 60 秒对普通接口够用，但上传、导出、AI 推理等场景很容易超。
- 不要全局修改，避免掩盖真实性能问题；只对特定路径放宽，例如：
location /upload {
proxy_pass http://backend;
proxy_read_timeout 1200;
}
IBKR Investing with Permission Gate
下载
通过IB网关在Interactive Brokers上投资股票/ETF，使用与okx交易相同的人机确认环节，适用于用户请求检查时
- 值设为 1200 就是 1200 秒，单位可省略；写成
1200s也合法 - 严禁设为 0（禁用超时），会导致连接长期占用，最终耗尽
worker_connections - 建议比后端实际最长处理时间多留 5–10 秒缓冲，而不是拍脑袋设成 3600
PHP 场景必须同步调 fastcgi_read_timeout 和 PHP 层
如果你用的是 PHP-FPM，proxy_* 系列参数完全不生效。Nginx 和 PHP 之间走 FastCGI 协议，起作用的是 fastcgi_read_timeout。
- 在 server 或 location 块中加：
fastcgi_read_timeout 1200; - 同时检查
/etc/php/*/fpm/php.ini中的max_execution_time = 1200 - 更重要的是确认
/etc/php/*/fpm/pool.d/www.conf里的request_terminate_timeout—— 它优先级更高，也必须设为 ≥1200 - 改完记得重启：
sudo systemctl restart php*-fpm && sudo nginx -s reload
别漏掉 connect 和 send 阶段的超时
很多人只盯 proxy_read_timeout，却忽略前置阶段。当后端部署在跨云、高延迟环境，或 Java 应用冷启动慢时，它们也可能先触发 504。
-
proxy_connect_timeout：默认 60 秒。若后端启动需 90 秒（如 Spring Boot 冷启），此值至少设为 100 -
proxy_send_timeout：控制发送完整请求体（比如大文件）的超时。网络抖动时，它可能比 read 更早超时，尤其上传场景建议同步加大 - 这两个值和
proxy_read_timeout没有继承关系，必须显式配置，否则就用默认值
