VPN故障排查手册

建立排查基线：先复现，再改设置

把“不能用”改写成可验证的现象

故障排查最费时间的地方，往往不是技术本身，而是描述过于宽泛。“连接不上”“很卡”“网页不行”都缺少判断条件。开始操作前，先把现象写成一条可重复的句子：是在点击连接后一直停留在连接中，还是显示已连接却无法访问网页；是所有网站都失败，还是只有某个 App 异常；是每条线路都慢，还是只有某个地区出现；是当前网络环境下发生，还是切换网络后仍然发生。描述越具体，后面的分支越短。

接着固定测试对象。选择一个普通网页、一个常用应用和一个明确的目标服务作为对照，不要每次测试都换不同内容。浏览器可能保留缓存，应用可能复用旧连接，目标站点也可能临时维护，所以单个结果不能直接证明线路有问题。更可靠的做法是让同一设备、同一网络、同一线路连续完成相同操作，并观察失败发生在连接建立之前、域名解析阶段，还是内容加载阶段。

先确认本地网络，再看加速链路

断开客户端后，先确认当前网络能够打开本地常用网站。如果基础网络本身无法使用，VPN 客户端没有可承载的底层连接，继续切线路不会解决问题。公共网络还可能要求先在浏览器完成认证；这类认证页面通常只有在暂时断开代理后才能正常弹出。完成认证，再重新连接客户端。公司、校园或酒店网络可能限制部分连接方式，此时切换到另一个可信网络做对照，比反复重装更有价值。

基础网络正常后，再核对设备时间与时区。时间偏差会影响加密握手、证书校验和登录状态，看起来很像线路离线。建议让系统自动同步时间，然后完全退出并重新打开客户端。这里的“完全退出”不是只关窗口，而是确认后台进程也结束，再重新启动。若客户端一直驻留旧状态，界面上的开关变化不一定等于连接核心已经重新加载。

建立一张简短的排查记录

记录不需要复杂表格，只要包含设备平台、当前网络类型、客户端显示状态、线路名称、失败对象、错误提示和最近一次正常使用的大致时间即可。不要只截取错误弹窗，最好同时保留客户端主界面与系统网络状态。若问题只在特定应用出现，还要记下该应用是否启用了自己的代理、加速、私有 DNS 或网络保护功能，因为这些设置可能覆盖系统代理。

还要区分“配置问题”和“服务容量问题”。前者通常在更换网络、重启客户端或修正系统设置后立即变化；后者更可能与线路选择、目标地区和使用时段相关。VPNIJ 覆盖 120+ 国家与 210+ 线路，排查时应优先用不同地区或不同线路类型做交叉验证，而不是在同一组相近线路间来回点击。完整覆盖信息可查看服务器与线路页面。

完成这一章后，应当能回答三个问题：故障是否稳定复现，问题影响全部流量还是局部流量，更换网络或线路后现象是否变化。只要这三个答案明确，后续章节就能直接进入对应分支，不必从头试遍所有设置。

完全连不上：从权限、订阅到线路逐层检查

先看客户端停在哪个阶段

点击连接后没有任何变化，通常先查客户端权限与后台状态；长时间停在“连接中”，更接近握手、网络限制或线路不可达；立即弹出认证错误，则优先检查订阅是否正确加载、账户状态是否有效。不要把这些现象混成同一种问题。界面上的错误文字很重要，即使看不懂，也应原样保留，避免凭记忆转述后丢掉关键字段。

在 Windows 与 macOS 上，系统可能要求允许客户端添加网络配置或启用系统扩展。权限被拒绝后，客户端界面仍可能正常打开，但连接核心无法接管流量。重新打开系统的网络、隐私或安全设置，确认相关授权处于允许状态。Linux 环境则要检查启动方式与网络管理权限；如果客户端只能修改界面配置，却没有权限写入系统路由，连接会在建立阶段失败。不要长期用高权限运行所有程序，只应按客户端所需完成必要授权。

