Xray REALITY 在家庭宽带下间歇性超时：MTU/PMTU 排障记录

现象

同一台 Linux 电脑、同一个 VLESS + REALITY 节点：

• 使用手机热点时，Xray 代理稳定可用。
• 切换到家庭宽带 Wi-Fi 后，部分网站打不开，代理请求经常出现 SSL connection timeout。
• 普通国内网站直连正常。
• Xray 本地代理端口能够接受 HTTP CONNECT，但后续 TLS 请求超时。
• 故障有时成功、有时失败，表现为“时好时坏”。

最终结论

问题与家庭宽带路径上的数据包尺寸或 TCP 分段方式强相关，符合 PMTU 黑洞、MSS 调整异常或 PPPoE 链路兼容问题 的特征。

将 Wi-Fi 接口 MTU 从 1500 降为 1400 后，Google 连通性测试连续 5 次返回 HTTP 204；恢复为 1500 后再次出现超时。

这说明：

• DNS 不是主要故障点。
• Xray 节点的 TCP 443 端口并未完全被封锁。
• IPv6 不是本次主要原因。
• REALITY/TLS 流量触发了与包大小或分段方式有关的链路问题。
• 无法仅凭单端测试确定丢包发生在路由器、光猫、运营商设备还是回程路径，也不能据此断言运营商在主动封锁 Xray。

什么是 MTU

MTU（Maximum Transmission Unit）表示网络接口一次可以发送的单个 IP 包的最大字节数，不是包的数量。

以普通 IPv4 TCP 为例：

MTU 1500
├── IPv4 头：通常 20 字节
├── TCP 头：通常 20 字节
└── TCP 有效载荷：最多约 1460 字节

PPPoE 通常额外占用 8 字节，因此常见路径 MTU 为 1492。

如果发送端按较大的 MTU 分段，而路径中的设备不能正确执行分片、MSS Clamping 或 PMTUD 通知，某些较大分段可能被静默丢弃，形成 PMTU Black Hole：

TCP 三次握手成功
→ 应用发送 TLS/REALITY 握手数据
→ 部分 TCP 分段没有被确认
→ 发送端不断重传
→ 最终 SSL/TLS 超时

注意：不能简单理解为“1500 字节的包只发送了 1492 字节”。网络不会剪掉多出的数据；包会被分片、要求发送端缩小，或者被整个丢弃。

排障证据

1. DNS 正常

多个 DNS 服务器均能解析域名，其中本地公共 DNS 响应很快。DNS 请求数据量较小，即使 MTU 路径异常也可能始终正常。

测试命令：

dig @8.8.8.8 www.baidu.com A +time=3 +tries=1
dig @114.114.114.114 www.baidu.com A +time=3 +tries=1
dig @223.5.5.5 www.baidu.com A +time=3 +tries=1

2. IPv4 直连正常

curl -4 --noproxy '*' -I --max-time 10 https://www.baidu.com

能够返回 HTTP 200，说明 Wi-Fi、默认路由和普通 IPv4 访问正常。

3. 本地代理能接收请求，但代理链路超时

curl -4 --noproxy '' -x http://127.0.0.1:5678 \
  -sS -o /dev/null --connect-timeout 5 --max-time 12 \
  -w 'HTTP=%{http_code} 总耗时=%{time_total}s\n' \
  https://www.google.com/generate_204

失败时：

curl: (28) SSL connection timeout
HTTP=000

其中：

• -4：强制 IPv4。
• --noproxy ''：确保请求不绕过代理。
• -x http://127.0.0.1:5678：使用本机 Xray 的 mixed/HTTP 代理。
• generate_204：Google 的连通性检测地址；正常返回 HTTP 204。

4. 节点的普通 HTTPS/TCP 路径可达

让 curl 把一个普通 HTTPS 请求直接发到节点 IP，并保持正确 SNI：

curl -4 --noproxy '*' --connect-timeout 5 --max-time 12 \
  --connect-to www.apple.com:443:NODE_IP:443 \
  -I https://www.apple.com/

能够返回 HTTP 200，说明该 IP 的 TCP 443 和普通 TLS 并未完全被阻断。普通 TLS 成功并不保证 REALITY 的握手分段也能正常通过。

5. Xray TCP 连接出现大量重传

在代理请求卡住时执行：

ss -ntip dst NODE_IP

故障连接的典型表现：

