客户端里配代理，有的工具会给出「自动」选项，让程序自己挑一种协议。这个自动背后是一串尝试动作，并不是某种智能判断。弄清楚它按什么顺序试、什么情况下会退到下一档，遇到连接异常时就知道该从哪里看。
自动选择的背后是一串尝试
代理IP客户端给出的自动选项，实际执行的是逐个试探。通常按能力从高到低排：先试支持完整转发能力的那一种，握手成功就用；握手失败或者返回明确的拒绝，再退到下一档。
有些工具会先发一个很轻的探测请求，确认对端支持哪种方式，再决定往哪走。这种做法看起来更聪明，代价是多一次往返，首次连接的耗时比固定配置长一些。对批量任务来说，这点耗时会被放大成明显的差异，任务量越大越明显。
真正影响体验的是重试的次数与间隔，试得太多会让首次连接明显变慢，尤其是网络本身不稳的时候。
降级什么时候发生
降级大多由三种情况触发：一是协议本身不被目标端支持，握手阶段就被拒；二是链路上的中间设备拦下了这类流量；三是本地配置与远端能力对不上。三种情况的共同点是发生在连接建立阶段，业务数据还没开始传。这个特征很有用，它意味着降级不会影响已经跑起来的连接，只会挡住新连接。
还有一种常见做法是并发发起。几路同时试，谁先成功就用谁，其余的关掉。这种策略在链路不稳时表现更好，代价是对本地资源有一定消耗，同时也会让观测到的连接数偏多。选哪种方式取决于任务形态：串行任务适合逐一试探，并发任务适合并行竞争。
- 确认工具默认的尝试顺序是什么
- 记录每次降级发生的时间与目标
- 看是集中在某个目标还是普遍现象
- 把稳定的组合固定下来，关掉自动
自动模式省事，代价是行为不透明。代理线路的自动选路适合探索阶段，固定配置适合长期运行。把试出来的那组配置写死，比留在自动上更可控。固定之后如果环境变了，再手动调一次就行，至少你知道自己改了什么。
自动是省事，不是更聪明。
把尝试顺序弄清楚、把降级的触发条件记下来，这套机制就不再是黑箱。遇到连接问题时，排查的范围也能缩小到具体的某一档。