挂机类业务最怕换线：地址一变，进程要重连，有时还得重新登录。于是一种做法是不换，一直用到坏；另一种是定时换，认为动一动更安全。这两种在什么场景下成立，取决于业务对”地址稳定”的依赖有多强。
一、先分清两类业务的诉求
挂机做的事大体分两种：一种长连接为主，进程和服务器保持一条持续通道；另一种短请求为主，隔几秒发一次独立请求。诉求差别很大。
- 长连接型：最怕地址变化。连接建立在某个地址上，中途换了线，连接断掉，恢复要靠进程自己重连。
- 短请求型：对地址变化不敏感，每次请求独立，换线只影响下一个请求用哪个出口。
问”要不要一直换IP”，先把业务归到哪一类说清楚，答案自然就出来了。
二、不换的代价与换的代价
| 做法 | 好处 | 代价 |
|---|---|---|
| 固定一条用到坏 | 长连接稳定，不中断、不重登 | 线路老化无人察觉，故障是突发的 |
| 到点就换 | 地址新鲜，单点问题影响面小 | 长连接会反复重建，重连期间没产出 |
| 会话保持设到上限 | 兼顾连接稳定与周期性换池 | 可用时长受线路类型限制，设不满 |
三、参数怎么设
会话保持。它决定一条地址能被连续用多久。长连接业务把它设到线路允许的上限，别用默认的短时长——默认值往往是为一次性请求设计的，撑不住持续连接。
失效重取的时机。建议放在业务空闲段主动取一次，别等连接断了才被动取。主动取只需几秒，被动取要连着一次重连和重新登录。
换线后的确认动作。取到新地址不等于成功，要确认进程真的用它重建了连接。挂机面板上显示”在线”不代表用的还是配好的那条线。
四、掉线自愈的最小闭环
- 探测：每隔固定时间做一次连通检查，只记录结果，不做判断。
- 判定：连续几次不通才认定掉线，单次超时多为抖动，别一次就动作。
- 恢复：重新取地址，再重建连接，这一步要留日志。
- 回写：新的”账号—设备—地址”关系写回台账，否则回溯时查不到当时用的是哪条。
四步里最容易漏的是最后一步。自愈跑通了但台账不更新，几天后你自己都不知道哪个号在哪条线上。
五、要换也得错开换
如果业务确实需要周期性换线，关键是别让它变成一次集体事件。按设备编号尾号分四组，每组间隔三到五分钟依次轮一遍，全程控制在十五分钟内。这样任意时刻最多只有一组在重建连接，面板上的在线数不会出现断崖。
轮转时间也有讲究：避开产出高峰，选在任务间隙或夜间低负载段。轮完后观察十分钟，确认各组连接数都恢复到轮转前的水平，再认定这一轮完成。十几台设备一次全换，看着省时间，实际是把自己的产出压在同一段恢复期里。
六、常见问题
问：十几台设备要不要统一换线时间？
答：不要。统一时间全断风险集中，建议错开，按编号分组，每组间隔几分钟轮一遍。
问：一条线用了很久还没坏，是不是就一直不用管？
答：仍要看时延和丢包。能用不等于好用，指标劣化往往先于彻底断开。
问：换线会不会触发平台的异常判定？
答：有可能，地址变化本身就是变量。降低影响的做法是保持其他条件稳定，一次只改一项，别在同一天既换线又改参数。
注意：上述做法只让网络条件保持平稳，不构成对账号状态的任何保证。游戏与平台的服务条款各有规定，实际执行以平台规则为准。