VPN故障排查

完全连不上：先检查网络与配置

分清是本地断网，还是代理连接失败

先断开客户端连接，暂时关闭客户端的自动重连，再访问平时可以直接打开的网站。如果此时同样无法访问，问题尚未进入国际线路这一层，应先完成无线网络认证、检查路由器联网状态，或处理当前网络的访问要求。酒店、学校和公共网络可能需要先打开认证页面；在认证完成前反复换线，通常无法改变结果。

如果直接访问正常，再打开客户端，记录连接按钮按下后发生了什么。始终停在连接中、立刻返回未连接、显示配置错误，以及出现连接成功但网页失败，属于不同分支。不要只记录“不能用”。客户端能否完成连接，与浏览器能否使用这条连接不是同一件事；已经显示连接成功的情况，应继续看下一章。

确认账户、套餐与线路列表

进入账户概览，核对套餐状态和剩余流量，再回到客户端手动更新订阅。月订阅流量按开通日每月重置，不能只根据自然月已经变化来判断是否应当恢复。付款页面显示完成，也不等同于客户端已经载入最新配置；面板与客户端应分别核对，避免拿旧列表重复尝试。

检查当前选择的是否为刚更新的订阅分组，而不是历史导入的同名配置。若列表为空、线路名称明显停留在旧记录，先处理订阅问题，不要手动猜测服务器地址或修改认证字段。若列表正常，选另一条线路测试，并保留原线路名称。线路类型与地区的区别可查线路说明，不要仅凭名称相近认定它们使用相同路径。

检查权限与同时运行的软件

首次启用时，系统可能要求允许创建 VPN 连接、安装网络扩展或授予网络管理权限。若曾经拒绝，客户端界面可能仍然可以浏览线路，却无法建立系统连接。进入系统网络与权限设置，确认该客户端获得必要授权。单位管理的设备可能由组织策略控制，应联系设备管理员核实，而不是持续提升权限或关闭管理组件。

同时退出其他正在接管网络的软件，包括其他 VPN 客户端、代理工具与网络调试代理，再重新测试。它们可能争用系统代理、路由或虚拟网卡，使界面看起来正常而实际流量走向冲突。先退出应用并观察变化，不要直接卸载所有软件；尤其不要关闭整套系统防护来代替诊断。若防护软件有拦截记录，应针对记录核对受影响进程。

用可恢复的对照缩小范围

在条件允许时，用同一设备切换另一种本地网络，保持客户端配置与所选线路不变。如果更换网络后恢复，优先排查原网络的认证、接入策略或路由器设置；如果始终失败，再用另一条线路比较。设备、网络、线路同时改变会丢失判断依据，因此每完成一项都要记下结果，再继续下一项。

错误中若包含证书、握手或时间相关描述，检查系统日期、时区和自动校时状态。时间明显不正确可能使正常证书验证失败。不要通过忽略证书错误来长期维持连接，也不要从陌生来源导入证书。若只有某条线路持续出现同一错误，而其他线路可用，保留报错原文，交由支持人员核对线路配置更合适。

已连接却打不开网页：检查分流与 DNS

连接状态并不代表请求已经进入代理

客户端显示已连接，通常只能说明某个连接环节已建立，不能证明浏览器请求已经经过该连接。先分别访问直接可用的网站与目标网站，观察是否全部失败。如果直接网站正常、目标网站失败，重点检查规则匹配、目标服务和出口；如果所有网页都失败，则需要检查系统代理、DNS 与路由设置，避免只围绕目标网站排查。

打开客户端的请求记录，刷新目标网页，查看是否出现对应域名。若没有记录，浏览器可能使用了自己的代理设置、扩展或现存连接，也可能根本没有经过当前客户端。先退出浏览器并重新打开，暂时停用负责代理的扩展，再按客户端说明启用系统代理。不要直接清除全部浏览数据，以免增加重新登录和验证的干扰。

把域名解析与网页连接分开看

DNS 用于把域名解析为地址，解析成功之后仍需建立连接。因此，域名能解析不代表网页一定可用，网页打不开也不一定是 DNS。错误提示包含找不到主机、域名不存在或解析超时，才更接近解析层问题；若提示证书异常、连接被重置或访问被拒绝，应保留原文，继续检查后续环节，不要全部归为解析故障。

桌面系统可以用下面的命令查看系统解析器是否返回结果。示例域名只用于检查基本解析过程，不代表目标服务的实际访问表现。运行后记录是否得到地址、是否超时，以及输出中是否有明确错误即可。客户端可能使用独立的 DNS 路径，因此系统命令正常而浏览器失败时，还应对照客户端日志，不能仅凭命令结果排除问题。

