核心解法是启用Nginx到PHP-FPM的FastCGI长连接：配置upstream keepalive与fastcgi_keep_conn on，从源头减少TIME_WAIT；辅以tcp_tw_reuse=1、tcp_tw_recycle=0等内核优化及连接数合理管控。
核心思路是：让 Nginx 与 PHP-FPM 之间尽量复用 TCP 连接，避免每次请求都新建+主动关闭，从而从源头减少 TIME_WAIT 的产生。端口耗尽本质是短连接高频销毁导致的本地端口池枯竭，不是靠“加大端口范围”硬扛，而是要切断生成逻辑。
确认问题是否出在 FastCGI 连接上
先定位瓶颈点，别一上来就调参数：
- 运行 ss -tan | grep ':9000' | grep TIME-WAIT | wc -l（假设 PHP-FPM 监听 9000）——若结果远超 2–3 万，说明 FastCGI 层确实在大量产生 TIME_WAIT
- 对比 ss -tan | grep ':80' | grep TIME-WAIT | wc -l（Nginx 对外端口）——若对外连接 TIME_WAIT 很少，但对内 9000 端口堆积严重，基本可锁定是 Nginx → PHP-FPM 这一跳用了短连接
- 检查 Nginx 配置中 fastcgi_pass 所在的 location 块，是否缺失 fastcgi_keep_conn on;（这是启用 FastCGI 长连接的关键开关）
启用 Nginx 到 PHP-FPM 的长连接
这是最直接、最有效的解法。默认情况下，Nginx 每次请求都会新建一个到 PHP-FPM 的 TCP 连接，处理完立刻关闭，自己作为主动关闭方进入 TIME_WAIT。开启 keepalive 后，连接会被 worker 进程缓存复用。
- 在 upstream 块中定义 FastCGI 后端，并启用连接池：
upstream php_backend {
server 127.0.0.1:9000;
keepalive 64;
}
其中 64 表示每个 worker 最多缓存 64 个空闲连接；值按后端节点数 × 平均并发 × 1.2 估算，常见取值 32–128 - 在 location 中改用 upstream，并开启长连接支持：
location ~ \.php$ {
fastcgi_pass php_backend;
fastcgi_keep_conn on;
# 其他 fastcgi_param 保持不变
}
fastcgi_keep_conn on 是必须项，它告诉 Nginx 不要在每次请求后断开底层 TCP，而是交由连接池管理 - 确保 PHP-FPM 配置中 pm.max_children 足够支撑并发，且 pm.start_servers 和 pm.min_spare_servers 设置合理，避免因子进程不足导致连接排队或被拒绝
配合基础内核与 Nginx 层优化
长连接解决 90% 问题，但线上环境建议叠加几项安全加固：
- 启用端口快速复用（安全）：
net.ipv4.tcp_tw_reuse = 1
允许内核将处于 TIME_WAIT 的 socket 重用于新的出站连接（如 Nginx 主动连 PHP-FPM），在 NAT 环境下也安全，推荐开启 - 禁用危险回收（必须）：
net.ipv4.tcp_tw_recycle = 0
该参数在有负载均衡、NAT 或多路径网络时会导致连接失败，2026 年所有主流生产环境都应设为 0 - 适度调整连接生命周期：
net.ipv4.tcp_fin_timeout = 30
加快非 TIME_WAIT 状态（如 FIN_WAIT2）的关闭速度，不缩短 TIME_WAIT 本身，但能释放关联资源 - Nginx 层控制连接总量：
在 http 块中设置 worker_connections 4096;，并确保系统级 ulimit -n ≥ 该值 × worker_processes；同时用 limit_conn 控制单 IP 或 zone 并发，防恶意打爆连接池
验证与持续观察
改完配置后不要只看是否“不报错”，要盯住关键指标：
- 重启 Nginx 和 PHP-FPM 后，持续观察：
watch -n 2 'ss -s | grep -i time' —— TIME_WAIT 数量应稳定在几百以内，不再随 QPS 线性上涨 - 用 ss -tan state time-wait sport = :9000 | wc -l 精确统计对 PHP-FPM 的 TIME_WAIT，确认是否大幅下降
- 监控 PHP-FPM 的 slow.log 和 status 页面（需开启），确认活跃连接数、空闲进程数是否平稳，无频繁 spawn/kill
- 注意日志中是否出现 upstream prematurely closed connection 类错误——这可能是 PHP-FPM 子进程异常退出，或 keepalive 连接被后端主动断开，需同步检查 PHP-FPM 的 request_terminate_timeout 和 request_slowlog_timeout
