VPN 故障排查手册

从现象开始，不从猜测开始

有效排查的起点不是“线路坏了”或“客户端有问题”，而是可以重复观察的现象。例如：所有线路都无法建立连接；只有当前网络环境无法连接；连接状态已经显示成功，但浏览器与其他应用都无法访问；只有某个应用不走代理；订阅链接能够打开，却无法更新线路列表。这些描述分别指向传输层、系统网络、DNS、分流规则和订阅解析等不同环节。先写清现象，后续每次改动才有明确的验证目标。

建议先保留当前配置，不要立刻删除订阅。确认套餐仍有效、可用流量未耗尽，并观察客户端能否正常显示原有线路。月订阅流量按开通日每月重置；如果刚好接近重置节点，应以用户面板显示的状态为准。若使用的是流量包，流量用完为止并永久不过期。套餐规则可在价格页面核对，账户中的实际状态则应以面板为准。

用对照试验定位边界

最有价值的对照通常来自网络、线路、客户端和设备。当前网络无法连接时，换到另一种可用网络环境；某条线路异常时，切换到不同地区或不同类型的线路；某个客户端异常时，在保留订阅的前提下检查另一个受支持平台；某台设备异常时，对照同一账户下其他设备的表现。VPNQD 同时在线不限台数，因此多设备对照不会因为固定台数上限而自然失效，但同一设备里重复导入、残留进程和系统网络扩展仍可能互相影响。

每次对照只改变一个条件。若同时换网络、换线路并重装客户端，即使问题消失，也无法知道究竟是哪一步起效。更稳妥的记录方式是写下“改动前现象、只修改的项目、改动后结果”。结果不必复杂，只需区分能否连接、能否解析域名、能否打开网页、是否只有个别服务异常以及断线能否复现。这样的记录也能显著提高后续工单处理效率。

保留可恢复的基线

在编辑规则、替换 DNS 或修改系统网络前，应先记录原始状态。客户端支持导出配置时可保存一份副本；不支持导出时，可记录模式名称、当前线路和已启用的系统代理选项。不要把真实订阅地址粘贴到公开论坛、截图或共享文档中。需要演示格式时，应使用明显的假值，例如：

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

排查完成后，应撤销没有必要的临时修改，尤其是全局代理、调试日志和为验证而关闭的分流规则。最终配置应回到能够解释、能够复现、也能够在重启后继续工作的状态。若必须依赖一组无法说明原因的偶然设置，问题通常尚未真正定位。

先区分“没有线路”与“线路握手失败”

客户端空白、线路列表过期和点击连接后持续等待是不同问题。若客户端里没有任何线路，优先转到订阅更新章节；若线路可以看到，但点击后立即返回未连接状态，应查看客户端是否提示权限、配置或认证错误；若长时间停在连接中，则更可能与当前网络、线路可达性、系统时间或残留进程有关。不要把这些现象统一归为服务器故障，因为处理路径并不相同。

登录用户面板确认账户状态与订阅是否有效。如果近期更换了用户名密码，不应把面板密码误填到客户端的其他认证字段中。订阅通常由面板交付，不需要手工拆分为多个未知参数。若面板可正常进入但客户端订阅已经失效，应从面板重新获取当前订阅，再替换旧内容；不要在旧地址后自行添加参数，也不要通过第三方转换站处理真实订阅。

核对系统网络权限与残留状态

Windows 与 Linux 常见问题是客户端未获得创建网络接口或修改路由所需的权限；macOS、iOS 与 Android 则可能在首次连接时出现系统网络扩展或 VPN 配置确认。用户拒绝过权限后，客户端界面仍可能允许点击连接，但系统不会真正建立通道。应进入系统网络设置，确认对应配置存在且处于允许状态。若系统里同时保留多个旧配置，应先退出相关客户端，再删除明确不再使用的旧项，避免多个网络扩展竞争控制权。

客户端异常退出后，后台进程可能仍占用系统代理或虚拟接口。此时重复点击连接只会叠加错误。应先完全退出客户端，而不是仅关闭窗口；随后确认系统代理是否仍指向已经停止的本地进程，再重新启动。若设备刚从休眠恢复，也可先断开现有连接，等待系统网络恢复后再连接。不要在客户端仍运行时频繁重置系统网络，这会让界面状态与系统实际状态分离。

比较当前网络与其他线路

