疑难解答手册

先建立可复现的排查方法

故障排查最容易失败的原因，不是缺少某个高级设置，而是同时改动了太多条件。切线路、换模式、改 DNS、重装客户端和重启路由器如果一起进行，即使连接恢复，也无法知道真正起作用的是哪一步；下一次发生同类问题时仍然只能反复试错。更可靠的做法是先保留现场，再一次只改变一个变量，并记录改变前后的结果。需要记录的不是笼统的“不能用”，而是客户端是否完成连接、浏览器是否能打开普通网页、只有某个应用异常还是全部应用异常、切换网络后现象是否变化，以及问题是否集中出现在某类线路。

先把链路拆成几个相互独立的层次。本地网络层负责让设备正常接入互联网；客户端层负责读取订阅、选择线路并建立连接；系统代理或隧道层负责接管应用流量；DNS 层负责把域名转换为可访问的地址；远端线路负责把请求送到目标服务；目标服务自身还可能根据地区、账户状态或访问方式返回不同结果。客户端显示“已连接”只代表握手过程完成，不等于后面每一层都正常。反过来，某个网页打不开也不能直接证明线路失效，因为浏览器缓存、域名解析和目标站状态都可能产生相似现象。

先做最小化测试

最小化测试是把复杂环境缩减到一个客户端、一条线路、一个浏览器和一个明确目标。暂时退出其他会修改网络路径的软件，关闭浏览器里的代理扩展，不要同时运行多个加速客户端。选择一条常用线路后，先访问普通网页，再测试实际需要的服务。若普通网页能够打开而特定服务失败，排查重点应转向地区、分流规则、缓存或目标服务，而不是继续重装客户端。若所有网页都失败，再检查系统代理、DNS 与本地网络。

保留一组对照条件

对照测试至少要包含“连接前”和“连接后”两种状态。断开客户端时确认本地网络能否打开原本可访问的网站；连接后再重复相同操作。如果断开时也无法访问，问题位于本地网络或设备系统，不应继续在线路列表里盲目切换。如果断开正常、连接后全部失败，重点检查客户端权限、系统代理冲突和 DNS。如果连接后只有部分服务异常，应查看规则命中与出口地区。跨设备对照同样有价值：同一网络下另一台设备正常，通常指向当前设备配置；多台设备同时异常，则更像本地网络、线路或订阅状态问题。

首次使用者应先按新手指引完成主线配置。本手册不会重复每个平台的全部安装过程，而是解释异常现象背后的判断逻辑。需要了解不同地区与线路类型时，可同时查看线路列表。排查过程中不要删除仍可工作的订阅配置，也不要把真实订阅地址粘贴到公开网页、搜索框或公开讨论区；需要提交工单时，只描述客户端中的订阅名称和错误现象即可。

完全连不上：从本地网络到握手逐层检查

“完全连不上”应进一步区分为几种状态：客户端无法启动、订阅无法载入、点击连接后立即报错、长时间停留在连接中、显示已连接但没有任何流量。它们看起来相似，实际处在不同环节。客户端无法启动属于系统权限或安装问题；没有线路可选属于订阅导入问题；连接立即失败多与线路、时间、权限或配置有关；一直连接中通常表示握手没有完成；显示已连接却无流量，则应继续检查系统代理、隧道权限与 DNS，而不是停留在“线路连不上”的判断上。

确认基础网络与系统时间

先完全断开客户端，用浏览器打开平时能够访问的网站。如果基础网络本身不通，应先重新接入当前网络，或切换到另一种可用网络进行对照。部分公共网络需要先在浏览器完成登录确认；在确认页尚未完成时，加速客户端往往无法建立稳定链路。系统日期与时间也应保持自动校准，因为明显错误的时间会影响证书验证和加密握手。调整后退出客户端并重新打开，让客户端重新读取系统网络状态。

接下来查看客户端内是否存在可选线路。如果线路列表为空、更新时间异常或订阅名称旁出现错误，应直接转到本页的订阅更新章节。若线路存在，先选择另一地区的常用线路测试，不要连续快速点击多个节点。每次切换后等待客户端完成状态转换，再打开一个新的浏览器窗口测试。旧标签页可能保留之前的连接、缓存或解析结果，用它判断新线路容易得到错误结论。

