SS / SSR 检测：加密方式对不上，端口开了也没用
SS（Shadowsocks）和 SSR 的检测难点不在网络层，而在参数层。端口开着、密码也对，只要加密方法或协议插件差一个字符，整个连接就会表现为"什么都连不上"。
一、SS 与 SSR 的参数差异
| 项目 | SS | SSR |
|---|---|---|
| 核心参数 | 服务器、端口、密码、加密方法 | 在 SS 基础上增加协议（protocol）与混淆（obfs） |
| 常见加密方法 | aes-256-gcm、chacha20-ietf-poly1305、aes-128-gcm | 同上，另支持部分流式加密如 rc4-md5、aes-256-cfb |
| 失败表现 | 握手无响应、连上即断 | 除上述外，还可能是协议或混淆不匹配 |
SSR 节点只有协议与混淆两项都填对才可用。只填对加密方法、协议留空或填成 origin、混淆填成 plain 的组合，是最常见的错配。
二、加密方式必须精确一致
加密方法不是"类似就行"，而是逐字匹配。两个关键分界：
- AEAD 与流加密不兼容。aes-256-gcm 属于 AEAD，aes-256-cfb 属于流式加密，两者握手格式完全不同，填错不会降级，只会直接失败。
- 同族不同强度也不兼容。aes-128-gcm 与 aes-256-gcm 密钥长度不同，同样不能互通。
所以遇到"服务商说节点正常、你这边一直连不上"，第一件事是把加密方法和服务端逐字符核对，而不是反复换客户端。
三、SSR 的协议与混淆
SSR 在 SS 之上加了协议与混淆两层处理，作用是改变流量特征。这两项的组合方式必须与服务端完全一致，否则：
- 协议不匹配：认证阶段失败，客户端通常直接报连接错误；
- 混淆不匹配：可能表现为连上但无法出网，或者连接几秒后被重置。
另外要注意，SSR 的混淆参数（如 http_simple 的主机名、tls1.2_ticket_auth 的域名）如果带了具体取值，也必须一并填对。
四、UDP 转发：网页能用不等于全能用
SS 是否支持 UDP 取决于服务端的 UDP 转发配置，多数节点默认只转发 TCP。
- 纯网页、HTTP(S) 访问：TCP 通就够了；
- 语音通话、联机游戏、部分实时应用：必须确认 UDP 转发开启；
- 现象对照：网页正常打开，但游戏匹配失败、语音无声音，通常就是 UDP 不通。
五、检测该看什么，不该看什么
| 做法 | 能得出的结论 | 可靠性 |
|---|---|---|
| 只测端口是否开放 | 服务在监听 | 低，无法判断账号与加密参数 |
| 本地客户端尝试连接 | 能否建立会话 | 中，取决于本地客户端配置是否正确 |
| 代理端点真实发起请求并读取响应 | 是否真的能转发流量、出口 IP 与地区 | 高，能区分加密失败与出口异常 |
第三种做法才是真正的"可用性检测"。它会把加密握手、目标连接、响应回读完整跑一遍，失败时还能指出是参数不对还是出口不通。
六、自查清单
- 加密方法与服务端逐字符核对，确认 AEAD/流加密归类正确；
- SSR 额外核对协议、混淆及其参数；
- 确认端口与密码无误，特别是复制粘贴带入了不可见空格；
- 用真实请求验证一次，看退出码与出口 IP；
- 需要 UDP 的场景单独确认 UDP 转发是否开启；
- 同一条线路短时间反复重连可能被限速，间隔一两分钟再测。
逐条发起真实请求验证，返回可用性、出口 IP 与落地地区。