确认订阅确实进入了当前配置

订阅导入成功不等于当前正在使用它。很多客户端同时保留本地配置、旧订阅与新订阅，连接按钮可能仍指向之前选中的配置组。打开配置或订阅页面，确认 VPNIJ 订阅处于启用状态，并查看线路列表是否已经出现。若列表为空、更新时间异常或名称仍是旧配置，应先处理订阅更新，不要继续测试连接。获取订阅与客户端应通过用户面板完成，营销页面不会提供静态安装包或真实订阅地址。

测试配置格式时，可以用明显的假地址检查输入位置和导入流程，但该地址不会产生可用线路：

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

如果假地址能被客户端识别为订阅输入，而真实订阅更新时返回错误，问题多半位于登录状态、复制内容、订阅请求或客户端兼容性；如果输入框本身不接受链接，可能选错了“导入文件”“手动添加节点”等入口。回到快速上手教程，按对应平台重新确认导入路径。

用跨地区线路做交叉测试

确认配置加载后，选择另一条不同地区的线路测试。这里强调“不同地区”，是因为同一地区的多条线路可能经过相近的本地网络出口，只在它们之间切换，无法排除当前网络到该地区的路径问题。先断开当前连接，等待客户端状态完全回落，再选择另一地区并重新连接。连续快速点击开关可能留下未完成的连接进程，让新测试受到旧状态影响。

如果某条线路可以连接，说明客户端权限、订阅与基础连接机制大体正常，问题集中在线路选择或当前网络到特定地区的路径。如果所有地区都失败，再切换基础网络做对照。原网络失败、替代网络成功，说明限制更可能来自本地网络环境；不同网络都失败，才继续检查客户端核心、系统代理残留和订阅状态。

清理冲突，而不是立刻重装

同一设备同时运行多个会修改路由、系统代理或网络过滤规则的工具，容易造成端口占用和路由冲突。退出其他网络工具、浏览器代理扩展和具备网络保护功能的软件，再重启 VPNIJ 客户端。仅关闭窗口可能不够，应确认菜单栏、任务区域或后台进程中不再运行。随后检查系统代理是否仍指向已经退出的旧程序；若存在残留，恢复为自动或关闭状态，再由当前客户端重新接管。

重装应放在较后的位置。重装前先导出排查记录，并确认用户面板可以重新获取客户端与订阅。直接删除应用可能保留系统网络配置，也可能清掉有价值的错误记录。更稳妥的顺序是退出冲突工具、重启客户端、重启设备、重新加载订阅，最后才考虑重新安装。若重新安装后所有网络和所有线路仍停在同一错误阶段，应提交工单，并附上平台、网络环境、错误原文、线路名称及已完成的排查动作。

判断结果也应明确：只有部分线路失败，转到线路选择与速度章节；显示已连接但不能访问内容，转到 DNS 与系统代理章节；客户端无法加载任何订阅，转到账户与订阅章节。不要在“完全连不上”这一分支里无限循环。

能连接但打不开网页：检查系统代理与DNS异常

先区分域名失败和连接失败

客户端显示已连接，只能证明隧道或代理核心已经启动，并不代表浏览器、DNS 与目标服务都正确经过这条路径。先访问一个平时稳定的网页，再尝试直接请求一个明确的 HTTPS 地址。如果浏览器提示找不到域名、名称无法解析或 DNS 错误，优先检查解析；如果域名能解析但连接超时，则更接近系统代理、路由或目标服务问题；如果只有某个浏览器失败，应先看浏览器自身的代理与安全 DNS 设置。

可以使用系统自带命令查看域名是否得到响应。示例域名只用于检查命令格式，不代表 VPNIJ 服务地址：

nslookup example.com
curl -I https://example.com

