跨境连接故障排查手册

排查顺序:三条判断先于任何设置

连接故障看起来千头万绪,实际只分三层:账号与订阅、客户端与设备、线路与网络。三层里任意一层出问题,表现出来的症状都可能一样——转圈、超时、页面打不开。所以本手册的顺序是先定位层,再改设置;一次只改一个变量,改完立刻复测。同时改三处,即使恢复了也不知道是哪一处起的作用,下次复发还得从头来一遍。

判断一,账号与订阅是否有效。登录用户面板,确认套餐在有效期内、当月流量没有用完。流量按开通日每月重置,用完不会自动续,表现是所有线路都连不上,或者连上之后没有流量。这一步只看面板,不动客户端。

判断二,故障是全局还是单点。换一台设备、换一个网络(例如用另一台设备开热点)、换一个目标网站,三次里只要有一次正常,就说明账号和线路池本身没问题,问题在本地。三样全失败,才值得怀疑线路。

判断三,问题在客户端还是在线路。同一条线路上反复失败、换一条线路就正常,是线路问题;换哪条线路都一样失败,是客户端或本地网络问题。这条判断决定了后面该看第 2 章还是第 3 章。

把这三条做完,通常已经能确定该跳到哪一章。下面这张表把常见症状与章节对应起来,可以先按症状找,再回到章节里逐条做。

开始排查前,顺手准备三样东西:出问题的设备、出问题的时间点、客户端日志里对应时间的那几行。工单里最有价值的信息不是"连不上"三个字,而是"某时某分、某条线路、报错原文是什么"。日志的取法在第 10 章统一说明。

复测的方法也要固定:同一个目标站点、同一个时段、同一条命令。改完设置立刻打开三个不同地区的站点,比反复点连接更能说明问题。如果改完第一次就通了,先别急着收工,隔十分钟再复测一次——间歇性故障最容易被第一次成功掩盖。

完全连不上:从订阅到本地端口逐层排除

先把"连不上"拆成三种表现:点连接后一直转圈、几秒内直接失败、显示已连接但流量计数始终为零。第一种多半卡在握手,第二种多半是本地配置或端口,第三种通常意味着隧道建立了但没有流量通过。三种表现对应不同的排查起点,混在一起看只会越查越乱。

下面六步按从账号到本地的顺序排列,每一步都能独立得出结论。做到哪一步通了,就停在那一步,不必继续往下。

1. 确认订阅在有效期内、当月流量未用完

   登录用户面板,看套餐到期时间与当月剩余流量。月订阅的流量按开通日每月重置,用完不会自动续;流量包用完为止、永久不过期,与月订阅的流量分开计算。这一步只看面板,不改客户端。

2. 换一条线路再试

   同地区换城市(东京换首尔),或换线路类型(IEPL 换中转)。连续三条不同地区的线路都失败,基本可以排除单条线路的问题;只有一条失败,那就是这条线路的事,换掉即可。

3. 换一个网络

   用另一台设备开热点给电脑,或改用移动网络。办公网、校园网、酒店网络常做端口与协议限制,换网就通,说明是本地网络的策略,不是账号问题。这一条能省下大量改客户端的时间。

4. 校准系统时间

   把系统时间设为自动同步。时间偏差超过几分钟,TLS 握手就会失败,而客户端通常只报一句"连接失败",看不出真正原因。校准后重启客户端再试一次。

5. 退出其他代理类软件

   两个客户端同时运行会抢同一个本地端口,后启动的那个往往静默失败。检查托盘与任务管理器,把不用的代理、加速器、抓包工具全部退出,只留一个。

6. 检查防火墙与安全软件

   首次运行时被拦下的入站规则不会自己恢复。在系统防火墙里找到该客户端,确认入站与出站都是允许;第三方安全软件的"网络防护"也可能拦截隧道,先临时关闭再测。

几个容易被忽略的原因