nslookup example.com

核对浏览器与客户端的解析路径

浏览器的安全 DNS、系统 DNS、客户端内置解析与路由器设置，可能同时参与请求处理。先记录当前配置，优先恢复客户端文档建议的默认方案，再逐项比较。不要把搜到的公共解析地址全部填进去；解析器之间路径不同，混合设置可能让结果更加不一致。公共网络还可能要求使用其认证流程提供的解析服务，应先完成认证。

如果浏览器开启了独立的安全 DNS，可临时切换为使用系统解析做对照，测试后恢复原设置。若改变后只有该浏览器恢复，应检查它的解析路径与代理是否匹配，而不是修改整台设备的路由。若所有应用都受影响，则回到系统和客户端层面。改变设置后，应重新打开目标应用，使新请求使用新的解析结果。

缓存与残留代理的处理边界

缓存可能保留旧的解析结果，但清缓存应放在路径检查之后。先关闭浏览器及目标应用，按当前系统的官方方法刷新解析缓存，再重新连接验证。若退出客户端后所有网页仍失败，检查系统是否残留指向本机的手动代理；应通过客户端正常关闭系统代理，再退出应用。不了解来源的代理设置先截图记录，避免误删单位配置。

如果更换网络与线路后，只有同一域名持续解析异常，或客户端显示请求已进入代理但网页仍反复失败，可提交目标域名、错误原文和脱敏日志。不要把含私人路径、查询参数或登录信息的完整网页地址直接发出。若目标网站明确显示地区或账户提示，应转入应用访问分支，而不是继续清空 DNS 缓存。

速度慢：区分带宽、响应与应用瓶颈

先描述慢在什么环节

“速度慢”需要拆成更明确的表现：网页迟迟没有响应、图片逐渐出现、文件传输速度不稳，或者会议声音断续。前者可能与解析和连接建立有关，持续传输则更依赖本地带宽、线路路径与目标服务器。先确定哪类操作变慢，再选用相同操作对照。仅凭某个测速页面的结果，无法解释所有应用的体验，也不能代表每个目标网站。

在断开代理后检查直接访问是否同样变慢，并暂停云盘同步、系统更新和大文件传输。家庭网络中的其他设备也可能占用上行或下行资源。不要因为套餐流量还很多，就排除本地拥塞；可用流量是使用额度，与当前网络能提供的传输能力不同。若本地访问已经卡顿，应先处理接入网络，再比较国际线路。

保留目标，只改变线路或网络

选择一个能够稳定复现的目标页面或任务，保持设备、应用和本地网络不变，仅切换线路。比较首屏是否更快出现、传输是否持续、交互是否稳定，而不是只看一次瞬时峰值。相邻地区未必拥有相同路径，同一地区的不同线路类型也可能表现不同。具体类型可参考服务器目录，目录是选择范围，不是速度保证。

若切线没有明显区别，再保持线路不变，更换本地网络做比较。有线网络可帮助排除无线信号与干扰，但需要设备条件允许。无线环境中，远离路由器、隔挡较多或接入设备繁忙，都可能产生抖动。测试时不要一边移动设备一边切线，否则网络环境变化会掩盖线路差异，得到的结论难以复现。

理解 IEPL、中转与直连的取舍

IEPL 专线、中转、直连描述的是路径组织方式，不能直接换算为固定速度排序。实际体验还取决于本地运营商、入口可达性、出口位置与目标服务的接入方式。选择时应从当前目标出发：办公关注持续交互与会议稳定，流媒体关注持续缓冲，文件传输关注长连接表现。不要把线路类型名称当成适用于所有网络的结论。

同一目标在不同时间也可能由不同内容分发节点响应。浏览器缓存、网站限速和服务器繁忙，都会让比较出现偏差。若其他网站正常而某个下载持续缓慢，应先核对目标服务本身的限制，再尝试同地区另一条线路。频繁更换国家可能触发账户的额外验证，还会改变内容分发路径，反而降低对照结果的可解释性。

检查客户端与设备负担

观察设备是否同时进行高负载任务、是否处于节能模式，以及客户端是否持续出现重试或解析错误。较高的系统负担可能使网页与网络处理一起变慢，这时线路并非唯一原因。先暂停非必要任务，保持默认配置复测。不要直接照搬所谓提速参数，尤其是并发、连接复用与网络栈设置；参数是否适用取决于具体客户端实现。