先在不启用加速连接的状态下确认当前网络能够正常访问常规网站。基础网络本身无法解析域名、需要网页认证或处于受限访客网络时，客户端通常也无法建立连接。公共网络常要求先在浏览器完成接入确认；该页面未出现时，可以暂时关闭系统代理后重新打开一个普通网页，让网络完成自身的认证流程，再回到客户端连接。

基础网络正常后，从服务器页面了解 IEPL 专线、中转与直连的用途，然后选择不同类型或不同地区的线路进行对照。若只有当前线路失败，保留错误信息并切换同地区其他线路即可；若所有线路都失败，再更换可用网络环境复测。不同网络下结果相反，说明问题更接近本地网络路径；不同网络下结果一致，则应继续检查客户端权限、订阅内容和系统时间。

什么时候应停止本地尝试

如果账户有效、订阅能够更新、系统权限已确认，并且在不同网络环境下所有线路都无法建立连接，应提交工单。工单需要写明平台名称、客户端名称、故障开始时的操作、所有线路还是个别线路受影响、不同网络下的对照结果，以及客户端显示的完整错误信息。日志中若包含订阅地址或认证内容，应先遮盖敏感部分；不要只写“连不上”，因为该描述无法区分网络拒绝、权限错误、配置损坏和订阅失效。

若只有某个系统用户、某个网络接口或某次系统升级后出现异常，也应一并说明。客服根据这些边界信息判断是否需要更换线路、重新下发订阅，或引导清理系统残留。没有边界信息时，处理只能从最基础步骤重新询问，反而延长定位过程。

连接状态不等于完整访问链路已经可用

客户端显示已连接，只能说明本地客户端与所选线路完成了连接过程。浏览器访问还要经过系统路由、代理接管、域名解析、目标服务响应和应用自身缓存。若连接后所有网站都打不开，先判断系统流量是否真的进入客户端；若只有域名打不开但已知网络请求仍能发出，应优先检查 DNS；若只有个别网站异常，则更可能与目标地区、浏览器状态、分流规则或目标服务自身策略有关。

首先关闭客户端中的临时规则修改，回到可识别的默认配置。检查系统是否同时启用了手工代理和客户端的虚拟网络模式。两套接管方式叠加时，浏览器可能把请求送到已经不存在的本地端口，或形成重复转发。若客户端支持系统代理与虚拟接口两种工作方式，应按其说明选择一种主要方式进行测试，而不是全部打开。验证期间也应退出其他会修改代理、DNS 或网络过滤的工具。

用域名解析命令分离 DNS 问题

命令行测试的目的不是追求复杂，而是确认系统能否把域名解析为地址。Windows 可使用系统自带的名称查询命令，macOS 与 Linux 也可以使用常见查询工具。示例域名应选择公开且稳定的测试域名，不要把真实订阅地址放进命令历史：

nslookup example.com

curl https://example.com

如果名称查询失败，而客户端日志持续出现解析相关提示，问题集中在 DNS 或系统网络；如果查询成功但浏览器失败，应继续检查浏览器代理、扩展和缓存；如果命令行与浏览器都失败，但关闭连接后恢复，则需要比较线路和接管模式。命令输出中不要只截取最后一行，完整的错误类型、查询对象和所用解析器更有价值。

处理 DNS 缓存与解析冲突

切换网络、线路或代理模式后，系统和浏览器可能继续使用旧的解析结果。应先完全退出浏览器再重新打开，并使用系统提供的网络刷新方式清理过期状态。若客户端允许选择由系统解析还是由客户端解析，可分别测试，但一次只保留一种设置。不要同时在路由器、系统、浏览器和客户端里填入多套自定义 DNS；层级越多，越难判断查询实际经过哪里。

部分浏览器带有独立的安全 DNS 功能，它可能绕开系统设置。若其他应用可以访问、只有浏览器域名解析异常，可以暂时让浏览器跟随系统设置进行对照。验证后再决定是否恢复浏览器独立解析。企业网络或受管理设备还可能下发固定代理与证书策略，这类策略应由设备管理员确认，不宜通过删除管理配置来规避。

个别网站打不开时不要重置全部网络

个别网站异常时，先用同一线路访问其他服务，并换一个浏览器或隐私窗口排除旧 Cookie、缓存和扩展影响。随后检查该域名在规则中是直连、代理还是被错误拦截。若切换到目标地区附近的线路后恢复，说明应调整线路选择而不是重装客户端。相关地区和线路类型可在服务器目录中查询。

