跨境网络故障排查手册

排查总纲:先判断故障落在哪一层

排查的目标不是把每一项设置都改一遍,而是用最少的动作把问题锁定在一段链路上。一次跨境访问至少要经过四段:设备到本地网络、本地网络到线路入口、线路入口到目标站点、目标站点返回结果。任何一段出问题,用户看到的现象都可能是「打不开」,但处理方式完全不同。

先分清「连不上」和「连上了但慢」是两回事。前者是链路建立失败,后者是链路可用但质量不够,两者的排查路径并不重叠,混在一起改设置,只会把问题越改越乱。还要区分两种时间线:首次配置就失败,多半是配置方式或平台兼容问题;用了一段时间后突然失效,多半是网络环境、线路调度或账号状态发生了变化。时间线不同,先查的方向也不同。

四层模型:把现象对应到链路段

这张表的作用是让你在三十秒内决定先动哪里。如果现象落在「本地网络」一行,先断开客户端,确认本地网络本身可用——本地网络不通的情况下,任何代理设置都不会生效,继续调客户端只是白费时间。

三步定位法

按下面三步依次替换变量。每一步只改一个条件,结果才有参考价值;一次改三样,即使恢复了也不知道是哪一样起的作用。

1. 换线路

   在客户端里切换到另一条线路,优先切到 IEPL 专线。如果切换后恢复正常,问题集中在原线路上:记下线路名称、所在地区与出问题的时间段,提交工单时一并附上。切换后仍然失败,继续第二步。

2. 换设备

   用同一个账号在另一台设备上连接同一条线路。如果另一台设备正常,问题在原设备的客户端或系统设置上,回到对应平台的章节自查;如果两台设备同时失败,继续第三步。

3. 换网络

   用移动网络热点替换当前的 Wi-Fi 或宽带,再连一次。如果热点下恢复正常,问题在原网络的出口、路由器或运营商链路上,与账号和线路都无关。

三步全部失败,基本可以判定不是单点故障,直接进入第九章的工单流程,不要继续在客户端里反复试。反复重装、反复切换,只会把原本正常的配置一起破坏掉,给后续定位增加干扰。

排查前先记录五项信息

记录不是形式主义。线路调度是动态的,同一个问题在不同时间段的表现可能不同,有记录才能判断规律;没有记录,只能凭印象描述,沟通成本会成倍上升。

• 问题发生的时间,精确到分钟,并注明所在时区。
• 当时使用的线路名称与所在地区,以及是否换过其他线路。
• 客户端所在平台与系统版本(Windows / macOS / iOS / Android / Linux)。
• 报错原文或截图,不要只写「打不开」。
• 已经做过的动作,例如「已切换三条线路、两台设备、两个网络」。

什么时候该找客服

下面这些情况建议直接提交工单,不必继续自查:

• 同一账号在两条以上线路、两台以上设备、两个不同网络下都无法连接。
• 单条线路连续失败超过一天,而其他线路正常。
• 账号层面的异常:无法登录、订阅获取失败、订单或支付状态与预期不符。
• 客户端本身崩溃、反复闪退或无法完成安装。

反过来,下面这些情况建议先自查:只有一台设备出问题、只有某一个网站打不开、只在某个时段变慢、换一条线路就能恢复。这些都属于单点现象,自查往往比等待回复更快。

完全连不上:从本地网络查到账号状态

「完全连不上」指客户端点下连接后一直停在「正在连接」,或者直接提示连接失败,任何网站都打不开。这一章按从近到远的顺序排查:设备 → 系统 → 本地网络 → 线路 → 账号。顺序不要跳,跳着改会同时引入多个变量,最后连「改之前是什么样」都说不清。

先读懂客户端的三种状态

客户端的「已连接」只代表本地隧道建立完成,不代表出口可用。真正能确认生效的是出口 IP 发生变化。所以第一步不是看按钮颜色,而是打开 IP 查询页,确认出口 IP 的归属地是否与所选线路的地区一致;不一致,说明流量并没有真正走出去,后面所有「打不开」的判断都不成立。

五个平台的客户端都提供运行日志(部分平台叫「连接日志」)。日志最后一行通常能看出卡在哪一步:卡在握手,多半是本地网络屏蔽了端口或系统时间偏差;卡在认证,多半是账号或订阅状态有问题;日志里反复重连、间隔很短,多半是本地网络不稳定或网卡在省电。

