代理IP的流程里，认证发生的顺序经常被忽略。它不在最后，而是在连接刚建立的时候：你的机器先和中间入口打招呼，对方确认你被允许使用，之后才轮到请求的转发。顺序搞反了，会一直以为是参数错了。
为什么先认证再转发
因为入口要先确定这次连接该不该接。确认通过，转发才开始；确认不过，请求连目标都到不了，你收到的是一句连接被拒绝。代理IP的认证发生在转发之前，这个顺序决定了一件事：认证失败的表现是连不上，而不是结果不对，两类问题的指向完全不同。
两种认证方式在流程里的差别
用账号密码的方式，是每次连接时把凭据带过去，好处是不挑机器；用白名单的方式，是入口先比对来源，符合条件的直接放行，好处是不用反复输入。代理IP的两种方式在流程里的位置相同，都在转发之前，区别只在确认的依据是什么，一个看凭据，一个看来源。
失败时怎么定位
连不上和结果不对怎么分？
先看失败发生在哪一步：连入口就连不上，是认证或网络的问题；连上了但结果不对，那已经和认证无关，要去查转发和目标。代理IP的排查最忌讳把所有失败都当成同一类，顺序一旦理清，定位时间会明显缩短。代理IP的排查顺序一旦理清，多数故障都能很快归位。
| 表现 | 可能所在步骤 | 先查什么 |
|---|---|---|
| 连接被拒绝 | 认证步骤 | 凭据与来源是否匹配 |
| 连接超时 | 连接建立 | 入口地址与网络 |
| 能连但结果不对 | 转发步骤 | 出口与目标 |
需要注意的是：两种认证方式不要在同一套配置里混用，混用会让失败表现的判断失去参照。
顺序理清，排查就有方向。
把代理IP的流程拆成先认证、再转发两段，很多原本模糊的故障就有了归属。认证只负责放行，转发才决定结果，这两件事不要混着查。