本地端口冲突。客户端默认的本地端口可能已经被别的程序占用。表现是界面正常、连接按钮也能点,但系统代理指向的端口上没有服务。改一个端口或退出占用者即可。

网络对 UDP 的限制。部分网络对 UDP 限速或直接丢弃。客户端里切换到 TCP,或换一种传输方式再试,能连上就说明是这个原因。

回环代理。分流规则如果把订阅域名、面板域名也判给代理,而代理这时还没连上,更新订阅与建立连接就会互相等待,看起来像怎么都连不上。把这两个域名设为直连,再重新连接。

路由器侧的拦截。家长控制、上网时间管理、DNS 过滤都会在路由器层拦截。用移动网络对比一次就能确认。

什么时候该停下来提工单

三条不同地区、不同线路类型的线路都失败,两个不同网络下同样失败,系统时间已校准、其他代理软件已退出——三条同时成立,基本可以判断不是本地问题。这时候提工单,并附上客户端日志与出问题的时间点,比继续试下去更有效率。工单要附哪些信息,见第 10 章。

能连上却打不开网页:先分清全部还是部分

客户端显示已连接、流量也在走,浏览器却打不开页面。第一件事不是改设置,而是做一个区分:所有网站都打不开,还是只有一部分打不开。这个区分决定了后面九成的路径。

全部打不开

全部打不开通常意味着 DNS 没有跟着隧道走,或者数据包在链路上被丢掉了。按下面三条依次验证。

DNS 是否在隧道内解析。在客户端里确认"DNS 由隧道解析"一类的选项是开启的,并且系统 DNS 没有被改成某个固定的本地地址。判断方法在第 9 章。

MTU 是否匹配。隧道封装会占用一部分包长。本地仍是 1500 时,大包会被丢弃,典型表现是首页能打开、图片与视频加载不出来、页面卡在半截。用不分片的 ping 测一次:

# Windows
ping -f -l 1472 example.com

# Linux / macOS
ping -M do -s 1472 example.com

1472 加上 28 字节的头部正好是 1500。能通说明 MTU 没问题;提示需要拆分数据包或直接超时,就把数值逐步降到 1400 附近再试,并把客户端的 MTU 调到 1400 到 1450 之间。这是隧道类问题的常见取值,不需要反复试到刚好。

分流规则是否把浏览器判成了直连。切到全局模式跑一次,能打开就说明是规则问题,再回到规则模式逐条补白名单。

部分打不开

只有特定站点打不开,问题通常在目标站点一侧,不在隧道。

地区限制。站点按出口地区提供服务,用对应地区的线路即可。常用地区与适用场景的对照在第 4 章。

出口 IP 触发验证。同一出口被多人使用时,站点可能要求额外验证或直接拒绝。换一条同地区的其他线路,通常就能通过。

本地缓存。浏览器与应用缓存了旧的解析结果或旧的连接。清一次 DNS 缓存(命令见第 9 章)再刷新。

流媒体与账号地区。流媒体除了出口地区,还看账号注册地区。出口换了、账号地区没换,照样只能看到部分内容。这类情况换线路解决不了,需要账号侧一致。

分流模式怎么选

排查时先用全局模式跑一遍。全局能通、规则不通,九成是分流规则的问题;两种模式都不通,回到 DNS 与 MTU 那两条。定位清楚之后再回到规则模式,把漏掉的域名加进白名单,而不是长期挂着全局——全局模式会把内网访问、局域网设备、本地开发服务一起塞进隧道,代价不小。

速度慢与晚高峰卡顿:先分清三种慢

慢至少有三种:一直慢、特定时段慢、特定站点慢。三者的成因与处理方式完全不同,混在一起改只会白费功夫。先花两分钟确认属于哪一种,再动手。

一直慢

从连接开始到现在,任何时段都慢,通常出在本地。依次检查:本地宽带本身的实际速率;Wi-Fi 是否工作在 2.4GHz 频段(近距离优先用 5GHz);路由器是否老旧或开启了限速;后台是否有系统更新、网盘同步、云备份在跑。

