用了代理IP之后延迟变高，是正常现象还是配置问题？回答这个问题需要先知道延迟的下限在哪里。请求多走了一段路，这段路本身的耗时是绕不开的，配置只能优化这段路之外的等待。把下限算出来，就能判断当前表现是接近合理值还是明显偏慢。
下限由三段构成
第一段是本地到转发点的距离，第二段是转发点到目标端的距离，第三段是转发这一环自身的处理耗时。前两段由物理距离决定，优化空间有限；第三段取决于中间的处理效率，是可优化项。代理IP的延迟优化，方向应集中在第三段。
先知道下限，才知道有没有优化空间。
优化之前先算下限，不然容易白忙。
为什么感觉每次都不同
测量的方法本身也会影响结果。并发测、串行测、不同时段测，得到的数字可能差出一截。建议固定一套测量方式：同一目标端、同一时段、同样的请求内容，连测多次取中位数。方法固定之后，代理IP的延迟数据才有纵向可比性，也才能拿来做判断。
同一份配置三次测出来的延迟经常不一样，原因在于链路上任何一段的临时波动都会体现在结果里。判断是否正常，要看多次测量的中位数而不是单次值。代理IP的表现评估如果只看一次结果，很容易把偶发波动当成配置问题。
本地网络状况会叠加在测得的延迟里，需要用一个不经过转发的请求做对照。本地自己的出口拥堵时，测出来的延迟会偏高，与代理IP本身无关。两边差值才是代理IP真正带来的部分，这个差值比绝对数字更有参考价值。
下限还有一个用途：判断要不要换方案。如果当前延迟已经接近理论下限，继续调参意义不大，要改善只能换更近的转发点或者改变链路结构。代理IP的选型讨论里，把下限摆出来，很多争论会直接结束。
代理IP接近下限，就该换思路。
对于时效敏感的任务，还可以把下限和可接受阈值放在一起比较。下限已经超过阈值，说明这个链路结构本身不合适，需要换设计；下限明显低于阈值，说明还有优化余量。代理IP的链路选型，用这两个数字对照比用单一实测值更清楚。
延迟问题的正确顺序是：先算下限，再看差距，最后才决定优化什么。跳过第一步，后面的动作就失去参照。代理IP的调优之所以常做无用功，多半是因为拿一个没有基准的数字在反复比较。
把下限算出来记下来，作为后续比对的固定参照，这个习惯的收益会持续很久。每一次调整之后拿结果和参照比一比，方向对不对立刻就能看出来，代理IP的延迟优化也就有了节奏。