故障排查大全:按症状逐层定位

排查框架:先定位故障层级

故障排查里最耗时间的部分从来不是修复,而是找错方向。同样一句「连不上」,可能来自账户状态、本地网络、客户端配置或目标服务本身,这四处的位置相差很远,处理方式也完全不同。如果一上来就反复切换线路,往往只是把同一个错误重演几遍,还顺手掩盖了真正的线索。

本章先给一套分层框架和一份信息采集清单。后面八章按具体症状展开,每章都可以独立阅读,但建议先花三分钟走一遍本章的分诊流程,确认问题落在哪一层,再跳到对应章节。第一次接触本服务的读者,也可以先看 上手教程 把注册、选套餐、导入订阅这条主线走完,再回到这里。

四个层级各自负责什么

账户层。账户层管的是「有没有资格连」。订阅是否在有效期内、当月流量是否已经用尽、套餐是否到期,这三点决定了客户端能不能从服务端拿到有效的线路配置。VPNWing 的月订阅分三档:¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量按开通日每月重置;另有流量包 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完为止,永久不过期。如果当月额度已经用尽,客户端通常表现为能连上但很快断开,或者直接提示订阅失效。中途升级套餐时,差价会折算成剩余天数,不需要重新计算周期。

网络层。网络层管的是「本地能不能出去」。这里包括 Wi-Fi 信号质量、路由器状态、所在网络是否对特定端口有限制、DNS 是否能正常解析。判断方法很直接:完全退出客户端,只用本机网络访问几个常用的本地站点,如果这一步就不通,那问题与 VPNWing 无关。

客户端层。客户端层管的是「配置对不对」。包括客户端版本、订阅是否成功导入、分流规则是否把目标域名判给了直连、系统代理或虚拟网卡是否被其他软件占用。这一层的问题最容易被误判成线路故障,因为表现同样是「连上了但打不开」。

目标服务层。目标服务层管的是「对面是否正常」。有些站点会针对数据中心 IP 段做限制,有些服务在特定时段做维护,还有些区域限制与线路无关、只与出口归属地有关。判断方法是换一条不同地区的线路再试同一个站点,如果所有线路都失败,大概率是目标侧的问题。

三分钟分诊:按顺序走一遍

1. 打开用户面板,确认订阅状态、剩余流量与到期时间。这一步排除账户层。
2. 完全退出客户端,用本机网络访问两个常用站点,确认本地网络本身可用。这一步排除网络层的基础连通性。
3. 重新打开客户端,切换到一条与当前不同的线路,优先换不同地区、不同线路类型,例如从直连换到 IEP 专线。这一步区分是单条线路问题还是全局问题。
4. 在浏览器里先访问一个此前确认可用的站点,再访问此前失败的目标站点。两步对比可以区分「整体不通」和「单个站点不通」。
5. 如果以上都正常但目标站点仍然失败,记录下失败时的具体提示文本,进入对应章节深入排查。

走完这五步,大多数问题已经能定位到具体章节。剩下的时间花在细节上,而不是反复试错。

关于同时在线设备数的常见误解

VPNWing 同时在线不限台数,一个账户可以在 Windows、macOS、iOS、Android、Linux 上同时使用,不需要为每台设备单独开通。因此当你看到与「连接数」「设备数」相关的提示时,通常不是账户额度限制,而是本地环境的连接表被打满了。

常见的两个来源:一是家用路由器的 NAT 会话表容量有限,当同一网络里同时有大量下载、视频、游戏连接时,新建连接会失败,表现和「设备数超限」很像;二是操作系统本身的文件描述符或端口占用达到上限。这两种情况的共同特征是,断开部分设备或暂停大流量任务后连接立即恢复。如果符合这个特征,处理方向是重启路由器、减少并发连接数,而不是更换套餐。

提工单前需要准备的信息

工单里信息越完整,定位越快。以下几项建议一次性附上:

• 注册时使用的用户名,不需要提供密码。
• 出问题的平台与系统版本,例如 Windows 客户端、macOS 客户端、iOS 客户端、Android 客户端、Linux 客户端。
• 客户端里显示的线路名称与线路类型,例如东京 · IEPL 专线、香港 · 中转。
• 故障开始的时间点,以及是持续出现还是间歇出现。
• 复现步骤:从打开客户端到出现问题的完整动作顺序。
• 错误提示的原文或截图,不要只写「连不上」。
• 已经做过的自查项,例如换过哪几条线路、换过哪个网络环境、是否重装过客户端。

什么情况应当直接提工单

有三种情况不必继续自查,直接提交工单效率更高:一是同一账户下的所有设备、所有线路在同一时间段全部失败;二是客户端在启动或导入订阅时直接报错退出,无法进入主界面;三是已经按对应章节的步骤完整走完一遍,问题仍然稳定复现。