如果问题只在开启某种接管模式时出现，记录模式名称与变化，而不是立即认定必须重装系统。虚拟网卡、系统代理和应用专用代理的接管范围不同，也可能与现有安全软件产生交互。恢复之前可用的模式能够帮助验证原因，但不应关闭必要的访问控制。单位设备应由管理员确认网络软件之间的兼容关系。

需要支持人员介入时，说明慢的具体任务、目标域名、出现时段、当前线路与已做的对照。能够说明“同一网络下其他网站正常，只有此目标持续缓冲”，比只附测速截图更有价值。若问题具有明显的时间规律，继续阅读晚高峰章节；若传输中连接直接断开，则应按断线问题处理。

晚高峰卡顿：建立同条件对照

确认问题是否确实随时段变化

晚间体验变差并不自动证明某条线路拥塞。家庭网络使用增加、无线干扰变化、目标服务繁忙，以及本地运营商路径变化，都可能集中出现在相近时段。先保留一组平时可用的配置，再在问题出现时重复同样任务。只有设备、网络、目标和线路大致一致，时段差异才有参考意义；临时更换全部条件，很难定位原因。

记录卡顿开始与恢复的大致时间，并区分整个会话都不顺畅，还是偶尔停顿后继续。持续带宽不足与短时抖动的处理方向不同。视频能逐渐缓存但会议反复断句，可能说明交互任务更容易暴露网络波动；也可能是应用采用了不同路径。不要用视频能够播放，直接证明会议软件不应存在网络问题。

先看本地网络，再看国际路径

问题发生时，先检查直接访问和局域网使用是否也受影响，暂停其他设备的大文件任务，并尽量在固定位置测试无线网络。如果换成有线后明显改善，应优先调整本地无线环境。如果同一设备换另一种接入网络后恢复，而线路保持不变，则应把原网络的接入质量与路径作为主要线索，不必继续反复导入订阅。

如果直接访问正常，只有国际目标变慢，再选择不同路径的线路对照。为了减少地区与内容分发差异，先比较同地区的其他线路，再考虑其他地区。每次切换后重新建立目标应用的会话，因为旧连接可能继续沿原路径运行。只看客户端中的线路名称变化，而不重新打开目标任务，可能会把旧会话的表现误认为新线路结果。

会议、文档与视频采用不同观察方式

视频任务可以观察缓冲是否持续补充，会议则应关注声音是否连续、画面是否间歇冻结，在线文档还要关注输入后同步是否及时。不要在正式会议进行中反复切线来做实验，切换本身可能使连接中断。先在会前用不涉及敏感内容的测试会话确认可用路径，并保留已经验证过的备选线路，需要时再有计划地切换。

若使用远程办公工具，还应留意组织代理、企业 VPN 和安全网关是否参与连接。某些业务必须经过组织网络，公共代理不应替代单位要求的访问方式。可以向管理员说明时间规律和错误表现，核对组织策略是否变化。相关选择思路见远程办公选线指南，但具体环境仍以组织规定和实际验证为准。

避免把临时有效的调整当成长期结论

降低视频画质、暂停同步或换用已验证的路径，可以作为当前任务的应急处理，但它们只是减少需求或改变路径，并未直接说明故障根因。任务结束后，仍应恢复到可比较的条件继续观察。不要为了追求某次测试结果而批量修改 DNS、连接参数与路由规则，否则下次发生问题时，将难以知道是哪项调整影响了结果。

当相同问题在固定时段重复出现，并且本地网络对照不能解释时，可把记录提交支持人员。说明受影响线路、目标服务、时间范围以及其他线路是否正常。支持人员据此才能核对相关路径；单独描述“晚上都很慢”缺少边界。若问题只出现于单个应用，且换时段也存在，应继续检查应用分流，而不是把全部现象归入晚高峰。

频繁断线与后台掉线：检查系统接管

区分连接断开与应用会话结束

先观察发生异常时客户端是否真的变为未连接，还是客户端仍在线但会议、聊天或网页会话结束。前者优先检查本地网络切换、进程存活和系统权限；后者还要检查应用自身的超时、认证与规则。重新打开客户端后立刻恢复，也不必然说明线路恢复，可能只是系统唤醒了后台进程。应把切到前台前后的状态一起记录。

留意断线是否发生在锁屏、合盖、切换无线网络、设备休眠或电量较低之后。网络接口切换时，原有连接可能需要重新建立，应用未必会立即重试。先在保持屏幕开启、固定网络的条件下测试，再与锁屏情况比较。不要通过永久关闭设备锁定来规避问题；锁屏只是诊断条件，不应牺牲设备的日常安全设置。