nslookup 返回解析结果而浏览器仍打不开，说明不应继续只改 DNS；此时要检查浏览器是否走了当前系统代理、是否保留旧连接，以及安全软件是否单独过滤浏览器流量。若解析命令直接失败，再处理 DNS 缓存、网络接口和客户端的 DNS 模式。命令输出应保留完整文本，提交工单时比一张被裁切的弹窗更容易判断。

检查系统代理是否指向当前客户端

部分客户端采用系统代理模式，应用需要读取操作系统的代理设置；另一些模式会接管系统路由。若客户端切换过模式，系统代理可能仍残留旧地址，表现为连接后所有网页都超时，退出客户端后也无法恢复。打开系统网络设置，确认代理由当前客户端管理。不要手工抄写客户端界面中的本地地址到多个位置，除非对应文档明确要求；手工配置最容易在端口变化或客户端重启后失效。

浏览器扩展也是常见冲突点。扩展设置可能覆盖系统代理，或者只让浏览器走另一套规则。排查时先暂时停用这类扩展，用浏览器的普通窗口测试，不要用保留复杂扩展状态的会话做唯一依据。若普通窗口成功，逐个恢复扩展；若所有浏览器失败而其他应用正常，检查浏览器安全 DNS、代理扩展和缓存；若所有应用都失败，则回到系统代理与客户端模式。

处理 DNS 缓存与错误接口绑定

设备在连接前后可能保留不同网络环境的 DNS 缓存。切换线路后，旧解析仍被浏览器或系统复用，就会出现部分网站打不开、地区内容没有变化，或者同一域名时好时坏。先完全退出浏览器，再断开并重新连接客户端，让系统重新建立网络接口。必要时使用系统提供的网络诊断或刷新 DNS 功能，不建议从陌生教程复制一长串修改注册表、网络服务或系统文件的命令。

如果设备同时启用了有线网络、无线网络、虚拟网卡或其他隧道接口，DNS 请求可能被发送到错误接口。最简单的验证方式不是删除接口，而是暂时停用当前不需要的连接，只保留正在使用的基础网络与 VPNIJ 客户端创建的接口。恢复后再逐一启用。这样能确定冲突来源，也方便回滚。直接重置全部网络会清除更多配置，不应作为第一步。

局部失败时检查目标服务与地区

某个网站打不开，并不能直接推导为整个连接失效。目标服务可能要求特定地区，可能拒绝当前会话，也可能在浏览器中保留之前地区的 Cookie。先用同一线路打开其他普通网页，再切换另一地区进行对照。若普通网页稳定，只有目标服务失败，问题已经从“网络不可用”缩小为“目标服务与出口地区不匹配”。此时应查看服务器页面了解线路地区，而不是继续修改系统 DNS。

应用内置的安全 DNS、私有解析或网络保护选项，也可能绕开系统配置。排查时暂时恢复应用默认网络行为，重新启动应用后测试。若恢复默认后正常，再根据需要逐项启用功能。切勿在客户端、系统和浏览器三处同时指定不同的解析策略；多层设置不会自动叠加成更稳定的结果，反而让请求路径难以判断。

最终应能把问题归入明确类别：系统代理残留、浏览器覆盖设置、DNS 缓存、接口冲突、线路地区不匹配或目标服务自身异常。若切换网络、线路和浏览器后仍只有同一域名失败，工单中应附域名、发生时间、线路名称、浏览器错误原文和命令输出，但不要提交账户密码或完整订阅内容。

速度慢与晚高峰卡顿：判断瓶颈在哪一段

速度不是线路名称旁的一项固定属性

跨境连接由本地设备、家庭或公共网络、本地运营链路、中转路径、出口地区和目标服务共同组成。任意一段拥塞，用户看到的结果都是“慢”。因此，单次下载、单个视频或某个网站的加载时间不能单独代表线路质量。排查应保持同一设备和同一测试内容，先测断开客户端时的基础网络，再连接线路复测，随后更换不同地区线路。只有这样，才能判断瓶颈是否跟随线路变化。

