连接故障排查手册

完全连不上：先确定失败发生在哪一层

“点了连接但没反应”只是表面症状，背后可能是客户端没有拿到有效订阅、所选线路暂时不可达、本地网络本身没有连通、系统代理状态没有切换，或旧配置仍占着通道。排查时不要同时改线路、协议、规则和 DNS。一次只改一个变量，改完重新测试；否则即使恢复，也不知道究竟是哪一步起效，下次还得重新摸黑。

先做最小化判断

第一步是退出客户端后重新打开，确认界面里能看到线路名称，而不是空白列表、过期提示或订阅读取错误。随后断开再连接当前线路，观察状态停在哪个阶段：如果点击后立刻回到未连接，优先检查配置是否完整；如果长时间停在连接中，通常更像线路不可达或本地网络拦截；如果界面显示已连接却无法访问任何页面，应转到下一章检查系统代理与 DNS，而不是继续重复点击。

接着验证本地网络。暂时断开加速连接，打开一个平时可正常访问的网站。如果基础网络本身也打不开，先修复本地网络，客户端不负责给断网的设备凭空造一条轨道。若基础网络正常，再选择另一条不同地区的线路测试。JVVPN 覆盖 90+ 国家 / 200+ 线路，切换线路的目的不是盲目抽卡，而是判断故障属于单条线路还是整个客户端环境。只有某条线路失败时，保留故障线路名称，换线继续使用；所有线路都失败时，再检查客户端与系统层。

清理互相抢方向盘的程序

系统里同时运行多个代理、网络过滤、防护或企业接入工具时，它们可能争用同一套系统代理设置。表现通常是客户端显示连接成功，但系统流量没有进入它；也可能前一个工具退出后留下代理地址，使网页持续转向一个已经不存在的本地入口。排查时完全退出其他同类程序，不只是关闭窗口，还要确认托盘或菜单栏里没有残留进程。随后在系统网络设置中检查代理是否由当前客户端接管，不要手工保留来源不明的地址。

Windows 可从系统代理设置确认自动或手动代理是否与当前客户端状态同步；macOS 应检查当前正在使用的网络服务，而不是另一个闲置接口；Linux 则要注意图形桌面代理、终端环境变量和应用自身代理是三套可能互不相认的配置。若终端曾设置代理环境变量，可先查看当前会话：

env | grep -i proxy

如果看到旧地址，先在当前终端取消对应变量，再重新启动需要测试的命令行程序。不要把不明来源的代理变量写进全局启动文件，那相当于给每个终端都塞一张过期登机牌。

重置顺序比重装更重要

仍然完全无法连接时，按“断开连接、退出客户端、关闭其他网络工具、重新打开客户端、更新订阅、换一条线路、再次连接”的顺序执行。只有客户端无法启动、配置文件损坏或系统授权明显缺失时，才考虑重新获取客户端。客户端下载必须从用户面板的下载入口获取，不使用来路不明的安装文件。重装前先退出旧客户端，避免新旧进程并存。

如果更换网络环境后能够连接，原网络可能存在路由、DNS 或访问策略差异；如果所有网络环境都失败，但同一账户在另一台设备正常，问题集中在当前设备；如果多台设备与多条线路同时失败，则应记录发生时间、客户端平台、线路名称和报错原文，直接进入工单章节。这个分叉判断比“再重启一次试试”更值钱，也更省头发。

能连接但网页打不开：拆开代理与 DNS

客户端显示已连接，只能证明连接流程完成，不代表域名解析、系统代理和应用流量都走在同一条轨道上。网页打不开时，先区分“所有网站都失败”“只有域名失败”“只有某个网站失败”还是“浏览器失败但其他应用正常”。这几种表象看起来相似，修法却完全不同。

用域名与基础请求分辨故障

先断开连接确认基础网络可用，再重新连接并打开多个不同网站。若所有网站都无法加载，同时客户端没有明显报错，检查系统代理是否开启，以及浏览器是否配置了独立代理。浏览器扩展可能覆盖系统设置，测试时应暂时停用相关扩展，并使用普通窗口而非保留大量旧状态的会话。若只有单个网站异常，优先清理该站点的缓存与登录状态，换线路复测；不要因为一个站点维护就给整个客户端判死刑。

