proxy_send_timeout 对静态请求无效，因其仅控制发送请求体超时；静态请求无请求体，真正影响延迟的是 proxy_connect_timeout、proxy_read_timeout 和 send_timeout。

proxy_send_timeout 不适用于处理“向后端发送静态请求的延迟”。

因为静态请求本身没有请求体（request body）。
proxy_send_timeout 专管 Nginx 向后端发送请求体数据（如 POST 表单、文件流、大 JSON、Base64 内容等）时的超时——它只在 Nginx 正把 body 一块块发给 upstream 的过程中起作用。

而静态请求（例如 GET /style.css、GET /images/logo.png）：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 请求方法是 GET
• 没有请求体（Content-Length: 0 或无该头）
• Nginx 向后端转发时，只发请求行 + 请求头，不发 body
• 所以 proxy_send_timeout 根本不会被触发

✅ 此时真正可能影响延迟的参数是：

• proxy_connect_timeout：Nginx 建连后端失败或过慢（如 DNS 慢、网络抖动、后端未监听）
• proxy_read_timeout：后端已连上，但迟迟不返回响应头或响应体（如静态文件磁盘 I/O 卡顿、权限问题、路径错误导致 404 响应慢）
• send_timeout：Nginx 把响应发给客户端时卡住（如客户端弱网、TCP 窗口满、连接假死）

⚠️ 常见误操作：

• 在 location ~ \.(css|js|png|jpg)$ 中盲目加大 proxy_send_timeout
  → 实际无效，配置冗余，还可能掩盖真实瓶颈

? 如果你观察到静态资源返回慢，建议按顺序排查：

• 确认是否真走代理：静态文件通常由 Nginx 直接 root/alias 服务，不经过 proxy_pass；若走了 proxy，先评估是否必要
• 检查后端是否真的在提供这些静态文件（比如误配 proxy_pass 到一个不托管静态资源的应用）
• 查看 Nginx error.log 是否有 upstream timed out (110: Connection timed out) while connecting to upstream（指向 proxy_connect_timeout 不足）
• 或 upstream timed out (110: Connection timed out) while reading response header from upstream（指向 proxy_read_timeout 不足）

? 总结一句话：
静态请求无 body，proxy_send_timeout 不生效；调它没用，该查建连、读响应、或干脆改用本地服务。