VLESS Reality 在一个网络可用，另一个不可用

VLESS Reality 在一个网络可用，另一个不可用，不说明配置坏了。尽量固定客户端、服务端、配置、设备和测试时间，再逐层对比 TCP 与端口、IPv4/IPv6、DNS、MTU、SNI、本地政策和路径过滤。找到第一个可复现差异，比随机切换选项更有价值。

完整 VPN 指南说明整条连接路径。本文假设同一配置已经在网络 A 成功，只做网络 A/B 对照，不与一般“VPN 无法连接”问题混在一起。

关键要点

• 改设置前在网络 A 保存干净基线。
• 区分 TCP 可达、REALITY 认证与之后的代理流量。
• 把 IP 协议族、DNS、端口、MTU、SNI、政策和过滤当成独立假设。
• 不关闭证书检查、不弱化标识，也不绕过网络所有者政策。
• 保存时间戳与脱敏证据，供各方核对同一事件。

VLESS Reality 在一个网络可用，另一个不可用怎么办？

使用同一设备、客户端版本、配置、服务端地址与端口、serverName、公钥、short ID、底层传输和测试目标。两次测试尽量靠近，避免服务更新、DNS 轮换或证书变化成为隐藏变量。

无需导出配置，只记录非敏感字段和版本，删除 ID、私钥、订阅地址、令牌与服务器信息，勿公开 URI。

证据	可用网络 A	故障网络 B
日期、时间、时区	精确记录	精确记录
接入类型与所有者	Wi-Fi/移动数据/以太网	Wi-Fi/移动数据/以太网
普通 HTTPS	成功或失败	成功或失败
服务端主机与端口	相同、已脱敏	相同、已脱敏
DNS A/AAAA	已记录	已记录
TCP 阶段	成功/超时/拒绝	成功/超时/拒绝
REALITY 阶段	结果、错误和时间	结果、错误和时间
连接后小请求	结果	结果

两个网络都能到达 VLESS Reality 服务器吗？

步骤 1：先证明普通网络可用

在网络 B 上断开配置，打开一个你有权访问的普通 HTTPS 页面。通过合法页面完成强制门户认证。不要接受证书警告；拦截 TLS 的门户不能作为有效基线。

记录设备的 DNS、默认路由和信号是否正常稳定。如果普通访问已经坏了，先修复或上报该接入网络的问题。在底层连接不可用时，VLESS Reality 的错误无法指出隧道特有的原因。

在网络 A 上重复同一个小型普通请求。目的不是比速度，而是证明两个网络在对比时都能承载正常流量。

步骤 2：找到最早失败阶段

客户端的一句“连接失败”会把好几个阶段混在一起。请使用受支持的日志或诊断视图，找出最早出现差异的那一点：

1. DNS 解析配置的服务器主机名。
2. 设备选择 IPv4 或 IPv6 地址。
3. TCP 到达配置的端口。
4. REALITY 检查服务器名称、公钥、short ID 和握手。
5. VLESS 完成认证并建立代理会话。
6. 所选应用的流量被路由进该会话。
7. 远端出口到达测试目标。

Project X 把 VLESS 描述为无状态的轻量传输协议，并列出客户端侧的服务器与身份字段。［1］REALITY 有各自独立的目标、serverNames、密钥和 short ID 约定。［2］把这些阶段分开，能避免把 TCP 被阻断误标为 VLESS 认证问题。

步骤 3：对比端口与 TCP

如果 B 无法完成 TCP 而 A 可以，核对完全相同的地址与端口。访客 Wi-Fi、单位网络和移动运营商可能允许常见网页，却限制未知端点或端口。本地防火墙也会造成类似现象。

只对自己的服务端做少量可达性测试，不扫描网络或第三方端口。超时表示客户端没收到可用响应，立即拒绝通常表示某处主动拒绝；两者都不能单独确定责任方。