测试时先停止后台同步、系统更新、云盘传输与其他设备的大流量任务。VPNIJ 支持不限台数，但“不限台数”不等于本地宽带与套餐流量会自动增加。多台设备同时下载时，每台设备都在共享当前网络能力与订阅流量。若只在其他设备忙碌时变慢，应先处理本地竞争，不要把结果归因于远端线路。

用场景而不是单一测速页面判断

测速页面通常选择自己的测试服务器，它与实际目标网站可能位于不同网络。更实用的判断是观察真实任务：普通网页是否能连续打开，长连接是否稳定，视频是否频繁降低清晰度，文件传输是否持续而不是短暂冲高后归零。测试对象必须保持一致，否则不同内容大小、缓存状态和服务端限制会掩盖线路差异。

浏览器缓存也会造成误判。第一次打开需要下载全部资源，后续打开可能直接读取本地内容，看起来像线路突然变快。可以使用无痕窗口或清理特定站点缓存，但不必每轮清空整个浏览器。应用测试则应完全结束后重开，避免复用旧连接。若某条线路网页正常而大文件持续缓慢，可能是路径吞吐或目标服务限制；若所有任务都出现长时间停顿，更像丢包、基础网络不稳或线路拥塞。

晚高峰要做跨地区和跨网络对照

晚高峰卡顿通常需要区分本地接入拥塞与跨境路径拥塞。先在问题时段断开客户端，观察本地网页和普通下载是否也出现波动；如果基础网络同步变慢，优先检查家庭路由、无线干扰和本地网络。若基础网络稳定，而特定地区线路明显变差，应切换到另一地区或另一线路类型。不要只在名称相近的线路之间切换，因为它们可能共享相似路径。

若更换基础网络后同一线路恢复，说明问题更接近原网络到该线路的路径；若不同网络下该线路都慢，而其他地区正常，则问题更集中于线路或目标地区；若所有线路只对某个服务慢，应考虑目标服务自身的地区容量、账号地区或内容源差异。按这个逻辑记录结果，客服才能复现，而不是收到一句无法定位的“晚上很卡”。

无线环境和设备负载不能跳过

设备离路由设备较远、周围无线网络密集、系统正在高负载运行，都可能让加密连接表现得更差。因为加密、分流和传输都需要设备持续处理，老旧设备或省电模式下的性能波动会直接反映在吞吐上。排查时关闭不必要的后台程序，接通稳定电源，使用更可靠的本地网络，然后再比较线路。若同一网络下其他设备正常，问题更可能位于当前设备；若所有设备同步变慢，则应向上检查网络与线路。

选择线路时，不要只追求地理距离。较近地区通常路径更短，但实际质量仍取决于当前网络和目标服务。VPNIJ 提供 120+ 国家与 210+ 线路，适合通过实际场景做少量对照，然后保留表现稳定的常用线路。频繁自动切换会改变出口和会话，某些应用反而需要重新登录或重新建立连接。

如果问题具有明显时段规律，应在正常时段和异常时段分别保留同一套测试记录。工单里附上网络类型、线路名称、目标服务、基础网络是否正常以及不同地区对照结果。不要只附测速截图；路径判断更需要可复现的场景与变化条件。

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

先判断是隧道断开还是应用会话重置

看到应用重新加载，不一定代表 VPN 隧道断开。移动端在锁屏、省电、网络切换或内存紧张时，会暂停后台应用；恢复前台后，目标 App 可能重新建立自己的连接。排查时应同时观察客户端状态：如果 VPNIJ 仍显示连接，普通网页也能打开，而只有目标 App 重新登录，问题更接近应用会话；如果客户端本身回到未连接，才进入隧道断线分支。

还要注意无线网络与移动网络之间的切换。设备离开无线覆盖、网络质量波动或系统自动选择另一连接时，底层地址会变化，已有隧道需要重新建立。短暂重连属于网络切换结果；如果设备静止、网络稳定时仍反复断开，则应检查省电策略、后台权限、客户端模式与线路稳定性。