系统时间偏差是最容易被忽略的原因

连接过程依赖 TLS 握手,而 TLS 要求设备时间与标准时间偏差在几分钟以内。系统时间不准,表现就是一直停在「正在连接」或者提示证书错误,但用户往往以为是线路坏了,于是不停换线路,问题依旧。

• Windows:设置 → 时间和语言 → 日期和时间,打开「自动设置时间」。
• macOS:系统设置 → 通用 → 日期与时间,打开自动设置。
• iOS:设置 → 通用 → 日期与时间,打开「自动设置」。
• Android:设置 → 系统 → 日期和时间,打开自动设置(不同厂商的菜单路径略有差异)。

修改后重启客户端再试一次。长期不联网的设备,时间偏差可能积累到几十分钟,这种情况尤其要先校准时间再看别的。

本地网络与安全软件

• 第三方防火墙或安全软件的「网络防护」「流量监控」可能拦截隧道建立,先临时关闭再试一次。
• 检查系统代理设置是否残留了旧的代理地址(Windows:设置 → 网络和 Internet → 代理)。
• 路由器上的上网管控、家长控制、广告过滤功能可能把线路入口当成可疑目标拦掉。
• 公司或学校的网络可能只放行常规端口,这种情况换协议或换端口通常可以恢复。

换线路与换协议

先切到 IEPL 专线线路再试一次。如果所有线路都失败,再换协议:Trojan、VLESS、Hysteria2、Shadowsocks 之间切换,每次只换一项。某一种协议在特定网络下被拦截是常见现象,换一种协议往往立刻恢复,这不需要重新购买或重新导入订阅。

账号状态自查

• 套餐是否在有效期内,流量是否已经用完(流量按开通日每月重置)。
• 订阅地址是否被分享给了其他人使用,导致登录状态互相顶掉。
• 是否在短时间内多地重复登录,触发了异常判定。

注册不需要邮箱地址,用户名 + 密码即可完成注册,因此账号相关的操作都在用户面板内完成;忘记密码走面板的找回流程,不需要额外提供其他信息。

现象对照表

能连上但打不开网页

这一类问题的共同点是:客户端显示已连接,但浏览器里网页一直在转圈,或者提示「无法访问此网站」。先不要动线路,按下面的顺序确认流量到底有没有走代理。绝大多数「连上了却打不开」都停在前两步。

「已连接」不等于「已代理」

客户端有两种工作方式。系统代理模式只改写系统的代理设置,浏览器和遵循该设置的应用会走代理,其他应用不受影响;TUN(虚拟网卡)模式接管全部流量,包括不识别系统代理的应用。如果客户端处于系统代理模式,而浏览器装了会接管代理设置的扩展,系统设置就会被覆盖,表现就是客户端说连上了、浏览器还是打不开。

判断方法很简单:打开本服务的 IP 查询页,看显示的出口 IP 归属地是不是所选线路的地区。不是,说明流量没有走代理,问题在客户端模式或浏览器扩展;是,说明代理已经生效,继续往下看。

用命令行把问题缩小到一层

浏览器给出的错误信息往往很笼统,命令行能直接把范围缩小。下面三行命令分别回答三个问题:目标站点通不通、域名能不能解析、解析结果稳不稳定。

# 1. 目标站点是否可达(示例域名,替换成你实际要访问的站点)
curl -I --max-time 10 https://www.example.com

# 2. 只做 DNS 解析,看域名能不能解析出地址
nslookup www.example.com

# 3. 用指定 DNS 再解析一次,对比两次结果是否一致
nslookup www.example.com 1.1.1.1

curl 返回 200 或 301,说明链路本身是通的,问题在浏览器侧;curl 超时但 nslookup 有结果,问题在出口或目标站点;nslookup 本身就失败,直接跳到第八章的 DNS 排查。三次测试要在同一个网络环境下做,否则结果没有可比性。

分场景判断