若运营者提供另一个获准端点，可在之后作为单变量比较。不要把服务伪装到被禁止端口，也不要规避明确网络政策。

比较地址、握手、传输与策略行为

步骤 4：对比 IPv4 与 IPv6

同一个主机名可能同时返回 A 和 AAAA 记录。网络 A 可能能到达 IPv4 地址，而网络 B 优先使用 IPv6；纯 IPv6 接入网络可能依赖 DNS64/NAT64，而这对字面 IPv4 地址并不适用。IPv6-only 排障指南详细解释了这条边界。

记录客户端实际选择的地址族，而不只是设备是否显示 IPv6 地址。比较两个网络上服务器的 DNS 答案，并确认配置的是主机名还是字面地址。字面 IPv4 端点无法被 DNS64 合成，因为根本不会发生 DNS 查询。

不要把全局关闭 IPv6 当作“修复”。那会改变网络本身，而不是证明兼容性，还可能破坏普通访问。应借助客户端或运营方诊断，核实服务器确实发布并监听了服务声称支持的地址族。

步骤 5：单独比较 DNS

若配置使用主机名，在两个网络分别记录 A/AAAA 和时间。答案不同可能来自地理调度、split DNS、缓存或解析政策，并不一定是恶意干扰。

区分连接前的服务端名称解析与连接后的目标名称解析。如果服务端主机名没有解析，握手尚未开始；若 REALITY 已成功但网页失败，应检查后一个路径。

不要盲目更换 DNS。在你管理的网络上，可把获准解析器对比作为一个变量，随后恢复原设置。ISP 阻断概览介绍 DNS 方法，却不能把每次失败都判定为封锁。

步骤 6：检查 SNI 与 REALITY

REALITY 从 serverNames 接受 SNI，名称应符合目标证书行为。［2］ 项目说明也把目标协议支持与路由位置列为兼容条件。［3］ 网络设备可能区别处理某个 SNI，但拼写错误、旧配置或目标变化也会产生类似结果。

比较两个网络的精确非敏感 serverName 与客户端版本。若 TCP 在 B 成功、握手却失败，保存错误和时间。不要换成随机热门域名；目标和允许名称是服务端绑定契约。

若 B 连普通 HTTPS 目标都限制，可以记录为路径政策线索，但这不能证明 REALITY 流量受到完全相同处理。

步骤 7：识别 MTU 症状

MTU 问题通常在连接看似已经开始之后才出现：极小的请求能成功，较大的页面却卡住；上传先于下载失败；或当证书、响应变大时隧道反复重置。这与 TCP 连接根本打不开是两回事。

通过已连接的会话，用一个小请求和一个中等大小的获准传输作对比。记录失败是否只在超过某个大小阈值后才开始，以及是否存在丢包。避免洪泛、穷举式探测，或宣称有一个适用于所有路径的“神奇”MTU 值。

如果客户端提供文档说明的 MTU 设置，只在支持范围内修改，并且先保存基线。如果同一个可复现请求没有改善，就恢复原值。较小的设置能成功，说明存在路径包大小问题，但并不能确定是哪一跳丢弃了数据包。

步骤 8：检查设备与网络政策

查看受管理的设备配置、终端安全、家长控制、强制私有 DNS、内容过滤、访客网络条款，以及明确禁止个人隧道的规定。在家庭 Wi-Fi 上的工作笔记本仍可能受设备策略约束；在公司 Wi-Fi 上的个人手机也可能受网络策略约束。

不要为了绕过规则而卸载设备管理、关闭安全软件或伪装流量。请询问网络所有者该端点和端口是否获准。如果过滤器由你自己管理，按准确的时间戳和目标查看日志，只有在政策允许时才添加范围最窄的文档化放行规则。