如果不同设备、不同网络和不同线路都只对同一目标服务异常，可能需要由客服确认线路侧情况。提交工单时附上目标域名、发生时使用的线路名称、是否能打开同类网站、域名查询结果和浏览器错误页。不要只发送整页截图而省略地址栏，也不要在截图中暴露账户凭据或真实订阅地址。

先确认慢在哪里

“速度慢”至少应拆成建立连接慢、网页首开慢、持续下载慢、视频缓冲、交互延迟明显或速度忽快忽慢。网页首开慢往往与 DNS、连接建立或目标站响应有关；持续传输慢更接近本地网络质量、线路拥塞或目标服务限速；交互迟缓则更受距离、路由和抖动影响。不同现象需要不同对照，不能只凭一次测速结果判断全部应用体验。

测试前先关闭正在同步、备份、下载或更新的任务，确认同一网络下没有其他设备持续占用出口。然后记录未连接时的基础表现，再在同一设备、同一网络和同一目标下测试所选线路。若基础网络已经不稳定，跨境线路无法修复本地无线干扰或上游宽带拥塞。相关测速方法可参考VPN 速度实测怎么做，重点是保持测试条件一致，而不是追逐单次峰值。

晚高峰要比较时段，不要只比较节点名称

晚高峰卡顿常表现为白天正常、集中使用时段出现波动。判断时应保留同一线路，在不同网络时段重复相同操作；随后在同一时段比较不同线路类型。这样可以区分目标服务波动、当前网络出口拥塞和线路路径变化。如果只在卡顿时连续切换许多节点，短暂恢复可能只是目标服务连接重新建立，并不能证明最后选择的节点长期更合适。

IEPL 专线、中转与直连的路径结构不同。线路名称不是速度承诺，也不能脱离当前位置与目标服务单独排名。距离较近的地区通常适合作为起点，但目标内容位于其他地区时，出口位置同样重要。应根据用途建立自己的常用线路组：网页与 AI 工具重视交互稳定性，持续传输更看重长时间吞吐，流媒体还要考虑内容地区。不要把一个线路承担所有场景。

检查协议、接管模式与设备负载

设备性能不足、节能模式、后台安全扫描和虚拟接口冲突都会影响吞吐。移动设备处于低电量策略时，系统可能限制后台网络；桌面设备同时运行虚拟机、容器或其他网络过滤程序时，数据会经过更多处理层。排查时应关闭无关高负载任务，并观察客户端进程是否异常占用资源。若只有某台旧设备慢，而同一线路在其他设备正常，重点应转向设备和系统环境。

客户端提供多种接管模式时，应使用默认建议作为基线。全局模式并不天然更快，规则模式也不必然更慢；差异取决于请求是否被正确分类。若某个测速工具在规则模式下实际直连，得到的结果不能代表线路。可以临时使用全局模式确认测试流量确实经过线路，完成后恢复日常规则，避免把本地服务和不需要加速的请求全部转发。

避免把流量状态误判为速度问题

月订阅包含的流量按开通日每月重置，套餐分别为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB。若面板显示流量状态异常，应先核对当前周期，而不是反复更换线路。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止且永久不过期。中途升级时，差价会折算成剩余天数，账户展示可能因此发生变化。

确认账户正常后，如果多条线路在不同设备上都于同一网络时段出现相同卡顿，而更换网络后明显改善，应优先联系当前网络提供方或检查本地路由环境；若不同网络下问题一致，且集中在特定地区或线路类型，应向客服提交线路名称、目标服务、发生场景和对照结果。不要在工单中填入自己推测的“带宽不足”，描述可复现现象比结论更有用。

区分线路断开、网络切换与应用休眠

频繁断线可能发生在不同层级。客户端明确显示连接已断开，说明通道本身没有保持；客户端仍显示连接，但应用请求停止，可能是系统路由、DNS 或应用网络状态异常；只有设备锁屏后断开，则更接近后台活动限制；从无线网络切换到移动网络时断开，则属于底层网络变化后的重连问题。先记录断线发生的动作，比记录“偶尔掉线”更能定位原因。

