VPN故障排查大全

建立可复现的故障诊断方法

网络问题最容易被误判，是因为多个环节会表现出相似现象。客户端显示连接失败，原因可能是本地网络暂时不可用、系统时间不正确、订阅没有更新、线路不可达，或旧的网络扩展仍占用接口。客户端显示已经连接，网页仍打不开，也不一定代表线路失效；浏览器代理、DNS 缓存、分流规则和应用自身的连接复用都可能继续使用旧路径。有效排查不是反复点击连接，而是把完整链路拆开，逐项确认输入、处理过程和输出。

开始前先记录原始状态。写下使用的平台、客户端名称、当前网络类型、所选线路、问题开始出现的大致时间、界面中的完整报错，以及普通网站是否能在断开服务后访问。不要先清空配置，也不要立即重装。原始状态一旦被覆盖，后续就难以判断是订阅内容、系统权限还是线路选择造成的异常。若界面允许复制日志，先保存一份文本；若只能查看报错，保留能看清上下文的截图，但提交前应遮盖用户名、密码和订阅内容。

用对照测试缩小范围

对照测试的核心是一次只替换一个变量。保持同一设备和同一客户端，先更换线路，可以判断问题是否集中在线路侧；保持线路不变，换到另一个本地网络，可以判断当前接入网络是否影响连接；保持网络和线路不变，分别测试浏览器与其他应用，可以判断是否属于单个应用的分流问题。若同时更换客户端、网络和线路，即使恢复，也无法知道是哪项改变生效，下次出现同类故障仍要从头试验。

还要区分“无法建立连接”“连接已建立但没有数据”“部分目标不可访问”和“可以访问但体验不稳定”。这些状态对应不同入口。前者优先查看权限、时间、订阅和协议；没有数据优先查看默认路由、DNS 与系统代理；部分目标异常优先查看规则、地区与应用缓存；体验不稳定则关注丢包、链路拥塞、本地无线环境和后台限制。把“不能用”改写成明确现象，通常已经完成了诊断中最重要的一步。

先保护账户与配置

ZJVPN 无需邮箱地址，使用用户名和密码即可注册，因此用户名和密码是恢复访问的重要凭据。排查时不要把凭据、订阅全文或包含令牌的链接发到公开讨论区。订阅地址的作用接近访问凭证，截图时也要检查地址栏、二维码和日志是否暴露完整内容。示例配置应始终使用明显的假值，例如：

subscription: "https://example.com/sub?token=YOUR_TOKEN"
profile: "diagnostic-copy"
dns-mode: "system"

复制配置做实验时，应保留一份未修改的原始副本，并给实验副本清楚命名。恢复时先退出客户端，再导入原始副本，避免多个网络扩展同时保持启用。若问题在一次系统更新、客户端替换或网络环境变化后出现，也要把这个变化写进记录。变化发生的先后顺序往往比单条错误代码更有价值。

完成基础记录后，再进入对应症状章节。若多个症状同时存在，以最靠前的失败点为准：先解决无法建立连接，再处理连接后的网页与 DNS，最后分析速度和单个应用。底层连接没有稳定之前，上层应用测试的结果通常没有诊断价值。

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

“完全连不上”指客户端无法进入已连接状态，或刚发起连接就立即回到断开状态。这里应先判断失败发生在客户端本地，还是发生在与线路建立会话的过程中。若点击连接后系统根本没有出现网络权限提示，或客户端明确显示权限不足，问题通常停留在设备侧；若连接过程持续一段时间后超时，才更像本地网络到线路之间的路径异常。两类问题的处理顺序不同，不能只靠更换线路碰运气。

确认本地网络与系统基础状态

先断开 ZJVPN，访问平时可以打开的普通网页。若普通网页也不能访问，应先恢复本地网络，因为加速连接依赖现有接入链路。接入页面需要确认条款或完成网页登录时，先在断开状态下完成认证，再回到客户端连接。办公、校园、酒店等网络可能对不同连接方式有各自规则；可在允许的网络环境中换一个接入网络做对照，但不要在问题网络上不断删除订阅，这不会修复底层接入。

