VPN 问题诊断手册

先建立诊断基线

把“不能用”拆成可以验证的现象

“连不上”“很慢”“某个应用不能用”是结果描述，不是故障位置。开始操作前，先写下客户端显示的状态、问题出现在哪个网络环境、哪些网站或应用受影响、切换线路后是否变化，以及同一设备在未连接状态下能否正常访问普通网页。客户端停留在正在连接，通常属于握手、协议或网络入口问题；客户端显示已连接但域名无法打开，更接近 DNS、系统代理或规则问题；只有视频缓冲或文件传输慢，则应检查线路质量、目标服务和本地链路。

还要区分“所有目标都失败”和“单一目标失败”。前者优先检查连接状态、系统代理、默认路由和 DNS；后者优先检查应用是否遵循系统代理、目标服务是否限制当前出口地区，以及规则是否将该域名错误地分到直连。若只有一台设备异常，而同一订阅在其他设备正常，问题大多位于该设备的客户端配置、权限或系统网络栈，不应立即更换套餐。

先保留证据，再执行清理操作

不要一开始就删除客户端、清空配置或重置系统网络。彻底清理会同时消除日志、错误提示和可对照的配置，使后续只能凭感觉猜测。更稳妥的顺序是：截取客户端状态页和错误信息，记下当前线路名称与协议，导出不含凭据的诊断日志，然后复制一份当前配置。完成这些动作后，再测试切换线路、重启客户端或刷新订阅。

日志中若包含订阅地址、访问令牌、用户名或其他认证信息，提交前应遮盖对应内容。客服通常需要错误类型、发生时间、平台、客户端界面状态、线路名称和复现步骤，不需要完整凭据。示例订阅地址应使用明显的假值，例如：

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

用最小变更法建立对照

测试时先保持设备和网络环境不变，只替换一条线路；若结果没有变化，再保持线路不变，只切换协议；随后才考虑更换网络环境。一次同时换线路、协议、客户端和网络，即使恢复，也无法知道是哪项操作生效。以后再出现同类问题，仍然需要从头试错。最小变更法看似较慢，实际能明显减少重复操作。

若问题可以稳定复现，记录完整路径，例如“启动客户端、选择某条线路、点击连接、客户端显示已连接、浏览器打开测试域名失败”。这种描述比“今天一直不能用”更有诊断价值。若问题无法稳定复现，则记录发生前后的网络切换、睡眠唤醒、客户端后台状态和线路切换动作，帮助判断是否属于系统生命周期问题。

完全断连的排查顺序

先确认基础网络和系统时间

客户端完全无法建立连接时，先退出连接状态，用浏览器访问日常可用的网站。如果普通网页也无法打开，应先恢复本地网络；此时反复切换 VPNHG 线路不会改变结果。无线网络处于已连接状态并不代表已经取得可用的互联网出口，公共网络还可能要求在浏览器中完成确认。先完成网络本身的接入流程，再启动客户端。

系统时间明显不正确也会使加密握手失败。证书校验和部分协议需要依赖当前时间，设备长时间关机、时区配置异常或系统时间未同步，都可能表现为连接立即失败。将日期、时间和时区恢复为系统自动管理后，彻底退出客户端并重新打开。这里的“彻底退出”不是只关闭窗口，而是确认托盘、菜单栏或后台进程已经结束。

用线路和协议构造交叉测试

在基础网络正常的前提下，先从节点页面了解 IEPL 专线、中转和直连的用途，再选择不同地区、不同线路类型进行交叉测试。若只有单条线路失败，而其他线路能够连接，问题更可能局限在线路或当前入口；若所有线路都在同一设备失败，但其他设备正常，应回到该设备检查客户端权限、系统代理和网络扩展。

协议切换也应遵循单变量原则。保持线路不变，在客户端支持的 Shadowsocks、VMess、Trojan 或 Hysteria2 之间切换，观察失败发生在“立即返回错误”还是“等待后超时”。立即失败常见于配置未加载、权限被拒绝或协议参数不匹配；等待后超时则更接近网络路径不可达、入口受限或握手数据未返回。不要依据协议名称判断快慢，当前网络能否稳定完成连接更重要。

检查客户端权限与冲突进程