• 所有网站都打不开:先看 DNS 与隧道是否生效,再看线路,最后看账号状态。
• 只有部分网站打不开:检查分流规则里这些域名是不是被写进了直连,或者目标站点本身在维护。
• 只有浏览器打不开,其他应用正常:检查浏览器扩展、浏览器自带的加密 DNS 设置。
• 只有一台设备打不开:与另一台设备对比,确认是设备侧问题而不是账号问题。

IPv6 造成的「一半能用」

部分宽带同时下发 IPv4 与 IPv6 地址,系统会优先使用 IPv6。如果线路只处理 IPv4,访问就可能出现「有的站点能开、有的站点一直转圈」这种看似随机的现象。处理方式有两种:在客户端里开启 TUN 模式,让全部流量进入隧道;或者在系统的网络设置里暂时关闭 IPv6,再测一次对比结果。

目标站点侧的问题

不要忽略目标站点自身的故障。用另一条线路、另一台设备、另一个网络分别访问同一个站点,如果三者都失败,而其他站点一切正常,基本可以判断问题在目标站点一侧,与本服务无关,等待对方恢复即可。

浏览器扩展与安全软件

广告拦截、脚本管理、代理切换类扩展都会改动请求的走向。排查时先全部停用,确认恢复正常后再逐个开启,定位到具体是哪一个扩展造成的影响。这一步只需要几分钟,却能排除掉相当一部分看似复杂的问题。

订阅更新失败:链接、缓存与状态检查

订阅是客户端获取线路列表的通道。更新失败时,客户端通常仍保留上一次成功获取的节点,所以现象可能是「能连,但节点列表是旧的」,也可能直接提示订阅更新失败。先看属于哪一种,再决定处理方式——前者往往不影响使用,后者需要立刻处理。

先确认三件事

• 设备当前能正常上网。更新订阅本身需要一次正常的网络请求,断网状态下点更新,报错是必然的。
• 系统时间是自动设置的。时间偏差会让请求在 TLS 阶段失败,错误提示却往往与网络有关。
• 套餐在有效期内,流量没有用完(流量按开通日每月重置)。

三项都正常再往下看。这三项覆盖了订阅更新失败里最常见的原因,先排除掉能省下大量时间。

订阅地址的形态

订阅地址是一段带凭据的链接,客户端通过它拉取线路列表。下面只是格式演示,真实地址请登录用户面板后在「概览」页复制。

# 订阅地址示例:仅演示格式,不是可用的真实地址
https://example.com/sub?token=YOUR_TOKEN

# 部分客户端支持按类型返回不同格式(示例)
https://example.com/sub?token=YOUR_TOKEN&flag=clash

订阅地址与账号绑定,包含访问凭据,等同于密码。不要发到群里、不要截图外发、不要贴进公开的配置文件或代码仓库。需要在多台设备上使用时,在每台设备上分别导入同一个地址即可,不需要额外申请,也不受台数限制。

两种导入方式

链接导入是首选。手动添加节点是备用方案:在客户端里逐条填写服务端地址、端口、协议与凭据。手动添加的节点不会随后续更新变化,如果发现某条手动线路连不上,先换回链接导入的方式确认是不是线路本身调整了。

更新失败的常见原因

更新频率与时机

建议每周更新一次;换线路、换地区或感觉速度下降时,先手动更新一次再看,不要急着改协议。更新后节点列表会按地区重新分组,如果发现某个地区的节点数量变化,通常是服务端在做线路调整,过一段时间再更新一次即可。

速度慢与晚高峰卡顿

「慢」是一个结果,不是原因。先量出瓶颈在哪一段,再决定改什么。整章按「先测本地、再测出口、最后调线路」的顺序展开;顺序反过来做,很容易把本地带宽的问题误判成线路问题,换了一圈线路也没改善。

先量本地带宽

断开客户端,先测一次本地宽带的实际速度,记下结果;连接客户端后再测一次。两次结果的差距,才是代理链路带来的损耗。如果本地宽带本身的数值就不高,那么换任何线路都不会变快,这时应该先联系宽带运营商。

测速时注意两点:两次使用同一个测速服务,结果才有可比性;关掉后台的下载、网盘同步与系统更新,它们会占满带宽,让结果严重失真。测速结果本身受服务端负载影响,单次结果不说明问题,连续测三次取中间值更可靠。

线路类型的差别