然后确认系统日期、时间和时区由系统正常维护。安全连接会校验证书有效期，时间明显偏差可能表现为握手失败、证书错误或连接后立即断开。修正时间后应完全退出客户端并重新打开，让网络组件重新读取状态。若设备刚从休眠恢复，先等待系统网络恢复稳定，再发起连接；休眠前残留的虚拟接口有时会短暂处于不可用状态。

检查系统授权与冲突组件

Windows 与 macOS 需要允许客户端创建或使用虚拟网络接口；iOS 与 Android 会在首次使用时请求建立 VPN 配置；Linux 则要确认客户端具备操作网络接口和路由所需的权限。拒绝过权限后，客户端不一定会再次自动弹出提示，需要进入系统设置检查对应权限。权限开启后，应先断开其他同类网络工具，再测试 ZJVPN。多个工具同时修改默认路由、系统代理或 DNS，会产生“界面都正常、数据却走错接口”的冲突。

检查系统中是否仍运行旧客户端、企业安全接入工具、抓包工具或虚拟机网络组件。无需永久删除这些软件，诊断阶段只要完全退出并确认相关网络扩展不再工作。若退出后可以连接，再逐个恢复，以确定冲突来源。防火墙或安全策略若弹出访问提示，应核对程序名称和来源后按组织规则处理，不应为了测试而整体关闭安全保护。受管理设备上的策略应交由设备管理员确认。

验证订阅、线路与协议

确认客户端中确实存在可选线路，而不是只有一个空配置名称。若线路列表为空、更新时间异常或所有项目同时消失，应先转到订阅更新章节。线路存在时，选择不同地区的线路做对照。ZJVPN 覆盖 90+ 国家 / 200+ 线路，测试的目的不是连续点击，而是观察“所有线路都在相同阶段失败”还是“只有某组线路失败”。前者更可能是权限、订阅或本地网络问题，后者更可能是特定路径问题，可到节点页面了解线路类型和地区选择原则。

客户端若提供不同连接模式，应先使用订阅默认值。不要在不了解含义时手动改写端口、传输方式、加密参数或服务器名称；任一字段与订阅不一致都会让握手失败。曾手工编辑配置的用户，可以新建一个干净配置并重新导入订阅，与旧配置对照。干净配置可连接时，说明故障来自本地修改，不必继续怀疑账户或全部线路。

若连接在一个网络中全部超时，在另一个网络中正常，记录两个网络的类型和失败时间，不要仅写“线路不能用”。若同一网络下其他设备可以连接，而当前设备不行，重点回到权限、冲突组件和客户端配置。若当前设备上所有线路都失败，同时其他设备也在相同网络失败，则本地出口或网络策略更值得检查。这样的交叉验证能明显缩小工单处理范围。

已连接却打不开网页：检查路由与DNS异常

客户端显示已连接，只代表会话已经建立，不代表每一类流量都正确进入该会话。网页打不开时，要继续区分域名解析失败、默认路由未切换、浏览器仍使用旧代理、目标网站拒绝当前地区，还是本地网络本身在切换过程中失去连接。直接断言“节点失效”会跳过大量可验证环节。最有效的方法是分别测试域名、地址、不同应用和不同线路。

先判断是所有目标还是部分目标

打开多个性质不同的普通网页，并同时观察其他应用是否能联网。若所有网页和应用都没有数据，优先查看默认路由、系统代理与 DNS；若只有浏览器异常而其他应用正常，优先检查浏览器代理、扩展和安全 DNS；若只有某个网站打不开，则应考虑目标地区、站点自身状态、缓存和分流规则。不要用单个网站的结果代表整条网络链路，目标服务自身维护也会产生相同表象。