桌面系统通常需要创建虚拟网络接口、修改系统代理或写入路由表。安装后首次运行若跳过权限确认，客户端界面可能正常打开，但连接动作无法真正影响系统流量。应在系统设置中检查网络扩展、虚拟接口和后台运行权限是否已允许。企业管理设备若限制网络配置，客户端可能无法自行修复，需要由设备管理方调整策略。

同一设备同时运行多个代理、过滤、抓包或网络加速程序时，彼此可能争用系统代理端口、虚拟接口或默认路由。排查时应完整退出其他网络工具，只保留一个客户端运行；若恢复，再逐个启用其他工具确认冲突来源。仅把窗口最小化通常不足以停止后台服务，应检查系统托盘、菜单栏和任务管理界面。

何时应停止本地尝试

当多个网络环境、多个地区线路和多个协议都出现同一失败，而基础网络正常时，应提交工单。附上平台、客户端名称、错误文本、线路名称、协议、问题发生时间和已经完成的交叉测试。若其他设备正常，也要明确写出“同一账户在其他平台可连接”，这能帮助客服把范围直接缩到终端配置。不要提交认证凭据，也不要在截图中保留完整订阅地址。

已连接但网页打不开

分清连接状态、路由状态与解析状态

客户端显示“已连接”只说明连接流程已经完成，不等于浏览器流量一定进入隧道。网页访问还依赖系统代理、默认路由、DNS 解析和浏览器自身设置。排查时先用域名访问一个普通站点，再用命令查看该域名能否得到解析结果。如果解析失败，重点检查 DNS；如果能解析但访问失败，再检查路由、系统代理与目标站点。

浏览器也可能启用独立代理、扩展程序或自己的安全 DNS，导致它不使用系统配置。最直接的对照方法是换一个未安装网络扩展的浏览器测试。如果新浏览器正常，说明连接与系统网络大体可用，问题位于原浏览器的扩展、代理或缓存；如果所有浏览器都失败，则继续检查系统层。

用系统命令确认 DNS 是否工作

命令的目的不是测速，而是观察域名能否被解析。将示例域名替换为实际无法访问的域名，但不要把包含认证参数的地址粘贴到公共记录中。

nslookup example.com

ipconfig /flushdns

curl -I https://example.com

nslookup 返回域名结果而浏览器仍失败，说明 DNS 至少完成了基本解析，应继续看系统代理和目标连接。若解析请求超时，可以断开客户端后再次执行作为对照。断开时正常、连接后失败，通常表示客户端 DNS 模式、虚拟接口或规则配置需要调整；两种状态都失败，则应先处理本地网络或系统解析服务。

清理 DNS 缓存只会移除旧解析结果，不会修复错误的路由或失效线路。执行后应重新打开浏览器或完全退出受影响应用，因为应用进程可能保留自己的缓存。不要连续执行清理命令并把偶然恢复当作根因，仍应记录清理前后的解析结果。

检查系统代理与虚拟接口

系统代理模式下，浏览器通常读取操作系统代理设置。如果客户端已经退出但代理地址仍残留，网页会因为代理端口无人监听而全部失败。此时应重新打开客户端，通过其“断开”或“恢复系统代理”动作清理设置，而不是手工删除不熟悉的网络接口。恢复后确认普通网页可访问，再重新连接。

虚拟接口模式会通过路由表接管流量，常见异常是系统从睡眠恢复、网络从无线切换到有线、或另一网络程序重写默认路由后，旧接口仍然存在。先断开连接，等待系统网络恢复，再重新连接；若仍无效，彻底退出客户端并重新启动。只有在保留日志后，才考虑使用系统提供的网络重置功能，因为重置可能同时清除其他网络配置。

针对 DNS 异常的分支处理

若某个域名在不同线路上的解析结果不同，不应手工固定未知地址。目标服务可能使用动态调度，固定旧地址会在短期看似有效，随后再次失效。更稳妥的办法是让客户端和系统恢复正常解析路径，并通过线路切换验证出口地区是否符合目标服务要求。

当 DNS 解析结果正常，但网页仍停留在连接中，可以同时测试另一个目标站点。若多个无关站点都失败，继续排查路由和代理；若仅一个站点失败，应检查该站点是否要求特定地区出口，或当前分流规则是否将它送往不合适的线路。不要因为单一目标异常就重装整个客户端。

速度慢与晚高峰卡顿

先判断瓶颈位于本地、入口还是出口

