搜索 K
Appearance
适用站点:AirPick · 机场推荐(airpick.co)|最后更新:2026-01|预计阅读:12 分钟
baidu.com / qq.com。国内站也不通 → 99% 是本地物理网络故障,与机场无关。绝大多数人凌晨两点在群里喊"机场挂了"的时候,真实的故障点其实是:光猫 PPPoE 掉线没重播、路由器 NAT 会话表被打满、或者运营商本地网正在割接。这套自测法就是为了不让你在错误的方向上浪费一晚上,也不让你在真正该维权的时候误判成"我自己网络问题"。
要做出正确判断,得先知道从你家到境外节点,一条数据包到底要跨过几道门。
第 1 道门:PON 光链路与光猫。 家用 GPON 的下行光功率正常区间大约在 -8 dBm 到 -27 dBm,接近 -27 dBm 就开始出现 CRC 错包和丢包抖动。光猫同时承担 ONU 认证、PPPoE 拨号、NAT、DHCP 四个角色,家用型号的并发 NAT 会话表普遍只有 3000–8000 条。当你挂着 BT、多个浏览器、Telegram 频道、Clash 的几千条长连接时,会话表打满的直接表现就是:新连接全部超时,但已建立的连接还在跑——这会被误判成"节点全挂"。
第 2 道门:运营商本地网(城域网 + 省网)。 这一层的问题是"半夜割接""BRAS 扩容""DNS 递归超时"。典型特征是 丢包集中在某个固定跳数,且对国内外流量一视同仁——即国内站也会卡。
第 3 道门:国际出口(BGP / IEPL / IPLC)。 传统公网中转走 BGP 国际出口,晚高峰 20:00–23:00 会出现明显的 QoS 限速与绕路;而 IPLC/IEPL 专线走物理专线,绕开公网拥塞,这也是"均衡专线"类服务的核心卖点。注意:这一层出问题,国内站是通的。
第 4 道门:节点侧协议与 TLS 层。 VLESS + Reality、Trojan 等协议在握手阶段一旦被 QoS 干扰,表现为"能连上但速度极低"或"TCP 通、TLS 握手超时"。这一层的判定依赖 tcping 与 openssl s_client。
关键结论:四道门里,只有第 3、4 道门属于"机场的责任"。 而现实中用户最容易把第 1、2 道门的故障归咎到机场头上——这就是"家里断网以为是梯子坏了"的高频误判来源。
请对着下表逐行核对,任意一行命中"本地故障"特征,就先别动机场配置。
| # | 检测层 | 观测手段 | 正常量化区间 | 异常判定阈值 | 责任归属 |
|---|---|---|---|---|---|
| 1 | 光链路(PON) | 光猫管理页光功率 | -8 ~ -27 dBm | 低于 -28 dBm 或 LOS 红灯 | 运营商 / 光纤 |
| 2 | PPPoE 会话 | 光猫 WAN 状态 | 已获取公网 IP,在线时长稳定 | 频繁重播、无 IP | 运营商 / 光猫 |
| 3 | 网关连通性 | ping 192.168.1.1 | 抖动 < 2 ms,丢包 0% | 丢包 > 1% 或超时 | 路由器 / 本地 |
| 4 | 国内 DNS | nslookup baidu.com 223.5.5.5 | 解析耗时 < 50 ms | 超时 / 返回 127.0.0.1 | 运营商 DNS |
| 5 | 国内站点 | curl -I https://www.baidu.com | 首字节 < 200 ms | 连接超时 / 无响应 | 本地物理网络 |
| 6 | 本地 NAT 会话 | 路由器连接数面板 | 低于设备上限 70% | 打满(如 8000/8000) | 光猫 / 路由器 |
| 7 | MTU / MSS | ping -f -l 1472(Windows) | 1472 不分片通过 | 需要降到 1400 才行 | PPPoE MTU 1492 限制 |
| 8 | 出口跳数丢包 | mtr -rwzbc100 1.1.1.1 | 全路径丢包 < 1% | 某一跳丢包 > 5% | 运营商 / 国际出口 |
| 9 | 节点 TCP 握手 | tcping 节点IP 443 | 握手 < 150 ms | 握手超时(无 SYN-ACK) | 机场节点 |
| 10 | 节点 TLS 层 | openssl s_client -connect | 握手成功返回证书链 | TLS 握手超时 / RST | 机场节点 / QoS |
提示:第 1–7 行只要有任意一行异常,先修本地;只有第 8–10 行异常而 1–7 行全部正常,才应该去联系机场客服或换节点。
Step 1 · 断开代理,测国内(10 秒) 完全退出 Clash / Surge / sing-box 客户端(不是切"直连模式",是退出进程,同时关掉系统代理开关与 TUN 模式)。浏览器打开 baidu.com。不通 → 直接跳到 Step 3。
Step 2 · 换设备换网络交叉验证(30 秒) 手机关闭 Wi-Fi,开启个人热点,电脑连接热点后复测同一个国内站和外网站点。
Step 3 · 光猫与路由器死机排查(60 秒) 观察光猫指示灯:PON 常亮、LOS 熄灭为正常;LOS 闪红 = 光纤断或光衰过大,直接报修。路由器看 WAN 口灯是否常亮。 执行一次"冷重启":光猫断电 30 秒后再上电(不是按重启键),等 PON 灯稳定常亮 2 分钟后再开路由器。注意:光猫重启后 PPPoE 重新拨号通常需要 30–90 秒才恢复。
Step 4 · 命令行确认(60 秒)
# 1. 网关是否可达
ping -c 4 192.168.1.1 # Linux / macOS
ping -n 4 192.168.1.1 # Windows
# 2. 国内 DNS 解析是否正常
nslookup www.baidu.com 223.5.5.5
# 3. 国内 HTTP 首字节
curl -o /dev/null -s -w "dns:%{time_namelookup} conn:%{time_connect} ttfb:%{time_starttransfer}\n" https://www.baidu.com
# 4. 出境路径逐跳丢包
mtr -rwzbc100 1.1.1.1Step 5 · 只有 1–4 全绿,才去动机场配置。 此时再测试节点 tcping,或直接联系机场客服,附上 mtr 截图。带证据的工单,处理优先级永远高于一句"你们是不是跑路了"。
下面是排查时真正会用到的一组命令,建议收藏。
# ── TCP 层握手测试(判断节点端口是否被墙/被QoS)
tcping -t 5 节点IP 443
# 输出 "Connected" 且时延稳定 → 节点端口活着
# 输出超时且国内站正常 → 大概率节点侧问题
# ── TLS 握手与证书链(判断 Reality / SNI 伪装是否被干扰)
openssl s_client -connect 节点域名:443 -servername 伪装的域名 </dev/null 2>&1 | head -30
# 能打印证书链 → TLS 层正常
# 卡住 5 秒以上或 Connection reset → 被中间设备干扰
# ── 路由追踪(判断丢包发生在哪一跳)
mtr -rwzbc100 8.8.8.8
# ── 查看本机连接数与端口占用(判断 NAT 会话表是否被打满)
netstat -an | grep ESTABLISHED | wc -l # macOS / Linux
netstat -ano | findstr ESTABLISHED | find /c /v "" # Windows
# ── 检查系统代理是否被残留的客户端劫持
scutil --proxy # macOS
netsh winhttp show proxy # Windows判定速查表:
| 现象 | 最可能原因 | 处理动作 |
|---|---|---|
tcping 通、TLS 超时 | 节点被 TLS 层 QoS 干扰 | 换节点 / 换协议 / 联系客服 |
tcping 超时、国内站正常 | 节点端口被封或宕机 | 换节点,无效则报障 |
mtr 第 4–6 跳开始丢包 | 运营商城域网问题 | 举证报修,与机场无关 |
mtr 全程不丢但延迟飙高 | 国际出口拥塞 / 公网绕路 | 换用 IEPL 专线类服务 |
ping 网关就丢包 | 路由器 / 无线干扰 | 换网线、重启路由 |
| 本机 ESTABLISHED 数破 5000 | NAT 会话表濒临打满 | 关闭 BT / 减少并发客户端 |
Windows。 排查前务必确认三件事:① 设置 → 网络 → 代理 里的手动代理开关已关闭;② 已退出所有 TUN 模式客户端,TUN 会接管路由表,让你"看起来网络全挂";③ 用 ipconfig /flushdns 清一次 DNS 缓存。MTU 问题用 ping -f -l 1472 www.baidu.com 逐步下调测试,PPPoE 环境下常见需要调到 1452 或更低。
macOS。 scutil --proxy 是判断"系统代理是否残留"的最快手段。开启 Clash Verge / Surge 的增强模式后,即使界面退出,遗留的 utun 网卡也可能还在,用 ifconfig | grep utun 检查。此外 macOS 的"私有 Wi-Fi 地址"在部分老旧路由器上会导致 DHCP 分配异常,表现为连上 Wi-Fi 但拿不到 IP。
Android。 长按 Wi-Fi 名称 → 修改网络 → 代理设为"无"。安卓的"私有 DNS"(DoT)在某些运营商网络下会强制走 dns.google 导致解析全超时,排查时先切回"自动"。
iOS。 设置 → 无线局域网 → 点击当前 Wi-Fi → 配置代理 → 关闭。iOS 的"无线局域网助理"会在 Wi-Fi 质量差时偷偷切 4G,造成测试结果互相矛盾,排查期间建议临时关闭。
路由器 / 光猫。 这是"光猫路由器死机排查"的主战场。优先检查:① WAN 连接模式是否为 PPPoE 且账号密码正确;② 是否开启了"双拨""多拨"导致 BRAS 拒绝;③ 是否有固件省电模式让 WAN 口在空闲时休眠;④ 是否 IPv6 与 IPv4 双栈冲突(部分运营商 IPv6 无回程,导致部分站点首选 IPv6 后超时)。降低 MTU 到 1492 并在路由器上开启 MSS Clamping,能解决相当一部分"部分网站打不开"的诡异问题。
| 套路 / 陷阱 | 表面说法 | 真实情况 | 核验方法 |
|---|---|---|---|
| 本地故障甩锅 | "你当地运营商问题,我们节点正常" | 客服统一话术,未核实 | 要求对方提供节点侧 tcping 与监控截图 |
| 跑路前兆伪装维护 | "线路升级,暂停服务 48 小时" | 实为资金链断裂准备跑路 | 观察官网/群是否同时失联,TG 群是否禁言 |
| 伪解锁宣传 | "全平台 4K / ChatGPT 原生" | 仅 DNS 解锁,IP 已进黑名单 | 实测流媒体原生 IP + 登录验证 |
| 超售假象 | "万人同时在线不限速" | 带宽超售 10 倍以上 | 晚高峰 20:00–23:00 连续 3 天测速 |
| 廉价"专线" | "IPLC 专线 9.9 元" | 实为公网中转冒充 | 看路由是否出现 59.43 段(CN2)以外的公网跳 |
| 流量虚标 | "120GB 大流量" | 后台倍率翻倍扣费 | 对比系统流量统计与面板余量 |
核心原则:凡是"理由充分"但"没有任何可验证证据"的解释,都要打问号。 而你自己用 mtr + curl 拿到的数据,是谁都改不了的。
Q1:国内网站能打开,但速度极慢,是机场问题吗? 不一定。先 curl 测百度首字节,如果国内站 TTFB 也 > 800 ms,属于本地宽带或运营商问题。只有国内站飞快、境外站慢,才是节点侧。
Q2:光猫重启后还是不通,怎么办? 看 LOS 灯。红灯闪 = 光路断了,自己无法修,直接打运营商报修。灯正常但无 IP,检查 PPPoE 账号是否被欠费停机。
Q3:手机热点下能用,家里 Wi-Fi 不能用,说明什么? 说明机场节点完全正常,故障 100% 在你的宽带或路由器。优先排查 MTU、DNS、路由器 NAT 会话表和无线信道干扰。
Q4:换了三台设备都不行,还要继续怀疑设备吗? 不需要。三台设备同时故障的概率极低,此时应直接怀疑光猫/宽带线路,或机场整体宕机——用热点交叉测试一步就能分清。
Q5:怎么区分"节点被墙"和"本地网络坏了"?tcping 节点端口超时 + 国内站正常 = 节点侧;ping 网关就丢包 = 本地。这一步不需要任何专业知识,两条命令即可。
Q6:晚高峰必卡,白天正常,是机场超售吗? 有可能,但也要排除运营商国际出口拥塞。用 mtr 观察丢包起始跳:发生在公网国际段,是运营商;发生在节点接入段,是机场。
Q7:怀疑机场要跑路,有什么早期信号? 官网无法访问、注册入口关闭、TG 群禁言、客服连续 48 小时无响应、突然推出"终身套餐大促"。出现任意两项,建议立即停止续费并保留支付凭证。
标签: #本地断网排查 #光猫死机排查 #4G热点交叉测试 #排除本地物理网络故障 #机场排障 #AirPick
结语: 排障的第一原则不是"先怀疑机场",而是"先把自己这一侧排除干净"。一次退出代理、一次热点交叉测试、一条 mtr 命令,往往能省下你和客服的一整晚扯皮。把本地物理网络这一层确认干净之后,剩下的问题才有资格被称作"节点故障"——也只有到那时,你手里的证据才真正有分量。
本文由 AirPick · 机场推荐(airpick.co)技术组维护,数据基于 2026 年 1 月实测,转载需注明出处。