关闭浏览器中的独立代理扩展，再新建隐私窗口测试。部分浏览器会保存旧的连接池，即使系统路由已经切换，现有标签页仍可能复用断线前建立的连接。完全退出浏览器后重开，比反复刷新同一页面更可靠。若隐私窗口可以打开，而普通窗口不行，检查扩展、缓存、站点数据和浏览器自定义 DNS，而不是继续更换线路。

区分 DNS 与路由故障

DNS 的作用是把域名转换为网络地址。解析失败时，浏览器常显示找不到服务器、域名不存在或解析超时；路由故障则更常表现为解析完成后连接超时。可使用系统自带命令查看解析结果。以下命令不包含凭据，可在对应平台的终端中执行：

nslookup example.com

ping example.com

traceroute example.com

在部分系统中，路由跟踪命令名称会不同；如果命令不可用，不必额外安装工具，保留浏览器报错和客户端日志即可。也不要把“目标不回应 ping”直接视为线路故障，因为目标服务器可能不响应这类请求。这里关注的是域名能否解析、请求是否立即在本地失败，以及断开与连接状态下结果是否变化，而不是追求某个固定数值。

如果域名无法解析，而直接访问已知地址可以建立连接，问题更接近 DNS。先退出客户端，再清理系统 DNS 缓存，重新连接后测试。Windows 可在终端使用：

ipconfig /flushdns

macOS、iOS、Android 和 Linux 的 DNS 管理由系统版本、网络管理服务及客户端实现共同决定，不应照抄不适用的命令。通用做法是断开连接、关闭客户端、切换一次网络，再重新建立连接。Linux 用户可以先查看当前解析状态和默认路由，再判断由哪个服务接管：

resolvectl status

ip route

避免多个 DNS 来源互相覆盖

客户端、操作系统、浏览器和本地网络都可能提供 DNS。若浏览器启用了独立安全 DNS，它可能绕过系统分配的解析路径；若客户端启用虚拟 DNS，而系统网络管理服务又在连接变化时覆盖设置，则可能出现刚连接时正常、稍后解析失败。诊断阶段应先减少变量：浏览器恢复跟随系统，客户端使用订阅默认设置，系统网卡不保留以前手工填写且已失效的地址。确认基础路径正常后，再逐项恢复个性化设置。

若仅特定域名解析到异常地址，应清理浏览器缓存与系统缓存，并换线路复查。若不同设备在同一接入网络得到相同异常结果，而换网络后恢复，说明本地解析来源值得重点检查。若同一设备无论使用哪个网络都异常，但其他设备正常，问题更可能停留在当前设备的浏览器、hosts 文件、安全软件或 DNS 配置。

检查系统代理与默认路由

某些客户端通过系统代理转发浏览器流量，另一些通过虚拟接口接管系统路由。客户端异常退出后，系统代理可能残留为已不存在的本地端口，导致断开服务后网页也打不开。此时应在系统网络设置中检查代理是否仍被手工启用。不要随意填写网络教程中的公共代理地址；正常情况下应由当前客户端自动管理。重新打开客户端并正常断开，通常比强制结束进程更容易恢复原设置。

如果连接后只有局域网设备无法访问，而互联网正常，可能是全局路由接管了本地地址。查看客户端是否提供局域网绕过或分流选项，并使用默认规则测试。若互联网和局域网都无数据，则应回到默认路由与虚拟接口检查。受管理网络中的内部域名可能只由组织内部 DNS 解析，连接外部线路后无法解析属于网络边界问题，应向管理员确认可用方式。

速度慢与晚高峰卡顿的分层判断

速度问题不能只看一次测速结果。跨境访问经过本地接入、运营商出口、线路入口、跨区域链路、目标服务和内容分发网络，任一环节变化都可能影响体验。晚高峰卡顿还可能来自家庭无线网络竞争、目标平台繁忙或所选地区距离较远。诊断目标不是得到一个漂亮数字，而是找出瓶颈是否稳定出现、集中在哪类目标，以及更换哪一个条件会改善。

先建立可比较的测试条件

