快柠檬连接错误如何分阶段？读懂SOCKS5协商、认证与返回代码

先确认实际环境是否使用SOCKS5

快柠檬连接错误的排查不能默认从代理协议开始。本文介绍通用SOCKS5知识，只适用于实际配置和日志明确使用该协议的环境；不表示快柠檬一定提供SOCKS5功能，也不提供默认端口、账号或认证方式。

客户端、SOCKS代理服务器、目标服务器是不同角色。入口本身无法连接时，还没进入完整的协议协商；想先判断设备联网、进程和会话是否正常，可从连接故障检查顺序开始。不要把SOCKS5失败与所有类型的VPN连接失败混为一谈。

第一阶段：版本和认证方法协商

客户端建立到代理的连接后，发送SOCKS版本以及自己支持的方法列表。代理从中选择方法：0x00表示无需认证，0x02表示用户名密码方式，0xFF表示没有可接受的方法，需要终止连接。这些是方法字段，不能拿来直接解释目标请求是否成功。

方法协商失败可能是双方支持的方法不一致，或根本连接到不兼容的服务。此时不应反复修改目标网址。先核对实际配置与服务说明，也不要通过绕过访问控制来“验证”代理是否可用。

第二阶段：所选方法自己的认证过程

选择用户名密码方式后，会进入RFC 1929规定的子协商。它有独立的版本与状态字段：该阶段状态0x00表示认证成功，非零表示失败。认证失败可能在CONNECT目标请求之前就发生，不属于目标服务器拒绝连接。

只在可信环境中核对凭据，不把密码写进公开日志或截图。该用户名密码子协商本身不提供加密，应结合实际传输保护方式评估使用环境。浏览器网页登录是另一种会话流程，遇到回跳循环可阅读Cookie与登录状态检查，不要把两类认证混用。

第三阶段：CONNECT请求和服务器回复

必要认证完成后，客户端才发送目标请求。地址类型可表示IPv4、域名或IPv6，目标地址与端口也需符合实际配置。代理回复中的REP字段才描述这次请求的处理结果。

认证成功只说明通过了对应认证阶段，目标仍可能不可达。REP成功之后，目标网页还可能返回HTTP错误；这已是后续应用层响应。软件的错误文案可能对标准状态作了包装，应尽量保留原始阶段和代码。

用最少的对照，定位最早失败点

1. 记录实际代理类型、客户端错误时间和脱敏代码，先确定入口连接是否建立。
2. 确认失败发生在方法选择、认证子协商，还是CONNECT回复；不要只保留“连接失败”四个字。
3. 只对允许访问的目标做少量对照，判断是否所有目标失败，或仅某个地址形式失败。
4. 若切换移动数据后结果不同，再参考DNS64/NAT64与地址族兼容路径比较网络条件。

处理快柠檬连接超时，应依据实际日志确定阶段。没有明确SOCKS5记录时，返回通用诊断流程；有明确记录时，保留最早失败点。不要持续并发测试第三方服务器，也不要分享真实代理密码。