Reality 连接错误：vision 相关历史 issue 写了什么
历史 issue 记录过 vision 与 reality 连接错误，以及 unknown UUID 等日志。评论有不同推测，关闭原因是未按模板提交；具体修复版本，官方没有说明，不能把关闭等同于已经修复。
这条记录发生在什么时候？
issue 444 提出于 2023-03-14，关闭于 2024-10-20。 标题针对当时的 alpha 构建，描述 vision 与 reality 连接错误。它属于历史问题记录，不能把当时的测试构建改写为今天所有版本都有相同现象。
关闭状态为 not planned，标签是 help wanted 与 question。状态和标签分别反映问题记录的分类与处理情况，不是已经提供了某个修复构建的说明。
| 记录内容 | 这次 issue 的信息 |
|---|---|
| 提出时间 | 2023-03-14 |
| 关闭时间 | 2024-10-20 |
| 关闭状态 | not planned |
| 修复版本 | 官方没有说明 |
用户报告了哪些现象？
报告者的日志反复出现 XTLS Vision 的 unknown UUID 提示。 还有用户称 ClashMetaForAndroid 失败而 v2rayNG 成功，服务端日志出现 hs.c.conn == conn: false。这是帖子里各用户的描述。
其中一条评论说，热切换配置可能让代理组仍停留在旧状态，重启后处理。这也只是评论者报告的场景，没有给出所有版本的行为保证。
日志文字用于辨认历史讨论在讲哪种现象，没有把它转化为你当前设备的诊断结果，也没有提供实际连接参数。
评论推测了哪些原因？
评论中有人将失败与客户端指纹及版本限制联系起来，但属于讨论推测。 Xray 维护者 RPRX 说，minClientVer 用于拒绝过旧的 uTLS 或客户端实现。他同时推测，失败可能和客户端缺少指纹有关。
他还对 Clash.Meta 在 REALITY 下自定义 ALPN 提出批评，这是评论者个人观点。技术名称在评论出现。
用户现象、评论推测和官方正式配置要求不是同一类依据。
有用户称去掉服务端 minClientVer 限制后可用。这里仅记录其自述，不把改动写成推荐操作，也不根据个例补一套修改服务端的步骤。
为什么关闭了这条问题？
关闭理由是没有遵循 issue 模板，并请提交者按模板重新提出。 这个理由涉及提交格式，不是代码修复记录。不能把页面状态从打开变成关闭，改写为维护者已经确认根因并给出修复版本。
| 内容性质 | 阅读时保留什么 |
|---|---|
| 用户变通方法 | 个别用户的自述 |
| 指纹相关判断 | 评论中的推测 |
| ALPN 评价 | 发言者个人意见 |
| 关闭理由 | 未按模板提交 |
按这几类内容分开看，能够保留讨论原来的不确定性。
官方还没有说明什么？
mihomo 的正式配置项与具体修复版本，官方没有说明。 历史 alpha 现象也没有对应当前版本的适用记录，不能直接扩展到你现在的客户端。
阅读旧记录时，可先看日期，再看发言性质，然后看关闭理由。这是整理该记录的次序，不是官方故障处理顺序，也不由此要求你更改客户端或服务端。
可以按记录内容核对：
- 看提出与关闭日期，不把旧 alpha 现象当成当前版本。
- 区分用户自述、评论推测和个人观点。
- 查看关闭理由，不从关闭状态补出修复版本。
相关问题可看 配置与连接排查资料，入门概念可看 客户端常见问题。这里不增加未经说明的系统或服务端操作。
核对状态：依据：官方文档与通用说明 · 最近核对 2026-11-01