工单入口在用户面板内,提交后可以在同一页面查看回复。如果问题与计费或退款相关,VPNWing 提供 30 天无理由退款,在工单里说明订单信息即可,不需要额外提供其他材料。

完全连不上:三个环节逐段判断

「完全连不上」指客户端无法建立连接:按钮一直转圈、进度停在某个百分比,或者刚显示已连接就立刻退回未连接。这三种表现的成因差别很大,先分清属于哪一种,能省掉大半试错。

三种「连不上」的区别

第一种是握手前失败:点下连接后很快报错,连转圈的时间都很短。这通常意味着客户端根本没能与线路入口建立会话,方向在本地网络或入口可达性。

第二种是握手中失败:转圈持续数秒到数十秒后失败。这说明网络路径是通的,卡在认证、配置下发或加密协商环节。

第三种是握手后立即断开:短暂显示已连接,几秒内又回到未连接。这类问题往往与配置完整性、系统代理冲突或安全软件拦截有关。

握手前:先确认本地环境

第一步永远是裸连对照。完全退出客户端,不是最小化到托盘,用本机网络访问两个常用站点。如果这一步就打不开,问题不在 VPNWing,先处理本地网络:重启路由器、切换 Wi-Fi 频段,或者改用蜂窝网络对比。

第二步检查系统时间。加密握手依赖证书有效期校验,系统时间偏差过大,常见于长期休眠后唤醒或手动改过时区的设备,会让握手在第一步就失败,而且错误提示通常很含糊。各平台的自动时间同步开关都在系统设置里,打开后重启客户端再试。

第三步检查安全软件。部分杀毒软件与防火墙会把客户端创建的虚拟网卡判定为异常网络接口并拦截,表现为客户端显示已连接、但系统里没有出现新的网络接口。处理方式是把客户端加入白名单,或者临时关闭防护做一次对照测试。测试完记得恢复。

第四步检查是否有第二个代理软件在运行。两个客户端同时接管系统代理或同时创建虚拟网卡,会互相覆盖配置,结果是两边都连不上。同一时间只保留一个。

握手中:认证与订阅

如果网络路径确认通畅,下一步看订阅。在用户面板里核对三件事:订阅是否在有效期内、当月流量是否还有剩余、套餐是否已经到期。这三项任意一项不满足,客户端都会在认证阶段被拒绝。

订阅导入失败也会表现为「连不上」。判断方法是在客户端里手动触发一次订阅更新,看是否提示成功。如果更新失败,直接跳到后面的订阅更新章节,那里有完整的排查路径。

还有一种情况是客户端版本与订阅格式不匹配。订阅内容会随客户端类型下发不同格式,如果手动粘贴过配置,格式错位会导致解析失败。处理方式是清空当前配置,重新从面板获取一次订阅,不要在旧配置上追加。

握手后:连上就断

短暂连接后立刻断开,常见原因有三个。

一是分流规则与本地网络冲突。例如规则把客户端自身的更新域名判给了代理,而该域名在代理侧不可达,客户端在启动自检时就会失败。处理方式是把客户端更新域名加入直连规则,或临时切换到全局模式做一次对照。

二是 MTU 不匹配。封装后的数据包超过路径 MTU 又没有被正确分片,会导致大包被丢弃,表现为连上了但几秒内掉线。这个问题在部分移动网络和拨号环境下更常见,后面「能连上但打不开网页」一章有详细的判断方法。

三是账户在别处被重复登录。虽然 VPNWing 同时在线不限台数,但如果同一账户在短时间内被大量设备反复登录,服务端可能触发保护性限流。处理方式是确认没有其他设备在循环重连。

现象对照表

仍然不通时

如果换过至少两条不同地区、不同类型的线路,直连与 IEPL 专线各一条,换过至少一个网络环境,问题仍然稳定复现,就应当提交工单。工单里附上客户端显示的完整错误文本、故障开始时间、以及已经试过的线路名称,能显著缩短处理时间。

如果只是某一条线路在特定时段不可用,可以先换用其他线路继续使用,同时在工单里说明具体线路名与时段,便于针对性排查。

能连上但打不开网页:分流、DNS 与 MTU

客户端显示已连接,状态灯是绿的,但浏览器一直在转圈,或者只有一部分站点打不开。这是排查里最常见也最容易误判的一类。它几乎不是「线路坏了」,而是「流量有没有走对路」的问题。

先分清两种范围

第一种是全都不通:连上之后任何站点都打不开,包括此前能正常访问的。这类问题通常出在系统代理设置、虚拟网卡没有正确接管流量,或者 DNS 完全失效。

第二种是部分不通:一部分站点正常,另一部分打不开;或者同一个站点,首页能开、点进详情页就失败。这类问题通常出在分流规则、DNS 解析结果或 MTU。

判断方法很简单:连上之后依次访问三个站点,一个本地站点、一个常用的国际站点、一个此前失败的目标站点。三步的结果组合基本能定位方向。