速度下降由整条路径中最弱的一段决定，包括设备到路由器、本地运营网络、线路入口、跨境链路、出口地区以及目标服务。只看一次测速峰值无法判断稳定性。更有价值的做法是保持同一设备、同一目标和同一测试方式，对比未连接、当前线路和另一地区线路的结果，并观察网页首开、持续下载、视频缓冲和交互延迟分别发生了什么变化。

未连接状态本身就不稳定时，应先处理无线信号、路由器负载或本地网络。靠近接入点、停止后台大文件同步、换用有线网络进行对照，都能帮助排除本地变量。若本地网络正常，而所有远距离线路都慢、邻近地区较稳定，问题可能与路径距离和当前网络入口有关；若只有单条线路下降，则优先更换同地区的其他线路类型。

按用途选择线路，不追逐单次峰值

IEPL 专线、中转和直连对应不同路径。需要稳定交互、视频播放或长连接时，应优先观察持续性、断线和缓冲，而不是只选择某次测速最高的线路。直连路径较直接，但实际表现更依赖当前网络环境；中转可调整入口路径；IEPL 专线适合对稳定性要求较高的场景。具体可用线路以节点列表为准。

地区距离也会影响交互体验。目标服务位于某个地区时，选择相近出口通常能减少额外绕行；但若目标服务按出口地区提供不同内容，则还要兼顾地区要求。流媒体问题可参考流媒体解锁说明，AI 工具连接问题可参考AI 加速说明。这些专题负责目标服务差异，本章只处理通用链路判断。

识别晚高峰的特征

晚高峰卡顿通常表现为同一设备、同一线路在特定时段持续下降，而其他时段恢复。确认这一点需要在不同时间保留同样的测试条件，不能用不同设备、不同无线位置和不同目标进行比较。若邻近地区线路同时下降，而换到另一入口或线路类型后改善，说明应优先调整路径；若所有网络活动都变慢，包括未连接时的普通访问，则瓶颈更可能位于本地接入。

视频播放不应只看能否开始。应观察起播是否缓慢、清晰度是否反复下降、拖动后能否继续加载，以及暂停一段时间后缓冲是否恢复。文件传输则要看持续速率是否稳定，交互应用要看操作反馈和长连接是否中断。把不同场景混成一个“速度慢”，会错过真正的瓶颈。

减少客户端之外的干扰

系统更新、云盘同步、媒体备份和其他设备的大流量任务都会占用本地出口。VPNHG 同时在线设备不限台数，但“不限台数”不表示共享网络的带宽不会被其他设备占用。排查时应暂停已知的大流量任务，并确认路由器没有开启会改变流量优先级的规则。若只有某个应用慢，还要检查应用自身是否使用独立下载节点或限制后台传输。

协议设置也可能影响特定网络下的表现，但不应无序切换。固定线路后分别测试客户端提供的协议，并记录哪个协议在当前网络下连接更快、持续更稳。若差异只出现在一个网络环境，说明协议与该网络路径之间存在适配差异；若所有环境一致变慢，则继续检查线路和目标服务。

提交速度问题工单时，应写清设备平台、基础网络类型、线路名称、协议、受影响的具体业务、问题出现的时段，以及换线路后的对比。不要只附一张测速截图；截图无法说明测试对象、目标地区、后台流量和持续稳定性。可复现步骤越完整，越容易判断应调整入口、线路还是终端配置。

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

区分线路中断与系统主动回收

频繁断线有两类常见来源：连接路径确实中断，或操作系统在锁屏、休眠、切换网络后暂停了客户端。前者通常在前台使用时也会发生，切换线路或协议后可能变化；后者常出现在屏幕关闭、设备省电、应用退到后台或无线网络切换之后。记录断线发生前的动作，比只记录断线时间更有价值。

如果桌面设备在睡眠唤醒后无法恢复，先确认基础网络已经重新取得连接，再断开并重连 VPNHG。系统恢复网络需要一定过程，客户端过早尝试可能保留失效接口或旧路由。若每次唤醒都能复现，应保留客户端日志，并检查系统是否允许客户端在登录后继续后台运行。

移动端先检查后台与省电策略

移动系统会根据电量、温度、后台活动和网络切换管理应用。客户端退到后台后被暂停，界面仍可能保留上次连接状态，但实际隧道已经失效。应在系统设置中允许客户端后台活动，避免将其加入严格省电或休眠名单，并确认系统 VPN 配置没有被其他网络应用替换。