在断开和连接状态下分别访问同一个稳定目标，并保持设备位置、接入网络和测试内容一致。不要一次使用多个测速网站，也不要把不同地区、不同文件和不同时段的结果直接比较。浏览器下载、云同步、系统更新、在线视频和其他设备的大流量任务会抢占本地带宽，测试前应暂停这些活动。无线环境中还要靠近接入设备，排除信号遮挡和频繁漫游。

若断开状态本身就很慢，先处理本地网络。若断开正常、所有线路都慢，并且换接入网络后恢复，问题更可能在原本地出口。若只有某一地区线路慢，换到邻近地区后恢复，可按使用目标选择更合适的线路。若只有某个内容平台卡顿，而普通网页、文件下载和其他视频服务正常，则要考虑目标平台分区、缓存节点和账号地区，不应把问题泛化为全部网络速度下降。

理解延迟、吞吐与稳定性的区别

延迟影响交互响应，吞吐影响持续传输，稳定性则决定连接是否出现抖动、重传和停顿。网页打开慢可能是解析或首个连接延迟；视频起播后频繁缓冲更接近持续吞吐或丢包；远程会议声音断续通常更看重稳定性，而不是短时峰值带宽。单次下载很快，也不能证明实时应用一定稳定。应根据实际场景记录现象，不要只提交一张测速截图。

线路距离通常会影响往返路径。访问日本地区的目标时，选择距离较近且目标可用的地区通常更合理；访问欧洲目标时，近距离入口未必意味着目标端路径最短。ZJVPN 覆盖 90+ 国家 / 200+ 线路，选择时可先参考节点说明中的地区与线路类型，再用实际目标做对照。频繁切换会打断连接池和内容缓存，因此每次更换后应等待应用重新建立会话，再观察一段完整使用过程。

晚高峰问题如何取证

晚高峰问题具有时间相关性，白天提交一张正常结果无法复现。应在正常时段和异常时段执行相同任务，记录线路名称、接入网络、目标服务和大致时间。若异常时段换到另一条线路立即改善，而本地普通网络仍正常，可把两条线路作为清晰对照提供给客服。若所有线路与普通网络都同时变慢，则本地接入拥塞的可能性更高。

不要通过不断刷新大型下载或同时运行多个测速来“压测”线路，这会让本地环境本身成为变量，也可能耗费套餐流量。月订阅流量按开通日每月重置；流量包用完为止且永久不过期。排查前可进入账户概览确认当前使用情况，避免把流量状态与速度故障混为一谈。套餐详情可在套餐页面核对。

流媒体与大文件场景

流媒体应用常会缓存上一次会话的地区和内容分发节点。更换线路后若画质或分区未变化，应完全退出应用，清理适当缓存后重新打开，而不是在播放过程中连续切线。有关平台选择和分区判断，可继续阅读观影解锁专题。若主要问题是 Mac 上的网络扩展、系统权限或 Apple 服务共存，可参考Mac VPN推荐与选购要点中的核对方法。

大文件下载应观察是否持续稳定，而不是只看开始瞬间。下载源可能按账号、地区或服务器限制速度；可用不同来源交叉判断，但不要使用来源不明的测试文件。若浏览网页正常，只有单个下载源慢，优先检查目标端；若多个可靠目标都在同一路线下持续变慢，再将线路、时间和目标类型整理进工单。

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

频繁断线需要先区分主动断开和被动中断。主动断开通常来自系统休眠、网络切换、省电策略、客户端自动规则或用户操作；被动中断则可能来自无线信号变化、本地出口重连、线路会话异常或客户端网络扩展崩溃。两者在界面上都可能只显示“已断开”，但日志中的时间顺序不同。诊断时要记录断线前设备发生了什么，而不仅是断线后的错误。

观察断线触发条件

先判断断线是否与锁屏、休眠、切换无线网络、离开应用、连接外设网络或恢复系统有关。如果每次锁屏后出现，重点检查后台运行和省电限制；如果网络从无线切到移动网络时出现，属于底层接口变化，应观察客户端能否自动重连；如果保持亮屏和网络不变仍周期性断开，则再查看线路、客户端日志与系统网络组件。把触发动作写清，往往比记录断线次数更容易复现。