观察断线是否与休眠、锁屏、网络切换、低电量模式、客户端切到后台或路由器重拨同步。若总在同一动作后发生，可以直接检查对应系统策略；若没有固定动作，再比较不同线路和不同网络。不要开启自动切换线路后再判断某条线路是否稳定，因为自动策略会隐藏实际切换过程。排查期间应固定一条线路，关闭不必要的自动选择功能。

移动端后台限制的处理

iOS 与 Android 都会管理后台网络活动，但具体入口和命名随系统界面而变化。应在系统设置中确认客户端被允许保持 VPN 配置和必要的后台活动，并检查低电量或省电策略是否对其施加了额外限制。Android 设备还可能由厂商电源管理单独控制后台应用；应把客户端加入允许持续运行的范围，而不是关闭整个系统的电源管理。

锁屏后立即断开与放置一段时间后断开是不同线索。前者通常与系统策略或网络切换相关，后者也可能来自路由器租约、无线休眠或线路保持失败。测试时保持设备在同一网络环境，先前台运行，再锁屏复测，最后切换网络复测。每次测试前重新建立连接并确认网页可访问，避免把前一次失败状态带入下一轮。

桌面系统的休眠与网络接口恢复

Windows、macOS 与 Linux 从睡眠恢复时，物理网络接口、DNS 与虚拟接口的恢复顺序可能不同。客户端界面可能仍保留连接标记，但原通道已经不可用。遇到这种状态，应主动断开并重新连接，而不是直接叠加新的系统代理。若每次休眠后都会复现，应检查客户端是否具有随网络变化重连的选项，并确保系统内没有其他网络工具争用默认路由。

频繁在有线、无线与其他网络之间切换时，旧路由可能暂时残留。完全退出客户端后重新打开，通常比连续点击连接更容易恢复干净状态。若必须重启系统才能恢复，应保存客户端日志并说明“退出客户端无效、重启后恢复”这一边界。这表明问题可能涉及系统网络扩展或残留进程，而不只是某条线路。

何时提交断线日志

当断线可以稳定复现，且已经排除锁屏、省电、网络切换和其他代理工具，应提交工单。说明使用平台、网络类型、线路名称、断线前正在进行的操作、客户端状态是否变化、重新连接能否恢复，以及其他线路是否相同。日志应覆盖断线前后，但不应公开真实订阅地址、用户名或认证内容。

如果问题只发生在移动端后台，应附上后台权限与省电策略的文字说明；如果只发生在休眠恢复后，应说明完全退出客户端是否有效。客服需要的是触发条件和对照，而不是长时间无筛选的全部日志。边界越清楚，越容易判断是系统生命周期、当前网络还是线路连接保持问题。

先确认订阅失败发生在哪一步

订阅问题通常表现为无法获取内容、下载到内容但解析失败、更新成功却没有线路、线路存在但名称或分组异常。无法获取内容更接近账户、网络或地址失效；解析失败可能来自客户端不兼容、复制内容不完整或旧缓存；更新后为空则需要检查账户状态和客户端过滤；分组异常则可能是新旧订阅叠加。先保留错误提示，不要立即删除全部配置。

从用户面板重新进入订阅交付入口，确认当前账户可用。VPNQD 注册无需邮箱地址，用户名与密码即可注册，因此排查时应确认登录的是最初使用的用户名，而不是把其他资料当作账户标识。获取新订阅后，应完整替换旧地址，不要手工截取其中一段，也不要把真实地址交给第三方页面转换。客户端与订阅应从面板获取，营销页面不提供静态安装包或公开订阅地址。

排除复制、缓存与重复导入

订阅地址中可能包含对复制完整性敏感的字符。通过聊天软件、富文本编辑器或自动换行的笔记应用中转时，地址可能被截断、插入空格或改写符号。最稳妥的方式是从面板直接复制，再粘贴到客户端订阅输入框。需要展示格式时只能使用假值：

subscription:
  name: VPNQD-example
  url: https://example.com/sub?token=YOUR_TOKEN
  update: manual

若客户端已有多个名称相近的订阅，应先辨认当前正在使用的配置。重复导入会造成线路重名、规则来源混杂或更新了错误条目。可以先停用旧订阅，再导入当前订阅；确认新条目正常后，再删除明确不再使用的副本。不要在无法确认内容时同时清除客户端数据和系统网络配置，这会让订阅问题扩展为连接问题。

判断网络获取失败还是客户端解析失败

