TL;DR：Reality 不是只填一个域名。SNI、dest、serverNames、publicKey、shortId、flow、uTLS fingerprint 要成组核对；任意一项错位，都可能表现成偶发握手失败。
VLESS Reality 的优势来自 TLS 握手层的细节控制。也正因为细节多，很多问题看起来像网络波动，实际是客户端字段和服务端字段没有对齐。尤其是同一份订阅同时给 v2rayN、NekoBox、sing-box、Clash Meta 使用时，字段名会变，但含义不能变。
字段对照
| 字段 | 服务端位置 | 客户端位置 | 检查重点 |
|---|---|---|---|
| SNI / serverName | serverNames | server_name / sni | 必须在允许列表里 |
| dest | realitySettings.dest | 通常不在客户端 | 目标应真实可达 |
| publicKey | 由私钥生成 | public_key / pbk | 复制不能缺字符 |
| shortId | shortIds | short_id / sid | 十六进制长度一致 |
| fingerprint | 无或默认策略 | fingerprint / utls | 多端建议显式设置 |
| flow | client user | flow | 常见为 xtls-rprx-vision |
检查顺序
先看服务端。dest 与 serverNames 应指向同一类真实 HTTPS 目标，端口通常是 443。serverNames 里写了多个名称时，客户端选择的 SNI 必须完全命中其中一个，不能自己加前缀或换根域。
再看客户端。v2rayN、NekoBox、sing-box 对字段命名不同，但 publicKey、shortId、serverName 的值应一致。uTLS fingerprint 建议先用 chrome，排障期间不要在多个客户端间混用随机值。
如果你使用配套订阅线路并导出多客户端配置，建议保留一份原始 Reality 参数表，后续哪端导入异常，就和这张表逐项对照。
操作清单
- 服务端私钥与客户端 publicKey 是一组。
- shortId 没有被二维码、换行或备注截断。
- SNI 在 serverNames 列表内。
- fingerprint 显式写为 chrome、firefox 或 safari 之一。
- flow 与客户端支持能力一致。
- 客户端核心版本支持 Reality 与 uTLS 字段。
常见坑
dest 可达不代表 SNI 正确；浏览器能打开目标站，也不代表 Reality 参数匹配。另一个坑是订阅转换器改写字段名时丢掉 fingerprint，导致桌面端正常、移动端异常。还有人把 serverName 写成 URL，带上 https://，这在多数客户端里都是错误写法。
落地前复查清单
把 Reality SNI uTLS 指纹 当成一次可回滚的小变更处理。先记录当前环境、账号状态、版本号和关键参数，再执行正文步骤。如果你属于“配置 VLESS Reality、Xray-core、sing-box 或多客户端订阅的用户”，不要在同一轮里同时改账号、网络、客户端和计费设置，否则失败后很难判断是哪一项造成。
| 检查项 | 记录方式 |
|---|---|
| 当前目标 | 写清这次只要解决 Reality SNI uTLS 指纹 的哪一个问题 |
| 基线状态 | 截图或保存现有配置、账单、地区、版本号 |
| 操作窗口 | 选择低峰时段，避免影响正在运行的任务 |
| 验证指标 | 用成功率、延迟、费用、可登录状态或页面返回结果判断 |
| 回滚入口 | 保留旧配置、旧密钥、旧订阅或原始文件路径 |
失败后怎么复盘
如果按流程走完仍然失败，先不要继续叠加新方案。把现象拆成三类：完全不可用、偶发失败、能用但成本或速度不达标。完全不可用优先检查前置条件；偶发失败看时间段、地区和上游状态；成本或速度问题再回到 客户端、协议、规则和网络工具配置 的具体约束。完成后对照“对照服务端与客户端字段，确认 SNI、publicKey、shortId、fingerprint 是否一致”复核一次，只保留能稳定复现改善的改动。
相关阅读
FAQ
Reality 一定要用 Vision 吗？ 不是强制，但新配置通常会搭配 xtls-rprx-vision。老客户端不支持时，应先升级再导入。
fingerprint 选哪个最稳？ 排障时选 chrome 最省事，因为实现覆盖广。确定客户端支持后再考虑其它值。
同一服务器能放多个 serverNames 吗？ 可以，但客户端要选择列表中的一个，并与预期 dest 逻辑保持一致。