在桌面平台上，系统休眠会暂停网络接口。唤醒后旧会话可能已经失效，客户端需要重新建立连接。若界面仍显示连接但没有数据，先手动断开再连接，不要立即重启设备。若每次唤醒都无法恢复，检查是否同时运行了其他网络扩展，以及系统代理是否在客户端恢复前被其他程序覆盖。企业设备还可能在唤醒后重新应用安全策略，应结合组织环境判断。

移动端后台策略

iOS 与 Android 会根据电量、内存、网络状态和应用活跃程度管理后台进程。客户端被系统挂起后，界面可能仍保留旧状态，但连接已经需要重建。应在系统设置中允许客户端按正常方式后台运行，并避免把它放入会强制清理的应用列表。Android 设备的厂商省电策略差异较大，应以系统设置中的电池与后台管理项为准；相关基础操作也可参考安卓VPN从安装到验证教程。

不要同时启用多个自动连接规则。例如系统按需连接、客户端启动自动连接和网络切换自动连接若同时生效，可能在接口变化时互相触发，形成连接与断开的循环。诊断阶段先保留一种自动策略，其余暂时关闭。确认手动连接稳定后，再逐项恢复自动化设置。若问题只在特定无线网络出现，检查该网络是否需要重新认证，或是否会在空闲时回收连接。

区分线路断开与本地接口重置

线路断开时，日志通常会出现远端连接关闭、握手超时或重连过程；本地接口重置则更可能伴随网络变更、路由消失、地址更新或系统网络服务重启。普通用户不必解释每条日志，只需保留断线前后的连续片段。不要只截最后一行，因为最后一行可能只是重试失败，真正原因出现在前面。

可在同一网络下更换线路观察。如果所有线路都在锁屏、休眠或网络切换后断开，优先处理系统策略；如果只有某条线路在保持设备活跃时中断，而其他线路稳定，记录线路名称并暂时使用其他线路。若换接入网络后问题消失，重点检查原网络的信号、认证和出口变化。若同一接入网络上的多个设备同时中断，则本地网络或上游路径更值得怀疑。

恢复时避免连接循环

出现连续重连时，先关闭自动连接，手动断开，等待系统网络恢复正常，再重新建立一次连接。不要快速反复点击开关；并发的连接与断开请求可能让界面状态落后于系统状态。若客户端无法停止，先正常退出应用，再从系统 VPN 设置确认配置已经断开。只有在网络接口明显残留且普通网页也受影响时，才考虑重启设备。

如果重启后暂时恢复，但每次运行某个应用或进入某种网络环境后复发，应继续做触发条件对照。重启只是清除了现场，不代表根因已经解决。把“重启可恢复”与“触发后复发”一并写入工单，可以帮助区分资源残留、客户端冲突和线路问题。若系统刚完成更新，也应注明更新前后差异，但不要猜测具体版本缺陷。

订阅更新失败与设备状态检查

订阅更新失败通常表现为无法下载配置、线路列表为空、更新时间不变化、导入后立即报格式错误，或旧线路仍存在但新内容没有出现。这里要区分账户访问、订阅地址、客户端解析、本地缓存和套餐状态。订阅是配置入口，不等同于线路连接；如果连订阅内容都没有正确取得，继续测试线路没有意义。

确认入口和账户状态

先通过用户面板获取订阅，不要使用聊天记录、历史截图或公开页面中保存的旧地址。ZJVPN 无需邮箱地址，用户名和密码即可注册；若忘记登录信息，应按面板提供的账户流程处理，不要重新创建大量重复账户。登录后检查概览和套餐状态，再从客户端下载入口获取适合当前平台的配置方式。

月订阅包括 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包包括 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止且永久不过期。排查时只需确认当前套餐是否处于可使用状态，不应手工换算剩余期限或猜测流量状态。若套餐信息与预期不一致，可先对照套餐说明，再提交订单相关信息。

