Nginx 中实际生效的是 keepalive_timeout 和 keepalive_requests，二者协同构成双杀机制决定长连接生命周期：谁先触发（时间超时或请求数达上限）即断连，从而缓解 worker 进程与 upstream 节点的热点倾斜。
keepalive_time 不是 Nginx 官方配置项，Nginx 中实际生效的是 keepalive_timeout（控制空闲超时）和 keepalive_requests（控制请求数上限），二者共同决定一条长连接的“绝对生命周期”——谁先触发，连接就立即关闭。所谓“防止流量在固定节点产生热点倾斜”，本质是避免大量客户端长期黏连到同一 worker 进程或 upstream 后端实例，导致资源不均、内存堆积、响应延迟上升。
keepalive_timeout + keepalive_requests 共同构成“双杀机制”
单靠时间或请求数都不够，必须协同设置才能形成确定性的连接退出边界：
- keepalive_timeout：设为 15–30 秒（API 场景建议 20 秒）。它定义连接空闲多久后自动断开，直接控制 fd 和内存句柄释放节奏
- keepalive_requests：设为 500–1000（React 应用推荐 1000，网关类建议 800）。它按请求计数主动掐断连接，防止单连接被反复复用、长期驻留
- 两者取先触发者：一个连接若 5 秒内处理完 1000 次请求，立刻断；若 1000 次还没跑完但已空闲满 20 秒，也立刻断
为什么能缓解节点热点倾斜
长连接不退出，就会持续绑定在某个 worker 进程的 event loop 和某个 upstream 连接池槽位上。当大量用户长时间保持连接，会造成：
Twitter热点监控与推文生成
下载
每小时自动在推特搜索中国、加密货币、国际热点、美国热点、特朗普等话题的热度信息，提取前十热点，依据 X 平台真实算法权重（开源代码数据）为每个热点生成高曝光推文或线程。用户提及“推特热点”“Twitter热点”“推特搜索”“热点推文”“生成推文”“社交媒体监控”“Twitter监控”等关键词时触发。
- worker 进程间连接数严重不均（比如 4 个 worker，两个占了 80% 的 keepalive 连接）
- upstream 后端实例连接分布失衡（如 3 台后端，一台扛了 90% 的复用连接）
- 连接池 slot 被“老连接”长期占满，新请求被迫新建连接，加剧 TIME_WAIT 和资源争抢
通过缩短绝对生命周期（例如将平均连接存活压缩到 15–25 秒），强制连接高频轮换，天然打散黏性，让负载更均匀地落在各 worker 和后端节点上。
配套必须做的三件事
只调这两个参数还不够，需同步落实以下措施才能真正防倾斜：
-
upstream 中启用 keepalive 并设合理池大小：例如
keepalive 64;（不是越大越好，建议按后端单实例稳定并发 × 0.7 ÷ worker 数估算） -
禁用 upstream 主动发 Connection: close：确保后端不干扰复用，例如 Flask 需设
keep_alive = True，FastAPI 默认支持，但要确认反向代理头未被覆盖 - 开启 reset_timedout_connection on：对已超时但未正常关闭的连接直接 RST 复位，加速槽位释放，避免“僵尸连接”拖慢整个池
验证是否真起效
别只看配置写了没，重点观察运行态指标：
- 用
ss -tn state established '( dport = :443 )' | wc -l在低峰期测连接数，应随流量明显起伏，而非长期高位平缓 - 打开 stub_status，关注
Reading/Writing/Waiting分布，Waiting 长期 > 300 说明空闲连接堆积，参数偏松 - 通过
$connection_requests日志变量统计单连接请求数分布，峰值应集中在设定的 keepalive_requests 值附近（如设 1000，则多数连接在 950–1000 次请求后断开）