排除多客户端与系统代理冲突

同一设备同时运行多个会接管网络的客户端，是连接失败的常见来源。一个程序启用系统代理，另一个程序建立隧道，退出其中一个后又没有还原设置，都会留下“客户端看似正常、系统却没有正确出口”的状态。处理时应退出所有相关程序，只保留当前使用的客户端；随后关闭再开启一次客户端内的系统代理或隧道模式。如果客户端提示需要建立系统连接或授予网络权限，应在系统设置中确认，而不是反复点击连接按钮。

安全软件、系统防火墙和受管理网络也可能阻止客户端建立连接。这里不建议直接长期关闭防护功能。更稳妥的做法是短暂切换到另一网络进行对照：另一网络能够连接，说明客户端与订阅大体正常，应检查原网络的限制；任何网络都失败，则继续检查设备权限、客户端配置和线路。办公或校园环境若有明确网络政策，应遵循其管理要求，不要尝试修改受管设备的策略。

如果多条线路、不同网络和重启后的客户端都无法完成连接，应停止重复安装。此时更有价值的是保存报错原文、客户端类型、操作系统、所选线路名称、发生时间和基础网络是否正常。不要只提交截图中的红色提示区域，截图应包含客户端状态与线路名称，同时复制可选中的错误文字。包含这些上下文的工单更容易判断是本地权限、订阅解析还是线路握手问题。

能连接但网页打不开：代理接管与 DNS 异常

客户端显示已连接，而浏览器提示找不到服务器、连接超时或页面一直加载，说明问题已经越过了初始连接环节。此时要判断请求有没有进入客户端，以及进入后卡在域名解析、路由还是目标服务。最直接的观察方式是打开客户端的连接记录或日志，再刷新一个新网页。如果刷新时完全没有新连接出现，浏览器流量没有被当前模式接管；如果能看到域名却无法建立连接，重点检查线路和规则；如果日志里只出现解析错误，则优先处理 DNS。

判断浏览器是否绕开系统设置

部分浏览器扩展会单独设置代理，某些浏览器还会使用独立的安全 DNS。它们可能绕开系统代理，也可能把域名查询送到与当前线路不一致的解析通道。排查时先使用没有代理扩展的浏览器窗口，暂时停用会修改网络的扩展，并让浏览器跟随系统网络设置。若普通窗口失败而新建的干净环境正常，问题通常位于扩展、缓存或浏览器自己的网络策略，而不是订阅本身。

系统代理模式主要接管遵循系统设置的程序；隧道模式通常覆盖范围更广，但需要系统权限。若浏览器可以访问、其他软件不能访问，可能是后者没有读取系统代理；若任何程序都没有流量，检查客户端是否真正启用了对应模式。切换模式前应先断开当前连接，完成切换后重新连接，避免旧会话继续占用网络路径。不要同时启用多个客户端的系统代理与隧道功能。

用命令区分解析与连接问题

下面的命令使用公开示例域名，不包含订阅信息。先查询域名，再请求网页响应头。如果域名查询失败而请求也提示无法解析，问题集中在 DNS；如果能够解析出地址但连接超时，则继续检查线路、规则与目标服务。命令行结果只是定位依据，不代表最终访问体验。

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

DNS 缓存可能保留连接前的解析结果。关闭浏览器后，可以按系统使用对应的缓存刷新命令，再重新连接和测试。命令需要在系统终端中执行；系统要求管理员权限时，应确认命令内容后再授权。刷新缓存不会修改订阅或套餐。

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux:
resolvectl flush-caches

如果命令在当前 Linux 环境不可用，不要安装不相关的软件来完成刷新，直接重启系统网络连接或客户端也能让许多临时解析状态重新建立。移动端可通过断开并重新接入当前网络、退出并重开客户端来清理会话。处理后应使用新标签页测试，不要只刷新原来持续报错的页面。

只有部分网站打不开时

普通网页正常、特定服务失败时，先核对当前出口地区是否符合该服务的访问要求，再切换同地区的另一条线路。随后清除该站点的 Cookie 与缓存，或用隐私窗口排除旧会话影响。若目标服务在断开连接时也异常，应考虑服务自身状态或账户状态。若同一线路下其他设备都能访问，重点检查当前设备的浏览器扩展、DNS 与分流规则；若多台设备表现一致，再把线路名称、目标域名和错误页面文字整理进工单。