安全地重新导入订阅

先给当前配置改名或导出备份，再新建一个空白配置导入最新订阅。这样可以判断问题来自旧缓存还是订阅内容。不要直接在旧配置中手工覆盖服务器地址和协议字段，也不要把不同服务的节点合并到同一配置后再要求客服判断。混合配置会让日志无法确认请求究竟来自哪一项。

复制订阅地址时要确认没有多余空格、换行或被聊天软件截断。地址应直接粘贴到客户端的订阅导入位置，不要放进浏览器搜索框，也不要发布到公开页面。若客户端支持扫码导入，仍应确认二维码来自已登录的用户面板。导入失败后保存完整提示，尤其要区分网络请求失败、授权失败、内容为空和格式解析失败，这些提示对应不同处理方向。

若浏览器可以访问用户面板，但客户端更新订阅失败，检查客户端是否被系统代理、DNS 或防火墙单独影响。可先断开现有连接，在普通网络下更新；若必须连接后才能更新，则选择当前可用线路再试。更新成功后，应确认线路列表确实发生刷新，而不是只看到“完成”提示。客户端可能保留旧配置副本，名称相同也不代表内容相同。

缓存、时间与格式问题

系统时间偏差可能导致订阅请求的安全连接失败，与线路握手问题类似。修正时间后完全退出客户端再试。若客户端下载到了网页文本而不是配置，可能是登录状态失效、地址复制不完整或请求被重定向；不要把网页源码当作配置导入。若日志中显示格式错误，先用用户面板重新获取原始订阅，避免手工编辑编码、引号或缩进。

清理缓存应当有边界。优先删除单个订阅的缓存，不要先清除整个客户端数据，因为其中可能包含其他有效配置和规则。需要重装前，先确认用户名与密码可用，并导出需要保留的非敏感设置。重装后只导入一份干净订阅进行验证，确认正常后再逐项恢复自定义规则。

不限台数不等于同一配置可无限复制

ZJVPN 不限同时在线设备台数，但每台设备仍应使用正确的平台客户端和当前有效订阅。出现“设备数超限”一类提示时，不要自行推断是套餐限制，因为事实表明确为不限台数。先确认提示来自 ZJVPN 用户面板、当前客户端还是其他混合配置；旧客户端、其他服务配置或本地规则也可能显示自己的限制文字。保留提示所在界面和配置名称，客服才能判断来源。

在多个设备上同时出现订阅失效时，优先检查账户与订阅入口；只有单台设备失败时，优先检查该设备的缓存、权限和客户端。跨平台导入时不要直接复制某个平台导出的完整本地配置，因为其中可能包含仅该平台可识别的路径、接口名或规则。应从用户面板分别获取适合 Windows、macOS、iOS、Android 或 Linux 的导入方式。

某个 App 不走代理：检查应用分流

只有某个 App 无法访问，而浏览器和其他应用正常，通常不是整条线路失效。常见原因包括应用绕过系统代理、分流规则把域名送到直连路径、应用使用独立 DNS、已有连接没有重建，或目标服务根据账号与地区做额外判断。排查重点是确认这个应用实际走了哪条路径，而不是持续更换账户或线路。

先做浏览器对照

找到该应用对应的官方网站或同一服务的网页入口，在当前线路下用浏览器访问。网页正常而 App 异常，说明基础线路和目标域名至少部分可达，接下来应检查应用自身；网页与 App 都异常，则更可能涉及目标地区、线路、DNS 或服务状态。若应用没有网页入口，可选择同类网络请求作为对照，但不要用完全无关的网站得出结论。

完全退出 App 后重新打开。许多应用会长期复用启动时建立的连接，更换线路后不会立即重建。仅返回桌面不一定代表进程退出，移动端还可能保留后台会话。重新打开后先等待登录状态和内容刷新，再观察错误。若重启应用后恢复，问题属于连接缓存，不必继续改分流规则。

系统代理、虚拟接口与应用绕行