命令行可使用以下方式检查域名是否能被解析，示例域名不会涉及真实订阅或凭据：

nslookup example.com

curl -I https://example.com

前一个命令如果无法返回解析结果，而其他基础网络操作正常，问题更接近 DNS；前一个正常、后一个失败，则继续检查代理路径、证书时间与应用设置。系统日期明显不正确时，加密连接会因为证书校验失败而被拒绝，因此应先启用系统自动校时。不要跳过错误信息：浏览器显示“找不到地址”“连接被重置”与“证书无效”，指向的是不同故障层。

DNS 异常的典型形态

DNS 负责把域名转换成网络可识别的地址。连接切换后，系统可能继续使用旧缓存；客户端可能接管了解析，但某个应用仍坚持使用自己的解析方式；家庭网络设备也可能缓存先前结果。常见现象包括域名间歇打不开、同一网站在浏览器与应用中结果不同、切换线路后内容区域没有变化，以及断开连接后仍然指向旧地址。

处理时先关闭发生问题的应用，断开客户端，再重新连接后打开应用。若问题仍在，可清理操作系统 DNS 缓存，然后重试。Windows 可在具有相应权限的终端执行：

ipconfig /flushdns

macOS 与 Linux 的缓存机制会随系统环境变化，不建议从不明教程复制一长串高权限命令。更稳妥的方式是重新连接当前网络、重启系统解析服务，或直接重启设备。客户端若提供 DNS 接管选项，应保持与当前模式一致；不要一边启用客户端解析，一边在浏览器里强制另一套解析，再期待两边像训练有素的编队。

确认规则模式没有把请求送错出口

规则模式会根据域名或地址决定流量走加速线路还是本地网络。如果规则较旧、分类不完整或用户自定义规则排在错误位置，网站可能被错误直连。测试时可临时切换到全局模式：若全局模式正常、规则模式失败，说明线路本身可用，问题集中在规则；若两种模式都失败，则回到 DNS、系统代理或线路层继续查。

某些用户搜索“翻墙软件故障”时，实际遇到的就是 DNS 与规则分流不一致，而非客户端彻底失效。诊断重点应落在可验证的请求路径上：域名有没有解析、规则命中了什么、请求最终从哪个出口发出。保留错误截图与复现域名，能让客服直接判断规则问题，远比一句“网页不行”更有用。

速度慢与晚高峰卡顿：先看瓶颈在哪

速度慢不等于线路坏了。最终体验受本地接入质量、无线干扰、线路距离、目标服务响应、规则模式、设备负载和时段共同影响。测速只跑一次、只测一条线路、只看峰值，得到的往往是情绪，不是结论。更完整的测速方法可参考VPN 测速怎么测才准，本章聚焦故障现场如何快速定位。

先比较断开与连接后的变化

在同一设备、同一网络环境、相近时间内，分别测试断开连接和连接后的网页打开、文件传输或流媒体播放。若断开时也明显缓慢，瓶颈首先在本地网络；若断开正常、连接后所有线路都慢，检查客户端模式、设备资源占用和本地网络对加密连接的影响；若只有特定线路慢，则切换到距离更近或路径更合适的地区。

测试时关闭正在同步、下载或上传的程序。云盘、系统更新、视频会议与局域网备份都可能占用链路，尤其上传被占满时，网页请求也会显得迟钝。无线网络还会受到距离与同频干扰影响，能使用稳定有线连接时可做一次对照。这个对照不要求长期改成有线，只用于确认问题是否发生在无线这一小段。

延迟、吞吐与稳定性不是同一个指标

延迟影响点击后的响应速度，吞吐影响持续传输能力，稳定性则决定播放或会议会不会周期性停顿。低延迟线路未必最适合大文件，高吞吐线路也未必在短请求中反应最快。选择线路时应围绕任务：网页和交互工具更看重响应连续性，流媒体更看重持续吞吐，远程协作则尤其怕抖动和短暂断流。