用户有时把 DNS 泄漏检测结果与“网页打不开”混为一谈。前者关注解析请求经过哪里，后者关注域名能否解析和连接能否完成。排查时先解决可用性，再根据客户端模式检查解析路径。频繁更换多个未知 DNS 地址会增加变量，可能让原本单一的线路问题变成解析与线路叠加问题。恢复客户端默认设置通常比连续尝试随机参数更容易建立可靠基线。

速度慢与晚高峰卡顿：区分带宽、延迟和拥塞

速度慢不是单一指标。网页首屏迟迟不出现，通常更受延迟、DNS 和连接建立过程影响；大文件传输缓慢更接近持续带宽问题；视频反复缓冲还会受到目标平台、清晰度自适应和线路稳定性的共同影响；交互式工具输入后等待时间很长，则可能对往返延迟更敏感。只有先描述具体慢在哪里，才能选择正确测试方法。用一次测速结果概括全部体验，往往会把目标服务的问题、无线网络波动和线路拥塞混在一起。

建立同条件对照

测试前暂停系统更新、云盘同步和后台下载，确保没有其他设备持续占用本地网络。先在断开客户端时完成一次实际任务，例如打开同一个普通网页或下载同一个公开测试文件；再连接后重复。两次测试应使用相同设备、相同本地网络和相同目标，避免一边使用无线网络、一边切到另一网络。随后只更换线路，不改变其他设置。这样才能判断瓶颈更接近本地接入、某条线路还是目标服务。

选线时先看地理距离和用途，而不是只看地区名称是否热门。距离较近的线路通常适合作为基础对照；访问有地区要求的服务，再选择符合要求的出口。专线、中转与直连的路径特征不同，不能仅凭名称推断任何时段都由某一类型占优。可在线路页面查看可用地区与线路类型，再根据当前网络逐条验证。避免在短时间内连续切换过多线路，因为缓存、旧连接和目标服务的会话仍可能沿用前一条路径。

晚高峰只卡顿时怎么判断

如果白天正常、晚间明显变慢，应先确认本地网络是否在相同时段也出现拥塞。断开客户端后访问本地可用服务，观察网页、下载与视频是否同步变慢；如果基础网络本身下降，切换远端线路只能部分改善。若基础网络稳定而某条线路反复卡顿，换到不同路径类型或邻近地区进行对照。若只有一个视频平台卡顿，而普通网页与下载正常，问题可能集中在目标平台路径、地区识别或内容分发节点，不宜直接归因于全部线路。

客户端模式也会影响表现。规则模式只让命中的流量经过线路，适合日常使用，但错误规则可能让相关域名走向不同出口；全局模式便于判断是不是分流造成问题，却不一定适合作为长期默认。排查时可短暂切到全局模式进行对照：全局正常、规则模式异常，说明应检查规则；两种模式都慢，则继续比较线路、本地网络和目标服务。完成测试后恢复适合日常使用的模式。

不要通过修改大量底层参数来追求一次测速峰值。参数与本地运营网络、系统实现和客户端模式存在关联，错误组合可能降低稳定性。更实用的目标是实际任务能够持续完成：网页响应一致、视频不频繁回退、文件传输没有长时间停滞。若多个时段、多个网络和多条线路均持续异常，提交工单时应附上测试用途、线路名称、网络类型、发生时段、连接前后差异与客户端日志。测速截图可作为补充，但不能替代这些条件描述。关于稳定性的自测方法还可参考连接成功率与断线率实测对比。

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

频繁断线需要先区分“线路会话中断”和“客户端被系统暂停”。前者通常表现为客户端仍在前台运行，但连接状态改变或日志出现重连；后者常见于锁屏、切换应用或省电后，回到客户端才发现系统已经停止其后台活动。两类问题的处理方向不同：线路会话中断要比较网络、线路与切换条件；后台暂停则要检查系统权限、电量策略和常驻连接设置。

记录断线触发条件

不要只记录“经常断”，应观察断线发生在静置、锁屏、网络切换、视频播放、文件传输还是设备唤醒之后。若每次从无线网络切换到另一网络时断开，属于底层网络接口变化，客户端通常需要重新建立会话；若保持同一网络也周期性中断，继续对比线路和本地网络稳定性；若只有锁屏后掉线，优先检查后台权限。触发条件越明确，越容易复现并判断。

