[Bug] 赞助商九云的 REALITY 订阅在 2.3.12 全部 -1ms（fp=ios），Clash Meta 正常

[Magixyne]

提交前排查

服务端问题已排除。 用 Xray-core 26.3.27 在本机以订阅中完全相同的出站参数直连该节点：

• 协议：VLESS + REALITY + TCP + xtls-rprx-vision
• sni / servername：cloudflare.com
• fingerprint：ios
• 结果：HTTP 204，388ms

同时模拟 v2rayNG 的「测试全部」，对该节点 UUID 发起 24 条并发连接，24/24 全部返回 204，服务端没有并发或速率限制。

节点 URI 结构（凭据已脱敏）：

vless://<UUID>@<SERVER>:12101?mode=multi&security=reality&encryption=none&type=tcp&flow=xtls-rprx-vision&pbk=<PUBLIC_KEY>&sid=<SHORT_ID>&sni=cloudflare.com&servername=cloudflare.com&spx=%2F&fp=ios

已搜索过的重复 issue：

• Android fingerprint doesn't work #4908 Android fingerprint doesn't work（2025-09）
• [Bug/Feature Request] Expand Fingerprint selection: Allow pinning specific uTLS IDs to bypass SNI+Fingerprint filtering #5406 Expand Fingerprint selection（2026-03，提到换用新版 Xray-core / uTLS 后 REALITY 连接大量失败）
• Randomized fingerprint problem #3522 Randomized fingerprint problem

以上都涉及 fingerprint 与 REALITY 的组合，但没有「fp=ios 全部超时、同一订阅在 Clash Meta 正常」这个具体情况，因此新开一条。

补充背景：该机场（九云 / jiuyundy.com）是 v2rayNG 的赞助商之一，其订阅在自家推荐的 Clash Meta 上完全正常。

预期行为

导入订阅后选择任意节点，连接应当正常建立，延迟测试返回实际数值。

实际行为

24 个节点全部显示 -1ms（测试超时），一个都不通，切换节点没有任何区别。

同一份订阅、同一网络、同一台设备，导入 Clash Meta 后全部正常。

复现方法

1. 导入上述订阅链接到 v2rayNG 2.3.12（默认配置，未开启 Mux，路由规则未改动）
2. 节点列表 → 测试全部配置真连接延迟
3. 观察：全部节点 -1ms

对照组：

4. 同一订阅导入 Clash Meta，节点全部可用

日志信息

Details

通过 adb logcat -s com.v2ray.ang GoLog V2rayConfigUtilGoLog Main 获取。

（待补充）

环境信息

• v2rayNG 版本：2.3.12
• Android 版本：待填
• 设备型号：待填
• 内核：默认（Xray）
• 配置：默认，未启用 Mux，未改动路由规则
• 网络：待填（例如国内家宽 / 移动 5G）

额外信息（可选）

1. 这批节点实际上是同一个 endpoint

订阅里的 24 条记录全部指向同一个 host:port，其余 23 条只是把「剩余流量 / 到期时间」写进备注的展示节点。所以现象是「整条线路全灭」，而不是部分节点失效。

2. 服务端对不同 uTLS 指纹的响应不一致

在同一 endpoint 上逐个替换 fingerprint 测试：

fingerprint	结果
ios	204
chrome	204
firefox	204
safari	204
random	204
android	连接被 reset

服务端 dest 是 cloudflare.com，对 android 指纹的 ClientHello 不友好，这一点与 #4908 的现象吻合。

3. 对 v2rayNG 侧的怀疑

服务端在 fp=ios 下完全正常，问题应该出在 2.3.12 对 VLESS URI 中 fp 参数的解析或映射上。可能的方向：

• fp=ios 未被识别，解析为空或落到非 uTLS 的 ClientHello，REALITY 握手必然失败
• 或最近一次 Xray-core / uTLS 升级带来的 fingerprint 回归（参考 [Bug/Feature Request] Expand Fingerprint selection: Allow pinning specific uTLS IDs to bypass SNI+Fingerprint filtering #5406）

A/B 对照：把该节点的 fingerprint 手动改成 chrome 或 firefox 后再测，若恢复连通即可确认是 fp=ios 的处理问题。这一条我会在补充移动端测试后同步结果。