直播、IM、推送类业务最怕中途断链。很多“玄学”现象，落到 IP、DNS、指纹、行为这几层上，都能解释清楚。

下面按“先判断范围、再处理、最后防复发”的顺序展开，涉及 长连接、代理 的关键动作都给了具体做法，可以照着走。

要求

支持 TCP 透传，不能只做 HTTP 转发。

动手前先确认影响范围，能局部处理就不要影响整机。

保活

心跳间隔要小于中间设备超时。

容易踩的坑：变更没留记录，下次故障时没人知道上一轮改了什么。

切换

断线后要能快速重连到同一出口。

这一步的判断依据建议写进操作记录，下次直接照做，不用重新摸索。

测试

连续跑 24 小时看断连次数。

速查表

常见问题

Q：长连接这类问题，最快的判断办法是什么？
先确认现象的范围：只有单台还是全部、只在某个时段还是持续。范围一缩小，原因基本就浮出来了。

Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。

小结

回到这篇的四个环节：要求、保活、切换、测试。把证据链固定成流程，比反复试错划算得多。相关判断标准建议做成表格长期维护。

相关阅读：代理池的轮换策略、代理稳定性该看哪些指标、代理延迟对业务的实际影响。