Android 的后台限制与 VPN 授权

在 Android 的应用设置中，核对客户端是否允许后台运行、是否被电池优化限制，以及系统是否在清理后台时结束其进程。不同设备的菜单名称可能不同，应按当前系统说明寻找对应选项。只对确有需要的客户端调整权限，不必把所有应用都改为不受限制。若设备有工作资料或组织管理策略，也要确认其允许当前 VPN 配置运行。

检查是否有其他应用在后台请求建立 VPN。系统 VPN 接管可能因新的连接请求而改变，导致原客户端失去接管权。先退出其他同类网络应用，再验证锁屏后是否仍断线。初次导入与权限流程可参考安卓订阅导入与验证教程；如果导入已完成，本章重点是进程与权限，不必重新创建账户。

iOS 与桌面系统的差异

iOS 上应检查系统 VPN 状态、客户端配置与设备管理要求是否一致，避免同时保留多个自动连接配置相互切换。不要把其他平台的省电菜单名称套用到 iOS。若恢复应用后出现新的授权提示，应核对来源并按客户端说明处理。若只在网络切换后短暂失败，可先手动重连，观察后续是否持续稳定，再判断是否需要进一步排查。

Windows、macOS 和 Linux 还应检查睡眠与唤醒后的网卡状态。合盖可能使系统进入休眠，网络任务随之暂停，这与客户端在正常运行中意外退出不同。唤醒后若直接访问也不可用，先恢复本地网络；若只有代理失效，再重新建立客户端连接。不要仅为解决唤醒问题修改不熟悉的系统服务或删除网络驱动。

保留断线前后的连续证据

日志应覆盖断线之前和之后，而不是只截重新连接成功的一行。重点保留网络变化、进程退出、权限失效与连接重试等提示。若只有某条线路在前台固定网络下持续断开，换线后恢复，则更接近线路或路径问题；若所有线路都在锁屏后失败，则更接近设备后台策略。这样的分支能避免把设备问题与服务问题混在一起。

适合提交工单的情况包括：权限已经核对、没有其他客户端争用，仍在正常前台使用中反复断开；或网络切换后始终无法恢复，必须重启应用。请说明设备平台、是否锁屏、是否切网、是否经过休眠，以及重连后能维持什么状态。不要用反复重装代替记录，因为重装会清除有价值的配置和日志线索。

订阅更新失败：核对来源与格式

先区分获取失败与解析失败

订阅更新包含获取内容与读取内容两个环节。获取失败常表现为超时、连接错误或访问被拒绝；解析失败则通常意味着已经拿到内容，但客户端不能把它识别为有效配置。先记录完整错误描述，再决定检查网络还是配置格式。不要看到更新失败就删除现有订阅；如果原配置仍能使用，它可以帮助恢复访问，也保留了比较依据。

进入用户面板确认当前账户与套餐状态，再从面板提供的入口重新获取适用于当前客户端的订阅。订阅需登录后获取，不应从公开文章、群消息或他人的截图复制。不同客户端支持的导入格式可能不同，使用面板对应入口比手动修改地址参数更可靠，也能减少复制错误造成的干扰。

核对复制内容，不公开订阅地址

复制时可能混入空格、换行、引号或说明文字，也可能复制成登录页面地址。可以在本地检查内容是否完整，但不要把真实地址粘贴到公开网页、在线转换工具或陌生诊断服务。订阅地址属于需要保护的访问材料。向支持人员说明来源页面和导入方式通常已足够，只有在受控支持流程明确需要时，再按指引处理相关信息。

如果曾经重置订阅凭据，历史保存的地址可能失效，应更新客户端中的来源，而不是只对旧地址继续点刷新。若在不同设备上维护了同一账户，也要分别核对它们当前使用的来源。浏览器书签、剪贴板历史与旧笔记容易保留过期内容；不要因为地址外观相近，就认为它们仍然具有相同状态。

检查更新请求实际走的网络

某些客户端允许订阅更新请求通过代理，另一些使用系统网络或独立设置。如果当前线路已经失效，而更新请求又必须经过它，就可能形成无法自我恢复的循环。按客户端说明检查更新请求的路径，在本地网络正常的前提下尝试合适的方式。调整前记录原设置，完成后再验证线路列表，不要同时改动所有网络选项。