方向一:分流规则

分流规则决定哪些流量走代理、哪些直连。规则出错有两种典型表现。

一是该走代理的走了直连。目标域名被规则判为直连,于是请求直接从本地网络发出,自然打不开。这种情况在规则库更新滞后、或者目标站点更换了域名时出现。处理方式是在客户端的规则列表里搜索目标域名,看它落在哪一条规则上;如果确实被判为直连,手动加一条代理规则,或者临时切换到全局模式验证。

二是该直连的走了代理。本地站点被送进代理通道,反而变慢或失败。这类问题不影响连通,但会浪费流量,也容易让人误以为线路慢。

判断技巧:切换到全局模式再试一次。如果全局模式下目标站点能打开,问题就在分流规则;如果全局模式下仍然打不开,继续往下看 DNS 和 MTU。

方向二:DNS 解析

DNS 问题的典型表现是能 ping 通地址,但域名打不开。原因是域名解析返回了错误结果,或者解析请求根本没有得到响应。

判断方法是在命令行里对同一个域名做一次解析,看返回的地址是否合理。如果解析结果明显异常,或者解析超时,基本可以确认是 DNS 环节。

处理方式有三种,按侵入性从低到高:

1. 在客户端里切换 DNS 模式。多数客户端提供跟随系统、使用内置 DNS、指定上游这几种选项,切换到内置 DNS 通常能绕开本地运营商的解析问题。
2. 手动指定一个可用的上游 DNS。设置后需要清一次系统 DNS 缓存,否则旧的解析结果还会被沿用。
3. 如果只有个别域名解析异常,可以在客户端里为该域名单独指定解析方式,或者改用地址直接访问做一次对照。这种方式仅用于验证,日常仍建议用域名。

方向三:MTU 与分片

MTU 问题的表现很有辨识度:小页面能打开,大页面加载到一半停住;图片显示不全、视频卡在第一帧、登录页面提交后一直转圈。原因是封装后的数据包超过了路径允许的最大长度,而路径上的设备又没有正确返回分片需要的控制消息,于是大包被静默丢弃。

判断方法是用不允许分片的探测包测试。在 Windows 上可以用 ping 的 -f 与 -l 参数组合,在 macOS 与 Linux 上用 ping 的 -D 与 -s 参数组合,逐步增大包长,找到不分片仍能收到回复的最大值,再加上包头长度就是可用 MTU。

处理方式是在客户端或系统网络设置里把 MTU 调低。常见的取值在 1400 附近,具体值需要按上面的探测结果确定,不要照抄别人的数字。调整后断开重连一次让设置生效。

用命令行缩小范围

以下命令只用于验证连通性,不涉及任何账户信息:

# 检查域名解析结果
nslookup example.com

# 检查目标是否可达(仅验证连通性)
ping -c 4 example.com

# 检查 HTTP 响应头,确认是网络问题还是站点问题
curl -I https://example.com

Windows 下把 ping -c 4 换成 ping -n 4。如果 nslookup 返回异常地址,问题在 DNS;如果解析正常但 ping 全部超时,问题在路由或分流;如果 ping 正常但 curl -I 超时,问题更可能在 MTU 或目标站点侧。

处理顺序

建议按分流规则、DNS、MTU 的顺序排查,因为三者的判断成本依次上升。分流规则只需要切换一次全局模式;DNS 需要一条命令;MTU 需要多组探测。按这个顺序走,大多数问题在前两步就能解决。

如果三步都确认正常,但目标站点仍然打不开,换一条不同地区的线路再试。如果换线路后恢复,说明是原线路到该站点的路径问题,记录下来提工单即可。如果换线路后依旧,而本地网络访问该站点正常,那更可能是目标侧对该地区出口做了限制。

速度慢:先分清带宽不足还是线路绕路

「速度慢」是描述最模糊的一类反馈。同样一句「慢」,可能是本地带宽不足、可能是线路绕路、可能是目标站点限速,也可能是设备本身在后台跑着别的任务。先把瓶颈定位到具体一段,再谈优化。

先确认瓶颈在哪一段

一条完整的访问路径可以拆成四段:设备到路由器、路由器到本地运营商、本地运营商到线路入口、线路出口到目标站点。四段里任何一段拥塞,最终表现都是「慢」,但处理方式完全不同。

一个基本的判断原则:经过代理的速度不会超过本地出口带宽。如果本地宽带上行本身只有很小的值,那么无论换哪条线路,上传方向都不会变快。同理,如果家里其他设备正在做系统更新或云盘同步,可用带宽会被先占掉一部分。

分段测量的方法

第一步,断开客户端,测一次本地网络到本地站点的速度,记录结果。这是基准值。

第二步,连上客户端,测一次到同一地区站点的速度。如果这一步就明显下降,问题在设备到路由器这一段,检查 Wi-Fi 信号强度、频段(2.4GHz 与 5GHz 的实际吞吐差别很大)、以及是否有同频干扰。

