Nginx 面对上游响应缓慢时无内置熔断，需通过分层超时、缓冲区限制、连接管理及重试策略等显式配置实现自我保护。
Nginx 的异步非阻塞架构在面对上游（upstream）响应缓慢时，并不会自动“自我保护”，而是依赖显式配置来限制资源消耗、避免雪崩。它的健壮性不来自内置熔断，而来自可精细控制的超时、缓冲区、连接数和重试策略。
超时控制是第一道防线
上游慢响应最直接的应对是设置分层超时，避免请求无限等待：
- proxy_connect_timeout：与上游建立 TCP 连接的最长等待时间，通常设为 1–5 秒，防止卡在三次握手或 SYN 队列中
- proxy_send_timeout：Nginx 向上游发送完整请求后，等待上游开始返回响应头的时限（不是整个响应），建议 10–30 秒
- proxy_read_timeout：从上游读取响应体的持续空闲超时，适用于流式或大文件场景，需结合业务节奏设定
缓冲区与内存使用需主动约束
默认情况下，Nginx 会将上游响应暂存于内存或临时文件中再转发给客户端。上游响应慢但数据量大时，可能耗尽 buffer 或填满磁盘：
- proxy_buffering on/off：关闭后 Nginx 边收边转，降低内存压力但失去响应头修改能力（如 add_header）
- proxy_buffer_size 和 proxy_buffers 控制初始响应头和响应体的内存缓冲上限
- proxy_max_temp_file_size 和 proxy_temp_path 限制写入临时文件的规模与位置，防止 /tmp 被打爆
连接管理防止上游拖垮 Nginx 工作进程
每个 upstream 连接都会占用 worker 进程的一个事件槽位。上游长期 hang 住会导致可用连接耗尽，新请求排队甚至被拒绝：
- proxy_requests 可配合 limit_req 实现每 upstream 连接的请求数限制（较少用）
- 更常用的是 upstream 中的 max_conns（需启用 keepalive）+ queue 指令，对超出连接池的请求排队而非立即失败
- 搭配 keepalive 指令复用连接，减少频繁建连开销，但需确保 upstream 支持 HTTP/1.1 keep-alive 或 HTTP/2
主动降级与快速失败策略
当上游持续不可靠时，仅靠超时不够，需引入外部干预逻辑：
- 用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504 开启失败重试，但要慎用 timeout 重试——可能放大上游压力
- 配合 proxy_next_upstream_tries 和 proxy_next_upstream_timeout 限制重试次数与时长
- 高级场景可接入 OpenResty，基于共享字典（shared dict）实现简单熔断计数器，或调用外部健康检查服务动态摘除节点
真正可靠的自我保护，是把 Nginx 当作一个可编程的边界网关，而不是黑盒代理。所有“自动”行为都源于你明确写的指令。