晚高峰要做跨时段与跨线路对照

如果白天正常、晚间反复卡顿，说明故障具有明显时段特征。不要只在卡顿时来回重连同一条线路，而应选择不同地区或不同线路类型做对照，并记录哪些线路在相同时段稳定。线路详情与类型说明可查看线路页面。直连路径通常更直接，但对本地网络变化敏感；中转路径会增加中间环节，却可能避开不理想的跨境路径；IEPL 专线适合关注路径稳定性的场景。具体选择仍应以当前网络的实际体验为准，而不是把某个标签当成万能护符。

流媒体掉画质时，还要区分服务端自适应与连接速度。播放器会根据一段时间内的持续传输状态调整画质，刚切线后立刻观察往往不准确。可停止播放、切换线路、重新打开内容，再观察是否持续稳定。关于码率、带宽与画质掉档的关系，可继续阅读看 4K 总掉 480p 怎么办。

若所有线路在相同网络下都慢，但换到另一网络明显恢复，应把本地网络类型与发生时段写进工单；若仅某一目标服务慢，其他网站正常，则记录目标域名和使用地区；若速度忽快忽慢，附上持续一段时间的现象描述，而不是只截某次峰值。稳定性问题需要时间线，单张截图很难说明轨道在哪一秒歪了。

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

频繁断线要先区分“客户端主动断开”“系统暂停网络”“无线网络切换”与“应用退到后台后被系统冻结”。前台持续使用时稳定、锁屏或切换应用后掉线，通常优先检查后台权限与省电策略；前台也按固定节奏断开，则更像网络波动、线路会话失效或多个网络工具冲突。

桌面端先排除休眠与网络切换

Windows、macOS 与 Linux 在睡眠、唤醒、切换无线网络或从有线转到无线后，原连接可能继续显示为已启用，但底层网络路径已经变化。最稳妥的恢复方式是先断开客户端，确认新的基础网络能够访问网页，再重新连接。若每次唤醒后都出现异常，可检查系统电源设置是否允许网络接口在空闲时被关闭，并关闭会自动接管网络的其他工具。

如果设备连接着多个可用网络，系统可能在信号变化时自动切换。连接会话建立在旧接口上，新接口接管后便可能中断。诊断期间固定使用一个网络，暂时关闭自动加入其他网络的选项。若固定后稳定，问题不在线路本身，而在网络接口切换。不要一边在不同接入点之间漂移，一边要求会话像焊死在轨道上。

iOS 与 Android 的后台策略

移动端系统会根据电量、后台活动和应用使用状态暂停进程。若客户端退到后台后不久失效，先检查是否允许该应用保持网络连接、是否被加入严格省电名单，以及系统是否在锁屏时关闭当前网络。不要使用一键清理工具强制结束客户端，也不要在任务切换界面手动划掉仍需工作的进程。

iOS 上应确认客户端所需的网络配置仍然存在，切换网络或系统唤醒后若没有自动恢复，可打开客户端手动重连。Android 设备的省电实现差异较大，应在系统的电池或应用后台设置中允许客户端持续运行，并确认数据使用权限没有被限制。设置名称会随设备环境不同而变化，判断标准只有一个：退到后台后，客户端进程与网络连接是否仍被允许保留。

通过时间规律判断线路还是设备

断线完全随机时，记录当时是否发生网络切换、锁屏、唤醒或大流量传输；只在某条线路发生时，换线并保留线路名称；所有线路都在同一设备掉线，而其他设备正常时，优先检查当前设备；多个设备在同一网络同时掉线，但换网络恢复时，问题更接近本地网络。这个交叉验证不需要复杂工具，只需要每次少改一个变量。

若断开后客户端自动重连但应用没有恢复，关闭并重新打开受影响应用，因为它可能仍持有旧网络会话。若客户端本身也无法恢复，完全退出后重开。反复出现且可以稳定复现时，不要持续重装；把“前台是否稳定、锁屏后是否发生、换线是否恢复、换网络是否恢复”写入工单，客服就能直接沿着会话生命周期排查。

