⚠️ AI 生成标识 · 本文由 AI Agent 协助撰写，人类作者审核发布。
先说结论：我家宽带这几个月一直在生病，而且病得很隐蔽——隐蔽到所有网速测试都显示”一切正常”，实际上看 B 站视频能卡到你怀疑人生。
一、症状：一切都正常，除了视频
最近几个月我家的网络一直给我一种暧昧的感觉：说它坏吧，网页秒开、微信秒发；说它好吧，看 B 站视频永远在转圈，加载半天下不动，拖动进度条更是折磨。
我一开始没当回事。B 站卡？那肯定是 B 站或者 CDN 的锅，全网流量高峰期嘛，正常。直到我实在忍不了了，决定认认真真查一次。
二、常规检查：全绿，绿得我发慌
我的第一轮排查做足了功课，结果每一项都让我摸不着头脑：
- ping 网关：3ms，丢包 0%
- ping 公网：5ms，丢包 0%
- DNS 解析：15ms，飞快
- 无线信号：81%，协商速率 585Mbps
- Clash 代理？没接管流量，排除
- 防火墙？没有异常
一切正常。但视频就是转圈。
那一刻我猛然意识到一个问题：ping 用的都是 32 字节的小包，而视频是几百 KB 的大包——我的所有测试都在用小包测大包的问题，能不绿吗？
三、真凶一：一个 8 字节的差
换大包测，狐狸尾巴立刻露出来：B 站接口首次连接要等 4~10 秒才有响应，但连上之后一切飞快。
关键线索就是”首次慢、复用快”。这几乎只有一种解释：数据包在路径上被丢了，TCP 在傻等超时重传。
用禁用分片的大包 ping 一测，真相大白：
1
2
ping -f -l 1472 → 被拒（1500 帧过不去）
ping -f -l 1464 → 通过（1492 帧刚好）
你家宽带实际只能过 1492 字节的包，但所有设备的网卡默认按 1500 发。差多少？8 个字节。这 8 个字节，是 PPPoE 拨号的”过路费头”。
原理说人话：PPPoE 宽带就像一条限高 1492 的隧道，标准以太网的车（1500）开不进去。正常流程是中间设备喊一声”超高了，你的车得改小”，你的电脑就会自动改小——但喊话的是光猫，而光猫的喇叭是坏的。于是你的电脑永远不知道自己超高了，每次都傻乎乎开 1500 的车去撞墙，撞完等 3 秒、再撞、再等 10 秒……你看到的”转圈”，就是它在反复撞墙。
我把笔记本网卡 MTU 改成 1400，B 站响应从 4.6 秒降到 0.14 秒。我以为我修好了。
四、并没有。我找到了第二个病
改完网卡的当天晚上我再测，发现网络还是有一阵一阵的慢。顺着往下查，又炸出一个更隐蔽的：UDP 出站全部超时。
UDP 是啥不重要，你只需要知道视频网站的快速通道（QUIC）和 DNS 查询都靠它。而我家宽带 UDP 全丢——发出去 10 个包，10 个石沉大海。TCP 正常、ping 正常、就是 UDP 死透。
这就更诡异了。查了一圈，矛头指向一个我从来没正眼看过的设备：光猫。
光猫比路由器更容易被我忽略，但它才是宽带真正的入口。它内部有个 NAT 映射表，负责给家里每台设备登记”你出去是哪个身份”。TCP 是有状态的，光猫维护得仔细；UDP 没状态，表项烂了它也不管。光猫常年不重启，这个表就越攒越乱，最后 UDP 全军覆没。
解法朴素到不可思议：断电重启光猫。30 秒后一切恢复。
而且翻记录发现，9 月初我家就出现过一次一模一样的 UDP 故障——只不过当时我用 DNS 兜底糊弄过去了。这破光猫，病了至少一个月，我愣是没发现。
五、插曲：一个差点把我带偏的”幽灵报错”
排查到一半的时候，有个现象差点让我下错误结论：我用 Windows 自带 curl 下载 B 站视频分片，超时 15 秒直接失败。但同一秒钟，我家的家庭服务器（走网线）0.15 秒就得到了服务器响应。
“难道是我笔记本的问题？网卡坏了？”
交叉验证之后我才发现：Windows 自带 curl 是个”较真的家伙”，默认要检查视频节点证书的吊销状态，而那个查询服务器在境外，访问超时它就放弃连接。加个参数：
1
curl --ssl-no-revoke <URL>
B 站视频分片立刻 5MB/s 满速下载。 折腾半天，这个”故障”从头到尾都不存在，纯粹是个测试工具在演戏。
我差点因为这个报错怀疑自己笔记本坏了。
六、最后一击：路由器，一行配置救了全家
笔记本改网卡 MTU 只救了笔记本——我家有线的家庭服务器还在被 8 字节的差坑着，下载从来没跑满过。
我把路由器 WAN 口 MTU 从 1500 改成 1492（PPPoE 的标准值），然后做了个对比：
| 改之前 | 改之后 | |
|---|---|---|
| 家庭服务器·Cloudflare 下载 | 240 KB/s | 3.6 MB/s，15 倍 |
| 家庭服务器·B 站视频分片 | 直接连不上 | 8.75 MB/s 满速 |
注意，服务器的网卡我一行都没动，还是 1500。它自己学会了——路由器在自家门口拦下超高的车、好好喊话，设备收到通知自动把包改小。这就是 PMTU 发现的魔法：不用你逐台设备去改，路由器一处设置，全屋设备自动适应。
尾
回头复盘，我家网络病根其实清清爽爽两个：
- MTU 黑洞：PPPoE 物理上限 1492，全屋默认 1500，中间光猫还会当哑巴——路由器改 1492 根治
- 光猫跑太久：NAT 表烂了，UDP 全丢——重启治标，每月重启治本
浪费了一个晚上的排查，最后修的就是”一行配置 + 一次重启”。
给同样被”看着正常但就是卡”折磨的你几个建议：
- ping 全绿不代表网络没事——小包测不出 MTU 黑洞，用
ping -f -l 1472和-l 1464试试 - TCP 连接快、首字节慢，八成是大包丢在路上了
- UDP 全丢但 TCP 正常？先重启光猫，别急着报修
- 宽带是 PPPoE 的家庭，路由器 WAN 口 MTU 设 1492，一劳永逸
- 如果哪次排查遇到”Windows curl 超时但别的工具正常”——恭喜你，遇见了 CRL 吊销检查这个幽灵，加
--ssl-no-revoke即可
最后说个反直觉的：光猫和路由器是两台设备，而你家的宽带，真正干活的是那台你最容易忽略的光猫。它病了，全家网速都跟着遭殃——哪怕路由器换一万块钱的也没用。
每月抽 30 秒重启一次光猫，或许能救你一整个下午。
