症状有三条：抖音视频能播但评论一直转圈，图片偶发加载失败；游戏延迟显示绿色但操作有滞后；部分网站整页打不开，刷新后恢复。

设备是小米 BE5000（固件 1.0.91），电脑走网线。此前一轮报障已经把校园网出口拥塞定为主因，结论写着”与用户侧设备无关”。

实际结果是两件事叠加：校园网出口分方向异常仍然存在，用户侧修不了；直接造成本次卡顿的是路由器自己的 IPv6 中继。关闭路由器 IPv6 后，50 路并发的最大 TCP 建连时间从 2504 ms 降到 243 ms。

一、分层定位

第一轮只做只读测量，不改配置。

层 测什么 结果
网卡 协商速率、错误与丢弃计数 1 Gbps 全双工，计数全 0
电脑 → 路由器 100 包 ping 192.168.31.1 全回，平均 1 ms，最大 3 ms
路由器 → 校园首跳 10.10.30.13 1 ms，0% 丢包
出口分方向 电信、联通、移动、教育网各一个靶标 电信 4 ms、联通 11 ms 正常；移动 29 ms、教育网 39 ms 偏慢
DNS 四个 resolver 各查 5 次计时 1–2 ms，无失败

路由器后台读数：CPU 负载 0，内存 45%，QoS 关闭，在线 3 台设备，WAN 是校园网下发的 10.12.x.x/20 地址，MTU 1500。

同一时刻电信方向 436 Mbps，教育网方向单线程 2.3 Mbps。这组数据把慢点定位在校园网出口之后，但它解释不了上面的三条症状。

链路分层与故障域划分

二、空闲 ping 测不出转发层故障

补充一条信息：网线直插宿舍墙口时体感更顺。这与第一层的结论冲突。如果慢点全在出口之后，绕不绕路由器不该有区别。

按可证伪的形式重排假设：

假设 预测
IPv6 路径异常（中继质量或 PMTU 黑洞） 同一目标 IPv6 明显慢于 IPv4，或大包失败
路由器 DNS 转发超时 经 192.168.31.1 解析有长尾，直查公共 DNS 正常
硬件转发 / NAT 路径抖动 DNS 与 IPv6 正常，但并发 HTTPS 有长尾，且路由器负载仍低
出口分方向拥塞 不同运营商方向吞吐差异大

第四条已有证据，但它无法解释”绕过路由器更顺”，只能算放大器。

四条假设都指向偶发，改用并发复现。40 路并发拉抖音首页，同一时刻对路由器的 ping 仍是平均 1 ms、0% 丢包，但 40 路中有一路 TCP 建连 3 秒超时，其余拉长到 215–470 ms，而这个站平时建连只有 20–50 ms。

这就是症状的来源：页面加载要并发拉几十到上百个资源，整体耗时取决于最慢的那一条；游戏测延迟只测自己那条 UDP 会话。用平均值判断链路健康会漏掉这类故障。