移动端要允许客户端持续运行

在 iOS 与 Android 上，系统会根据电量、后台活动和应用使用情况管理进程。确认 VPN 配置处于允许状态，并避免把客户端设置为严格受限的后台应用。Android 设备的系统界面差异较大，相关入口可能位于电池、应用管理、后台活动或自启动设置中；目标不是关闭整套系统保护，而是让 VPNIJ 客户端在连接期间保持必要的后台运行能力。

若只在锁屏后断线，先保持屏幕开启完成一轮对照。屏幕开启稳定、锁屏后中断，说明线路本身未必有问题，应优先检查后台与省电。若前台也断线，再切换网络与线路。iOS 上如果系统反复提示添加或启用配置，应确认当前只使用需要的 VPN 配置，避免旧配置与当前客户端同时争用连接。Android 上若其他网络保护应用同时运行，也应暂时退出做对照。

桌面端检查休眠、网络切换和进程状态

Windows、macOS 与 Linux 在休眠唤醒后，网络接口可能重新初始化。客户端界面仍显示旧状态，但实际连接已失效。出现这种情况时，先主动断开，再重新连接，不要直接连续切线路。若每次唤醒都需要手动恢复，应检查系统是否允许客户端在登录后运行，以及休眠后网络是否由系统正确重建。

频繁断线也可能来自多个客户端同时接管系统代理或路由。关闭其他网络工具后，确认系统代理没有指向已退出的进程。若连接建立后过一段时间固定失效，记录失效前设备是否切换网络、进入休眠、启动大型下载或更新系统。关联动作比“用了很久后断开”更有诊断价值。

通过替换变量缩小断线范围

保持同一设备和线路，换一个基础网络测试；再保持设备和网络不变，换另一地区线路测试。若断线跟随基础网络，检查路由设备、网络认证与无线稳定性；若只跟随某条线路，保留线路名称并切换其他地区；若所有网络和线路都只在当前设备发生，应检查系统权限、后台策略与客户端状态。若多台设备在同一网络同步断开，问题更可能位于本地网络或上游路径。

VPNIJ 支持不限台数同时在线，因此不应把正常的多设备使用简单归为设备数量超限。但同一网络中的大量持续传输仍会竞争本地资源与套餐流量。排查断线时暂停其他设备上的高负载任务，确认是否只是连接被拥塞拖慢到超时。用户面板中的套餐状态与流量记录也应一并核对。

什么时候需要提交断线工单

当不同网络、不同地区线路下都能稳定复现，且客户端明确从已连接变为未连接时，应提交工单。附上设备平台、客户端错误原文、线路名称、基础网络类型、断线发生时设备是否锁屏或休眠，以及断线前正在进行的操作。如果问题只在锁屏后发生，应明确写出前台是否稳定；如果只在网络切换时发生，也应注明切换方向和能否自动恢复。

不要发送账户密码、完整订阅内容或包含访问凭据的截图。必要日志应先检查其中是否含敏感字段，只提供与故障时间相邻的连接状态和错误信息。信息完整时，客服可以判断是会话被系统终止、线路连接中断，还是本地网络发生切换，避免重复询问。

订阅更新失败与账户状态排查

先确认登录、套餐和订阅来源

订阅更新失败时，第一步不是反复点击更新，而是登录用户面板确认账户与套餐状态。VPNIJ 无需邮箱地址，使用用户名和密码即可注册。若忘记用户名、密码输入错误或登录状态失效，客户端里的旧订阅可能仍保留，但无法继续获取新配置。先在面板确认能够正常进入账户，再从下载或订阅相关区域获取当前内容。

套餐分为月订阅与流量包。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。排查时应确认当前使用的是哪类方案、状态是否有效、流量是否仍可用，而不是仅凭客户端中残留的线路名称判断。