还有一种常见情况是出口地区选得太远。物理距离决定了下限,从亚洲访问欧洲出口,线路再好也要多走一段。就近选地区,是提升体感最直接的一步。

特定时段慢

白天正常、晚间变慢,是国际带宽的公共现象,不是某一家服务的问题。晚间的处理思路不是反复重连,而是换线路类型。

线路类型在客户端的线路列表里就能看到,每条线路后面都标了类型。晚间把常用线路从直连换成同地区的 IEPL 专线,通常比换地区更有效。

特定站点慢

只有某个站点慢,先怀疑站点本身:它是否对共享出口限速、是否对单连接限速、CDN 是否把你调度到了远端节点。判断方法很简单——同一条线路打开另一个同类站点,速度正常,就不是隧道的问题。

浏览器扩展也会拖慢:广告拦截、脚本管理、翻译插件在跨境访问时会放大等待时间。用无痕窗口(默认不加载扩展)对比一次即可确认。

怎么测才算数

不要看测速软件的峰值,看真实任务的完成时间:同一部片子从点开到能播放用了多久,同一份文件从开始到下载完成用了多久。测的时候固定三件事——同一个目标、同一个时段、同一个操作。线路 A 与线路 B 各测三次取中位,两次结论才有可比性。

本站的线路表不列延迟数字,页面上也不放实时测速。延迟随本地网络、时段、目标站点变化,写一个固定值没有参考意义;真实体感只能在自己的网络下测出来。

按用途选出口地区

更完整的选线规则见 线路选择入门指南;全部地区与线路分布见 服务器 页。

什么时候该考虑换档位

慢与"流量用完"是两件事:流量用完通常直接不通,不是变慢。如果确认是流量不够用,月订阅有三档可选:¥9.9 每月含 60GB、¥18 每月含 250GB、¥28 每月含 500GB,流量按开通日每月重置,中途升级按剩余天数折算差价。用量波动大的场景,也可以叠加流量包:¥158/300GB、¥358/1000GB、¥658/3000GB,用完为止、永久不过期。具体对比见 套餐 页。

频繁断线:按断线的时间规律反推原因

断线最容易被误判成线路不稳。先别换线路,先看规律:固定间隔断、随机断、换网时断。三种规律对应三套完全不同的原因,规律看对了,原因基本就出来了。

固定间隔断

每隔五分钟、每半小时断一次,时间点几乎一致。这类断线通常不是线路掉了,而是会话被回收。

心跳与超时。客户端在一段时间内没有数据往来时会主动断开重连。挂着不动就断、一有流量就正常,是这个原因。客户端里开启"保持连接""定时心跳"一类的选项即可。

会话超时。路由器或运营商侧会回收长时间空闲的会话。表现与心跳问题一样,处理方式是把路由器的会话超时调长,或让客户端定期发探测包。

随机断

没有固定时间,断完能自动恢复或需要手动重连。常见原因有三个:Wi-Fi 漫游(设备在多个接入点之间切换时隧道重建)、信号弱、省电策略(见第 8 章)。

处理顺序:固定在一个 Wi-Fi 频段与一个接入点做对照;关闭系统的"Wi-Fi 助理""自动切换网络";记录断线时的位置与动作。移动过程中断、坐下就恢复,基本可以确定是漫游。

换网时断

从 Wi-Fi 切到移动网络、或从一张卡切到另一张卡时断线,本身是正常现象,隧道需要重建。要确认的是它是否自动重连:客户端里找"网络变化自动重连"一类的开关,打开。部分系统在切换网络后会回收连接授权,需要重新确认一次。

记录什么才有用

三次断线就能看出规律,前提是记录对了。记四样:时间点(精确到分钟)、持续多久、当时在做什么(挂着不动还是正在传输)、是否换了网络。再加上客户端日志里对应时间的那几行,这四样加日志,足够判断属于上面哪一类。