订阅更新失败：从链接到配置逐段核对

订阅负责把可用线路与配置交给客户端。更新失败时，客户端可能继续显示旧线路，也可能清空列表。先不要删除仍可工作的旧配置；错误地先删后更，会把“部分可用”升级成“完全空仓”。正确顺序是确认账户状态、重新获取订阅、在浏览器或客户端中验证链接能否访问，再决定替换还是重新导入。

确认拿到的是当前订阅入口

登录用户面板，在概览或订阅相关区域重新复制当前订阅入口。不要从聊天记录、旧文档或其他设备的历史剪贴板中取链接。订阅入口属于账户交付信息，应只导入受信任的客户端，不要发布到公开页面，也不要交给不明转换服务。教学示例可以长这样，但它不是可用地址：

https://example.com/sub?token=YOUR_TOKEN

如果复制时混入空格、换行或标点，客户端可能把它识别成无效地址。应直接使用面板复制按钮，并完整替换客户端中的旧值。若客户端支持更新现有订阅，优先使用更新；只有订阅条目本身损坏、名称重复或无法编辑时，再新建条目。新条目确认成功后再删除旧条目，避免两份配置一起失效。

按报错类型处理

“网络错误”通常表示客户端没有成功访问订阅入口，可先断开当前代理后更新，再尝试连接一条可用线路后更新，借此判断入口在当前网络下的访问路径。“格式错误”更接近客户端不支持返回格式、链接复制不完整或内容被其他页面替代。“授权失败”则应重新登录面板获取当前入口，不要反复编辑链接字符。客户端显示更新成功但线路没有变化时，检查是否打开了另一个同名订阅，或客户端仍在使用缓存配置。

有些客户端支持自动更新，但系统后台限制可能让自动任务没有执行。先手动更新一次，确认订阅本身可用，再处理自动更新。若手动成功、自动失败，问题属于客户端调度或系统后台权限；若手动也失败，则继续检查网络与订阅入口。不要把自动更新频率调得过于激进，频繁请求既不会让线路凭空变新，还可能让日志里挤满没有诊断价值的重复错误。

避免配置叠加与旧规则残留

重新导入后，客户端可能同时保留旧订阅、手工线路和新订阅。选择线路前确认它属于哪一组，删除完全重复且已经停用的配置。若线路出现但无法连接，回到“完全连不上”章节，不要继续把问题归给订阅。订阅更新解决的是配置获取，线路连接解决的是网络会话，两者是前后相邻的舱段，不是同一个零件。

若账户可以正常进入面板，但任何客户端都无法更新，可记录使用平台、客户端名称、错误原文以及“断开连接更新”和“连接后更新”各自的结果。若只有某个平台失败，其他平台正常，问题更可能在该客户端的导入格式或网络权限。首次导入流程不熟悉时，可阅读iOS 订阅导入全流程或返回使用指南重新核对主线步骤。

某个 App 不走代理：查规则、进程与网络栈

浏览器正常、某个 App 却无法访问，通常说明整体连接没有坏，故障集中在应用自己的代理策略、分流规则或网络实现。部分应用遵循系统代理，部分应用有独立代理开关，还有一些应用直接建立连接，不读取系统设置。先确认问题只发生在单个应用，再决定要改客户端规则还是应用设置。

用全局模式做一次隔离测试

保持同一条线路，临时从规则模式切换到全局模式，完全退出问题应用后重新打开。若全局模式恢复，线路和应用本身大概率可用，问题落在分流规则；若仍然失败，检查应用是否设置了独立代理、是否缓存旧网络会话，以及目标服务是否只在特定地区提供内容。测试结束后恢复原来的规则模式，再处理具体规则，不建议长期把诊断状态当成最终配置。

规则通常按顺序匹配，前面的宽泛规则可能抢先命中，使后面的精确规则永远没有机会。检查自定义规则时，关注目标域名、相关子域名和应用实际访问的服务域名，而不是只盯着产品首页。若客户端能显示连接日志或规则命中结果，可在打开应用时观察对应请求走了直连还是代理。日志里不应包含完整订阅入口，分享截图前也应遮盖账户相关信息。

