很多人以为填了账号密码，数据连接就会带着身份一起走，其实 SOCKS5 的认证发生在握手阶段，而且有自己的一套报文格式。搞清楚身份检查藏在哪一步，代理IP登录失败时就知道该去哪找问题。
先说结论：SOCKS5 的账号密码认证（对应 RFC 1929 定义）发生在握手第二轮的认证方法协商之后，是独立于数据传输的一小段对话。认证通过，才继续报目的地；认证失败，会话到此结束。
第一步，方法协商时把认证方式报上去。客户端在问候消息里列出支持的认证方式，比如无认证、用户名密码、GSSAPI，服务器从中选一种回复，选中的就是接下来要走的路。
第二步，发用户名密码报文。报文以 0x01 开头，接着是一个字节的用户名长度、用户名内容、一个字节的密码长度、密码内容。服务器按这个格式解析，缺一字节都对不上。
第三步，服务器回认证结果。一个字节的状态码：0x00 表示认证成功，0xFF 表示失败。失败后连接直接关闭，不会再往下走目的地请求。
第四步，认证通过后才报目的地。身份检查通过，客户端才发第三轮的目的地请求，之后的流程和没开认证的完全一样。
整套认证走下来，位置很容易记：它夹在方法协商和目的地请求之间，属于连接建立阶段的一小段插曲。搞清楚这个先后顺序，再看代理IP登录报错，就能判断是卡在认证前、认证中还是认证后，排错路径立刻清晰许多。
补充：无认证的场合
一些内网或测试环境把认证方式设为无认证，握手时客户端报无认证、服务器也接受，两步就跳过认证环节。这类地址只适合可信环境，公网使用的代理IP基本都要开认证。
需要注意的是，SOCKS5 的认证只解决“你是谁”的问题，不负责数据加密。认证报文本身是明文传输的，密码在链路里裸奔，所以真正在意安全的环境还要靠上层协议或专用通道来保护。这也是使用代理IP时要注意的一条底线：认证管身份，加密管内容，两者不能互相替代，缺一不可。
把认证环节从连接流程里单拎出来看，代理IP登录失败的排查就清晰了：认证失败多是账号密码或格式问题，认证成功却连不上，才是目的地或网络的问题。分清楚这两类，方向就对了。先判断是哪一类，再决定往哪查，能省下不少来回折腾的时间。
再补充一个细节：用户名密码认证的报文里，用户名和密码的长度字段都是单字节，意味着各最多 255 字节。日常使用的账号密码远达不到这个上限，但如果从别处拷贝了超长字符串，可能被截断导致认证失败，这也是个冷门的排查点。多数代理IP服务商对账号长度也有自己的限制，配置时留意一下说明即可，能少踩一个坑。另外，不同服务商对用户名密码的字符集要求也可能不一样，遇到特殊字符报错时先考虑这个方向。