自建AI中转遇到运营商QoS，大流量长连接被切断问题
自建AI中转服务跑着跑着就断，尤其是流量一大、连接开久了就被掐断，十有八九是运营商在中间做了QoS限速或阻断。
本文先帮你确认这个判断，再给出从服务端和客户端两侧都能落地的调整方案，让长连接在现有网络条件下尽量稳定存活。
第一步：确认断连现象是不是运营商QoS造成的
先别急着改配置，把问题定位清楚。
运营商的QoS策略通常表现为：持续大流量传输一段时间后连接被重置（RST）或静默丢弃（无响应），而小流量连接或刚建立的连接正常。
在服务器上执行下面命令，查看当前TCP连接状态：
ss -s
ss -tn state established | wc -l如果连接数并不多（例如几十个），
但每个连接都只存活几分钟就被断开，
再配合客户端日志里的 Connection reset by peer 或 timeout，
基本可以怀疑是QoS干预。
更准确的判断是抓包看断连前的网络行为。
在服务端抓包一段时间：
tcpdump -i eth0 -nn 'tcp port 你的中转端口' -w qos.pcap然后检查断开瞬间是收到 RST 还是只出现大量重传。
若多次在同一传输量级或时间点断开，说明运营商确实在做限制。
第二步：从服务端参数入手，提高长连接存活率
确认和QoS相关后，先调整服务端的内核参数，让TCP本身更抗断开。
打开 /etc/sysctl.conf，增加或修改以下内容：
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_retries2 = 5执行 sysctl -p 生效。
其中 tcp_keepalive_time 从默认7200秒缩短到60秒，能让服务端更快发现死连接并主动回收，减少被运营商沉默丢包后的挂死时间。
如果你的中转服务本身支持TCP Keep-Alive参数，也建议在应用里开启并设置较短间隔。
比如Nginx反代场景，可以在配置块中加入：
proxy_socket_keepalive on;
proxy_read_timeout 300s;
proxy_send_timeout 300s;第三步：客户端侧尽量用空闲保活和自动重连机制
服务端调完，客户端也要配合。
AI中转大流量场景下，客户端经常长时间空闲（比如等待模型响应）后触发运营商空闲超时断开。
此时应用层心跳或TCP Keep-Alive能起到“占线”作用。
如果使用OpenAI兼容SDK或自研脚本，在TCP连接之上额外发心跳包更可靠。
以Python为例，连接建立后每60秒发送一个空白或注释字符请求：
import socket
import time
s = socket.create_connection(("你的服务器IP", 端口), timeout=30)
s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 10)
while True:
# 正常业务请求逻辑
pass同时，客户端必须实现指数退避自动重连。
断连发生后不要立刻疯狂重连，否则更容易触发运营商封禁。
建议第一次等待2秒，之后按4秒、8秒、16秒递增，最大不超过120秒。
第四步：降低被QoS关注的几个实用避坑方法
- 降低单连接峰值：把大流量拆到多个TCP连接上，避免单连接长时间跑满带宽。例如在负载层设置每个上游连接的最大带宽或请求数。
- 启用压缩：如果中转的文本数据可压缩（如JSON），开启gzip或zstd，能显著减少传输体积，降低触发阈值概率。
- 换用非标准端口：部分运营商会优先针对常见80/443端口做深度包检测，改成8443、2053等非常用HTTPS端口，偶尔能绕过简单QoS规则。
- 避免跨运营商高峰时段跑大任务：晚上9点到11点更容易被限速和断连，批量任务尽量错峰。
常见疑问：换CDN或改UDP能做到彻底解决吗？
换CDN本质是换IP和链路，如果运营商针对的是流量特征而非目标IP，CDN同样会被限。
改成UDP（如QUIC）能绕过部分TCP层QoS，但自建中转使用UDP会受到运营商UDP限速更明显，且配置复杂度高。建议优先做连接保活和重连，而不是押注在单一对抗手段上。
最终验证：观察断连频率是否下降
调整完成后，连续运行24小时，统计同样的中转任务下断连次数。
你可以在服务端用 last -n 20 或中转应用日志里的重建连接次数来做对照。
如果断连频率从每小时多次降到每天一两次，则说明当前方案已接近运营商QoS规则的容忍上限。
另外，观察重连后的连接是否还能继续完成之前的请求。
如果业务侧做了请求幂等处理，即使断开重连也不会丢任务，这才是最关键的结果。
自建AI中转想完全避开运营商QoS限制很难，但通过缩短探活周期、增加心跳、控制单连接峰值和合理重连，能让断连对业务的影响降到最小。
如果你的网络环境比较特殊，也可以把本文的sysctl参数和客户端心跳间隔再按实际情况微调。