区分系统代理与虚拟网络模式

系统代理主要影响遵循操作系统代理设置的程序；虚拟网络模式则从更底层接管流量，通常能覆盖更多应用。若某个 App 完全忽略系统代理，而客户端提供相应接管模式，可在理解系统授权提示后进行测试。切换模式前先断开连接，切换后重新连接并重启目标应用，避免旧会话继续沿用先前路径。

Linux 环境尤其需要区分图形桌面代理、终端环境变量、容器网络与应用内代理。终端程序可以查看代理变量：

env | grep -i proxy

若目标程序运行在容器或独立沙盒里，宿主系统代理未必会自动传入。此时应按照该运行环境的网络配置方式处理，而不是把真实订阅地址直接写进镜像或配置仓库。示例配置只应使用假值，并通过运行时环境提供需要的本地代理信息。

处理缓存、地区与登录会话

某些服务会同时参考出口地区、账户地区、缓存与既有登录会话。切换线路后，旧应用进程可能仍保留之前的连接，导致网页已经变化而 App 没变化。应退出应用、切换线路、确认连接稳定后重新打开。仍异常时，可清理该应用缓存或重新登录，但不必一开始就删除全部数据。先做可逆操作，再做破坏性操作，是排查的基本礼仪。

若同一服务在浏览器可用、App 不可用，记录应用名称、平台、所选线路、规则模式与全局模式的对照结果；若不同线路表现不同，可到线路页面了解地区与线路类型，再选择与目标服务匹配的出口。用户口中的“梯子连上但 App 不动”，很多时候就是应用不读取系统代理或规则把请求送错出口。把这一层查清，比连续换一圈线路更有效。

若应用更新后突然失效，而其他环境没有变化，应优先怀疑应用网络行为或缓存发生变化。可以用浏览器访问同一服务做对照，并在工单中说明“更新前可用、更新后异常”，但不要编造或猜测具体客户端版本。客服需要的是可复现条件，而不是一串可能写错的版本号。

设备与账户异常：别把登录问题当线路故障

JVVPN 不限同时在线设备数，因此正常情况下，不应因为同时连接的设备台数触发套餐设备上限。出现“另一台设备能用、当前设备不能用”时，重点应放在当前设备的配置、订阅是否同步、账户状态与流量状态，而不是计算家里到底开了多少块屏幕。关于多设备计数与家庭场景，可阅读VPN 多设备共用完整解读。

先检查账户与套餐状态

进入用户面板确认能够正常登录，并查看当前服务状态。JVVPN 注册无需邮箱地址，用户名与密码即可注册，因此用户名应妥善保存。若忘记的是登录身份而不是客户端配置，不要连续创建多个相似账户，否则容易在不同账户间购买、复制订阅和提交工单，最后像把行李送上了相邻航班。

月订阅包括 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。若客户端能连接但随后无法正常传输，应登录面板核对当前订阅与流量状态，而不是只在客户端界面反复刷新。套餐详情与选择入口位于套餐页面。

多设备之间不要复制缓存文件

在新设备上使用时，应从用户面板获取适合当前平台的客户端，并重新导入当前订阅。不要直接复制另一个系统的客户端缓存目录，因为其中可能包含平台相关路径、旧规则、失效会话或不兼容设置。JVVPN 支持 Windows / macOS / iOS / Android / Linux，各平台的系统代理、后台权限和网络接管方式不同；订阅内容可以一致，客户端运行环境却不能简单克隆。

若某台设备线路列表为空，而其他设备正常，先在问题设备手动更新订阅；若更新失败，按订阅章节处理。若列表存在但无法连接，按连接章节处理。若能连接但应用不通，按分流章节处理。这种按阶段切分的方法能避免把所有问题都塞进“账户异常”这个黑洞。

区分账户登录、客户端订阅与支付状态

