risk/troubleshoot · 集群 B · 性能与 DNS 问题 · 4/6

分层排障法:设备、客户端、订阅、节点、目标站五层定位

发布时间 待核实核实日期 待核实最近更新 待核实测试状态 Not Tested
Answer First · 核心结论

分层排障法把代理链路拆成五层:设备与本地网络、客户端、订阅、节点与线路、目标站。自上而下逐层确认,每层只回答一个问题:这一层是否正常。前三层基本可以自行解决,第四层需要对比判断,第五层往往与机场无关。配合「每次只改一个变量」的原则,可以避免在错误方向上反复折腾。

五层模型是什么

五层模型是把一次代理访问经过的所有环节,按「离你远近」分成五层,每层回答一个是非问题。它的作用不是提供标准答案,而是提供一个固定的检查顺序,避免想到哪查到哪。

  层级   名称            要回答的问题                    控制权
  ────   ──────────      ──────────────────────────      ──────
  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 客户端    运行中  系统代理  关闭 ← 发现问题
  处理:开启系统代理 → 恢复
  ─────────────────────────────

养成记录的习惯后,你会发现自己的故障集中在哪几层,下次排查可以直接从那里开始。

把模型用起来

五层模型可以压缩成一句话:先确认自己这边没问题,再去怀疑别人。实际使用中,你不需要每次都完整走一遍,熟悉之后往往看一眼现象就知道大概在哪一层。

如果排查结果指向服务端长期问题,可以参考 主力服务故障时的替代方案与备用订阅规划,并在 机场品牌库 查看其他品牌的资料。本站未对任何品牌做过实测,所有资料仅供参考。

常见问题

为什么要按从设备到目标站的顺序排查?

因为越靠近设备的层越容易检查、也越在自己控制范围内。先排除简单的本地原因,可以避免把本地问题误判为服务商问题。

每一层都要全部检查完吗?

不需要。每层只要能确认正常就进入下一层,发现异常就在该层处理。熟练之后,很多问题在前两层就能定位。

客户端日志有什么用?

日志能告诉你连接卡在哪个阶段,例如解析失败、握手失败还是认证失败。它是判断问题在哪一层最直接的依据,分享日志时注意去除订阅链接等敏感信息。

如果五层都看起来正常,问题还在怎么办?

可能是多个因素叠加或间歇性问题。建议记录出现问题的时间、节点和目标站,积累几次样本后再分析,或带着记录联系服务商。

信息来源与更新时间

信息来源
品牌清单资料(品牌公开信息整理)
测试范围
本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
发布时间
待核实
核实日期
待核实
最近更新
待核实

字段含义与数据状态见 字段说明;核查进度见 品牌动态与核查日志。