三类线路都覆盖在 110+ 国家 / 250+ 线路的范围内,客户端里可以直接按地区与类型筛选。晚高峰优先 IEPL 专线,是因为专线通道不经过公共互联网的国际出口,受整体拥塞的影响更小;直连线路路径最短,但恰恰最容易在高峰时段被公共出口的拥塞拖慢。

协议与开销

协议决定封装方式与额外开销。Hysteria2 基于 QUIC,在丢包较多的网络里更稳,适合线路质量波动大的场景;Trojan 与 VLESS 走 TLS,兼容性好,适合大多数日常使用;Shadowsocks 开销小,在老设备上表现更好。协议之间可以随时切换,切换后需要重新连接一次,不需要重新导入订阅。

设备侧的瓶颈

• Wi-Fi 频段:2.4GHz 覆盖范围广但速度上限低,近距离优先连接 5GHz。
• 老设备的加密性能:较老的处理器在加密解密上开销更大,表现为网页能开但视频卡。
• 后台任务:系统更新、网盘同步、游戏平台下载都会持续占用带宽。
• 路由器性能:入门级路由器在多设备同时使用时,转发能力可能先于宽带先到瓶颈。

晚高峰的应对顺序

按下面的顺序依次尝试,每次只改一项,改完立刻复测。

1. 切到 IEPL 专线

   优先选择距离目标站点较近的地区。同一地区有多条专线时,逐条试,记录哪一条在高峰时段更稳。

2. 切换协议

   在 Trojan、VLESS、Hysteria2、Shadowsocks 之间换一种,尤其是网络丢包明显时,基于 QUIC 的协议通常改善更明显。

3. 检查分流

   让国内站点走直连,减少隧道内的无效流量;同时确认没有规则把目标站点错误地放行到直连。

4. 确认不是本地问题

   换一台设备、换一个网络再测一次。如果只有原设备慢,问题在设备或本地网络,与线路无关。

时段与建议

如果只在特定时间段变慢,而且换线路后明显改善,基本可以确认是国际出口拥塞,而不是账号或设备的问题。体育直播这类对延迟更敏感的场景,选线思路可以参考 体育直播 VPN 推荐 一文。

频繁断线与移动端后台掉线

断线分两种:一种是真的断开,客户端状态回到未连接;另一种是「假断线」,客户端显示已连接,但流量停了。两者的排查方向完全不同,先分清楚再动手,否则容易在错误的方向上折腾半天。

先分清真断线与假断线

• 真断线:客户端状态回到未连接,日志里能看到断开记录。方向是本地网络、网卡节能、链路质量。
• 假断线:状态仍是已连接,但网页打不开。方向是保活机制、DNS、客户端进程被系统回收。

判断方法:断线发生时立刻打开 IP 查询页。能打开,说明隧道还在,是应用层的问题;打不开,说明隧道确实断了。这一步只需要几秒钟,却能决定后面往哪个方向查。

桌面端:网卡节能与电源计划

• Windows:设备管理器 → 网络适配器 → 属性 → 电源管理,取消勾选「允许计算机关闭此设备以节约电源」。
• Windows:控制面板 → 电源选项,把计划改为「高性能」,避免处理器与网卡频繁降频。
• macOS:系统设置 → 电池,关闭「低电量模式」,或在使用时接通电源。

这三项是桌面端断线最常见的来源。无线网卡在空闲时进入省电状态,恢复需要时间,表现就是每隔一段时间卡一下或者直接断开。

移动端:后台被系统回收

iOS 与 Android 都会在内存紧张或省电模式下回收后台进程。代理进程被回收,表现就是切到别的应用待一会儿再回来,连接已经断了,而且没有任何提示。

• iOS:设置 → 通用 → 后台 App 刷新,允许客户端刷新;同时关闭低电量模式。
• Android:设置 → 应用 → 客户端 → 电池,选择「不受限制」或加入省电白名单。
• Android:在最近任务列表里锁定(加锁)客户端,避免被一键清理。
• 关闭系统自带的「智能省电」「深度睡眠」类功能对客户端的限制。

网络切换时的重连

