risk/troubleshoot · 集群 B · 性能与 DNS 问题 · 4/6
分层排障法:设备、客户端、订阅、节点、目标站五层定位
分层排障法把代理链路拆成五层:设备与本地网络、客户端、订阅、节点与线路、目标站。自上而下逐层确认,每层只回答一个问题:这一层是否正常。前三层基本可以自行解决,第四层需要对比判断,第五层往往与机场无关。配合「每次只改一个变量」的原则,可以避免在错误方向上反复折腾。
五层模型是什么
五层模型是把一次代理访问经过的所有环节,按「离你远近」分成五层,每层回答一个是非问题。它的作用不是提供标准答案,而是提供一个固定的检查顺序,避免想到哪查到哪。
层级 名称 要回答的问题 控制权
──── ────────── ────────────────────────── ──────
L1 设备与本地网络 不开代理能正常上网吗?时间对吗? 自己
L2 客户端 客户端运行且真正接管流量了吗? 自己
L3 订阅 订阅最新、套餐有效、流量充足吗? 自己+服务商
L4 节点与线路 多个节点都异常吗?换网络呢? 服务商
L5 目标站 只有某些网站异常吗? 目标站
注意最右一列「控制权」:L1、L2 完全在你自己手里,L3 部分依赖服务商,L4 主要由服务商负责,L5 则属于目标网站。排查时越往下,你能做的越少,所以越要先把上层排除干净。网络层面的原理可以参考 网络原理与排障 专题。
L1 设备与本地网络
L1 的判断标准是:关闭代理后,国内网站能正常访问,系统时间与时区正确。
| 检查项 | 方法 | 异常时 |
|---|---|---|
| 本地网络 | 关闭代理访问国内网站 | 修复宽带、WiFi、移动网络 |
| 系统时间 | 对比网络时间,检查时区 | 开启自动对时 |
| 网络环境 | 是否在企业、校园或公共网络 | 换网络对比,遵守网络使用规定 |
时间问题的原理见 系统时间不同步为什么会导致代理断连。
L2 客户端
L2 的判断标准是:客户端内核正常运行,并且目标应用的流量确实进入了客户端。
常见检查项包括:客户端进程是否在运行、系统代理或 TUN 是否生效、代理模式是否为直连、是否有其他代理软件冲突、客户端日志是否有报错。具体逐项方法见 代理客户端无法连接的常见原因与逐项排查。
客户端日志在这一层特别有用。不同阶段的报错大致对应不同的层:
| 日志中出现的信息(大致) | 指向的层 |
|---|---|
| 配置解析失败、规则加载失败 | L2 客户端 / L3 订阅 |
| 域名解析失败 | L1 本地 DNS 或 L2 客户端 DNS |
| 握手失败、证书错误 | L1 时间 或 L4 节点 |
| 认证失败、连接很快断开 | L3 订阅参数 |
| 连接成功但目标站返回错误 | L5 目标站 |
L3 订阅
L3 的判断标准是:订阅能成功更新,用户面板显示套餐有效、流量充足、设备数未超限。
订阅层的问题会同时影响所有节点,是「所有节点同时失效」的常见原因之一。订阅更新失败的处理见 订阅更新失败怎么办,订阅原理可参考 订阅管理 专题。
L4 节点与线路
L4 的判断标准是:多个不同地区的节点中至少有一部分能正常工作,且速度在可接受范围。
这一层要用对比法:
换同地区节点 ──▶ 正常? ──是──▶ 原节点异常
│否
换不同地区节点 ──▶ 正常? ──是──▶ 某地区线路异常
│否
换网络环境 ──▶ 正常? ──是──▶ 原网络到入口的路径问题
│否
多设备都异常 ──▶ 服务端整体问题,反馈服务商
如果问题是速度慢而不是连不上,L4 的分析方法见 代理速度慢的定位方法。节点相关概念可参考 节点与 IP。
L5 目标站
L5 的判断标准是:问题是否只出现在特定网站或服务上。
如果其他网站都正常,只有某一个网站异常,问题大概率不在机场。可能原因包括:目标站自身故障、目标站对某些地区或 IP 类型有访问策略、分流规则把这个网站分到了不合适的出口。这一层的详细判断见 部分网站能开部分不能。对于 AI 和流媒体平台,可用性还与平台的地区政策和 IP 策略有关,参考 AI 工具访问 专题。
单变量原则
分层模型之外,最重要的方法是「每次只改变一个变量」。很多排查失败不是因为不知道该查什么,而是一次改了太多地方,导致无法判断哪一步起了作用。
| 做法 | 结果 |
|---|---|
| 同时更新订阅、换节点、重启客户端 | 问题可能解决,但不知原因,下次仍要从头查 |
| 先更新订阅 → 测试 → 再换节点 → 测试 | 能明确知道是哪一步解决了问题 |
建议在排查时简单记录每一步的操作和结果,这既能帮你积累经验,也方便向服务商反馈。
一个完整的排查示例
下面用一个虚构的场景演示如何使用五层模型。场景:晚上回家打开电脑,浏览器访问境外网站一直转圈,而早上在公司还正常。
L1:关闭代理访问国内网站,正常;检查系统时间,正常。L1 排除。
L2:客户端在运行,查看系统代理设置,发现系统代理是关闭的。原因可能是早上在公司时手动关掉了,或者客户端更新后重置了设置。重新开启系统代理后,问题解决。
这个例子说明,很多故障在 L2 就能定位,根本不需要怀疑服务商。如果 L2 正常,就继续 L3:手动更新订阅,查看面板;再到 L4:换节点、换网络对比。
示例排查记录
─────────────────────────────
L1 本地网络 正常 时间 正常
L2 客户端 运行中 系统代理 关闭 ← 发现问题
处理:开启系统代理 → 恢复
─────────────────────────────
养成记录的习惯后,你会发现自己的故障集中在哪几层,下次排查可以直接从那里开始。
把模型用起来
五层模型可以压缩成一句话:先确认自己这边没问题,再去怀疑别人。实际使用中,你不需要每次都完整走一遍,熟悉之后往往看一眼现象就知道大概在哪一层。
如果排查结果指向服务端长期问题,可以参考 主力服务故障时的替代方案与备用订阅规划,并在 机场品牌库 查看其他品牌的资料。本站未对任何品牌做过实测,所有资料仅供参考。
常见问题
为什么要按从设备到目标站的顺序排查?
因为越靠近设备的层越容易检查、也越在自己控制范围内。先排除简单的本地原因,可以避免把本地问题误判为服务商问题。
每一层都要全部检查完吗?
不需要。每层只要能确认正常就进入下一层,发现异常就在该层处理。熟练之后,很多问题在前两层就能定位。
客户端日志有什么用?
日志能告诉你连接卡在哪个阶段,例如解析失败、握手失败还是认证失败。它是判断问题在哪一层最直接的依据,分享日志时注意去除订阅链接等敏感信息。
如果五层都看起来正常,问题还在怎么办?
可能是多个因素叠加或间歇性问题。建议记录出现问题的时间、节点和目标站,积累几次样本后再分析,或带着记录联系服务商。
信息来源与更新时间
- 信息来源
- 品牌清单资料(品牌公开信息整理)
- 测试范围
- 本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
- 发布时间
- 待核实
- 核实日期
- 待核实
- 最近更新
- 待核实