分清复制错误、请求失败和解析失败

订阅更新过程可以拆成三个阶段：客户端先拿到订阅地址，再向地址发起请求，最后解析返回的配置。地址复制不完整时，通常会立即提示格式错误或请求失败；网络无法访问订阅请求时，会出现超时、连接失败或状态错误；内容已经返回但客户端不兼容时，则可能提示解析失败、配置为空或字段错误。不同阶段的解决办法不同。

重新复制订阅时，应从用户面板使用完整复制操作，不要手工选择一部分文本，也不要把链接发送到会自动截断或改写内容的地方。检查链接前后是否多出空格、换行或标点。不要在工单、公开页面或截图中展示完整订阅内容。若需要说明问题，只保留错误提示和被遮盖的地址开头即可。

如果客户端提供“更新订阅”和“重新导入”两个入口，先尝试更新；更新仍指向旧配置时，再删除对应的失效条目并重新导入。删除前确认面板可以重新获取订阅，避免把唯一可用配置一并清掉。不要删除客户端的全部设置来解决单个订阅问题，除非已经完成备份并确认其他排查无效。

订阅能更新但线路没有变化

这种情况通常与缓存、当前配置未切换或客户端没有重新加载有关。更新后查看订阅的更新时间与线路列表，确认当前选中的配置组就是 VPNIJ。随后断开连接，完全退出客户端再重新打开。若客户端支持多个配置文件，检查活动配置标记，不要只看订阅名称存在。线路列表存在但无法连接时，回到“完全连不上”章节，不要继续在更新按钮上循环。

部分客户端会把订阅分组与本地手动线路混在一起。更新只影响订阅分组，不会替换手动条目。若连接页面仍选择旧的本地配置，更新成功也不会改变实际路径。排查时从配置来源一路追到当前线路：订阅属于哪个分组、分组是否启用、连接页选择了哪条线路、系统代理由哪个客户端接管。链路一致后再测试。

支付状态与连接状态要分开判断

VPNIJ 支持支付宝、微信与 USDT。支付完成后若面板中的订单或套餐状态没有按预期显示，应先保留支付渠道的订单信息，并通过用户面板提交工单。不要重复创建多笔相同订单来测试，也不要通过反复导入订阅判断支付是否成功。支付与配置是不同层级：面板负责显示账户权益，客户端负责读取订阅，两者需要分别确认。

若刚完成套餐升级，应以用户面板中的当前状态为准。中途升级差价折算成剩余天数，不要自行按流量或价格换算有效期。若显示内容与预期不符，把升级前后套餐名称、操作时间和订单状态写入工单，由客服核对。正文中的价格与规则可在套餐页面再次确认。

更新失败工单应提供什么

需要提供设备平台、客户端所处页面、更新动作、错误原文、订阅是否曾经正常、用户面板中的套餐状态，以及更换网络后结果是否变化。若客户端返回状态码，可以原样附上，但不要附完整订阅地址。若问题发生在复制后，说明使用了“更新”还是“重新导入”；若更新成功但列表为空，附上配置页截图并遮盖敏感字段。

当用户面板也无法打开时，应先测试普通网页和其他网络；当面板正常、只有客户端更新失败时，重点检查客户端入口、网络请求和解析；当更新完成、线路存在但不能连接时，转回连接章节。把故障停留在哪个阶段说清楚，通常比重装客户端更快。

某个 App 不走代理：检查应用分流与连接缓存

先证明其他流量确实正常

单个 App 异常时，先用浏览器打开普通网页，再测试另一个联网应用。如果其他流量稳定，说明客户端、订阅和线路至少能够承载部分请求，排查重点应从“线路是否在线”转向应用自身、分流规则和连接方式。若所有应用都失败，应回到系统代理与 DNS 章节，不要在单个 App 的设置里继续深挖。