若客户端提示无法下载订阅，先确认普通网页可以访问，并比较关闭连接和启用连接时的结果。部分情况下，旧代理状态会影响客户端自身请求。完全退出客户端、清理残留系统代理后重新打开，再尝试更新。若面板在浏览器中也无法进入，应先处理当前网络；若浏览器能正常进入面板，但客户端始终无法获取，则应记录客户端错误并检查其网络权限。

如果订阅内容能够获取但解析失败，不要尝试手工修改服务端下发内容。应确认使用的是面板提供的客户端入口或受支持的导入方式。不同客户端对字段、分组和规则的支持范围不同，把一种格式强行导入另一种客户端可能得到空列表。此时应回到面板重新选择对应平台的获取方式，而不是在本地猜测字段含义。

更新成功但仍看不到新线路

更新成功后，客户端可能仍显示旧分组缓存。先切换到新订阅条目，确认当前配置来源，再重新载入配置。若设置了地区、协议或关键词过滤，也要检查是否把线路全部隐藏。VPNQD 提供 120+ 国家、180+ 线路，但客户端界面可能根据分组、筛选和当前订阅状态展示不同内容，不应仅凭某个折叠分组判断订阅为空。

若重新获取、替换旧地址并取消过滤后仍然无法更新，应提交工单，附上平台、客户端名称、错误全文、面板能否打开、订阅是下载失败还是解析失败、是否存在旧订阅，以及使用假值遮盖后的地址结构。客服不需要用户发送真实订阅内容。若需要重新下发，应只通过用户面板或工单中的受控流程处理。

先确认是应用独有问题

当浏览器和其他应用正常，只有某个应用无法访问时，不应先更换整个订阅。先确认该应用在关闭连接时的表现，再确认启用连接后是否发生变化。如果应用始终相同，可能没有被客户端接管；如果启用后变得异常，可能命中了错误规则或不兼容当前网络模式；如果应用部分功能正常、部分功能失败，则可能使用了不同域名、独立网络组件或多条连接路径。

一些应用遵循系统代理，一些应用直接建立网络连接，还有一些应用把内容、登录和更新请求分散到不同域名。仅设置系统代理时，不遵循系统代理的应用可能继续直连；使用虚拟网络模式时，接管范围通常更广，但仍会受到分流规则和系统权限影响。排查应围绕“请求有没有进入客户端”展开，而不是只看客户端是否显示已连接。

用临时全局模式验证接管范围

如果客户端支持规则模式与全局模式，可以临时切换到全局模式进行对照。全局模式下应用恢复，说明线路本身大体可用，问题集中在规则命中；全局模式下仍失败，则应检查应用协议、线路地区、系统接管方式或应用自身状态。验证结束后应恢复日常规则，避免让不需要跨境线路的本地请求持续经过代理。

修改规则前先查看客户端连接记录或规则命中信息。找到应用访问的域名后，判断其被标记为直连、代理还是拦截。不要仅凭应用品牌名编写一个过宽的通配规则，因为登录、内容分发和更新域名可能属于不同服务。更稳妥的方式是从失败请求出发，只调整必要域名，并在每次调整后重新启动应用验证。

检查应用内部代理和缓存

部分桌面应用有独立代理设置。应用内部代理与系统代理同时启用时，可能形成重复转发；应用内部仍保留旧本地地址时，也会把请求发向已经停止的进程。应先让应用跟随系统设置进行测试，确认正常后再决定是否需要独立配置。不要把订阅地址直接填入应用的代理地址栏，订阅与本地代理端口不是同一种信息。

应用在首次启动时可能缓存地区、解析结果或登录会话。切换线路后，旧连接仍可能保持在原路径。应完全退出应用并重新打开，而不是只关闭主窗口。若浏览器隐私窗口正常、应用仍异常，可以清理该应用允许清理的网络缓存或重新登录，但不应先删除全部用户数据。涉及工作资料或本地项目时，清理前应确认数据同步与备份状态。

特殊协议与受管理环境

某些实时通信、游戏、企业软件或系统服务使用的连接方式与普通网页不同，可能不遵循应用层代理。此时应优先使用客户端推荐的系统接管方式，并确认系统网络扩展正常。企业设备上的安全策略、证书和网络过滤也可能限制应用连接，不应通过删除管理策略处理；应向设备管理员确认允许的网络方式。