在桌面系统中，休眠和唤醒会重建网络接口。唤醒后旧连接可能仍显示存在，但已经不能传输。遇到这种状态，应先在客户端执行断开再连接，而不是立即重启系统。如果能够恢复，说明问题与休眠后的会话续接有关。若无法恢复，再退出客户端、确认基础网络正常后重新启动。设备连接扩展坞、切换无线与有线网络时也会出现类似情况。

移动端后台权限

移动端系统会根据电量策略限制后台应用。应在系统设置中允许客户端保持必要的后台活动，并确认系统连接权限仍然有效。不同系统的设置名称会变化，因此不要依赖某个固定菜单路径；可从应用信息、电量管理或系统连接设置中查找与后台运行、自动启动、省电限制相关的选项。修改后重新打开客户端，建立连接，锁屏后再回到浏览器测试实际访问是否连续。

如果系统状态栏中的连接标记在锁屏后消失，通常表示客户端或系统连接被停止；如果标记仍在但应用访问失败，可能是网络切换、DNS 或会话失效。前者查看后台策略，后者执行一次断开重连并检查网络。不要同时开启多个常驻网络工具，它们可能争用同一个系统连接权限，导致其中一个在后台被替换。

线路与本地网络的对照

在同一网络下切换另一条线路，如果断线消失，说明原线路或对应路径更值得检查；多条线路都断，则切换本地网络继续对照。另一网络稳定，通常指向原网络质量、路由设备或接入策略；任何网络都不稳定，再检查客户端权限、系统时间、冲突软件和订阅配置。若同一账户在其他设备稳定，当前设备的系统策略优先级更高。14VPN 支持 Windows、macOS、iOS、Android 与 Linux，平台之间的后台管理方式并不相同，不能把桌面端的常驻逻辑直接套到移动端。

处理网络抖动时，不建议启用频繁的自动切线策略。过于敏感的切换可能把短暂波动放大成反复重连，并中断正在进行的下载、会议或长连接。先固定一条线路确认基础稳定性，再决定是否需要自动选择。工单中应写明断线时客户端是否仍运行、系统连接标记是否存在、是否发生网络切换、前后台状态、线路名称，以及重新连接能否立即恢复。若有日志，应截取故障前后相邻片段，删除其中可能包含的订阅地址后再提交。

订阅更新失败：地址、网络与缓存的分层处理

订阅更新失败与线路连接失败是两个不同阶段。订阅负责把线路配置交给客户端；线路连接则使用已经导入的配置建立会话。因此，旧线路仍能连接但无法更新，不代表全部服务立即不可用；线路列表为空也不代表所有远端线路故障，更可能是订阅没有成功读取。处理时应尽量保留当前仍可工作的配置，先新建或重新导入，确认成功后再删除旧项。

先确认订阅获取路径

客户端与订阅需要从用户面板获取。登录后进入下载相关页面，按当前平台复制或导入订阅，不要使用搜索引擎、聊天记录中的旧地址或他人提供的链接。营销页面不会提供静态安装包或真实订阅地址。需要重新获取时，可前往用户面板下载入口。注册无需邮箱地址，使用用户名与密码即可；应妥善保存登录信息，避免因无法进入面板而反复尝试旧订阅。

复制订阅时应确保没有多余空格、换行或标点。部分应用会把链接末尾的标点一并识别，导致请求地址错误。可以先粘贴到本地纯文本编辑器检查首尾，再导入客户端。不要把链接发到公开在线工具中验证。教程或文档中的示例地址仅用于说明格式，例如：

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

这个示例不是真实订阅，也不能用于连接。真实地址应只从用户面板取得，并保存在受控设备中。

判断是下载失败还是解析失败

错误提示若包含超时、连接失败或域名解析，说明客户端没有成功下载订阅内容，应先检查基础网络、系统时间和 DNS；若提示格式错误、内容为空或无法识别，说明请求可能返回了非订阅内容，或者当前客户端与导入方式不匹配。此时重新从面板选择对应平台的导入入口，不要手工修改链接参数。若浏览器能打开面板而客户端始终无法更新，检查客户端是否被另一代理设置影响，并尝试在断开当前连接后更新。