还要区分“App 没有走代理”和“App 已走代理但目标服务拒绝当前会话”。前者常表现为出口地区没有变化、请求始终走本地路径或只有浏览器有效；后者则可能出现地区不可用、登录状态异常或内容列表未更新。仅凭页面提示无法完全判断，需要切换线路、完全退出 App，并对照浏览器中的相同服务。

理解系统代理、全局接管与规则分流

采用系统代理时，只有遵循操作系统代理设置的应用会自动经过客户端；有些 App 使用自己的网络组件，可能忽略系统代理。全局接管模式覆盖范围通常更广，但仍可能受到系统权限、虚拟接口和应用网络策略影响。规则分流则根据域名、地址或应用决定路径，规则未命中时，目标流量可能直接连接。

排查应先暂时使用客户端提供的更直接模式进行对照。如果直接模式下 App 正常，而规则模式下失败，说明问题集中在分流规则，而不是线路本身。此时检查该服务是否使用多个域名、内容是否来自独立资源域名，以及规则顺序是否让更宽泛的直连条件提前命中。不要随意下载来源不明的规则文件覆盖当前配置，这会引入更多未知条件。

应用内部设置可能覆盖系统路径

部分浏览器、开发工具、下载工具和通信应用允许单独设置代理、私有 DNS 或网络接口。应用内配置的优先级可能高于系统代理，旧地址失效后就会出现“其他应用正常，只有它不行”。打开应用网络设置，先恢复为跟随系统或默认行为，完全退出应用后重新启动。如果恢复默认后正常，再根据实际需要逐项配置。

浏览器还可能启用自己的安全 DNS，开发工具可能读取环境变量，命令行程序则不一定自动使用桌面系统代理。可以检查当前终端环境中是否残留代理变量：

printenv | grep -i proxy

如果输出指向已经退出的旧客户端，应在当前终端会话中清理相应变量，再重新启动命令。不要把真实订阅地址写入环境变量或配置示例。对于需要明确代理参数的程序，应以该程序官方文档和当前客户端显示的本地配置为准，不要从其他设备照抄。

清理应用连接缓存与地区会话

应用通常会复用已经建立的长连接。切换线路后，旧连接可能继续使用原路径，直到应用重启或连接超时。正确测试方式是先退出 App，确认后台进程结束，再切换线路并重新打开。只把应用切到后台通常不足以清理连接。若目标服务根据账户、Cookie 或本地缓存保留地区信息，还需要退出当前会话或清理该服务的站点数据，但不必删除整台设备的所有应用数据。

如果问题涉及 AI 工具，可阅读AI 工具访问专题，了解长连接、登录会话与地区线路的关系。Midjourney 与 Discord 生态的具体线路判断，可参考Midjourney 与 Discord 线路选择指南。这些内容用于解释应用层差异，不替代本章的基础对照步骤。

按结果选择解决方向

若直接接管模式正常、规则模式异常，检查规则匹配与应用域名；若浏览器正常、命令行异常，检查环境变量和程序自身代理支持；若切换线路并重启 App 后恢复，问题多半与旧连接或地区会话有关；若同一 App 在不同设备都失败，而其他服务正常，应关注目标服务状态与地区要求；若只有当前设备失败，则检查该设备的应用权限与本地配置。

提交工单时，应提供 App 名称、设备平台、客户端模式、使用线路、其他应用是否正常、完全重启 App 后是否变化，以及不同地区对照结果。无需提交 App 的账户密码。若涉及分流规则，只提供相关规则片段并遮盖敏感内容，不要上传完整订阅配置。

什么时候找客服，以及如何提交有效工单

哪些情况适合继续自查

现象会随着网络、线路、客户端模式或目标应用设置明显变化时，继续完成一轮对照通常更高效。例如，更换网络后恢复，说明应优先处理原网络；只有特定地区线路异常，可以暂时选择其他地区并记录线路名称；只有单个浏览器失败，则先清理浏览器代理扩展与连接缓存。这类问题已有明确分支，不必在结果尚未固定时立即提交多张零散截图。