第三步,连上客户端,测一次到目标地区站点的速度。这一步反映的是跨境链路的质量。

三次结果放在一起看:如果第一步就慢,问题在本地;如果第一步正常、第二步明显下降,问题在客户端或路由器;如果前两步正常、第三步慢,问题才在跨境线路。

需要强调的是,单次测速结果的波动很大,受测速服务器负载、时段、浏览器缓存影响。判断时应连续测三次以上,看中位数而不是单次峰值。

线路选择:地理邻近不等于路由最优

很多人默认「离得越近越快」,实际并不总是。跨境链路的质量取决于路由跳数、经过的骨干网、以及是否走独立通道,而不只是直线距离。三类线路的差异可以这样理解:

线路类型说明:IEPL 专线走独立通道,中转经骨干节点转发,直连为本地出口。完整的地区与类型清单可以在 线路列表 页查看。

如果某条线路在白天表现良好、晚上明显变慢,大概率是共享链路在高峰期拥塞,换到 IEPL 专线通常能改善。如果某条线路在任何时段都慢,那更可能是路由绕路,换地区比换类型更有效。挑选线路的通用方法可以参考 按地区、线路类型与用途选线 这篇。

客户端设置的影响

几个容易被忽略的设置项:

• 协议与加密套件。加密强度越高,运算开销越大。在低功耗设备上,例如老款移动设备或入门级路由器,这部分开销可能成为瓶颈。如果设备性能有限,可以选用开销更低的组合。
• 多路复用。开启后多条连接复用同一条隧道,能减少握手次数,但在丢包率高的链路上可能放大阻塞。可以试着开关对比。
• 分流规则的复杂度。规则条目极多时,每次请求都要做一次匹配,在低性能设备上会带来可感知的延迟。精简规则或改用按域名后缀匹配能缓解。
• 后台任务。系统更新、云盘同步、照片备份都会在后台占用带宽,而且往往在夜间自动启动。排查速度问题时先确认这些任务的状态。

什么时候是套餐额度的问题

如果速度下降的同时伴随连接不稳定,建议先打开用户面板看一眼当月流量。VPNWing 的三档月订阅分别是 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量按开通日每月重置。当月额度接近用尽时,部分客户端会给出提示。

如果只是某个月用量偏大,可以购买流量包补充:¥158/300GB、¥358/1000GB、¥658/3000GB,用完为止,永久不过期。流量包与月订阅的额度分开计算,不冲突。如果长期用量都超过当前档位,升级月订阅更划算,差价会折算成剩余天数。三档的完整对照可以在 套餐与价格 页看到。

不要用单次测速下结论

测速结果受太多因素影响,单次数字没有参考价值。判断一条线路是否适合自己,更实用的做法是在自己的常用时段、用自己常访问的站点,连续观察几天。如果某条线路在多数时段都稳定,就不必因为某一次测速数字偏低而换掉它。

如果按上面的方法分段测完,确认瓶颈在跨境链路,而且换过至少两条不同地区的线路都没有改善,可以把三次测量的时间、线路名称与结果一并提交工单。

晚高峰卡顿:拥塞来源与线路切换

如果白天的连接一切正常,到了晚上七点到十一点之间开始卡顿、视频频繁缓冲、会议声音断续,这大概率不是设备故障,而是跨境链路的共享资源在高峰期被占满。

为什么偏偏是晚上

跨境访问的路径上有一段是共享的。工作日的晚间是家庭网络使用最集中的时段:视频、游戏、下载、视频会议同时涌入,国际出口的带宽被大量占用。与此同时,目标侧的服务器也处在自己的高峰时段,响应速度同样会下降。

这意味着两件事。第一,晚高峰的卡顿往往是双向叠加的结果,不完全是线路的问题。第二,单纯换一条同类型的线路,改善可能很有限,因为新线路走的还是同一段拥塞链路。

三类线路在高峰期的表现差异

不同类型线路对拥塞的敏感度不同:

• IEPL 专线走独立通道,不经过公共互联网的拥塞段,在高峰期受到的影响最小。代价是单位成本更高,通常用于对稳定性要求高的场景。
• 中转经骨干节点转发,前半段走优化路径,后半段仍共享公共链路。高峰期表现介于专线与直连之间。
• 直连为本地出口直接出网,完全依赖公共链路,高峰期波动最明显。

VPNWing 目前提供 120+ 国家 / 160+ 线路,覆盖三种线路类型。日常浏览用直连通常够用;如果晚高峰是主要使用时段,优先选 IEPL 专线或中转。完整的线路清单与类型标注可以在 线路列表 页查看,按地区分组,每条都标了类型。

先排除家里的变量

在把问题归给线路之前,先花两分钟排除本地因素:

