核心是启用内核级TCP keepalive并协同调优：so_keepalive=on配合系统参数net.ipv4.tcp_keepalive_time=600、intvl=60、probes=3；proxy_timeout设为8h或1d以匹配业务空闲窗口；proxy_responses 1确保后端真正就绪；同步加固文件描述符、连接队列与TIME_WAIT回收。
用 Nginx stream 模块配置四层 TCP 长连接的长效保持，核心是让连接“活下来、不被掐、不误断”。它不靠应用层心跳，而是通过内核级保活机制和精准超时控制，把连接稳稳托住，特别适合数据库、WebSocket 后端、IoT 设备直连等场景。
启用 TCP Keepalive 并调优内核参数
so_keepalive=on 是基础，但光开开关不够，得配合系统级参数才能真正防断连：
- 在 server 块中显式写 so_keepalive=on，启用内核自动发送 keepalive 探针
- 同步调整内核参数：
net.ipv4.tcp_keepalive_time = 600（首次探测前空闲时间）
net.ipv4.tcp_keepalive_intvl = 60（重试间隔）
net.ipv4.tcp_keepalive_probes = 3（失败后重试次数） - 这些值比默认更激进，能更快发现链路异常，避免连接卡在“半死”状态
设置合理且宽松的 proxy_timeout
长连接怕的不是慢，而是“静默超时”。proxy_timeout 决定空闲多久就断开，必须覆盖业务最大空闲窗口：
- MySQL 类场景：设为 proxy_timeout 8h（28800s），匹配 mysqld 的 wait_timeout
- WebSocket 后端：建议 proxy_timeout 1d（86400s），覆盖整日会话周期
- 切忌设成默认的 60s 或 300s——那是为短连接设计的，对长连接等于主动断链
用 proxy_responses 控制连接就绪判定
三次握手成功 ≠ 后端服务已准备好。proxy_responses 可防止“假连接”：
- proxy_responses 1 表示：必须等到后端返回第一个数据包，才认为连接建立完成
- 这对 MySQL、Redis 等很关键——端口监听了，但进程可能还没加载完库或初始化完连接池
- 若设为 0（默认），Nginx 会在 SYN-ACK 后立即转发，容易导致客户端发包失败
配套系统资源与连接队列加固
再好的配置，碰上系统瓶颈也会失效。长连接数上来后，这些必须同步到位：
- 提升单进程文件描述符上限：worker_rlimit_nofile 2097152，并在 limits.conf 中为 nginx 用户设 soft/hard nofile 2097152
- 增大监听队列：net.core.somaxconn = 65535，避免新连接被丢弃
- 加速 TIME_WAIT 回收：net.ipv4.tcp_tw_reuse = 1（仅客户端主动发起时生效）
- events 块中启用 epoll 并设高 worker_connections：worker_connections 1048576