如果刚刚修改了很多设置，先恢复到最近一次可用状态，再按本手册的最小改动原则重测。客服无法从“已经试过所有办法”判断具体做过什么。把已执行动作写成清单，并标出每一步之后现象是否改变，信息价值远高于泛泛描述。

哪些情况应直接提交工单

不同基础网络与不同地区线路下都稳定复现同一错误，客户端明确显示认证、配置解析或连接核心异常，用户面板中的订单或套餐状态与操作结果不一致，或者订阅请求持续失败且登录状态正常，这些情况适合提交工单。若支付状态需要核对，也应保留支付宝、微信或 USDT 对应的订单信息，通过用户面板工单入口提交，不要重复支付验证。

VPNIJ 提供 30 天无理由退款。退款规则应以退款政策为准；技术排查工单与退款申请应分别说明诉求，避免一条消息里混合线路问题、账户问题和订单问题。需要比较套餐时，可查看套餐页面，不要在工单中自行换算中途升级后的剩余天数。

工单中应包含的环境信息

一条可处理的工单，应说明设备平台是 Windows、macOS、iOS、Android 还是 Linux，当前使用的基础网络类型，客户端显示状态，订阅是否能更新，线路名称，故障对象，错误提示原文，问题是否能稳定复现，以及更换网络和线路后的结果。VPNIJ 支持这些平台，但平台间权限、代理接管和后台策略不同，只写“电脑”或“移动端”不足以判断。

如果是速度问题，说明基础网络是否正常、是否只有特定地区或目标服务变慢、问题是否与使用时段相关；如果是断线，说明设备是否锁屏、休眠或切换网络；如果是 DNS 问题，附上解析命令与请求命令的完整输出；如果是订阅问题，说明失败发生在复制、请求还是解析阶段。每项都不需要长篇叙述，但必须能还原问题路径。

设备平台：
基础网络：
客户端状态：
订阅状态：
所选线路：
故障对象：
错误原文：
复现过程：
更换网络后的结果：
更换线路后的结果：
已经完成的排查：
期望协助的事项：

截图、日志与隐私边界

截图应包含完整错误提示和必要上下文，例如客户端状态与线路名称。不要只截一个没有标题的弹窗，也不要把多张图片裁成无法判断先后顺序的碎片。日志只需提供故障发生前后的相关片段，并先检查用户名、订阅内容、访问凭据和其他敏感字段。账户密码与完整订阅地址不属于排查材料，任何工单都不需要提供。

命令输出应使用文本或清晰截图，避免重新手打导致字符变化。若错误发生在某个目标域名，可以提供域名和错误文字；若涉及账户订单，则提供用户面板可见的订单状态与支付渠道信息。VPNIJ 的支付方式为支付宝、微信与 USDT，除此之外的付款描述不应作为本站订单依据。

提交后保持测试条件稳定

工单提交后，可以使用已确认正常的其他线路继续工作，但不要不断删除配置、重置系统网络或安装多个客户端。环境变化过大，会让客服给出的判断无法与当前设备对应。若必须继续调整，应在工单中补充改动内容和新的结果，保持时间顺序清楚。

客服要求复测时，应尽量复用最初的设备、网络、目标服务与线路，再按要求替换其中一项。若问题已经自行恢复，也应说明恢复前最后完成的动作，以便判断是网络变化、配置刷新还是目标服务恢复。一次处理完成后，把最终有效步骤保留下来，下次遇到相似现象可以直接从对应层级开始。

整份手册的核心只有一条：先把问题缩小，再处理。完全连不上看权限、订阅和握手；连接后打不开看系统代理与 DNS；速度慢看基础网络、线路和目标服务；频繁断线看网络切换与后台策略；订阅失败看账户、请求与解析；单个 App 异常看分流与应用配置。边界明确后，绝大多数问题都能得到可验证的结论。