1. 家里是否有其他设备在做大流量任务。系统更新、云盘同步、电视盒子缓存视频都会占用带宽,而且往往在晚间自动启动。
2. Wi-Fi 是否被邻居的同频信号干扰。晚高峰同样是邻居用网的高峰,2.4GHz 频段的干扰会明显加剧。切换到 5GHz 频段通常立刻改善。
3. 路由器是否长时间没有重启。部分家用路由器在连续运行数周后,会话表碎片化会导致新建连接变慢。重启一次做对照。
4. 设备本身是否在降频。笔记本在电池模式下会限制性能,加密解密的开销随之上升。

这四项排除掉之后,再把问题归到线路上,判断才准确。

可以做的五件事

第一,按用途选线路。视频会议和大文件传输优先 IEPL 专线;日常浏览和短视频用中转或直连即可。不必所有场景都用同一条线路。

第二,错峰安排大流量任务。系统更新、备份、大文件下载可以安排在白天或深夜,避开高峰时段。

第三,减少并发。同一账户同时在线不限台数,但同时跑多个高带宽任务会互相挤占。晚高峰期间可以暂停不必要的后台同步。

第四,关闭不必要的运算开销。在性能有限的设备上,选择开销更低的加密组合能腾出一些处理能力。

第五,记录时段与线路。如果某条线路在固定时段稳定变慢,记录下来。这份记录对判断是线路问题还是整体拥塞很有价值,也是提工单时最有用的信息。

关于速率承诺

需要说明的是,VPNWing 不承诺具体的速率数字。跨境链路的实际速度受本地带宽、目标站点、时段、路由等多重因素影响,任何固定的速率承诺都无法反映真实情况。可以确认的是线路类型与覆盖范围:120+ 国家 / 160+ 线路,三种线路类型可选,同时在线不限台数。

如果晚高峰的卡顿已经影响到正常使用,而且换过专线类型仍然没有改善,建议提交工单,附上具体时段、线路名称与使用场景。这类问题往往需要按线路逐个排查,提供的信息越具体,定位越快。

频繁断线:重连策略与网络切换

断线比连不上更让人烦躁,因为它打断的是正在进行的事情。排查断线的关键不是「重连」,而是找出断线的规律:间隔是否固定、是否与某个动作同时发生、是否只在某个网络下出现。规律一旦确认,原因基本就锁定了。

三种断线规律

第一种,间隔固定。每隔几分钟或几十分钟断一次,间隔大致相同。这类问题通常与保活机制、心跳超时或服务端的会话时限有关。

第二种,随机出现。没有固定间隔,有时几小时不断,有时十分钟断三次。这类问题多与网络环境有关:Wi-Fi 信号波动、移动网络在基站之间切换、或者上游链路抖动。

第三种,空闲后断线。正在使用时不断,放下不管一段时间后回来发现已经断开。这是典型的 NAT 会话超时,属于预期行为而不是故障。

判断方法很直接:记录三次以上断线的时间点,看间隔是否接近。三次就足够看出规律。

规律性断线:保活与超时

如果间隔固定,先检查客户端的保活设置。多数客户端提供心跳间隔或保活开关,开启后客户端会周期性地发送小包维持会话。关闭保活时,链路上的中间设备可能因为长时间没有数据而回收会话,表现为固定间隔断线。

第二个检查点是服务端的会话时限。部分线路为了均衡负载会设置单次连接的时长上限,到时间后强制重连。这种情况的表现是:断线后立刻能重连成功,而且重连后又能稳定使用一个相同的时长。如果符合这个特征,说明不是故障,可以考虑换一条会话策略不同的线路。

第三个检查点是系统休眠。笔记本合盖、移动设备锁屏后,系统会暂停网络活动,唤醒时隧道已经失效。处理方式是在系统电源设置里允许网络设备在睡眠时保持活动,或者养成唤醒后手动重连的习惯。

随机断线:网络切换与信号

随机断线的排查重点是网络环境。

Wi-Fi 信号波动。距离路由器较远、中间隔墙、或者周围同频设备多,都会导致丢包率上升。丢包达到一定程度后,客户端判定链路不可用并触发重连。判断方法是靠近路由器再做一次对照,如果断线频率明显下降,问题就在信号。

移动网络切换。在移动中使用时,设备会在基站之间切换,每次切换都会短暂中断数据连接。如果客户端没有做快速重连,表现就是断线。这类问题在通勤路线上尤其明显,属于网络特性,处理方向是开启客户端的自动重连并缩短重试间隔。

双网并存。部分设备同时开着 Wi-Fi 与蜂窝网络,系统会在两者之间做智能切换。切换瞬间隧道会失效。如果不需要双网加速,建议关闭其中一个。

上游链路抖动。如果同一网络下的其他设备也在同一时间出现网络中断,问题在本地运营商或上游,与 VPNWing 无关。判断方法是同时观察一台没有走代理的设备。