无线网络与移动网络切换时，设备出口发生变化，原连接通常需要重新建立。若切换后一直停留在旧状态，可回到客户端确认状态，先断开再连接。不要在网络尚未稳定时连续点击连接，这会产生多次重试并使日志难以阅读。若只有某一类网络经常掉线，可固定同一线路和协议分别测试，判断问题是否由该网络入口触发。

桌面端检查睡眠、虚拟接口与冲突软件

Windows 和 macOS 在睡眠、快速用户切换或网络接口变化后，可能保留旧的代理或路由状态。先退出所有会修改网络配置的程序，只保留 VPNHG 客户端；随后重启客户端并复现睡眠或切网动作。如果问题消失，再逐个恢复其他程序。这样可以确认是客户端自身恢复失败，还是多个工具争用系统网络控制权。

Linux 环境应重点保留虚拟接口、路由和服务日志。桌面网络管理服务在接口切换时可能重写默认路由，本地防火墙也可能在网络区域变化后加载另一套规则。不要只观察客户端窗口，应同时查看系统网络状态。若脚本或服务负责自动启动客户端，要确认旧进程退出后才启动新进程，避免重复实例争用端口与接口。

处理看似随机的间歇性断线

间歇性问题最容易因为证据不足而陷入反复重试。应记录断线前设备是否切换网络、是否进入休眠、是否有大流量任务启动、客户端是否自动切换线路，以及断线后普通网络是否仍可访问。若普通网络同时中断，先处理本地网络；若普通网络正常而隧道失效，再比较其他线路和协议。

不要把自动重连掩盖的问题当作已经解决。自动重连可以恢复使用，但若断线持续发生，仍应确定触发条件。对于实时会议、远程终端和持续传输，短暂重连也会中断会话。选择更稳定的线路类型、关闭冲突工具、允许后台运行，并避免设备在任务期间进入休眠，通常比提高重试频率更有效。

订阅更新失败

先确认拿到的是订阅入口而不是网页内容

订阅导入应从用户面板的下载或订阅区域完成，不要把营销页面地址、浏览器地址栏中的登录页面或第三方分享页面当作订阅地址。VPNHG 的客户端与订阅入口统一通过用户面板提供，静态页面不放安装包直链或真实订阅地址。若还未完成首次导入，请回到使用教程确认获取路径。

客户端提示内容格式错误时，先在面板重新复制订阅入口，避免复制到前后空格、换行或说明文字。不要把真实地址粘贴到公开网页或公共截图中。用于测试文档格式时，只能使用明显的假值：

subscription:
  source: "https://example.com/sub?token=YOUR_TOKEN"
  update: manual

如果浏览器打开后返回登录页面、错误页面或普通 HTML，客户端自然无法解析为订阅内容。此时重点检查账户登录状态、获取入口和客户端支持的导入方式，而不是手工修改返回内容。

区分获取失败、解析失败与应用失败

订阅更新包含几个连续阶段：客户端发起请求、服务返回订阅内容、客户端解析节点、客户端把新配置写入当前配置集。获取失败常表现为网络错误、超时或认证无效；解析失败通常会出现格式、字段或配置错误；应用失败则可能显示更新成功，但列表没有变化，或者新配置未被设为当前配置。

排查时先记录错误原文。若是获取失败，切换基础网络并确认用户面板可正常打开；若是解析失败，重新从面板复制入口并使用客户端支持的导入方式；若是应用失败，检查客户端当前选中的配置集，确认更新后的配置没有被旧配置覆盖。不要只凭“节点列表没变化”判断服务没有返回数据。

检查缓存、旧配置和重复配置集

部分客户端会缓存订阅结果，或同时保留多个同名配置。更新后仍看到旧线路时，先确认当前启用的是哪一个配置集，并比较配置来源，而不是直接删除全部内容。可以将旧配置临时停用，再重新导入，以便保留回退路径。若新配置工作正常，再清理确认无用的旧项。

自动更新任务可能在设备休眠、客户端未运行或网络不可用时失败。手动打开客户端并执行一次更新，可区分计划任务问题与订阅入口问题。移动端若限制后台活动，自动更新可能不会按预期执行；这与连接后台掉线类似，应检查系统对客户端后台活动的管理。

账户状态与流量周期的核对