客户端侧的四个开关

大多数断线问题,靠这四个开关就能解决:开机自动连接(避免重启后忘记连)、断线自动重连(避免手动干预)、保持连接与心跳(对抗会话回收)、仅在使用时连接(移动端省电,但会牺牲后台连续性)。四个开关按使用场景取舍,桌面端建议前三个全开,移动端按是否需要后台常驻决定第四个。

什么时候是上游问题

如果同一条线路在不同设备、不同网络下都在相近的时间点断,而且换线路就好,那才轮到上游。这时候换线路并把时间点写进工单,比反复重连有用。

订阅更新失败:从链接完整性查到拉取网络

订阅更新的本质,是客户端向订阅地址发一次请求,拿回一段配置文本。失败只有四类原因:链接不对、请求发不出去、请求被中间页接管、客户端没保存成功。按顺序排除,四步之内必有结论。

1. 重新复制完整链接

   从用户面板复制,不要手抄,也不要用聊天软件里转过一手的文本——中间的换行与空格会被一起复制进去。链接里带参数,少一个字符就取不到配置。

2. 在浏览器里直接打开一次

   正常的返回应该是一段纯文本或一个下载文件。如果打开的是一个登录页、一个错误页、或者一片空白,说明链接失效或请求被中间页接管了。这一步是整章里最有效的一步。

3. 先连上再更新

   订阅地址本身可能需要通过隧道才能访问。先用一条可用线路连上,再点更新。反过来做,会卡在"没连上所以更新不了、更新不了所以连不上"的循环里。

4. 删掉旧订阅重新添加

   比反复点更新可靠。部分客户端在更新失败后会保留旧配置,看起来像更新成功但节点没变。

习惯用命令行的,可以直接用一条命令验证链路是否通:

curl -sS -m 15 "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

示例地址是假值,只用来演示命令形状,实际链接从面板复制。命令返回一段文本,说明链路通、内容对;返回一段 HTML,说明请求被中间页接管;直接超时,说明请求发不出去。三种结果对应三种处理方向。

更新成功但节点变少或变空

变少。线路池会随运营调整,数量有增有减,属正常现象。只要常用地区还在,不必处理。

变空。通常是拿回了一个错误页,客户端解析不出任何节点。回到第 2 步,用浏览器验证链接本身。

浏览器也打不开。问题在账号侧,登录面板确认套餐状态与剩余流量。

多设备共用一个链接

本站同时在线设备不限台数,同一个订阅链接在多台设备上导入是允许的,不需要为每台设备单独申请。需要注意的是,不要在多台设备上反复重置订阅——部分客户端的重置会作废旧配置,导致其他设备一起失效。需要换配置时,先把新链接导入,确认可用,再删旧的。

时间不同步也会导致更新失败

HTTPS 请求需要校验证书有效期。系统时间偏差过大时,证书校验直接失败,客户端只报一句更新失败,没有任何细节。把系统时间设为自动同步,重启客户端再试一次,是这类问题唯一的处理方式。

单个应用走不了代理:先看它走不走系统代理

浏览器正常、某个应用不行,说明隧道本身是通的,问题出在这个应用怎么发请求。应用的网络行为分三类:跟随系统代理、自己直连、走 UDP。先判断属于哪一类,再决定用哪种接管方式。

三类应用

跟随系统代理。大多数浏览器与部分桌面应用属于这一类。系统代理一开,它们就跟着走。

自己直连。很多游戏启动器、软件更新器、命令行工具不读系统代理设置,必须用虚拟网卡(TUN)模式接管全局流量才能覆盖。

走 UDP 或 QUIC。部分浏览器与视频应用默认走 QUIC。隧道对 UDP 支持不好时会表现为卡住而不是报错,很容易误判成这个应用用不了。

平台差异

处理顺序

1. 切到 TUN 模式

   这是覆盖面最广的一种接管方式,能覆盖不读系统代理的应用。切完重启目标应用再试。