从 Wi-Fi 切到移动网络、或从一个 Wi-Fi 漫游到另一个时,隧道需要重新建立。部分系统会等待十几秒才恢复,这属于正常现象;如果一直不恢复,手动断开再连接一次即可,不需要重启设备。频繁在两种网络之间来回切换时,建议在稳定下来之后再开始长时间的任务。

路由器与光猫

长时间开机的路由器可能出现会话表满、内存占用高等问题,表现为整个网络间歇性卡顿,而不只是代理连接断开。断电重启一次光猫与路由器,再观察一天;如果断线频率明显下降,问题就在本地网络设备上。

双频合一与漫游

部分路由器把 2.4GHz 与 5GHz 合并成同一个名称,设备在频段之间来回切换时连接会短暂中断。家里有多台路由器时,漫游设置不当也会造成同样的现象。可以先把两个频段拆成不同的名称,固定连接其中一个,观察断线是否减少。

记录规律比反复重装有用

记录断线的间隔、持续时间、当时使用的线路与网络类型。固定间隔的断线通常是保活或节能设置造成的;无规律的断线更可能是链路质量或本地网络问题。安卓设备的省电策略差异较大,从安装到加入白名单的完整流程可以参考 安卓 VPN 从零开始。

某个 App 走不了代理

浏览器正常,但某个桌面软件、游戏或命令行工具连不上,通常不是线路问题,而是这个应用没有进入代理。原因集中在三点:代理模式、分流规则、应用自身的网络行为。按这三点依次检查,基本都能定位。

代理模式决定谁被接管

分流规则的匹配顺序

分流规则按域名、IP、应用名依次匹配,先匹配到的先生效。如果目标域名被写进了直连规则,或者被某个更靠前的规则提前命中,这个应用就不会走代理——即使它在客户端的应用列表里。

排查方法:打开客户端的连接日志,操作一次出问题的应用,看日志里有没有出现对应的连接记录。没有记录,说明流量根本没进入客户端;有记录但标注为直连,说明规则把它放行了;有记录且走了代理,说明问题在应用自身或目标站点。

常见误配

• 规则列表里手动添加过「直连」条目,后来忘了删除。
• 只代理了部分进程,应用不在列表里。
• 应用自己走独立的网络栈,部分下载工具、游戏平台会绕过系统代理。
• 应用优先使用 IPv6,而线路只处理 IPv4。

游戏与 UDP 应用

游戏类应用大量使用 UDP,而系统代理通常只处理 TCP 流量,所以「浏览器正常、游戏进不去」是典型现象。这类应用需要在客户端里开启 TUN 模式,并确认客户端支持 UDP 转发;开启后如果延迟反而升高,再换回延迟更低的地区节点。

AI 工具类应用

ChatGPT、Claude、Gemini 等 AI 工具对链路稳定性更敏感:它们大多是长连接,中途一旦断开就需要重新建立会话,表现是「登录后一直转圈」或者「回答到一半中断」。遇到这种情况,优先切到 IEPL 专线,再确认应用是否在代理范围内。更细的做法整理在 ChatGPT 加速 页面。

验证是否生效

最直接的验证方式:在出问题的应用里访问一个只有走代理才能打开的地址,或者用应用自带的网络诊断查看出口地址。也可以用本服务的 IP 查询页确认当前出口。桌面端全局代理与分流之间的取舍,以及开机自启的配置方式,整理在 Windows VPN 推荐 一文里。

DNS 异常与出口 IP 自查

DNS 负责把域名翻译成 IP 地址。DNS 出问题时,现象很有迷惑性:网页打不开,但通信类软件正常;或者同一台设备上有的域名能解析、有的不能。先分清属于哪一类,再决定改什么。

先分清三类问题

三类问题的处理方式不同:解析失败多半是本地 DNS 服务不可用;解析异常通常是解析路径上有干扰;DNS 泄漏则是配置问题,需要把解析请求收回隧道内。

用 IP 查询页做三项自查

• 出口 IP 的归属地是否与所选线路的地区一致。
• 是否出现 DNS 泄漏提示。
• 断开客户端前后各查一次,对比两次结果是否不同。

查询入口在 我的 IP 页面,不需要安装任何额外工具,也不需要命令行基础。三项结果记下来,提交工单时一并附上即可。

客户端里的 DNS 设置