如果返回内容看起来像网页，可能是网络认证页、登录页或错误页面，而不是订阅配置。公共网络未完成认证时尤其需要留意。不要把网页文本保存为配置强行导入，也不要通过忽略证书验证获取内容。先完成网络认证、核对面板入口，再重新更新。若错误持续出现，记录响应类型与提示即可，不必公开整段返回内容。

导入成功后还要确认选中与持久化

导入成功不代表客户端已经切换到新配置。查看当前激活的配置名称、线路列表和更新时间，确认新订阅已经启用。如果存在同名分组，先用易辨认的本地名称区分，再进行连接验证。某些应用会保留手动选择的历史线路；新配置中该线路已变化时，需要重新选线。不要只凭成功提示就认定后续连接使用了新内容。

如果应用重启后配置消失，或每次导入都无法保存，检查本地存储权限、应用数据位置与设备管理限制。这类现象更接近客户端持久化问题，不是订阅服务器无法提供内容。桌面系统不要随意以不同账户交替运行客户端，否则可能看到不同的配置目录。清理工具若会删除应用数据，也应检查其规则后再做对照。

当面板能够正常访问，重新获取的正确入口仍在不同网络中更新失败，或客户端持续报告格式错误时，应提交工单。附上客户端名称、系统平台、错误原文、导入方式，以及其他设备能否更新。若只有某个客户端失败，明确这一范围；若账户状态与预期不符，同时说明面板显示的情况，避免把计费与解析问题混为一谈。

某个 App 不走代理：检查接管范围

浏览器可用，不代表所有应用都被接管

系统代理通常供愿意遵循系统设置的应用使用，但并非所有软件都会读取它。某些应用使用独立网络栈、自带代理选项或直接连接方式，因此浏览器正常不能证明该应用也经过客户端。先确认问题是否仅出现在单个应用，再打开客户端请求记录，观察启动应用和执行目标操作时是否出现相关连接，避免直接把它判为线路失效。

如果没有记录，先检查应用自己的代理设置、客户端的接管模式与进程排除规则。若记录存在，再查看实际命中的策略与所选出口。应用可能同时连接登录、内容、更新和通知等不同域名，只验证首页域名可能不足以解释功能失败。应围绕发生问题的具体操作观察，不要在不了解用途时把所有域名都改成同一策略。

用临时模式对照规则问题

在个人设备且符合使用环境要求的前提下，可以短暂切换客户端支持的代理模式做比较。若改变模式后应用恢复，说明原规则或接管范围值得检查，而不是证明应长期让全部流量使用同一路径。完成测试后恢复原模式，再针对目标域名、进程或规则顺序调整。涉及单位内网、局域网设备与业务系统时，应先确认组织要求。

规则通常有匹配顺序，宽泛规则可能先于具体规则生效。修改前记录目标连接实际命中的条目，避免仅凭规则文件中“已经存在该域名”就认为配置正确。订阅更新也可能替换部分规则，本地修改应按客户端支持的覆写或自定义方式保存。不要直接改动难以维护的生成配置，否则下一次更新后问题可能重新出现。

注意长连接、UDP 与缓存会话

部分应用会长时间保留连接，客户端切线后，原会话未必立即迁移。退出应用并确认后台进程结束，再重新打开验证，通常比只刷新界面更有判断价值。需要保留工作的应用应先保存内容，避免结束进程造成数据丢失。如果重新启动后恢复，继续观察是否只在切线后复现，而不是马上把问题归为账号或目标服务限制。

会议、语音和实时协作可能使用与网页不同的传输方式。若网页功能正常而通话异常，应核对客户端是否支持并启用了该应用需要的流量接管，同时检查本地网络策略。不要照搬不明来源的端口清单或放宽整套防护规则。对于组织管理的会议系统，优先参考其官方网络要求，并让管理员确认允许的连接方式。

区分网络不通与服务拒绝访问

如果应用已明确返回地区、账户、支付或验证提示，说明请求可能已经到达目标服务，继续修改 DNS 不一定有帮助。ChatGPT、Claude、Gemini 等工具的可用性还受目标服务的地区与账户政策影响；流媒体也可能按内容和账户状态判断访问。线路覆盖不等于对每个第三方服务作固定可用承诺，应以目标服务当前规则和实际结果为准。

测试时先保持出口地区稳定，再比较同地区其他线路，避免频繁跨地区引入额外验证。若同一账户在浏览器可用而应用失败，也要检查应用自身缓存、授权会话和官方状态说明。不要为了诊断把个人账户交给他人登录。AI 访问场景可查AI 加速专题，其中的选线思路应与本章的接管检查一起使用。