三、双栈分开压

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 同一目标，分别强制 IPv4 / IPv6，各打 50 路并发
$u = "https://www.douyin.com/"
foreach ($fam in "-4", "-6") {
  "=== $fam ==="
  $sb = {
    param($x, $f)
    $w = "%{http_code},%{time_connect},"
    $w += "%{time_starttransfer},%{time_total}"
    curl.exe -sS -L --noproxy "*" $f -o NUL `
      --connect-timeout 3 --max-time 8 -w $w $x
  }
  $jobs = 1..50 | ForEach-Object {
    Start-Job -ScriptBlock $sb -ArgumentList $u, $fam
  }
  $null = Wait-Job $jobs
  $r = @($jobs | ForEach-Object { Receive-Job $_ })
  Remove-Job $jobs
  $ok = @($r | Where-Object { $_ -like "200,*" })
  $c = @($ok | ForEach-Object { [double](($_ -split ",")[1]) })
  $avg = [math]::Round(($c | Measure-Object -Average).Average * 1000)
  $max = [math]::Round(($c | Measure-Object -Maximum).Maximum * 1000)
  $fail = $r.Count - $ok.Count
  "ok=$($ok.Count) fail=$fail avg=${avg}ms max=${max}ms"
}
协议栈 成功 建连平均 建连最大
IPv4 50/50 41 ms 252 ms
IPv6 50/50 220 ms 2504 ms

双栈并发建连长尾对比

IPv6 没有失败请求，平均值也不算异常，问题全在最大值上。

DNS 假设同时被排除：四个 resolver 各查 5 次，路由器转发没有长尾也没有失败。

另一组按 PMTU 黑洞思路做的探测失败了。用 ping -6 向三个 IPv6 靶标打 1452、1440、1400、1280 四种载荷，全部 0 回复。1280 是 IPv6 强制最小 MTU，连它都不回说明不是分片问题，而是目标根本不回 ICMPv6；随后单独测 443 和 80 端口，各 100 次全部连通。这组探测不能作为证据。IPv6 环境下 ping 不通是常态，判断健康度要用 TCP 建连。

四、根因：pi_relay

xqnetwork/ipv6_status 返回如下。真实前缀和接口标识符已替换为 RFC 3849 文档前缀 2001:db8::/32，只保留结构：

1
2
3
4
5
6
7
8
9
10
{
  "ifname": "ae_wan",
  "ipv6_mode": "pi_relay",
  "wanType": "pi_relay",
  "ip6addr":        ["2001:db8:1f00:230::a1/64"],
  "lan_ip6addr":    ["2001:db8:1f00:230::b2/64"],
  "lan_ip6prefix":  ["2001:db8:1f00:230::"],
  "ip6gw": "fe80::1",
  "peerdns": "1"
}

pi_relay 决定了问题的形状。正常结构下路由器应通过 DHCPv6-PD 拿到比 /64 更大的前缀（/60 或 /56），自行切分 /64 下发给 LAN，LAN 是一段独立地址空间。这里学校只给了 WAN 一个 /64，LAN 用的还是同一个前缀，路由器无法做路由，只能中继邻居发现报文，让电脑直接在校园网那个 /64 里取地址。

pi_relay 与 DHCPv6-PD 两种结构

直插墙口时电脑自己发 RS、收 RA，这层中继被整个跳过，所以体感更顺。

IPv6 转发本身没有额外开销，出问题的是没有 PD 时的中继模式和这版固件的实现质量。hwnat 的 force_start 读数为 0（硬件 NAT 强制开关关闭），当时也列为嫌疑，但改它会导致路由器重启、影响面比 IPv6 大，排除 IPv6 之后未再处理。

五、修复与验证

先在客户端禁用 IPv6：

1
Disable-NetAdapterBinding -Name "以太网" -ComponentID ms_tcpip6

返回拒绝访问，改网卡绑定需要管理员权限。改路由器反而更合适：影响面覆盖全部设备，回滚只需把开关拨回去。

登录走固件的 xqsystem/login，密码按 sha256(nonce + sha256(密码 + 固件常量)) 做摘要，管理密码从本地文件读取、不回显。

1
2
3
GET  xqnetwork/get_wan6_switch_v2   ->  enabled = 1
POST xqnetwork/set_wan6_switch_v2   ->  enabled = 0,  code = 0
GET  xqnetwork/get_wan6_switch_v2   ->  enabled = 0

客户端 ipconfig /renew 后只剩链路本地地址，全局 IPv6 地址与 ::/0 默认路由撤销，IPv4、网关和校园认证连接不变。

指标 修复前 修复后
50 路并发成功 / 失败 IPv4 50/0，IPv6 50/0 50/0，走 IPv6 的请求为 0
建连平均 41 ms / 220 ms 39 ms
建连最大 252 ms / 2504 ms 243 ms
本机 → 路由器 平均 1 ms 50/50，平均 1 ms，最大 1 ms
抖音主页（连续 10 次） 0.10–0.28 s
抖音静态 CDN 0.025–0.10 s
哔哩哔哩主页 0.07–0.11 s
图片 CDN 0.03–0.08 s

改动只有这一个开关。全局关闭意味着所有连这台路由器的设备一起改走 IPv4，它们手上的旧连接不会自动迁移，改完需要重开应用。

结论适用于这台 BE5000、1.0.91 固件、只下发 /64 的校园网。可复用的是判据和实验设计，不是”关 IPv6”这个动作。

六、用户侧修不了的部分

关掉 IPv6 后重测分方向吞吐：

方向 靶标 下载
电信 华为云镜像 302 Mbps
移动 网易镜像 44 Mbps
教育网 USTC 镜像 4.5 Mbps

223.5.5.5 平均 4 ms、20 包 0 丢包。同一时刻电信方向能跑 300 Mbps，说明不是总带宽、账号限速或终端性能，而是校园网到不同上游的分方向问题。

上一轮为排除用户侧做过一次 A/B：同一根墙线、同一个 10.12.x.x 内网地址、同一个 NAT 出口，分别在”经路由器”和”直连墙口”两种接法下测同一批目标 IP，结果一致甚至直连更差。

目标 经路由器 12:37 直连墙口 13:19
校园首跳 0% 丢包 / 2 ms 0% 丢包 / 1 ms
网易 / 移动 5% / 53 ms / 4 Mbps 10% / 56 ms / 1 Mbps
华为云 / 电信 7.5% / 28 ms / 9 Mbps 1 Mbps

其余排除项：MTU 1472 不分片可通，非路径 MTU 黑洞；下行 301 Mbps 满载时 RTT 从 29 升到 43 ms，非缓冲膨胀；用 ping -i 让对端分别看到 TTL 127/128/129，丢包率 4%/10%/4% 无规律，非针对 NAT 终端的策略。最有说服力的是路由器内置测速，测速源就是 WAN 口本身，不经 NAT 不经电脑，故障期间连测三次为 1.41 / 1.13 / 1.51 Mbps 下行。

这些整理进了一份报障文本。配套留了个常驻脚本，每 60 秒采一轮五个方向的时延、抖动、丢包和 WAN 实时流量，追加进 .diag\watch.csv。四天后它记录了移动方向从 45–47 ms / 10% 丢包恢复到 29 ms / 0%，同时教育网从 21 ms 劣化到 39 ms。有连续采样，方向性变化才可比较。

另有一条至今有效的分流优化，校内域名走校园 DNS、其余走公共 DNS，重启不丢：

1
2
Add-DnsClientNrptRule -Namespace @("buct.edu.cn", ".buct.edu.cn") `
  -NameServers @("202.4.130.100", "202.4.130.101", "223.5.5.5")

七、IPv4 与 IPv6 的取舍

项目 IPv4 IPv6
宿舍内工作方式 BE5000 做 NAT，多设备共用一个内网地址 理想是路由器获 PD 前缀再分配，实际是同前缀中继
兼容性 最成熟 大部分支持，不是全部
延迟 取决于路径 协议本身不比 IPv4 慢，受中继实现与上游质量影响
对体验的影响 — 双栈应用优先试 IPv6，评论、头像、图片分属不同 CDN

表格最后一行是本次问题的成因：主文档走 IPv4 很快，评论和图片走 IPv6 很慢，页面卡在后者上。

方案 收益 代价 适用条件
路由器全局关闭 IPv6（当前做法） 长尾消失，全设备统一 纯 IPv6 校内资源不可达 不需要 IPv6
终端设 IPv4 优先、IPv6 后备 保留 IPv6 能力 手机等设备仍受中继影响，部分应用自选栈 需要 IPv6
向学校申请 DHCPv6-PD 结构正确，保留完整 IPv6 取决于网络中心是否配置 长期解法
改 AP / 桥接模式 绕过中继与 NAT 多设备各自认证、可能限终端数或绑 MAC、防火墙与设备隔离消失、内网结构变更 确认账号支持多终端
刷第三方固件或 NAT66 可精细控制 NDP Proxy 变砖风险，且修不了上游路由质量 不推荐

顺序建议：先关闭；确实需要 IPv6 时退到终端优先级方案；同时向网络中心确认宿舍有线是否支持 DHCPv6 Prefix Delegation。不要把 pi_relay 留作长期默认路径。

八、排查清单

按顺序执行，前一层不干净则后面的测量无效：

  1. 网卡协商速率与错误、丢弃计数
  2. 电脑 → 网关连打 100 包，记录最大值而不是平均值
  3. 网关 → 校园或运营商首跳
  4. 分方向吞吐，至少电信、联通、移动、教育网各一个镜像靶标
  5. 多 resolver 的 DNS 计时
  6. 以上正常但仍有卡顿：40–50 路并发打同一目标，看建连最大值
  7. curl -4 与 curl -6 分开各压一轮

判据：

  • 平均值正常、最大值离谱即为长尾，页面卡顿量级与最大值对应。
  • 空闲 ping 不能排除转发层故障。
  • IPv6 的 ICMP 不通是常态，用 TCP 建连判断。
  • “绕过路由器更顺”与既有结论冲突时，先重排结论，不要补测。

以下动作在当时条件下都不必做：恢复出厂（根因是固件默认中继模式，重置后仍在）、改 DNS（DNS 正常，只会增加变量）、开 QoS 或限速（CPU 负载 0，排队不在路由器）、为 160 MHz 换信道（本机走网线，且宿舍频谱拥挤）、测出长尾前刷固件。

9 月 11 日同一套流程复用于一次新的变慢：网卡与网关正常，国内靶标 3–4 ms 且 0 丢包，1.1.1.1 平均 105 ms，Cloudflare 下载 6.7–19.1 Mbps，本机后台流量接近 0。国内全好、只有跨境差，判定为国际出口或跨境路由，未改动任何配置，定位耗时约 15 分钟。

遗留问题：关闭 IPv6 之后路由器网页后台提示管理密码错误，同一密码走 xqsystem/login 可正常取得会话令牌，说明密码未变，故障在登录页的 nonce 生成与提交链路，当时未查完。

九、小结

“直连更顺”这条主观描述是本次唯一有效的实验线索。它与既有结论冲突时，该怀疑的是既有结论：几天前写下的”与用户侧设备无关”作为报障结论成立，作为排查终点不成立。另一个可迁移的点是判据选择，测速工具报的是单条会话的平均值，页面加载取决于并发会话中最慢的那一条，所以要盯最大建连时间和并发失败率。

BE5000 的转发性能没有变化，教育网方向仍是 4.5 Mbps，报障文本尚未提交。变化是 2.5 秒长尾消失，以及下次变慢时有了一套明确的测量顺序。