优先使用线路自带的 DNS 解析,让解析请求随隧道一起出境。如果手动把 DNS 改成了公共地址,解析请求可能绕过隧道回到本地运营商,既影响解析结果,也会让解析记录暴露在隧道之外。除非有明确的理由,否则不要手动改动客户端下发的 DNS 配置。

浏览器自带的加密 DNS

部分浏览器内置了加密 DNS(DoH),开启后会绕过系统与客户端的 DNS 设置。如果只在浏览器里出现解析异常,先把这个选项关掉,或者改成「跟随系统」,再测一次。这一项经常被忽略,却能解释「其他应用都正常,只有浏览器打不开」这类现象。

命令行排查

# 用系统默认 DNS 解析
nslookup www.example.com

# 用指定 DNS 解析,对比两次结果是否一致
nslookup www.example.com 1.1.1.1

# Windows:清空本地 DNS 缓存
ipconfig /flushdns

# macOS:清空本地 DNS 缓存
sudo dscacheutil -flushcache

两次解析结果不一致,说明解析路径上存在干扰;先清缓存,再把客户端的 DNS 设置恢复为默认值,然后重新连接一次。缓存清理后第一次解析通常稍慢,属于正常现象。

DNS 正常但网页仍然打不开

如果解析正常、出口 IP 也正确,但网页依然打不开,说明问题不在 DNS。回到第三章按「分场景判断」继续排查,重点看分流规则与浏览器扩展这两项。

设备数、账号共享与工单提交

这一章处理账号层面的问题,以及前面八章都排查完之后该怎么做。账号类问题的特点是:本地怎么改都不会变好,只有从账号侧确认才能定位。

不限台数意味着什么

VPNPF 的套餐不限台数:同一账号可以在 Windows、macOS、iOS、Android、Linux 上同时在线,不需要为每一台设备单独购买,也不需要数着设备数量使用。换新设备时,直接在新设备上导入订阅即可。

不少服务按设备数计费,超过数量就会提示「设备数超限」并要求升级套餐。本服务的套餐没有这个限制,所以你在自己的设备之间切换时,不需要担心台数问题。如果遇到登录后被顶下线的情况,更多是账号共享造成的,而不是台数限制。

账号共享会带来什么

订阅地址与账号绑定,等同于账号凭据。把订阅地址分享出去,等于把账号交给别人使用。多人共用同一个账号会带来三个后果:同一时间的连接数被大量占用,自己用的时候反而变慢;登录状态互相顶掉,频繁要求重新登录;出现异常登录记录时,无法判断来源。

如果需要给家人或同事使用,建议单独注册账号,而不是共用同一个订阅地址。注册不需要邮箱地址,用户名 + 密码即可完成,给家里人单独开一个账号的成本很低。

这些情况必须提交工单

• 账号无法登录,找回流程也走不通。
• 订阅获取失败,且换设备、换网络后仍然失败。
• 订单或支付状态与实际情况不符。
• 需要申请退款(60 天无理由退款)。
• 按本手册前八章排查完,问题依然存在。

工单要附的信息

信息给全,通常一轮就能定位;信息给不全,一来一回就要多花半天。按下面的清单整理,直接复制进工单即可。

1. 账号信息

   注册时使用的用户名。不要提供密码,工单里不需要密码,也不会有人向你索要密码。

2. 问题发生的时间

   精确到分钟,并注明时区。时间点能帮助判断是线路调整还是本地网络波动。

3. 线路名称与地区

   出问题时使用的线路名称、所在地区,以及是否换过其他线路、换过之后结果如何。

4. 客户端与系统

   使用的平台(Windows / macOS / iOS / Android / Linux)与系统版本,以及客户端的版本信息。

5. 报错原文或截图

   直接复制客户端的报错文字,或附一张包含完整报错信息的截图,不要只描述「打不开」。

6. 已经做过的排查

   例如「已切换三条线路、两台设备、两个网络,现象一致」。这一项能省掉一轮来回确认。

提交之后

工单入口在用户面板内,登录后即可提交与查看进度。提交前建议先在本手册里检索对应症状章节,大部分问题可以在自查阶段解决。支付方式支持支付宝、微信与 USDT,订单相关的问题在工单里附上支付时间与金额即可,不需要提供支付凭证截图以外的敏感信息。