需要工单协助时，提供应用名称、受影响功能、系统平台、客户端模式、目标域名及规则命中结果。截图应遮住对话内容、个人资料和访问凭据。若问题只在某种接管模式下出现，明确正常模式与异常模式的差异；若目标服务已有明确拒绝提示，保留提示原文。这样的材料比整份规则文件更容易定位，也减少不必要的信息暴露。

对于 Windows 桌面应用，系统代理、托盘常驻和开机自启之间的关系还可参考Windows 全局代理与分流指南。本章只处理运行中的流量去向，不把开机启动成功视为连接验证完成；每次更改启动方式后，仍需检查当前配置和目标请求是否真正生效。

设备提示与工单：整理可复现证据

看到设备数超限，先核对提示来源

I8VPN 同时在线不限台数。如果界面出现设备数超限，不应直接理解为需要购买更多设备名额。先确认提示来自 I8VPN 用户面板、客户端本身，还是正在访问的第三方应用。第三方账户可能有自己的会话管理规则，设备系统也可能限制特定网络配置；这些限制与本服务的同时在线政策不是同一件事。

记录提示出现的位置、完整文字与触发操作，再核对当前登录账户和实际启用的订阅。历史配置、其他服务的订阅或客户端自身的账户功能，都可能让提示来源混淆。不要为了排除问题而批量退出全部设备或公开账户资料。如果确认提示来自本服务相关流程，提交截图与复现步骤，请支持人员核对，不必自行推测额外收费条件。

把排查过程压缩成清晰记录

有效工单应先写预期结果与实际结果。例如，预期是开启客户端后目标网页正常加载，实际是客户端已连接但浏览器报告解析超时。接着说明发生时间与时区、系统平台、客户端名称、本地网络类型、线路名称和当前模式。最后写已经尝试的调整及其结果，特别标明哪些条件未变，帮助支持人员理解对照是否成立。

错误原文比概括更有价值，但不需要粘贴整份日志。截取与发生时间相关的前后片段，保留错误类别和顺序，遮住订阅地址、登录凭据、个人目录与无关访问内容。I8VPN 采用无日志策略；用户主动提交的诊断材料仍应遵循最小必要原则。策略说明不意味着可以不经检查就把设备上的所有记录发送出去。

什么情况应停止自行修改

当操作开始涉及删除系统网络组件、导入未知证书、修改组织管理策略或放宽整套安全规则时，应停止尝试并寻求适当支持。这些操作可能影响与本问题无关的应用，也会破坏原本可用的环境。若设备属于单位，先联系管理员；若是某条线路持续报错而其他线路可用，可保留可用路径，把异常线路的证据提交本服务处理。

如果已经做过较多修改，先列出改动清单，按可确认的顺序恢复，而不是继续叠加“修复工具”。恢复客户端默认设置前，应保存必要的本地规则并注意备份中的敏感信息。重置系统网络属于影响范围较大的操作，不宜作为首步。无法确认修改影响时，说明当前状态与已做操作，比声称全部按默认配置更有助于排查。

计费与连接问题分开处理

月订阅流量按开通日每月重置，中途升级差价折算成剩余天数；流量包用完为止，永久不过期。若客户端连接异常同时伴随流量不足提示，应先在面板核对额度与套餐状态，再决定是否需要调整使用方案。具体价格与计费方式以套餐及流量包说明为准，不能用重复付款代替网络诊断。

本服务提供 7 天无理由退款，完整条件见使用条款。排查过程中如需处理订单或退款，请在工单中明确说明诉求，并提供必要的订单识别信息，不公开完整支付凭据。支付方式为支付宝 / 微信 / USDT；不要把第三方应用要求的付款方式与本服务混淆，也不要根据某个网页提示推断订单已经失效。

恢复后保留最小可用基线

问题解决后，记录有效线路、接管模式、必要权限和修复原因，删除测试时不再需要的临时规则，并恢复为日常使用配置。随后验证直接访问、目标应用、锁屏恢复与订阅更新，确认修复没有引入新的问题。记录应保存在个人可控的位置，不含完整凭据。今后再次异常时，用这份基线对照，比从头尝试陌生参数更可靠。

如果尚未完成初次配置，返回快速上手教程继续主线；如果只需要简短问答，可查帮助中心。本页的目标是把“不能用”拆成明确边界：哪台设备、哪种网络、哪条线路、哪个应用、什么操作会失败。边界越清楚，越容易选择下一步，也越能减少不必要的改动。