更新成功但线路列表没有变化，可能是客户端仍显示缓存。先查看订阅的更新时间或手动刷新列表，再完全退出并重新打开客户端。不要连续创建多个同名订阅，否则后续选线时很难确认实际使用的是哪一份。可以给保留的订阅使用清晰名称，确认新配置可用后再清理旧项。删除前应确保不是唯一可工作的配置。

订阅状态与流量检查

若面板显示套餐状态异常或当期流量已经用完，客户端更新和线路使用可能受到影响，应先在面板核对当前订阅。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。另有用完为止、永久不过期的流量包：¥158/300GB、¥358/1000GB、¥658/3000GB。需要比较方案时查看套餐页面，不要根据客户端里的缓存名称推断账户状态。

如果重新获取、换网络、校准时间和对应平台重新导入后仍失败，工单应附客户端名称、操作系统、错误原文、订阅更新时间、面板能否正常打开、旧线路是否仍可用。不要附真实订阅地址或完整配置文件；支持人员需要核对账户时，提供用户名与问题描述即可，不应在工单正文填写密码。

某个 App 不走代理：从模式、规则到进程检查

浏览器正常、某个 App 无法访问，是典型的流量接管或分流问题。首先确认这个 App 是否遵循系统代理。浏览器通常会读取系统设置，而游戏、命令行工具、部分桌面应用和带有自有网络栈的软件可能不会。系统代理模式下，前者正常并不能证明后者也被接管。隧道模式覆盖范围通常更广，但依赖系统权限。排查目标不是一开始就修改规则文件，而是先证明该 App 的连接有没有进入客户端。

观察连接记录与进程

打开客户端的连接记录，清空或记住当前最后一条记录，然后在目标 App 中触发一次明确请求。如果客户端出现对应域名、地址或进程，说明流量已经进入客户端，应继续查看它命中了直连还是代理规则；如果完全没有新记录，说明当前模式没有接管该 App，或者 App 使用了另一网络接口。支持进程显示的客户端中，还应确认记录对应的是实际执行程序，而不是启动器。某些 App 的界面进程与网络进程并不相同，只给启动器设置规则可能不会生效。

短暂切换到全局模式是有效的对照方法。全局模式下恢复，说明线路可用，问题集中在规则匹配；全局模式仍失败，则应检查 App 自身设置、目标地区、DNS 和线路。完成判断后不要忘记恢复原有模式。若客户端支持按域名、进程或应用设置规则，应优先使用可读、范围明确的条件，避免加入覆盖面过大的通配规则。规则范围越大，越容易让无关流量改变路径。

检查 App 内部代理设置

部分 App 有独立代理选项。它可能被设置为直连，也可能保留了旧客户端的本地地址，从而绕开当前系统设置。排查时将其恢复为跟随系统，或按当前客户端提供的本地代理信息配置。不要从其他教程复制端口与地址，因为这些值取决于当前客户端设置，事实是否一致只能在本机客户端中确认。若 App 支持“自动检测”与“手动代理”，优先从跟随系统开始测试。

命令行工具同样可能读取环境变量。可以在终端检查当前环境中是否残留代理变量：

Windows PowerShell:
Get-ChildItem Env: | Where-Object Name -Match 'PROXY'

macOS / Linux:
env | grep -i proxy

如果输出指向已经退出的旧客户端，应在当前终端会话或系统环境设置中清理对应变量，再重新打开终端。不要直接复制未知的删除命令；先确认变量名称与来源。若没有相关变量，而命令行请求仍不进入客户端，可使用隧道模式进行对照，或按当前客户端文档设置本地代理。

域名、地区与缓存

一个 App 可能同时连接登录域名、接口域名、静态资源与长连接服务。只为主域名添加规则，可能出现界面能打开但内容加载失败。观察连接记录时应在完整操作过程中收集相关域名，并检查它们是否走向一致的出口。不要仅凭网上的旧域名清单批量添加规则，因为服务端域名会变化。以当前连接记录为依据更可靠。