网站账户登录成功，不代表客户端已经导入订阅；客户端存在订阅，不代表它已经更新到当前状态；支付完成后，也需要回到面板确认对应服务已经显示。支付宝 / 微信 / USDT 是本站支持的支付方式。遇到订单状态与预期不一致时，通过用户面板查看订单并提交工单，不要重复创建订单来试探系统。

如果问题与付费后的使用预期有关，可先查看套餐条款。本站提供 7 天无理由退款，具体申请应通过用户面板处理。排障与退款是两条独立流程：技术问题可以继续提交工单定位，退款请求则应明确写出对应订单与诉求，避免客服从一段混杂描述里猜用户究竟要修连接还是处理订单。

什么时候找客服，以及工单怎么写

自查的目标不是让用户兼职网络工程师，而是收集足够信息，快速判断故障边界。完成基础网络确认、换线测试、客户端重启和订阅更新后仍然失败，就应提交工单。若多个平台、多个网络环境与多条线路出现相同问题，也不必继续在本地拆飞船；这类现象更值得由服务端统一检查。

这些情况适合直接提交工单

所有线路同时无法连接，并且基础网络正常；订阅入口在不同客户端都无法更新；某条线路持续异常且换线可恢复；支付记录存在但面板服务状态未按预期显示；同一问题可以按照固定步骤重复出现；客户端给出明确错误代码或错误原文。这些情况都有清晰的检查对象，提交后客服能够沿着账户、订阅、线路或客户端方向处理。

如果只是单个网站短暂打不开，可先换线路并稍后复测；如果基础网络本身断开，应先处理本地网络；如果只有某个 App 不通而浏览器正常，应完成全局模式对照后再提交。工单不是许愿池，信息越具体，往返确认越少。

一份可执行的工单应包含什么

• 故障现象：写清是无法连接、连接后无网络、速度异常、频繁断线、订阅更新失败，还是单个应用不通。
• 发生环境：提供 Windows、macOS、iOS、Android 或 Linux，以及所用客户端名称。
• 线路信息：写明发生问题的线路名称，并说明更换其他线路后的结果。
• 网络对照：说明断开连接时基础网络是否正常，换到另一网络后是否恢复。
• 模式对照：若涉及单个应用，说明规则模式与全局模式的表现是否不同。
• 错误原文：直接复制客户端提示，不要只写“报错了”，也不要自行改写成猜测结论。
• 复现步骤：从打开客户端开始，按实际点击顺序描述直到错误出现。
• 必要截图：截图应包含状态与报错，但遮盖完整订阅入口、账户凭据和支付敏感信息。

推荐的复现描述模板

问题类型：连接后无法打开网页
平台与客户端：填写实际平台和客户端名称
所选线路：填写线路名称
基础网络：断开客户端后可以正常访问网页
对照结果：更换线路后的实际表现
规则模式：填写当前模式与切换后的结果
错误原文：粘贴客户端显示的完整提示
复现步骤：
打开客户端
更新订阅
选择线路
建立连接
打开目标网站后出现错误

模板中的描述应替换成真实现场，不要附完整订阅入口，也不要上传包含密码的配置文件。若错误只在特定时段发生，写明大致时段与持续表现；若问题随机发生，说明最近一次发生前是否切换网络、锁屏、唤醒或进行了大流量传输。与其堆很多无关截图，不如给一条清晰时间线。

提交后保留现场，避免继续大改

工单提交后，尽量保留能够复现问题的线路名称、客户端设置与错误信息。若必须继续使用，可换到正常线路，但不要立即删除所有配置、重装系统或清空账户内容；现场被彻底改写后，客服只能根据残片推理。若问题自行恢复，也应在工单中补充恢复时间、是否换线以及执行过的操作，这些信息有助于判断是临时线路波动、缓存失效还是本地网络变化。

提交入口位于用户面板的工单中心。客服需要的是可验证事实，不需要“肯定是服务器炸了”这种先下结论的宇宙广播。把现象、环境、对照与错误原文摆齐，排障就从猜谜变成工程问题。完成处理后，再把客户端恢复到日常规则与常用线路，避免长期停留在为诊断临时开启的全局模式。