空闲后断线:NAT 会话超时

家用路由器和运营商网关都会维护一张 NAT 会话表,表项有生存时间。一条长时间没有数据的连接会被回收,回收之后隧道就断了。这是所有基于 NAT 的网络都会遇到的现象,不是 VPNWing 特有的问题。

处理方式有两种:一是开启客户端的保活,让连接上始终有少量数据流动;二是在路由器设置里延长 NAT 会话的超时时间,部分路由器提供该选项,名称可能是「TCP 超时」「会话保持」之类。

需要注意的是,保活间隔不宜过短。间隔太短会让客户端持续发送小包,在移动网络下增加耗电。多数场景下,几十秒到几分钟的间隔已经足够。

系统层面的干扰

几个容易被忽略的干扰源:

• 省电策略。Windows 的节电模式、macOS 的低电量模式、Android 与 iOS 的电池优化,都会在后台限制网络活动。把客户端加入白名单可以避免。
• 安全软件的联网控制。部分安全软件会对每个程序的联网行为做审核,在后台静默阻断重连请求。
• 虚拟网卡冲突。安装过其他 VPN 或虚拟机软件后,系统里可能残留多个虚拟网卡,路由优先级混乱会导致间歇性断线。清理不用的虚拟网卡通常能改善。
• 系统代理被改写。部分软件会定时改写系统代理设置,改写瞬间连接中断。检查是否有这类软件在运行。

处理清单

1. 记录三次以上断线的时间点,确认是否有规律。
2. 开启客户端保活,观察是否改善。
3. 换一个网络环境做对照,例如从 Wi-Fi 换到蜂窝网络。
4. 检查系统电源与省电设置,把客户端加入白名单。
5. 清理不用的虚拟网卡与多余的代理软件。
6. 换一条不同线路类型的线路做对照。

如果按清单走完,断线仍然稳定出现,而且能提供断线时间点与线路名称,就可以提交工单。这类问题通常需要结合服务端日志排查,时间点越精确越有帮助。关于连接成功率与断线率怎么自己测,稳定性自测方法 这篇给了可复现的步骤。

订阅更新失败:地址、时间与格式三处核对

订阅是客户端与账户之间的配置通道。客户端定期向订阅地址请求一次,拿到线路列表、分流规则与连接参数。订阅更新失败意味着客户端拿不到最新配置,表现可能是线路列表为空、线路全部显示超时,或者客户端提示配置无效。

订阅是怎么工作的

订阅地址是一串带令牌的链接,令牌与账户绑定。客户端发起请求后,服务端根据令牌识别账户,返回对应格式的配置内容。整个过程有三个环节可能出错:请求能不能发出去、服务端认不认这个令牌、返回的内容客户端能不能解析。

对应到排查上,就是三个方向:地址、时间、格式。

需要说明的是,订阅地址属于账户凭据,应当只在用户面板里获取,不要粘贴到公开渠道,也不要发给他人。如果怀疑地址已经外泄,可以在面板里重置。

方向一:地址本身

最常见的失败原因是地址不完整。订阅地址通常较长,从聊天软件、邮件或笔记里复制时容易被截断,或者被自动加上换行与空格。

检查三点:地址是否以完整的协议头开头,中间没有空格与换行;地址是否被聊天软件做了智能识别,把一部分字符变成了链接或表情;地址末尾的参数是否完整,尤其是令牌部分。

另一个常见原因是地址被安全软件改写。部分安全软件会对所有加密请求做中间人检查,改写请求后服务端无法识别令牌。判断方法是在客户端里用同一地址请求两次,如果两次都失败,而浏览器访问其他站点正常,可以尝试临时关闭这类检查做对照。

方向二:时间与证书

订阅请求走的是加密连接,证书校验依赖系统时间。系统时间偏差过大时,证书会被判定为无效,请求在握手阶段就失败,而客户端给出的提示通常只是「更新失败」,不会说明具体原因。

检查方法:打开系统时间设置,确认自动设置时间处于开启状态,并核对时区是否正确。跨时区旅行、长期休眠、手动改过时间都可能导致偏差。

如果时间正确但依然失败,再看是否安装了会拦截加密流量的软件。这类软件会替换系统证书链,导致客户端无法验证服务端证书。

方向三:格式匹配

订阅内容会按客户端类型下发不同格式。如果客户端的类型识别错误,或者手动选择了不匹配的格式,解析就会失败。

判断方法:在面板里重新获取一次订阅,按客户端类型选择对应格式,不要手工拼接。如果客户端支持多种格式,优先使用客户端自动识别的那个。

格式不匹配的另一个表现是「更新成功但线路列表为空」。这说明请求成功了,但返回的内容没有被正确解析。处理方式是清空当前配置后重新导入,而不是在旧配置上追加。

用命令行验证地址可达性

以下示例使用占位地址,仅用于说明方法。不要替换成真实订阅地址后粘贴到公开场合:

# 检查订阅地址是否可达,只看响应头
curl -I "https://example.com/sub?token=YOUR_TOKEN"

# 检查返回内容的前几行,确认是配置而不是错误页
curl -s "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

如果第一条命令返回 4xx 或 5xx,说明服务端拒绝了请求,重点检查令牌与地址完整性;如果返回 200 但第二条命令输出的是网页而不是配置文本,说明请求被中间设备拦截或重定向了。

重新导入的完整步骤

1. 在用户面板里确认订阅处于有效状态,当月流量未用尽。
2. 重新复制一次订阅地址,复制后先粘贴到纯文本编辑器里检查有没有多余字符。
3. 在客户端里删除当前配置,建议先导出备份,不要直接覆盖。
4. 新建配置,粘贴地址,等待更新完成。
5. 确认线路列表有内容,随便选一条线路连接测试。
6. 如果客户端支持,开启自动更新,并设置一个合理的间隔。

仍然失败时

如果按上面三步都确认无误,订阅仍然更新失败,可以尝试换一个网络环境再更新一次,部分公共网络会对非标准请求做拦截。如果换网络后成功,说明原网络存在限制。

如果所有网络环境下都失败,提交工单时请附上更新失败的具体提示文本、使用的客户端平台、失败开始的时间,以及是否在多个网络环境下复现。不要把完整订阅地址贴在工单里,只说明令牌尾号即可。

单个应用走不了代理:分流规则与转发方式

浏览器一切正常,某个特定应用却始终连不上。这类问题的排查思路与前面几章完全不同。它不是「网络不通」,而是「这个应用的流量没有按预期进入隧道」。

为什么只有某个应用不行

不同的应用处理网络请求的方式差别很大:有的遵循系统代理设置,有的自己实现网络栈,有的直接用地址而完全跳过域名解析,还有的优先使用 UDP。分流规则通常按域名或进程匹配,一旦应用的行为超出规则的覆盖范围,流量就会漏出去。

判断的第一步是确认这个应用到底有没有走代理。方法是连上客户端后,在客户端的连接日志里观察是否有该应用的请求记录。如果没有记录,说明流量根本没进隧道;如果有记录但请求失败,说明进了隧道但目标侧拒绝。

原因一:不读系统代理

系统代理是一种约定,应用可以选择遵守,也可以选择忽略。部分应用直接建立连接,不查询系统代理设置,于是流量绕过隧道直接发出。

处理方式是把客户端切换到 TUN 模式,有的客户端叫虚拟网卡模式或增强模式。TUN 模式在网络层接管流量,不依赖应用是否遵守系统代理,覆盖面更广。

代价是 TUN 模式需要更高的系统权限,并且在部分系统上可能与安全软件冲突。切换后如果系统网络异常,先把模式切回来再排查。

原因二:硬编码解析地址

有些应用内置了解析服务器地址,或者直接写死了服务端的地址,完全跳过系统解析。这种情况下,即使分流规则里写了对应域名,也不会被匹配到。

判断方法:在客户端的连接日志里看目标地址。如果日志里显示的是域名,说明走了系统解析;如果显示的是地址,说明应用自己做了处理。

处理方式有两种:一是把该应用的目标地址段加入代理规则;二是把客户端切换到全局模式,让所有流量都进隧道。全局模式只建议临时使用,长期开启会浪费流量,也会让本地站点变慢。

原因三:UDP 与 QUIC

多数代理协议对 TCP 的支持是完备的,对 UDP 的支持则要看具体实现。如果应用主要使用 UDP,例如语音通话、实时对战游戏、部分即时通讯,而客户端没有开启 UDP 转发,这些流量就会直接失败。

另一个相关的问题是 QUIC。QUIC 基于 UDP,被不少站点用作首选传输方式。如果 UDP 被阻断,而客户端又没有做回退处理,表现就是网页一直转圈,但换成别的浏览器又能开。

处理方式:在客户端里开启 UDP 转发,如果提供该选项;如果只影响浏览器,可以在浏览器设置里关闭 QUIC,强制回退到 TCP;对于游戏与语音类应用,优先选择对 UDP 支持良好的线路。

原因四:证书固定

少数应用会把服务端证书的指纹写死在代码里,只信任特定证书。这类应用经过任何中间人解密都会失败,而代理正好会做类似的事情。

表现为应用提示网络异常或连接不安全,但同一设备上的浏览器访问同一服务正常。这类问题通常没有客户端侧的解决办法,只能把该应用的域名加入直连规则,让它走本地网络。如果本地网络本身无法访问该服务,那就只能等应用侧调整。

按应用类型对照

排查顺序

