TL;DR：Reality 排障先建一张字段表。publicKey、shortId、serverName、fingerprint、flow 任意一项错位，都可能表现为握手失败或秒断。
Reality 配置不匹配很少给出直白错误。用户看到的常是「能导入但连不上」「手机能用，桌面不行」「更新订阅后全部 timeout」。这些现象背后，最常见的是 shortId、publicKey、serverName 或 fingerprint 在转换过程中被改写、截断或丢失。
字段对照表
| 字段 | 服务端位置 | 客户端位置 | 检查重点 |
|---|---|---|---|
| privateKey | Reality 服务端 | 不出现在客户端 | 只保存在服务端 |
| publicKey | 由 privateKey 生成 | publicKey / pbk | 必须同源 |
| shortIds | 服务端允许列表 | shortId / sid | 客户端值要命中列表 |
| serverNames | 服务端允许列表 | serverName / sni | 只写域名，不写 URL |
| fingerprint | 客户端 TLS 指纹 | fingerprint / utls | 多端排障先固定一个值 |
| flow | 用户或出站字段 | flow | 客户端必须支持 |
不要只看二维码能不能扫。二维码、订阅转换器和 GUI 导入器都可能改字段名，但字段含义不能变。
publicKey 最容易复制错
Reality 客户端填的是 publicKey，不是服务端 privateKey。常见错误有三类：
- 从另一台服务器复制了 publicKey。
- 重新生成了密钥，但客户端仍用旧 publicKey。
- 复制时漏了末尾字符。
排查时重新在服务端生成或打印对应 publicKey，再和客户端逐字比对。不要在公开地方贴完整密钥；如果求助，只说明长度、来源和是否刚刚重新生成。
shortId 要看列表命中
服务端通常是 shortIds 列表，客户端只填一个 shortId。客户端值必须在列表里。问题经常出在：
- 把空字符串和未填写混为一谈。
- 十六进制字符被自动转成大写或被截断。
- 复制时带了空格。
- 订阅转换时字段名从
shortId变成不被客户端识别的名字。
如果服务端允许多个 shortId，先只保留一个明确值做测试。确认能连后，再恢复多值。
serverName 和 fingerprint 一起看
serverName 是握手里的名称，应命中服务端 serverNames。不要写成 https://example.com/，也不要带路径。fingerprint 则影响客户端模拟的 TLS 指纹。排障时建议先统一成一个主流值，例如 chrome，不要每个客户端用各自默认值。
如果只有某个客户端失败，重点看它导入后的最终配置，而不是原始链接。很多 GUI 会把字段展示成另一个名字，实际保存时又映射回核心字段。
最小复现流程
- 服务端确认 Xray-core 或 sing-box 版本支持 Reality。
- 固定一组 privateKey/publicKey。
- 服务端只保留一个 serverName 和一个 shortId。
- 客户端手动填 publicKey、shortId、serverName、fingerprint。
- 打开 debug 或 info 日志，观察握手错误。
- 成功后再恢复多客户端订阅导出。
如果你需要多客户端参数统一，可以使用配套订阅线路导出不同格式，但仍建议保留一份 Reality 原始字段表。
看日志时抓哪些词
Xray-core 常见线索包括 Reality 验证失败、TLS handshake failed、connection ends。sing-box 侧可能看到 tls、reality、handshake、bad key、short id 相关错误。不同版本用词不完全一样，关键是看失败发生在 TLS/Reality 阶段，还是后续代理转发阶段。
如果日志显示已经连到出站目标但目标访问失败，问题可能不在 Reality 字段；如果握手阶段直接失败，优先查 publicKey、shortId、serverName、fingerprint。
相关阅读
FAQ
shortId 长度必须固定吗？ 以服务端配置和核心文档为准。排障时不要混用多个长度，先用一个明确值。
publicKey 改了，shortId 要一起改吗？ 不一定。它们是不同字段。但如果你重建整套 Reality 配置，客户端两者都要同步。
订阅转换后丢 fingerprint 怎么办？ 先手动补上 fingerprint 测试。如果补上就正常，说明转换链路没有完整保留 Reality 字段。