ROXI你在客户端里看到“Reality 握手失败”“连接后立刻断开”“TLS/Handshake error”，但同一台设备上别的网络又能正常连。或者现象更隐蔽：节点配置没改过，昨天还能用，今天突然超时，测速也从正常变成 0。
如果你怀疑是 Reality 协议“最难被墙”，但又不知道它到底为什么抗封锁、失效时该先查哪里，这篇就是按排障思路写的。
先分清是哪种情况
Reality 协议本身不是“永远不会出问题”，常见故障通常落在下面 4 类。
1. 本地配置错了
最常见的是服务器地址、端口、UUID、flow、serverName、publicKey、shortId 其中一项填错，或者客户端和服务端版本不兼容。症状通常是“连接立即失败”，但别的节点正常。
2. 目标站点或伪装参数不匹配
Reality 依赖看起来像正常 HTTPS 的握手，如果你填的 dest、serverName、SNI、TLS 指纹和真实可访问站点不匹配，客户端会在握手阶段就被拒绝。
3. 服务器侧网络不通
服务器本身出站、入站、DNS、证书相关环境异常，也会表现为握手失败。很多人只查客户端，实际上是机器上防火墙、云厂商安全组、443 端口没放行。
4. 线路被干扰或被封锁
如果你在某些网络环境下始终失败，换一条普通网络又正常，才更像是链路被干扰、被限制访问，或者需要经过代理才能连到目标。
分步解决
1. 先确认是不是“配置写错”
打开客户端，把节点参数逐项对照服务端导出的配置，重点看这几项：地址、端口、UUID、传输类型是否都是 Reality，对应的 publicKey、shortId 是否完全一致。
Windows 上如果你用的是图形客户端，通常在节点编辑页直接查看；macOS 和 iOS 也是点进节点详情核对；Android 多数是在“编辑配置”或“高级参数”里看。
如果你能登录服务器，先把服务端配置和客户端配置对照一遍。命令行里可用 grep 或 cat 查看配置文件，例如：
cat /etc/xray/config.json
重点搜索 inbounds、realitySettings、dest、serverNames、privateKey、shortIds。
只要这里有一项不一致，先改到一致再测，不要急着怀疑“被墙了”。
2. 检查 serverName、dest 和真实站点是否可达
Reality 的思路是让握手“像是在访问一个正常站点”。因此 serverName 和 dest 不能乱填，目标站点最好是你服务器实际能访问到的 HTTPS 站点。
在服务器上测试目标站点是否能通：
curl -I https://example.com
如果连这个都超时，说明服务器到该站点本身就不通，Reality 也就没法正常伪装。
再看客户端里填的 serverName，最好与目标站点证书常见域名一致，不要随手填一个不存在或明显不相关的名字。若你改过 SNI，改回与服务端配置一致的值再试。
3. 逐项检查端口、防火墙和安全组
服务器上先看监听状态：
ss -lntp | grep 端口号
如果没有输出，说明程序没监听成功，先重启服务；如果有监听，再检查系统防火墙和云厂商安全组是否放行同端口。
Ubuntu/Debian 常见检查：
sudo ufw status
如果启用了 UFW，放行端口：
sudo ufw allow 端口号/tcp
CentOS/RHEL 常见检查 firewalld：
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=端口号/tcp --permanent
sudo firewall-cmd --reload
如果是云服务器，还要去控制台的安全组里确认 TCP 端口已放行。很多“Reality 协议连不上”其实只是 443 没开。
4. 校验服务端证书与密钥是否正确生成
Reality 常见用法不要求你像传统 TLS 那样部署证书文件，但私钥、公钥、shortId 还是必须成对匹配。服务端生成后，客户端要使用对应公钥。
如果你是手工改过配置，最稳妥的方法是重新生成一次密钥对，再把新的公钥填回客户端。
服务端重启后，看日志是否有“handshake”“reality”相关字样。常见查看方式：
journalctl -u xray -e
或者如果你是自己前台运行，就直接看终端输出。
出现“invalid key”“shortId mismatch”“reality settings error”之类字样，基本就不是网络问题，而是配置错。
5. 只在特定网络失败时，优先判断是不是链路限制
如果家里 Wi‑Fi 能连，手机流量不能连，或者反过来，说明更像是网络环境差异，而不是节点坏了。
你可以先做两个简单测试：
在客户端里切换“系统代理”或“全局/规则”模式，排除浏览器本身没走代理；
把节点复制到另一台设备上测试，确认不是某个设备的本地 DNS 或证书缓存问题。
Windows 可先在命令行测端口连通性：
powershell Test-NetConnection 服务器IP -Port 端口号
macOS 可用：
nc -vz 服务器IP 端口号
Android/iPhone 如果没有命令行，就用客户端里的连通性测试或日志页，重点看是“超时”还是“握手被拒绝”。
验证是否修好
最直接的验证不是“节点图标变绿”，而是做三件事。
第一，查看客户端日志，确认没有继续出现 handshake failed、timeout、invalid shortId 之类报错。
第二，访问一个平时会直连失败的网站，确认它能稳定打开，不是偶尔通、偶尔断。
第三，连续切换几次网络环境测试：Wi‑Fi、手机热点、不同运营商网络，看连接是否保持一致。
如果你能在日志里看到连接成功，并且访问网页时延迟稳定、不反复重连，才算真正修好。
还是不行怎么办
如果前面都核对过，仍然只有某些网络能用、某些网络完全不行，那就要接受一个现实：问题可能不是你本地配置，而是链路侧限制更强，或者目标线路已经不稳定。
这时建议按这个顺序兜底：
先把服务端和客户端都升级到较新的稳定版本，避免旧版兼容性问题；
换一个端口再测，优先试 443、8443 这类常见 HTTPS 端口；
重新生成一套 Reality 参数，避免旧配置被长期识别；
如果确认就是网络被封锁、被墙、需要代理才能访问目标服务，再考虑使用可用的中转方式，Roxi 也可以作为其中一种途径。
理解 Reality 为什么难被墙，关键不在“它不可被识别”，而在于它把握手做得尽量像正常 HTTPS：看起来是普通 TLS 访问，内容又经过额外保护，所以单靠粗暴封端口、关键词或简单指纹匹配，误伤成本会很高。但这不等于它不会失效，真正排障时还是要回到配置、端口、日志和网络连通性这四件事上。