很多人以为代理是靠端口号来分辨协议的：1080 就是 SOCKS，8080 就是 HTTP。实际上端口只是一个约定，改成什么都能跑，真正的判断发生在数据到达之后。搞清楚代理是怎么识别协议的，就能明白为什么有些流量会被误判、为什么改了端口就连不上。
识别一般分三步走
第一步看前几个字节。HTTP 流量以明文开头，请求行里的 GET、POST 这类方法一目了然，代理读到就能直接判定。第二步看握手特征。加密流量虽然看不到内容，但开头的握手包有固定结构，特征对得上就按 TLS 处理。第三步才是端口兜底，前两步都判不出来时，按端口上的约定去猜一个默认协议。三步是层层递进的关系，前一步命中就不会走到后一步，所以内容特征永远优先于端口。
端口就是协议吗
常见看法：端口决定了协议，填什么端口就是什么协议。
实际情况：端口只是一个监听入口。服务可以在任意端口上提供任意协议，只要客户端和服务端双方约定一致就行。反过来，同一个端口也可能同时跑着多种协议，由服务端根据内容自行分流。把端口当成协议的判断依据，在排查时会得出错误结论。
这也是为什么填错端口的表现千差万别：有的直接连不上，有的能连上但一发数据就断。前者是端口上根本没有服务在监听，后者是服务在、但双方说的不是同一种语言，握手失败后连接被关闭。
识别错了会发生什么
把 HTTP 当成 SOCKS 处理，或者反过来，结果都是握手失败、连接中断，因为双方交换的第一组数据就对不上。把普通 HTTP 当成加密流量处理，代理会一直等待一个永远不会到来的握手包，直到超时。把隧道请求当成普通请求解析，代理会试图去读一个根本不存在的请求行，同样以失败告终。这些失败在日志里通常表现为握手错误或协议错误，而不是简单的连接超时。
为什么有的代理能自动分流
能自动分流的代理，本质上是把识别放在了最前面。收到连接后先读一小段数据做判断，识别出来再交给对应的处理模块，识别不出来就按端口约定走默认路径，或直接在握手阶段协商出本次要用的方式。这套流程发生在连接建立的最初几毫秒内，对使用者是无感的，但它决定了这条连接后续能不能正常工作。
那么，改端口到底有没有用？有用，但只在约定的意义上——它能避开一些简单的扫描和默认配置冲突，却改变不了流量本身的特征。真正决定能不能连上的，是客户端填写的协议类型、端口与服务端提供的是不是一致，三者对齐才是关键。用代理IP时，配置里那几个看似不起眼的协议选项，往往比端口号更值得核对。