若订阅突然无法更新，应在用户面板核对套餐状态与流量信息。月订阅流量按开通日每月重置，中途升级差价折算成剩余天数；流量包用完为止，永久不过期。不要根据自然月日期自行判断重置时间，也不要通过反复导入来改变账户状态。面板中的订单与订阅状态才是排查依据。

VPNHG 注册无需邮箱地址，使用用户名和密码即可完成。因此提交账户相关工单时，应提供用户名、订单状态页面截图和错误时间，不要提供密码。若客户端报告认证失败，而面板可以正常登录，附上订阅更新的错误文本；若面板也无法进入，则先确认用户名输入和密码管理记录。

当多个客户端对同一订阅都返回相同错误，而面板套餐状态正常时，应停止反复删除配置并提交工单。说明哪些平台测试过、获取阶段是否成功、返回的是网络错误还是解析错误。若只有一个客户端失败，则优先导出该客户端日志，并用另一受支持平台作对照。

某个 App 不走代理

先确认应用是否遵循系统代理

浏览器能够访问而某个 App 无法访问，常见原因不是线路失效，而是该应用不读取系统代理。部分应用直接建立网络连接、使用独立网络栈，或只在启动时读取代理设置。连接 VPNHG 后，应彻底退出受影响应用并重新打开，确保它重新获取系统网络状态。只关闭窗口可能保留后台进程，仍然沿用旧连接。

如果客户端提供系统代理与虚拟接口模式，可以在保留当前线路的情况下切换模式作对照。系统代理适合遵循操作系统代理配置的应用；虚拟接口模式通常能覆盖更多不读取系统代理的流量，但也更依赖系统权限、路由和 DNS 配置。切换后先验证普通网页，再测试目标应用，避免把新增的系统问题误认为应用问题。

检查分流规则实际命中了什么

规则模式会根据域名、地址或应用进程决定直连与代理。目标服务可能使用多个域名，主页面域名进入代理，并不代表登录、媒体、接口和文件域名都使用相同路径。若客户端提供连接日志或规则命中记录，应在打开目标应用时观察新出现的请求，确认相关域名被分到哪条规则。

规则顺序通常从更具体的条件到更宽泛的条件匹配。自定义规则放置位置不当，可能被前面的通用直连规则提前命中。修改前先导出当前配置，避免无法回退；修改后彻底重启应用，并清理应用自身保存的连接状态。不要在不了解域名用途时把所有流量都长期改为同一种路径，应先解决明确的目标。

处理浏览器正常、桌面应用异常

桌面应用可能自带代理设置。若应用内部配置了旧地址、旧端口或“直连”，它可能覆盖系统设置。应检查应用网络选项，优先选择“跟随系统”或与当前客户端模式匹配的配置。若此前手工填写过代理地址，先记录原值，再恢复自动或系统模式进行测试。

应用更新后也可能更换网络组件，导致旧规则中的进程名不再匹配。此时域名规则通常比只依赖进程名更容易验证。若必须使用进程规则，应从系统任务信息确认实际发起网络请求的进程，而不是只依据应用窗口名称。辅助进程、更新进程和主进程可能分别建立连接。

处理移动应用与内嵌网页

移动应用经常同时包含原生接口、内嵌网页和媒体请求。登录页能打开而内容加载失败，可能表示不同请求走了不同规则，也可能是出口地区不符合目标服务要求。先选择与目标服务相匹配的地区线路，再在规则日志中观察域名。如果切换地区后恢复，应记录有效地区；如果所有地区一致失败，再检查应用版本、缓存和系统 DNS。

应用从后台恢复时可能继续使用断线前的长连接。回到前台后若界面持续加载，应完全结束应用进程并重新打开。移动端系统的后台限制还可能同时暂停 VPN 客户端，因此要先确认系统 VPN 状态仍有效，再判断目标应用本身。

用最小规则修复，而不是扩大接管范围

排查规则问题时，应从目标应用的明确域名或进程入手。一次加入范围过大的规则，可能让原本应直连的本地服务也改变路径，引入新的登录、地区或速度问题。每次只增加一类可解释的条件，验证成功后记录用途。后续若目标服务更换域名，也能知道应更新哪一条规则。

若某个应用在所有受支持平台都出现相同问题，而浏览器访问其网页正常，应同时考虑目标服务的应用接口策略。此时提交具体失败页面、错误文字和出口地区，比笼统描述“App 不能用”更有效。客服可以据此核对线路侧访问情况，但无法仅凭应用名称推断实际请求。

设备提示、账户核对与工单

