ROXI你在选协议时，最常见的现象是：同一台设备上，换了 VLESS、VMess、Trojan 或 Shadowsocks 之后，有的能连、有的连不上；或者客户端里显示“连接超时”“握手失败”“认证失败”，但你又不确定是协议本身不对，还是服务器配置不对。还有一种情况是：手机能用，电脑不能用，或者家里 Wi‑Fi 不行，换流量又正常，问题看起来像协议选择，其实是网络环境差异。
先分清是哪种情况
先别急着反复切协议，通常是下面 4 类原因之一。
第一类是服务器端和客户端协议不一致，比如服务端开的是 Trojan，你客户端却按 VMess 去连，必然失败。
第二类是传输层参数不匹配，比如 TLS、WS、gRPC、Reality、端口、路径、SNI 这些设置有一项不同，协议本身对了也连不上。
第三类是网络环境限制不同，比如某些网络只放行 443 端口，或者对 UDP、QUIC、WebSocket 有干扰，这时同一协议在不同网络表现会不一样。
第四类是客户端兼容性问题，老版本客户端不支持 VLESS 的某些写法，或者 iOS、Android、Windows 上的内核实现不同，导致看起来像协议问题。
如果你现在的目标是“我该选哪一种协议”，可以先按使用场景理解：
VLESS：更偏现代，常和较新的传输方式配合，配置灵活，很多新方案优先选它。
VMess：历史更久，兼容性广，但现在更多是存量部署，作为新方案通常不是首选。
Trojan：外观上更接近普通 HTTPS，配置思路相对直观，适合已经明确要走 TLS 的场景。
Shadowsocks：结构简单，客户端多，老设备和轻量场景很好用，但它本质上更像“轻量代理”，不是所有高干扰网络都同样稳。
分步解决
1. 先确认服务端到底开的是哪一种协议
如果你有服务器管理权限，先看服务端面板或配置文件，不要凭感觉猜。
常见检查方式如下：
在 Linux 服务器上，如果你知道服务端程序名，可以先看进程：ps aux | grep -E 'v2ray|xray|sing-box|trojan|ss-server'
再看配置文件里的入站类型：
VLESS 通常会写成 protocol: vless
VMess 通常会写成 protocol: vmess
Trojan 通常会写成 protocol: trojan
Shadowsocks 通常会写成 method: 例如 aes-128-gcm、chacha20-ietf-poly1305
如果你是通过面板管理，就直接打开对应入站/节点详情，确认“协议类型”“端口”“传输方式”“TLS 开关”这几项。
这一步的目的只有一个：客户端必须和服务端完全对上，别混用。
2. 按设备把客户端字段填对
Windows：
打开客户端的节点编辑页，重点核对“协议类型”“地址/域名”“端口”“UUID/密码”“传输方式”“TLS/伪装域名”。
如果是 VLESS/VMess，通常要填 UUID；Trojan 和 Shadowsocks 则分别是密码和加密方式。
如果有“允许不安全”“跳过证书验证”这类选项，先不要乱开，除非你明确知道服务器是自签证书。
macOS：
进入节点详情页，和 Windows 一样核对协议、端口、UUID/密码、SNI 或 Server Name。
如果客户端有“系统代理”“全局路由”两项，排障时先只开系统代理，便于判断是否真的连通。
Android：
打开节点编辑，检查“传输”“安全”“SNI”“路径”“Host”是否与服务端一致。
很多 Android 客户端会把“TLS”和“Reality”分在不同选项里，别把两者混填。
iOS：
在节点页面里确认协议名称、服务器地址、端口、UUID/密码、TLS 开关。
iOS 上有些客户端会把“域名”与“IP”分开填写，若证书绑定的是域名，尽量填域名，不要直接填 IP。
如果你不确定填什么，最稳妥的做法是把服务端导出的分享链接或订阅信息导入客户端，而不是手工逐项抄写。
3. 先从最简单的协议开始试
如果你只是想先连上，再谈体验，建议排查顺序是：
Shadowsocks
Trojan
VLESS
VMess
原因很简单：Shadowsocks 配置最少，适合判断“是不是基础连通问题”；Trojan 次之；VLESS 和 VMess 常常还涉及更多传输参数。
注意，这不是绝对优先级，只是排障顺序。你最终该选哪一种，要看服务端实际支持什么。
4. 把“传输层”单独看一遍
很多人以为是协议选错，其实错在传输层。
如果服务端是 TLS：
确认客户端里启用了 TLS，且 SNI/Server Name 与证书域名一致。
如果服务端是 WebSocket：
确认路径 path 完全一致，Host 头也要对。
如果服务端是 gRPC：
确认 service name 一致，且客户端和服务端都支持 h2。
如果服务端是 Reality：
确认公钥、短 ID、服务器名这些字段与服务端完全匹配。
如果你改来改去还是失败，先把传输方式简化成服务端当前明确支持的那一种，不要混搭。
5. 用命令确认端口和连通性
Windows：
打开 PowerShell，测试端口连通性：Test-NetConnection 服务器域名 -Port 端口号
如果 TcpTestSucceeded 是 False，说明端口层面就没通。
macOS：
终端执行：nc -vz 服务器域名 端口号
看到 succeeded 才说明端口可达。
Android/iOS：
没有统一命令行就用客户端自带的“延迟测试”“连通性测试”；如果客户端支持日志，打开后看是否卡在 TCP 建连还是 TLS 握手。
如果端口不通，先别纠结协议类型，优先检查防火墙、安全组、运营商封锁和服务器监听地址。
验证是否修好
先不要只看“节点已启用”，要做三件事。
第一，客户端状态页是否显示已连接，且日志里没有连续重连、认证失败、TLS 握手失败。
第二，测试一个明确会受影响的网站或接口，确认页面能打开，而不是只看首页缓存。
第三，分别在当前网络和另一种网络下测试，比如 Wi‑Fi 和手机流量各试一次，判断问题是不是特定网络导致的。
如果你想更严谨，可以把代理开关关闭后再开一次，确认不是系统缓存或旧路由规则造成的假成功。
还是不行怎么办
如果你已经确认协议类型、端口、传输层、证书、SNI 都对了，仍然连不上，按这个顺序继续查。
先换一个客户端验证兼容性，避免是客户端版本太旧。
再换一个网络环境验证，比如从公司网切到家里网，或从 Wi‑Fi 切到流量，判断是否被中间网络干扰。
然后看服务端日志，重点找“认证失败”“no matching protocol”“invalid user”“handshake error”这几类字样。
如果你发现问题只在某个网络环境出现，且确实是网络被限制、访问目标需要代理才能连通，那么可以考虑更换一套更适合当前网络的协议组合，或者用 Roxi 这类全平台工具做一次对照测试，先确认是协议选择问题还是线路本身的问题。
最后再回到选型上：只是日常轻量使用，Shadowsocks 往往最省事；要兼顾现代配置和灵活性，优先看 VLESS；已经有稳定 TLS 环境，Trojan 也很常见；VMess 更适合作为兼容旧配置的过渡方案。
核心原则只有一个：先让“服务端协议、客户端协议、传输参数”三者完全一致，再谈哪个协议更适合你。