2. 关掉应用的 QUIC 与 HTTP3

   浏览器里通常有关闭项;关掉之后流量回到 TCP,隧道处理起来稳定得多。

3. 检查应用是否用了自己的 DNS

   部分应用内置私有加密 DNS,绕过系统设置。关闭应用的"安全 DNS"选项,让它跟随系统。

4. 命令行工具手动指定代理

   在客户端界面里找到本地端口,写进环境变量,或在命令里加参数。后台服务需要单独配置,它不继承用户的环境变量。

5. 确认分应用代理列表

   安卓等支持分应用代理的平台上,目标应用必须在代理列表里被勾选,否则它走的是直连。

验证命令行工具到底有没有走隧道,用一条只输出状态码的命令最直接:

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

返回 200 说明这条命令的流量通了,返回 000 说明没通。开代理前后各跑一次,对比结果即可。同样的方法也适用于判断某个脚本、某个构建工具是否走了隧道。

仍然不通的几种情况

应用写死了 IP 或使用私有协议。这类流量绕过分流规则,只能靠 TUN 模式整体接管。

应用有独立网络权限。移动端部分应用被系统单独限制了网络权限,在系统设置里放行。

应用自身的地区限制。出口换了但账号地区没换,应用照样拒绝服务,这与隧道无关。

开发场景下的长连接需求(补全请求、包管理器、模型接口)对稳定性要求更高,选线与分流的细节见 AI 编程工具的网络与线路说明。

移动端后台掉线:省电策略比线路更常见

锁屏几分钟后连接消失,解锁后要重新连。这类问题九成不是线路,而是系统的后台管理:为了省电,移动系统会冻结后台进程、回收网络配置、限制后台数据。先按平台处理系统设置,再考虑线路。

iOS

低电量模式。开启后会限制后台刷新与网络活动,隧道首当其冲。关闭后再测一轮,这是最容易被忽略的一条。

后台 App 刷新。关闭后,应用无法在后台维持连接。在系统设置里为该客户端单独打开。

按需连接。开启后,系统会在需要网络时自动拉起隧道,不必手动点连接。这是移动端最省心的一个开关。

网络切换。Wi-Fi 信号弱时系统会切到移动网络,切换过程隧道重建,表现为每次走到某个房间就断。固定使用其中一种网络做对照即可确认。

Android

电池优化。系统会把不常用的应用放进受限状态,后台网络被切断。把客户端加入电池优化白名单,并允许后台活动。

自启动权限。部分定制系统默认禁止应用自启动,重启后连接不会自动恢复。在应用管理里单独放行。

从最近任务里划掉。很多系统会连带结束该应用的隧道。需要后台常驻时,在多任务界面把该应用锁定。

通用检查清单

1. 关闭系统对该应用的省电优化

   包括智能省电、深度睡眠、后台限制这类开关,逐个确认。

2. 允许后台数据与后台活动

   系统的流量节省模式也会切断后台连接,需要单独放行。

3. 双卡设备固定数据卡

   两张卡来回切换会导致隧道反复重建。固定一张做数据卡,信号更稳。

4. 用另一台设备做对照

   同一网络下另一台不掉线,基本可以确定是本机的系统策略,不是线路。

什么情况不是省电问题

解锁状态下也频繁断,回到第 5 章看时间规律;只在换 Wi-Fi 时断,是漫游;只在某个应用切到前台时断,是该应用抢占了网络或改写了 DNS;连接图标一直在、但后台下载停止,是系统限制了后台数据,而不是隧道断了。

把这四种情况区分开,能避免在系统设置里反复改却不见效。移动端的省电策略是逐版本变化的,系统大版本更新之后如果出现新的掉线规律,优先回到这一章重新过一遍清单。

DNS 异常:能 ping 通却解析不出域名