出现设备数提示时先核对提示来源

VPNHG 同时在线设备不限台数。若客户端出现“设备过多”“会话受限”或类似提示，不应直接理解为 VPNHG 套餐限制。先确认提示来自 VPNHG 用户面板、本站客户端、操作系统，还是另一个应用。第三方客户端可能对本地配置、同步账户或连接会话有自己的限制，其提示并不等于服务端设备数量限制。

还应检查是否重复启动了多个客户端实例，或旧进程在后台保持连接。同一设备上的重复实例可能争用端口、系统代理和虚拟接口，并产生看似与设备数有关的错误。彻底退出客户端、结束残留进程后只启动一个实例，再进行连接测试。如果提示仍存在，保留完整错误文字和出现位置。

核对用户名、套餐与订单状态

账户异常应从用户面板开始确认。VPNHG 无需邮箱地址，用户名加密码即可注册，因此找回或核对账户时应以实际用户名为准。进入面板后查看套餐是否有效、订阅入口是否可见、流量信息是否正常，以及订单状态是否完成。支付方式支持支付宝、微信和 USDT；若订单状态与实际支付过程不一致，应在工单中提供订单页面信息，不要重复创建无法区分的订单。

月订阅包括 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包包括 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。排查流量和周期问题时，应先确认购买的是月订阅还是流量包，避免用月订阅的重置逻辑解释流量包状态。完整规则可查看套餐页面。

什么情况适合直接提交工单

经过交叉测试后仍无法定位，或问题涉及订单、账户状态、订阅返回内容和多条线路同时异常时，应提交工单。技术问题至少写明平台、客户端、线路、协议、网络环境、错误原文、发生时间和复现步骤；账户问题写明用户名、订单状态与面板中看到的结果。若已完成线路、协议或设备对照，也应逐项写出结果，避免客服要求重复测试。

以下情况不适合继续无序重试：多个网络环境都无法连接；多个客户端都无法解析同一订阅；面板状态与客户端认证结果不一致；同一故障可稳定复现且已经保留日志；订单完成后面板状态未更新。此时继续删除配置可能破坏证据，提交结构化信息更有效。

工单中应该附什么

问题类型：连接 / 网页访问 / 速度 / 断线 / 订阅 / 应用分流
设备平台：
客户端：
线路名称：
协议：
网络环境：
发生时间：
错误原文：
复现步骤：
已经测试：
对照结果：

截图应覆盖错误提示和客户端状态，但要遮盖密码、完整订阅地址、访问令牌及其他认证信息。日志可保留错误前后的连接过程，不需要上传与问题无关的全部历史记录。若文件包含敏感字段，应先复制一份并进行脱敏，不要直接编辑唯一原始日志，以免丢失上下文。

如何描述间歇性和性能问题

间歇性问题需要时间线：问题发生前设备做了什么、是否切换网络、是否休眠、普通网络是否同时异常、自动重连是否成功。性能问题则要写清受影响的业务、线路地区、线路类型、问题时段和对照线路。单独一句“速度很慢”无法区分本地无线、跨境路径、目标服务和后台任务。

如果问题只影响某个网站或 App，应提供目标名称、错误页面、浏览器与应用的对照、所选出口地区和规则命中结果。若是流媒体区域内容差异，不要只提交片名；应说明目标平台、所选地区和客户端状态。若是 AI 工具连接异常，应说明网页端与应用端是否一致，以及切换线路后是否变化。

处理完成后的回归检查

问题恢复后，应回到最初记录的复现步骤重新执行，而不是只确认当前页面能打开。连接类问题要测试断开与重连；DNS 问题要重新解析原目标域名；断线问题要复现锁屏、睡眠或切网动作；订阅问题要确认更新后新配置已实际启用；应用分流问题要重启应用并验证相关功能。

若修复依赖某条自定义规则、特定协议或某类线路，应把有效配置和适用场景记录下来。以后系统更新、客户端重装或订阅重新导入时，可以快速恢复。与此同时保留默认配置的副本，出现新问题时可与默认状态对照，避免长期累积的修改互相影响。

排障的终点不是“多试几次后暂时恢复”，而是能够说明故障位于哪一层、哪项操作改变了结果，以及是否需要服务端继续核对。按本手册保留基线、执行单变量对照并提交完整工单，可以减少重复沟通，也便于在同类问题再次出现时直接复用结论。