1. 确认应用的流量是否出现在客户端日志里。没有记录,走「不读系统代理」这条线。
2. 有记录但失败,看日志里的目标地址是域名还是地址。是地址,检查硬编码与规则覆盖。
3. 看是否与 UDP 相关。关闭 QUIC 或开启 UDP 转发做对照。
4. 仍然失败,检查证书固定,把该应用的域名加入直连规则做对照。

如果确认是某条线路对该应用不友好,换一条线路类型再试。如果所有线路都一样,记录下应用名称、平台,以及客户端日志里的目标地址,提交工单时一并附上。远程办公场景下会议与协作工具的选线差异,可以参考 远程办公的线路选法 这篇。

移动端后台掉线与 DNS 解析异常

移动端的问题有两个来源:系统对后台应用的限制,以及解析结果在切换网络后的残留。这两类问题在桌面端很少出现,在移动设备上却相当常见。

移动端为什么会后台掉线

移动操作系统为了省电,会对后台应用做严格限制。当客户端被切到后台,系统可能在一段时间后冻结它的网络活动,隧道随之失效。回到前台时,客户端需要重新建立连接,期间会出现几秒到几十秒的中断。

这是系统设计使然,不是客户端故障。判断方法很简单:把客户端保持在前台,观察是否还会断线。如果前台稳定、后台断线,就是系统的后台限制。

iOS 与 Android 的差异

iOS 对后台网络的限制更严格。系统会给 VPN 类应用一定的后台处理时间,但不会无限期保持。较长一段时间不使用时,连接可能被系统回收。iOS 上可做的设置有限,主要是允许客户端使用后台刷新、关闭低电量模式,以及在需要长时间保持连接时把客户端留在前台。

Android 的差异更大,因为各家厂商在系统层面做了额外的省电优化。常见的设置项包括电池优化白名单、后台活动限制、自启动权限,以及锁定后台之类的厂商特有开关。如果客户端在某个品牌的设备上特别容易掉线,优先检查这几项。

Linux 桌面端虽然不属于移动端,但同样存在类似的电源管理问题。笔记本合盖休眠后,网络设备可能需要重新初始化,隧道会失效。

让移动端稳定在线的设置

按平台分别处理:

1. 系统设置里找到该客户端,把电池优化设为不限制,或加入白名单。
2. 允许后台活动与后台数据使用。
3. 关闭系统的智能省电、超级省电模式,或在这些模式下把客户端加入例外。
4. 在客户端的设置里开启自动重连,并适当缩短重试间隔。
5. 如果不需要在移动网络下使用,可以设置为仅在 Wi-Fi 下保持连接,减少切换带来的重连。

这些设置能减少掉线频率,但无法完全消除。移动网络本身的切换、信号盲区、系统回收资源都会造成短暂中断,这是移动场景的固有特性。

DNS 异常的典型表现

解析问题在移动端更常见,因为设备频繁在 Wi-Fi 与蜂窝网络之间切换,每次切换都会带来解析服务器的变化,而系统缓存里可能还留着上一次的解析结果。

典型表现有三种:能 ping 通地址但域名打不开,解析环节失败但路由是通的;部分域名解析到错误地址,打开后显示的不是预期页面;切换网络后一段时间内全部域名打不开,过几分钟自行恢复,这是缓存过期后的自愈过程。

判断方法:用系统自带的网络诊断工具,或者安装一个能查询解析结果的应用,对同一个域名做一次解析,看返回结果是否合理。如果解析结果与在电脑上查到的不同,基本可以确认是解析环节。

各平台清理解析缓存

清理缓存能让新的解析结果立即生效:

• Windows:在命令提示符里执行 ipconfig /flushdns。
• macOS:执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。
• Linux:视发行版而定,使用 systemd-resolved 的系统执行 sudo resolvectl flush-caches。
• iOS 与 Android:系统没有提供公开的清缓存入口,最直接的办法是开关一次飞行模式,或者重启设备。

清理之后,建议在客户端里把解析方式设置为内置解析,避免再次被本地运营商的解析结果影响。如果只是想确认当前出口的归属地,可以用站内的 IP 检测 页做一次查询。

判断顺序与收尾

移动端问题建议按这个顺序排查:

1. 确认是前台掉线还是后台掉线。后台掉线,走系统省电设置这条线。
2. 确认是否只在移动网络下出现。是,检查网络切换与信号。
3. 确认是全部域名失败还是个别域名失败。全部,检查解析与隧道状态;个别,检查分流规则。
4. 清理解析缓存,切换客户端的解析模式,再试一次。

如果按顺序走完仍然频繁掉线,提交工单时请附上设备型号与系统版本、客户端平台、掉线发生时的网络类型,以及是否在后台时发生。这些信息能帮助判断是系统限制还是客户端行为。

需要补充的是,VPNWing 同时在线不限台数,移动设备与电脑可以同时使用同一个账户,不需要为移动设备单独开通。如果只是因为移动端偶尔掉线而想换方案,可以先按上面的步骤调整设置,多数情况下能明显改善。