Nginx应对后端临界过载需组合配置：降权至30%～50%并保留健康检查、启用slow_start防冷启动冲击、切换least_conn调度、收紧超时参数，并实时验证日志与监控指标。
当后端节点处于临界过载状态（比如 CPU 持续 ≥85%、P95 响应时间翻倍、错误率突升），Nginx 的静态 weight 本身不会自动“减负”，但可通过组合配置主动为其释放压力，让其获得喘息窗口。关键不是调小 weight 数字本身，而是切断新增流量 + 防止雪崩 + 保留恢复通道。
权重要降，但不能归零
weight=0 确实能停止分发新请求，但它会让该节点完全脱离健康检查视野——你无法知道它是否正在缓慢恢复。更稳妥的做法是：
- 将 weight 调低至原值的 30%～50%（例如从 10 降到 3 或 4）
- 同时保留
max_fails=2 fail_timeout=30s，确保它仍被探测 - 这样既大幅减少新请求，又能让 Nginx 持续观察其
/health?ready=1返回是否变正常
必须启用 slow_start，防重启压垮
节点若因 GC、慢查询或锁竞争临时卡顿，恢复后直接全量承接流量极易再次崩溃。应在 server 行中加：
server 192.168.1.20:8080 weight=3 max_fails=2 fail_timeout=30s slow_start=60s;
slow_start=60s 表示：该节点从健康检查恢复后，60 秒内权重从 0 线性增长到设定值（3），避免冷启动冲击。
切换调度策略，绕过权重依赖
如果多个节点都逼近临界，单纯调权效果有限。可临时改用 least_conn（最少连接数）策略：
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=10;
server 192.168.1.20:8080 weight=3; # 已降权，但 least_conn 会优先避开连接数高的它
server 192.168.1.30:8080 weight=10;
}least_conn 不看 weight，只看当前活跃连接数。过载节点连接堆积多，新请求自然流向空闲节点，比调 weight 更快见效。
配合超时收紧，快速失败不积压
临界过载时，请求排队等待只会加剧线程阻塞。需缩短 Nginx 层超时，让失败更快返回、客户端重试：
proxy_connect_timeout 2s; proxy_send_timeout 3s; proxy_read_timeout 4s;
这样，一旦后端响应慢，Nginx 在几秒内就断开并转向其他节点，不把请求卡死在过载机器上。
日志与监控必须同步盯紧
调完配置后，立刻验证三项数据（至少等 2～3 分钟）：
- access log 中
$upstream_addr统计：确认目标节点请求数下降比例是否匹配预期 -
$upstream_response_timeP95：看延迟是否开始回落（若仍 >1s，说明应用层瓶颈未解） - error.log 中
upstream timed out是否减少：若没减少，说明超时值设得仍不够紧，或后端已无响应能力
不复杂但容易忽略
