访问某个服务，一段时间正常、一段时间不通，过一会儿又好了——这类现象很难归因。说线路坏，它大部分时间是通的；说好，它又确实失败过。可达性时好时坏的真正含义是：链路上有一个环节在两种状态之间切换。要判断代理IP线路为什么对同一目标出现这种表现，得把可能切换的环节找出来，代理IP线路只是其中一段，未必是出问题的那一段。
一、失败形态先分两类
第一类是完全连不上，报错停在建立连接阶段。第二类是连得上但传输异常，连接建立成功、后续请求失败。两类的原因分布差别很大：前者多半在路由、出口可达性或者对方端口限制上；后者多半在会话状态、超时或者对方主动断开。
分不清这两类就开始换线路，是排查里最常见的时间浪费。区分方法很简单：从线路侧发一次连接测试，同时从目标服务的其他可达路径测一次。两边都失败说明问题在目标侧或者中间某段公共链路，只有一边失败才需要考虑线路自身。
二、五个会切换状态的环节
环节一是目标服务的地址分布变化。同一域名会解析到不同地址，其中部分地址可能不接受当前出口归属的连接。这一类的表现是间歇失败而不是全失败，因为解析结果在几个地址之间轮转。验证方法是把失败时段的解析结果记下来，看失败是否集中在某几个地址上。
环节二是线路出口的实际归属变化。线路的出口地址在若干条之间分配，落到某个被目标拒绝的地址上就会失败。这一类与环节一的区别在于：它按出口分布呈现比例，而不是按时间规律。
环节三是会话状态失效。有状态的流程中途换了出口，之前建立的协商结果不再有效，后续请求被拒。特征是同一会话内前一次成功、后一次失败，且重试仍失败。
环节四是目标服务的自身维护或者负载策略。这类与线路完全无关，但时间规律明显，通常落在固定时段。判断办法是换一条完全不同的线路测同一时段，现象一致就与线路无关。
环节五是凭据与额度的临界状态。用量接近上限时，部分请求会被拒绝，而这类拒绝在报错形态上常常表现为连接不通，看起来像线路故障。这一类最容易被误判，因为它的失败比例恰好与用量波动同步。查法是看失败率与用量的相关性，两者同步就基本可以确认。
三、排查的三步顺序
第一步记现场。失败发生时记录四件事：时间点、当时用的线路、失败的请求特征、以及失败是发生在建立阶段还是传输阶段。四件事不在当时记下来，事后无法还原。批量环境里这一步最容易省，也最不该省。
第二步做对照。同一时刻用两种路径各测一次——一种走代理IP线路，一种走原始出口。两种结果对照，能立刻区分问题在线路段还是在目标段。对照要在同一个时间窗内做完，隔十分钟再测结论就不成立了，因为状态本来就在切换。
第三步看周期。把失败时间点标在时间轴上，看是否有规律：整点附近、固定时段、还是随用量起伏。规律指向维护节律或者额度临界，无规律则更像归属分配或者地址轮转。这三步走完，绝大多数时好时坏的现象能落到某一类上，剩下的少数才需要拿对照数据去找供应商一起查。
还有一点值得长期注意：可达性问题常被当成不稳定问题去处理，加各种重试和切换逻辑。但如果根源是归属与目标规则不匹配，重试只会让失败多发生几次，问题依旧。判断该修配置还是该加容错，依据是失败的分布形态而不是失败本身。批量环境里这类区分做得到位，能省下一批无效的容错代码。
问：时好时坏要不要设告警？
要按形态设，不按出现次数设。同一时段内集中失败要告警，零星失败不该告警，否则值班会被大量无意义提醒淹没，真出问题的那一次反而被忽略。
问：能不能直接换目标地址避开这个问题？
如果确认根源在环节一或者环节五，调整目标或者控制用量有效；如果根源在归属分配，换目标只是让同一个问题换个地方出现。先定位再动作。