proxy_send_timeout在Nginx正向代理中无效，因其仅适用于反向代理场景；正向代理应关注proxy_connect_timeout、proxy_read_timeout、keepalive_timeout等底层连接超时参数。
在 Nginx 作为正向代理使用时，proxy_send_timeout 并不生效，也不应被配置或依赖——这是关键前提。
为什么 proxy_send_timeout 在正向代理中无效
Nginx 的 proxy_send_timeout 仅作用于 反向代理场景（即 Nginx 作为服务端，向上游服务器发送请求时控制发送超时）。而在正向代理模式下（Nginx 接收客户端的 CONNECT 请求，建立隧道后直接转发 TCP 流量），Nginx 不解析、不缓冲、不重发 HTTP 请求体，它只是透传字节流。此时整个通信由底层 TCP 连接维持，Nginx 不参与应用层数据的“发送”过程，因此该指令被完全忽略。
常见误配：有人在正向代理配置中加入 proxy_send_timeout 60s;，但实测修改该值对连接行为毫无影响。
正向代理真正需要关注的超时参数
正向代理（尤其是 HTTPS 透传）依赖的是连接级和读写级的底层超时，而非代理模块的 HTTP 超时指令：
- proxy_connect_timeout：仅对 CONNECT 请求本身有效（即建立隧道前的握手阶段），默认 60s，可适当调小（如 10s）避免客户端长时间等待失败连接
- proxy_read_timeout：在隧道建立后，若 Nginx 需要读取上游响应（如某些非纯透传场景或错误响应），才起作用；纯 CONNECT 隧道中通常不触发
- keepalive_timeout：控制客户端与 Nginx 之间空闲连接的保持时间，建议设为 75s 左右，兼容多数客户端的 keep-alive 行为
-
tcp_nodelay / tcp_nopush：对隧道性能有实际影响，建议开启
tcp_nodelay on;减少小包延迟
稳定正向代理的关键实践
除了超时设置，还需注意以下几点以避免连接中断或代理失败：
- 确保使用
resolver指令（配合resolve或 DNS 解析），避免 upstream 域名无法解析导致 CONNECT 失败 - 若需支持 HTTPS 代理，必须启用
ssl_preread on;（配合 stream 模块），并在 stream 上下文中配置透传，而非 http 块 - 避免在 http 块中用
proxy_pass http://...实现“伪正向代理”，这本质是反向代理，不支持 CONNECT 方法，也无法代理 HTTPS - 日志中重点监控
$status和$upstream_http_content_length（仅限非隧道响应），隧道成功时状态码通常是 200，且无响应体
正向代理的核心是 TCP 隧道可靠性，不是 HTTP 代理的请求生命周期管理。盯住连接建立、空闲保持和底层传输，比纠结 proxy_send_timeout 更有效。