如果 App 对出口地区有要求，应选择符合其服务条件的线路，并清除 App 内缓存或重新登录后测试。旧会话可能继续保留连接前的地区信息。AI 绘图工具与 Discord 生态的网络特点可参考Midjourney 加速器连接要求详解。若应用在全局模式下仍失败，而同线路浏览器访问相关网页正常，应把 App 名称、系统平台、失败操作、错误原文、当前模式和连接记录整理后提交工单，不要只写“这个 App 用不了”。

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

14VPN 不限设备台数。如果客户端出现“设备数超限”“会话异常”或类似提示，不应据此自行推断套餐存在设备上限。先确认提示来自当前客户端、目标服务还是系统网络组件。某些目标服务会限制自己的登录会话，某些客户端也会把配置冲突、重复授权或旧连接描述为设备问题；这些提示并不等同于 14VPN 套餐限制。判断时应保留完整提示页面，查看它出现在哪个应用、执行了什么操作，以及退出目标服务账户后是否仍然存在。

先排除账户与配置混用

确认当前设备导入的是本人账户从用户面板取得的订阅，不要混用历史账户、他人配置或来源不明的订阅。多个设备可以使用同一账户的有效订阅，但每台设备都应从受控来源导入，并避免公开分享真实订阅地址。若某台设备异常、其他设备正常，重新从面板获取订阅并在异常设备中建立一份清晰的新配置；确认新配置可用后再删除旧配置。若所有设备同时出现账户状态问题，应直接在面板核对订阅状态和流量，而不是逐台重装。

登录面板失败时，先核对用户名与密码。注册无需邮箱地址，因此账户识别以用户名为准。不要在多台设备上反复修改不同配置后再提交问题，这会破坏对照条件。应选一台最容易复现的设备作为主测试环境，保留另一台正常设备作为对照。支付相关问题需要说明所选套餐与支付方式；本站支持支付宝、微信与 USDT。工单中不应发送支付密码、账户密码或完整订阅地址。

什么时候应该停止自查

完成基础网络、另一网络、另一条线路、单客户端环境和重启后的对照，问题仍能稳定复现时，就应提交工单。出现账户状态与面板显示不一致、订阅持续无法获取、多条线路在不同网络下同时失败、同一错误在多个平台重复出现，也适合交由支持人员检查。相反，如果问题只在某个浏览器扩展、某个目标服务账户或受管理网络中出现，应先处理对应环境，因为支持人员无法远程改变第三方服务状态或组织网络策略。

工单附件怎样准备

截图应包含足够上下文：客户端状态、线路名称、错误提示与发生操作。裁剪掉无关桌面内容可以保护隐私，但不要只截取一个没有标题的报错框。文本日志比单张截图更适合分析连接过程，应截取故障发生前后的相邻内容。提交前搜索并删除真实订阅地址、访问令牌、密码和其他凭据。若日志过长，可先复现一次，再导出这次操作附近的内容。

描述时间时写清发生时段与时区，描述网络时写明是家庭、办公、公共网络还是其他接入环境，不需要提供详细地址。描述线路时使用客户端显示的完整名称。速度问题应说明具体任务，例如网页首次加载、持续下载、视频缓冲或交互延迟，并附连接前后的对照；断线问题应说明是否锁屏、切网、休眠或后台运行；订阅问题应说明是下载失败、解析失败还是刷新后仍显示旧内容。

问题类型：
操作系统与客户端：
使用线路：
基础网络是否正常：
具体操作与错误原文：
是否能够稳定复现：
更换线路后的结果：
更换网络后的结果：
已完成的排查步骤：
附件内容：

提交后应保持测试环境相对稳定。如果支持人员要求复现某一步，再按指定条件测试并反馈结果，不要在等待期间同时更改客户端、规则、DNS 与网络设备。每次只验证一个假设，才能让日志与反馈互相对应。需要进入用户面板提交请求时，可使用工单入口。如果问题最终与套餐选择有关，可查看套餐说明；14VPN 提供 7 天无理由退款，具体服务条款以站内条款页面为准。

系统排查的目标不是记住所有命令，而是建立稳定的判断顺序：先确认基础网络，再确认订阅和客户端，然后确认流量接管、DNS、线路与目标服务，最后通过对照测试缩小范围。只要现象、条件和改变后的结果记录清楚，大多数“偶尔不能用”的模糊问题都能转化成可复现、可处理的具体问题。