使用系统代理模式时，只有遵循系统代理设置的应用会自动进入代理路径；某些应用会直接建立网络连接，因此浏览器正常而应用直连。虚拟接口模式通常能覆盖更多系统流量，但仍可能受到排除规则、局域网绕过和应用白名单影响。客户端若提供全局、规则或直连模式，诊断阶段可短暂使用覆盖范围更明确的模式做对照，确认后再恢复适合日常使用的规则模式。

不要长期使用全局模式来掩盖错误规则。若全局模式正常、规则模式异常，应查看日志中目标域名匹配了哪条规则。规则集可能因缓存或更新时间不同而未包含新域名，也可能把内容域名与登录域名分到不同线路。应用往往不只访问一个主域名，还会连接认证、接口、图片和媒体域名；只处理主域名可能出现能登录却加载不了内容的情况。

通过日志识别分流结果

打开客户端日志后，清空旧内容，启动目标 App 并复现一次。查找复现时间附近的域名、连接结果和规则名称。日志量很大时，不要复制整天内容；保留启动应用前后连续片段即可。若日志完全没有该应用产生的请求，可能说明应用绕过了当前代理方式，或日志级别未记录流量。若请求出现但被标记为直连，则检查规则；若进入线路后超时，再比较其他线路和目标地区。

time: "REPRODUCE_TIME"
application: "TARGET_APP"
route: "RULE_OR_DIRECT"
result: "COPY_THE_VISIBLE_ERROR"

上面的文本只是整理记录的模板，不是要导入客户端的配置。不要根据网上零散规则直接添加宽泛匹配项，因为过大的域名后缀或进程规则可能让无关应用也改道。修改前保存原规则，修改后只测试目标应用，并验证普通网页、局域网服务和其他常用应用没有受到影响。

账号地区、缓存与目标限制

部分内容服务不仅判断当前网络地区，还会参考账号地区、账单地区、应用商店地区和历史缓存。换线路后仍显示原内容，不一定是分流失败。先完全退出账号与应用，清理适当缓存，再用与目标地区一致的线路测试。涉及流媒体时，可参考流媒体页面中的地区与画质判断；涉及 AI 工具时，可查看AI 工具访问说明。

若应用内嵌网页可以打开，但媒体、上传或实时功能失败，说明不同功能可能使用不同域名或传输方式。应分别记录哪一步失败：登录、列表加载、图片、播放、上传还是实时连接。不要只写应用名称。客服看到具体阶段后，才能从线路日志和规则方向定位，而不是重复建议清缓存。

平台权限与本地网络例外

Android 的按应用代理、iOS 的系统网络扩展、macOS 的网络过滤器以及 Windows 的防火墙规则都可能只影响特定程序。检查目标应用是否被排除、是否只允许在某类网络下访问，以及安全软件是否对它设置了单独规则。Linux 用户还要留意容器、沙箱和命名空间；运行在隔离环境中的应用可能不使用宿主系统的默认代理。

局域网应用通常应保持直连，例如访问本地存储或打印设备。若为解决某个互联网 App 而把全部本地流量强制送入线路，可能导致局域网服务失效。修改规则时应清楚区分目标域名与本地地址。恢复后要同时验证目标应用和局域网，确保解决一个问题时没有制造新的路径冲突。

何时找客服，以及工单应附哪些信息

自查的目标不是让用户独自解决所有问题，而是排除可以快速确认的本地因素，并为客服提供可复现条件。出现账户、订单、订阅入口异常，或完成基础对照后问题仍稳定复现，就应提交工单。有效工单应描述事实、时间顺序和对照结果，不需要猜测技术原因。写“服务器坏了”无法帮助定位；写清某平台、某线路、某接入网络、某目标在什么操作后出现什么错误，处理效率会高得多。

适合立即提交工单的情况