• 状态为 ESTAB，表示 TCP 三次握手已经完成。
• Send-Q 大于 0。
• bytes_acked 极少。
• bytes_retrans 持续增加。
• RTO 逐步退避，应用最终超时。

这证明问题发生在 TCP 建连之后的数据传输阶段，而不是本地代理端口没有运行。

6. 路径 MTU 与接口 MTU 不一致

tracepath -4 -n NODE_IP

探测结果显示路径中出现 pmtu 1492，而 Wi-Fi 接口当时使用 MTU 1500。

PMTU 是针对具体目标路径的；测试其他网站不能完全代替对真实节点的测试。

7. A/B 对照确认与 MTU 强相关

MTU 1500 时连续请求：

HTTP=000，SSL connection timeout

临时降低 MTU：

sudo ip link set dev WIFI_INTERFACE mtu 1400

再次测试 5 次：

HTTP=204
HTTP=204
HTTP=204
HTTP=204
HTTP=204

恢复 MTU 1500 后，超时重新出现。这是本次判断中最有力的因果证据。

修复方法

临时修改

sudo ip link set dev WIFI_INTERFACE mtu 1400

重连或重启后可能失效。

使用 NetworkManager 永久修改指定 Wi-Fi

nmcli connection modify "WIFI_PROFILE" 802-11-wireless.mtu 1400
nmcli device reapply WIFI_INTERFACE

检查结果：

nmcli -g connection.id,802-11-wireless.mtu connection show "WIFI_PROFILE"
ip link show dev WIFI_INTERFACE

如有 2.4 GHz 和 5 GHz 两个配置，需要分别设置。

恢复自动 MTU

nmcli connection modify "WIFI_PROFILE" 802-11-wireless.mtu auto
nmcli device reapply WIFI_INTERFACE

也可临时恢复为 1500：

sudo ip link set dev WIFI_INTERFACE mtu 1500

再次故障时的判断流程

1. 检查当前 MTU

ip link show dev WIFI_INTERFACE

应看到 mtu 1400。

2. 检查 Xray 是否监听

ss -lntp 'sport = :5678'

3. 对比直连与代理

直连：

curl -4 --noproxy '*' -I --max-time 10 https://www.baidu.com

代理：

curl -4 --noproxy '' -x http://127.0.0.1:5678 \
  -sS -o /dev/null --connect-timeout 5 --max-time 12 \
  -w 'HTTP=%{http_code} 耗时=%{time_total}s\n' \
  https://www.google.com/generate_204

判断：

结果	优先排查
直连和代理都失败	Wi-Fi、路由器、默认路由或宽带
直连正常、代理失败	Xray、节点、REALITY 或代理路径
代理命令成功、浏览器失败	浏览器代理设置、QUIC、缓存或分流
只有单个网站失败	网站本身、DNS 结果或 Xray 路由规则

4. 检查节点 TCP 端口

nc -vz -w 5 NODE_IP NODE_PORT

5. 检查 PMTU

tracepath -4 -n NODE_IP

6. 在请求卡住时查看 TCP 重传

ss -ntip dst NODE_IP

7. 做更小 MTU 的临时对照

若 MTU 已为 1400 仍失败：

sudo ip link set dev WIFI_INTERFACE mtu 1300

如果 1300 成功而 1400 失败，说明故障仍与包尺寸有关；如果两者都失败，应优先检查节点、REALITY 配置和服务器状态，不要无限降低 MTU。

测试后恢复：

sudo ip link set dev WIFI_INTERFACE mtu 1400

经验与边界

1. HTTP/1.1 200 Connection established 只说明本地 HTTP 代理接受了 CONNECT，不代表远端 TLS 已成功。
2. TCP 状态 ESTAB 只说明三次握手完成，不代表应用数据一定能通过。
3. Ping 超时不能直接证明 MTU 有问题，因为目标可能屏蔽 ICMP。
4. tracepath 比单纯 ping 更适合观察 PMTU，但结果仍需要通过实际业务流量做 A/B 验证。
5. 降低 MTU 会略微增加包数量和协议开销，一般对日常速度影响很小；稳定性改善通常更重要。
6. 若需要精确定位丢包位置，应在客户端和代理服务器两端同时抓包，对比序列号、ACK 和重传。单端抓包只能证明数据未被确认，不能确定是哪台设备丢弃。
7. 本次最严谨的结论是“与数据包尺寸或分段方式直接相关”，而不是简单断定“运营商故意丢包”或“1500 比 1492 多 8 字节导致所有包失败”。