云端接入代理IP最常被问的两个问题是延迟和掉线，这两个问题的处理方式不一样。
崩坏学园2的号如果对操作时机有要求，延迟就会被放大。掉线则和延迟不同，它往往是这条代理IP本身的问题，和号在做什么关系不大。
- 延迟偏高：多半是云端机器到目标之间的路径问题。
- 频繁掉线：多为地址本身不稳定，需要换一条。
- 偶发掉线：先看是不是批量操作引起的。
三类问题的处理顺序建议从上往下：先排除路径问题，再看代理IP的稳定性，最后才怀疑操作方式。顺序反了，容易在操作习惯上白花时间，改了半天操作方式，结果问题在地址那一头。
延迟怎么测
测延迟要和本地做对比，单看云端的数值没有意义。同样的操作在本地跑一遍，在云端跑一遍，两个数值的差才是云端带来的额外开销。测的时候注意选同一时段，不同时段的路径不一样，数值没有可比性。测的次数也要够，三五次取中间值，单次结果受波动影响太大，拿它下结论容易误判方向。
掉线怎么处理
偶发掉线先别急着换代理IP地址，看看是不是批量操作或者重启引起的。批量操作会让大量实例同时重连，短时间内的失败率本来就高。等操作停下来再观察一段时间，很多偶发问题会自己消失。
- 先记录掉线的时间点和当时的操作。
- 连续观察两到三天，看有没有规律。
- 确认是规律性掉线之后，再换地址测试。
规律性掉线有几种常见的形态：固定时间点掉、固定几个实例掉、每次持续同样的时长。这三种形态对应的原因不一样，记录的时候把这几个维度都写上，判断起来会快很多，也不至于一有问题就大面积去换地址，把本来正常的那部分也搅乱。
还有一个容易忽略的点是云端机器的负载。同一台云手机上跑太多实例，机器本身的处理能力会不够，表现出来也像网络问题。确认的时候看一眼机器的负载，能排除掉一部分误判。
崩坏学园2的号如果对时效要求不高，延迟的容忍度会大很多，重点放在掉线的处理上。反过来，对时效要求高的号，两端的问题都要盯。