用户面板无法正常显示已生效的套餐、订单状态与支付记录不一致、订阅入口返回明确授权错误，或用户名和密码确认无误但账户流程异常，应直接提交工单。支付方式仅包括支付宝、微信与 USDT；涉及支付时，应提供面板中的订单信息和状态截图，不要发送支付密码、私钥、助记词或完整付款凭据。若需要核对套餐，可先参照套餐页面中的月订阅和流量包说明。

连接问题方面，如果普通网页在断开状态可访问，系统时间和权限正常，重新导入干净订阅后，换线路与接入网络仍出现相同错误，也适合提交工单。若某组线路在多个网络中稳定复现相同异常，而其他线路正常，应把正常线路作为对照写入。速度问题则应至少提供正常与异常时段、目标类型和所选线路，避免只提交一张无法复现的截图。

涉及特定 App 时，先完成浏览器对照和应用重启。若日志显示请求已进入线路，换线路后仍在同一步失败，可提交目标应用、失败功能、目标地区和脱敏日志。若日志中完全没有请求，则更可能是本地分流或代理覆盖问题，应同时说明客户端模式和应用是否被排除。

工单信息清单

可以按以下模板组织工单正文。模板中的大写内容应替换为自己的描述，但不要填写用户名密码、完整订阅地址或其他敏感凭据：

问题类型：CONNECT / DNS / SPEED / SUBSCRIPTION / APP
使用平台：PLATFORM
客户端：CLIENT_NAME
所选线路：ROUTE_NAME
发生时间：REPRODUCE_TIME
问题现象：VISIBLE_ERROR_AND_FAILED_STEP
断开状态：NORMAL_OR_ABNORMAL
更换线路结果：CONTROL_RESULT
更换网络结果：CONTROL_RESULT
已经尝试：ACTIONS_ALREADY_TAKEN
附件：REDACTED_SCREENSHOT_AND_LOG

日志如何脱敏

提交前搜索日志中的订阅地址、token、用户名、密码、二维码内容和本地文件路径。订阅地址应整段删除或替换为“已隐藏”，不要只遮盖末尾，因为前半部分也可能包含账户信息。公网地址是否需要遮盖可根据故障类型判断；若不确定，先在工单中说明已脱敏，由客服再告知需要补充的最小信息。截图还应检查浏览器标签、通知栏、剪贴板浮窗和其他应用窗口。

日志必须保留上下文。只复制“连接失败”一行通常不足以判断原因，应该包含发起连接、选择线路、握手、路由或 DNS 设置到失败的连续过程。也不要上传与问题无关的长期日志，过多内容会淹没关键事件。最好的范围是开始复现前清空日志，执行一次完整操作，失败后立即停止并导出。

客服回复后的验证方式

收到处理建议后，仍应一次只执行一项。若建议重新导入订阅，先保留旧配置，再新建干净配置测试；若建议更换线路，保持网络和目标不变；若建议调整分流，先保存当前规则。恢复后反向验证原来的失败条件，确认问题确实消失，而不是目标服务短暂恢复。将验证结果回复到原工单，避免创建多个内容相同的工单让上下文分散。

如果建议没有生效，直接补充执行结果、时间和新的日志，不必重复提交整段背景。若问题发生条件改变，例如从完全无法连接变成可以连接但 DNS 异常，也要明确说明症状已经变化，并转到对应章节重新做基础对照。故障演变本身就是重要线索。

排查结束后的配置收尾

问题解决后，删除实验过程中创建的无效配置，恢复必要的自动连接和分流规则，并确认系统代理、DNS 与局域网访问都处于预期状态。保留一份干净订阅配置作为基线，但不要把订阅正文存放在公开云文档或聊天群。多个设备使用时，分别确认 Windows、macOS、iOS、Android 和 Linux 上没有遗留冲突组件。

若此次问题与错误配置有关，可以把最终有效的设置名称、处理步骤和触发条件写入自己的维护记录。下次出现相似现象时，先验证是否为同一触发条件，而不是机械重复所有步骤。对长期使用者而言，一份简短、准确、经过验证的本地记录，比收藏大量来源不明的网络教程更可靠。