如果你要的是在两个网络上都能用的连接，而不是修好这份配置，托管客户端是更短的路。安装 AethoVPN，在两个获准网络上都连接应用里的同一个位置；如果这个位置在限制更严的网络上卡住，就换一个负载指示为绿色的位置。开始 3 天免费试用，把两个网络并排对照。这些结果反映的是托管服务在你这两个网络上的表现；如果要修好自己的 VLESS 配置，仍以上文的 REALITY 握手检查为准，因为 AethoVPN 公开的设置流程没有写明任何协议。

步骤 9：区分路径过滤与服务端故障

B 失败后，不改配置再测 A。若 A 也失败，服务端、账户、证书或服务状态可能已经变化；若 A 仍稳定成功，而 B 总在同一阶段失败，接入路径就成为更强变量。

只把 B 上第二台获授权设备用于确认。两台都卡在 TCP，更应检查网络；只有一台失败，则对比系统协议族、客户端版本、防火墙和 VPN 权限。在网络这个常量得到证明之前，不要把本案并入笼统的设备差异调查。

单一症状不能证明检测。拥堵、IPv6、DNS、端口、MTU 和政策都可能造成网络特定故障。采用证据支持的最窄解释。

步骤 10：把证据交给正确负责人

向服务运营者提供脱敏版本、时间、协议族、TCP 结果、REALITY 错误、到达时的 VLESS 错误，以及单变量结果。网络所有者通常只需目的地址类别、端口、时间和普通 HTTPS 结果，不要泄露凭证，也不要要求对方为你绕过政策。

若你管理两端，把客户端时间与服务端 accept、handshake、auth、outbound 日志关联。A 成功而 B 没有 accept，问题在更早路径；已有 accept 但认证失败，则返回配置与时钟证据。

VPN 连接测试指南适合确认连接后的路由，不能反推握手前为什么失败。

总结

• 固定配置、设备、服务端和时间窗口后再比较网络。
• 找到第一个差异阶段：DNS、协议族、TCP、REALITY、VLESS、路由或目标。
• 分别检查端口、IPv4/IPv6、DNS、MTU、SNI、政策与过滤。
• 故障后重测网络 A，排除服务端漂移。
• 测试应获授权、有限、可恢复并且不含秘密。

常见问题

移动数据可用能证明 Wi-Fi 阻断 REALITY 吗？

不能，只能证明路径相关差异。Wi-Fi 的 DNS、IPv6、端口、MTU、门户、设备配置或过滤都可能是原因。

应该在故障网络更改 serverName 吗？

不应该。名称必须匹配服务端 serverNames 和目标行为，随机替换通常只会制造无效配置。

IPv6-only 网络能访问 IPv4-only 服务端吗？

有时可借助 DNS64/NAT64，但并非普遍成立。字面 IPv4 不经过 DNS 合成，可能无法到达。

为什么连接成功后大页面仍卡住？

这可能是握手后的 MTU 或丢包问题。调整受支持的 MTU 前先对比小请求与中等请求。

TCP 超时能证明审查或封锁吗？

不能。它只表示没有收到可用响应。路由、墙规则、端点故障、拥堵和故意过滤可能表现相同。

可以关闭杀毒软件或设备管理测试吗？

不要这样做。只在自己管理的设备使用日志和获准临时控制，不能移除组织管理与安全保护。

哪些信息可以安全发送给支持？

发送版本、时间、网络类型、DNS 与协议族、首个失败阶段和 A/B 结果。不要发送完整配置、密钥、令牌或订阅地址。

免责声明：本文仅用于获授权故障诊断，不授权绕过网络政策、扫描第三方系统或削弱认证与设备保护。

来源：

1. Project X, "VLESS": https://xtls.github.io/en/config/outbounds/vless.html
2. Project X, "REALITY": https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/transports/reality.md
3. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md

Sources checked 2026 年 9 月 9 日。

---

延伸阅读：

• 理解完整 VPN 路径
• 排查 VLESS Reality 故障
• 排查一般 VPN 连接失败
• 验证连接后的路由
• 排查 IPv6-only 接入网络