从现象到根因：网络排错的系统化方法论（OSI 分层实战）
前面九篇都是具体场景，这一篇讲『道』：面对一个没见过的网络故障，如何不靠运气、不瞎试，用结构化方法逼近根因。掌握了思路，任何新设备都能自己排。
一、先定义『现象』而非『猜测』
- 区分症状与假设：『WiFi 坏了』是结论，『手机连上 WiFi 但打不开网页，且 Ping 网关超时』才是可操作的现象。排错前先用一句话写清可观测事实。
- 划定影响范围：是个别设备、某个 SSID、整个网段还是全部外网？范围越精确，故障域越小。这是后续二分法的依据。
- 确认『何时开始』：是突然发生还是渐进？刚升级固件、搬了家具、加了设备吗？时间点是变更回溯的锚。
二、用 OSI 模型自底向上
- 物理层：灯亮不亮、线有没有松、光功率够不够。先排除最土的层面，别一上来改配置。
- 链路/网络层：拿到 IP 了吗？能 Ping 通网关吗？能 Ping 通公网 DNS 吗？Traceroute 卡在第几跳？
- 传输/应用层：端口通吗？DNS 解析对吗？证书有效吗？逐层验证，哪层断就在哪层修。
三、二分法与最小系统
- 剥离变量：把复杂网络拆成最小可复现系统——一台电脑直连光猫，能通说明问题在内部网络，不通说明在运营商或光猫。
- 逐个回退变更：最近改了什么就先改回去。固件升级出问题就回滚；新加 AP 出问题就先撤下。变更即嫌疑。
- 对照法：拿一台正常的设备/配置做对照，差异点就是突破口。这是定位软件 bug 最高效的手段。
四、记录与验证
- 改动一次只改一个量：同时改三处，成功了也不知道是哪处生效，失败了更不知根因。控制变量是排错纪律。
- 用证据闭环：修完后要能解释『为什么之前不通、现在通了』，并用日志/抓包佐证，而非『好像好了』。
- 建立自己的检查表：把反复遇到的问题沉淀成清单（如『QoS 先关硬件加速』），下次直接套用。
技术总结：排错不是试错，而是『定义现象 → OSI 分层定位 → 二分法缩小范围 → 单变量验证』的闭环。纪律比经验更重要，证据比感觉更可靠。