Reality 是目前隐蔽性最强的代理伪装技术之一：它不需要你自己的域名和证书，而是"借用"一个真实存在的大网站（比如某软件下载站）做握手目标，把你的流量藏进一次看起来完全正常的 TLS 握手里。配好之后非常稳，但配的过程中一旦连不上，报错信息往往只有一句干巴巴的 connection failed，让人无从下手。
这篇是我自己搭 VLESS+Reality 三协议、又在客户端折腾 1.14 版本升级时踩过的坑的整理。不讲部署步骤（部署看上面那篇），只讲"连不上时按什么顺序查"。默认你已经有一台装好 sing-box 的 VPS，和一份客户端配置。
第 0 步：先看日志，别靠猜
排错的第一原则：让程序自己说话。服务端看实时日志：
journalctl -u sing-box -f然后在客户端点一下连接，看服务端滚动出什么。90% 的 Reality 问题，服务端日志里都写得明明白白，比如 reality: authentication failed（认证失败，多半是公钥或 short_id 不对）。没有日志的瞎调，等于闭眼修车。
第 1 步：配置先过 check
JSON 手改很容易多逗号、少括号。改完先跑：
sing-box check -c /etc/sing-box/config.json报错就按行号修，通过了再谈别的。这个习惯能过滤掉一半"玄学问题"。
第 2 步：公钥私钥别搞反
这是新手最高频的翻车点。生成密钥对：
sing-box generate reality-keypair它会输出一对 PrivateKey 和 PublicKey。记住：PrivateKey 只放服务端，PublicKey 只给客户端。两边放反、或者客户端填成了服务端的私钥，握手必失败。检查时把两端配置并排打开，一项项对。
第 3 步：short_id 对不上
服务端配置里 short_id 是一个数组，客户端填其中任意一个即可：
// 服务端
"short_id": ["d0902526d9e9ea13"]
// 客户端
"short_id": "d0902526d9e9ea13"注意两点：short_id 必须是偶数位十六进制（0 到 16 位），用 sing-box generate rand 8 --hex 生成最省心；客户端填的值必须在服务端的数组里出现过，差一个字符都不行。
第 4 步：server_name / SNI 两端一致
客户端 tls.server_name 填的域名，必须是服务端 Reality 允许的那个。服务端有两个相关字段：外层 tls.server_name 和 reality.handshake.server，三者通常填同一个域名（即你的伪装目标站）。客户端填了 A 站、服务端配了 B 站，握手直接失败。
第 5 步：伪装站（握手目标）挂了或不达标
Reality 的精髓是把流量伪装成访问某个真实网站，所以这个"目标站"本身必须健康。合格的目标站要满足：支持 TLS 1.3、支持 HTTP/2、延迟低、长期稳定。可以用 curl 快速检测：
curl -so /dev/null --tlsv1.3 --http2 \
-w '%{http_version} connect=%{time_connect}s\n' \
https://目标站域名如果目标站自己都连不上、或者不支持 TLS 1.3，换一个。优先选那些常年不挂的大站，不要选随时可能改版下线的小站。另外注意：目标站的 443 端口要能从你的 VPS 正常访问。
第 6 步：uTLS 指纹
客户端的 utls.fingerprint 建议填 chrome，让握手时的 TLS 指纹看起来像 Chrome 浏览器。有些客户端默认不开启 uTLS，或者填了服务端不支持的值，会导致握手特征异常。这是"配置看着都对但就是连不上"时的重点怀疑对象。
第 7 步：flow 两端必须一致
如果服务端用户配置了 "flow": "xtls-rprx-vision"，客户端必须同样配置；服务端没配，客户端就删掉这一项。一边有、一边没有，必断。分享链接里的 flow=xtls-rprx-vision 参数对应的就是它，导入配置时注意别丢了。
第 8 步：端口和防火墙
最朴素也最容易漏的一步：服务端监听的端口（通常是 443）有没有被防火墙放行？
ss -tlnp | grep 443看 sing-box 是否真的在监听；再检查云服务商的安全组和本机防火墙（ufw/firewalld）是否放行了 TCP 443。443 被占用的情况也常见——比如机器上还跑着 nginx，ss 一看便知。
常见报错速查表
| 服务端日志 / 现象 | 最可能的原因 | 对应步骤 |
|---|---|---|
reality: authentication failed | 公钥/私钥搞反，或 short_id 不在服务端数组里 | 第 2、3 步 |
| TLS handshake failure / 超时无响应 | 端口没放行、伪装站不可达 | 第 5、8 步 |
| 配置看着都对，依然连不上 | uTLS 指纹、flow 不一致 | 第 6、7 步 |
sing-box check 报错 | JSON 语法问题 | 第 1 步 |
一个误区：Reality 对系统时间不敏感
有人把别处"校准时间"的经验套过来。实际上 Reality 不验证证书有效期，时间偏差不会导致握手失败——时间问题更多是 Hysteria2 等依赖证书验证的协议的坑。Reality 连不上时，别在时间上浪费时间。
排查顺序总结
日志 → check → 公钥配对 → short_id → SNI → 伪装站 → 指纹 → flow → 端口。按这个顺序走一遍，绝大多数 Reality 连接问题都能定位。如果走完还是不行，把服务端日志里那行报错原文记下来再去搜——带着原文搜，比搜"reality 连不上"有效十倍。
之前写过 sing-box 完整指南（部署、订阅转换与通用排错）和 1.14 升级实战，遇到其他报错可以对照着看。