向客服提交此类问题时，应说明应用名称、失败的具体功能、浏览器是否正常、全局与规则模式的对照、所用线路以及应用完全退出后是否变化。如果客户端能显示规则命中，应附上脱敏后的相关记录。不要只写“这个 App 用不了”，因为登录失败、内容加载失败、文件传输失败和实时连接失败对应的排查方向并不相同。

不限台数不等于设备环境不会互相干扰

VPNQD 同时在线不限台数，因此出现连接问题时，不应先按固定设备上限处理。但不限台数只说明服务侧不以固定台数限制同时在线，并不意味着同一设备上可以同时运行多个客户端、多个虚拟接口或重复的系统代理。多个客户端争用默认路由时，常见表现包括连接按钮反复切换、网页偶尔可用、DNS 走向不一致以及休眠恢复后无法重连。

每台设备应保留一个明确的主要客户端和当前订阅。需要比较客户端时，应完全退出原客户端，再启动另一个测试；不要让多个客户端同时接管系统网络。家庭共享场景可参考多设备 VPN 推荐与设备数说明，重点是保管账户资料、区分各设备配置，并避免把真实订阅地址发到公开群组。

判断账户问题还是单机问题

如果同一账户在其他设备正常，只有一台设备异常，故障通常集中在该设备的客户端、权限、网络接口或本地配置。如果所有设备同时无法更新订阅，应先检查账户状态和当前网络；若不同网络下仍一致，再提交工单。若只有某个家庭网络下所有设备异常，而换到其他网络恢复，重点应转向路由器、DNS 和上游网络，而不是逐台重装客户端。

路由器承担全屋网络时，终端设备可能同时经过路由器加速与本机客户端，形成重复路径。排查应先选择一种方式：关闭终端客户端，验证路由器路径；或让终端绕开路由器上的相关规则，单独验证客户端。全屋方案的取舍可参阅路由器 VPN 方案与边界。未经确认不要同时修改路由器和全部终端，否则无法知道故障发生在哪一层。

提交工单前整理可复现资料

高质量工单应包含症状、环境、触发条件、对照结果和错误证据。症状要写清是无法连接、连接后无法访问、速度波动、订阅失败还是个别应用异常；环境包括 Windows、macOS、iOS、Android 或 Linux，以及客户端名称；触发条件包括锁屏、网络切换、休眠恢复、更新订阅或切换线路；对照结果则说明其他线路、其他网络和其他设备是否相同。

错误证据可以是完整错误文本、脱敏日志或包含上下文的截图。截图应保留客户端状态、线路名称和错误区域，同时遮盖用户名、密码、真实订阅地址及认证内容。不要裁掉错误标题，也不要只提交一张没有说明的图片。若问题涉及目标网站或应用，应写出目标名称、失败功能和同类服务是否正常，但不要提供不必要的个人资料。

哪些情况应直接联系支持

账户状态与面板展示不一致、所有受支持平台均无法获取订阅、不同网络下所有线路都无法连接、同一地区多条线路持续出现一致异常，或客户端返回无法通过本地设置处理的认证错误时，应直接提交工单。支付与退款问题也应通过受控工单处理。VPNQD 支持支付宝、微信与 USDT，并提供 30 天无理由退款；具体申请与订单状态应以账户和相关条款为准。

若问题来自操作顺序不清，可先回到使用教程重新核对注册、选择套餐、获取订阅和导入客户端的主线。注册无需邮箱地址，用户名与密码即可完成。客户端下载和订阅都应从用户面板获取，不应使用来源不明的安装包或订阅转换页面。若需要重新获取客户端，可进入面板下载区域。

完成排查后的收尾

问题解决后，应撤销仅用于验证的全局模式、自定义 DNS、临时规则和调试日志，保留最终起效的最小改动。随后重启客户端并进行一次正常使用验证，确认系统重启、网络切换或应用重新打开后仍能工作。把最终原因与处理方式记录下来，可以避免下次再次从头排查。

如果问题暂时消失但原因仍不清楚，应继续保留触发条件和对照记录，不要把偶然恢复写成已经解决。稳定的结论应能说明故障位于账户、订阅、客户端、系统权限、网络环境、线路、DNS、分流规则或目标服务中的哪一层。系统排查的目标不是修改更多设置，而是用更少的改动得到可以重复验证的结果。