DNS 负责把域名翻译成 IP 地址。它出问题时,表现很像断网:浏览器提示找不到服务器,但直接 ping 一个 IP 却是通的。判断方法很简单——先 ping 一个 IP,再 ping 一个域名,两次结果一对比就清楚了。

ping -c 4 1.1.1.1
nslookup example.com
nslookup example.com 8.8.8.8

第一条通、第二条失败,是本机 DNS 的问题;两条都通、第三条失败,是本机 DNS 被改写或缓存了错误结果;三条全失败,可能根本没有网络,回到第 2 章。Windows 上把 ping -c 4 换成 ping -n 4 即可。

常见现象对照

清一次缓存

改完设置先清缓存,否则旧的解析结果还会继续生效一段时间。各平台的命令如下:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

移动端没有命令行,开关一次飞行模式即可让系统重新发起解析。

为什么会泄漏

多个网络服务。系统里可能同时存在有线、Wi-Fi、虚拟网卡等多个网络服务,代理只改了其中一个,解析请求从另一个出去了。

浏览器自带加密 DNS。浏览器可以自己指定加密解析服务器,完全绕过系统设置。排查时先关掉它。

分流规则把 DNS 判成直连。规则里如果只写了域名匹配,没覆盖解析请求本身,解析就会走本地。

排查顺序小结

先确认隧道内解析是否开启,再清缓存,再关掉浏览器与系统的加密 DNS,最后检查分流规则。四步做完仍然解析失败,把两条 nslookup 的输出附进工单,比自己继续猜快得多。

C6VPN 的隐私策略是匿名无日志:不记录浏览内容与访问目标。DNS 在隧道内解析是这套策略的一部分,所以排查时优先让解析走隧道,而不是把请求交给本地运营商。

多设备、并发与提工单的时机

本章处理两类问题:多台设备同时使用时的表现,以及什么时候该停止自己排查、转去提工单。

不限台数意味着什么

同时在线设备不限台数,同一个账号可以在 Windows、macOS、iOS、Android、Linux 上同时登录,不需要为每台设备单独购买。这一点在 套餐 页也有说明。

但不限台数不等于每台设备独享带宽。出口带宽是共享的,多台设备同时看 4K、同时下载大文件,彼此会挤占。判断方法很直接:关掉其他设备再测一次,速度恢复就是并发占用,不是线路变差。

路由器级代理是另一种用法:把订阅导入路由器后,家里所有设备共用一个出口。好处是省事,代价是所有设备同一个出口 IP,遇到站点风控时会一起受影响,排查时也不容易分清是哪台设备的问题。建议先用单机方式确认线路可用,再决定是否上路由器。

关于设备数已达上限的提示

本站账号侧没有设备数量限制。如果客户端里出现了类似提示,先看提示来自哪里:多数情况是本机同时装了两个客户端抢同一个本地端口,或路由器插件对并发连接数做了限制。处理方式:退出多余的客户端,检查路由器插件的并发设置,再重新登录面板复制订阅。

什么时候该提工单

下面五条里满足两条以上,就值得停下来提工单,而不是继续试:

• 三条不同地区、不同线路类型的线路都连不上
• 两个不同网络(家宽与移动网络)下同样失败
• 系统时间已校准,其他代理类软件已全部退出
• 订阅链接在浏览器里能打开,客户端里更新失败
• 同一条线路在另一台设备上正常,本机始终失败

工单里要附什么

不要附什么

账号密码、完整的订阅链接、支付凭证截图、身份证件。这几类信息对定位问题没有帮助,只会增加泄漏面。订阅链接需要展示时,把 token 段落涂掉。

入口与后续

工单在用户面板内提交,登录后进入工单页即可。提交前先看一遍 使用教程,有一部分问题在教程里已有现成答案;也可以从 联系与支持 页确认当前可用的联系方式。

如果排查到最后确认是服务不符合预期,30 天无理由退款可以在面板内申请。注册本身不需要邮箱地址,用户名与密码即可完成,这一点在退款流程里同样成立——不会因为找不到邮箱而卡住。