当绝大多数程序可以正常工作、只有一个应用异常时，不应把三种运行模式轮流切换当作首选动作。适用条件是内核已经在运行，入站端口、绑定地址和鉴权对其他应用有效，故障表现集中在单一客户端。设计排查步骤时，必须先拆成两问：该应用的流量有没有进入 Clash；若已进入，内核按什么全局项处理。文档中的全局配置不会描述某个客户端自己的代理开关，只能作为内核侧的判断依据。
用运行模式排除“全局已偏、却误判单应用”
运行模式可选 rule、global、direct，此项有默认值，默认为规则模式。global 是全局代理，需要在 GLOBAL 策略组选择代理或策略；direct 是全局直连。判断依据：若当前是 global 或 direct，凡是已经进入内核的流量都应走同一类处理，不应只有一个应用与众不同。若确实只有一个应用异常，更合理的解释是它没有进入内核，或进入后的来源地址、地址族、鉴权结果与其他应用不同。步骤：先读取当前 mode 是否仍是预期值；若刚改为 global 却未在 GLOBAL 组完成选择，应视为配置不完整；若 mode 为 direct，则进入内核的请求都会直连，不能用“别的软件看起来正常”证明该应用也按代理路径处理。失败时下一步：把模式恢复为 rule 后再观察该应用；仍然异常则进入进程匹配与日志，而不是继续在三种模式之间切换。
按进程匹配模式决定能否把故障收窄到该应用
find-process-mode 控制是否让 Clash 去匹配进程：always 开启并强制匹配所有进程，strict 为默认并由 Clash 判断是否开启，off 不匹配进程，推荐在路由器上使用此模式。判断依据：当你需要把“只有一个应用异常”解释成进程维度的差异时，若模式为 off，内核不会按进程识别，该应用与其他应用在进程条件上无法被区分；若为 always，则所有进程都会被匹配，结果和默认的 strict 不同。步骤：记下当前 find-process-mode；在本机需要区分该应用时不要使用 off；在路由器或无法提供进程信息的环境使用 off，此时不要把单应用异常理解成“进程条件生效了但没命中”。失败时下一步：将模式从 off 改为 strict 或 always 后重新加载，再看异常是否仍限于该应用；若始终得不到进程信息，转向鉴权、绑定地址和日志。
用日志、鉴权、地址族和出站参数做对照
日志级别仅在控制台和控制页面输出，可选 silent、error、warning、info、debug。判断依据：只有一个应用异常时，应在高于 silent 的级别里看到与该次连接有关的错误或一般运行信息；需要尽量完整的运行信息时使用 debug。HTTP(S)、SOCKS、mixed 代理可配置 authentication，并用 skip-auth-prefixes 设置允许跳过验证的 IP 段。若该应用未提供用户名密码，而其他应用来自可跳过网段，就会出现“只有它失败”。ipv6 控制内核是否接受 IPv6 流量，默认为允许；该应用若只走 IPv6 而此项关闭，会与仅使用 IPv4 的应用不同。interface-name 指定出站接口，routing-mark 为 Linux 下出站连接提供默认流量标记，tcp-concurrent 会使用 DNS 解析出的所有 IP 并采用第一个成功的连接。keep-alive-interval、keep-alive-idle 与 disable-keep-alive 用于 TCP Keep Alive，在 Android 上禁用项强制为 true，可能改变移动端长连接应用的表现。步骤：临时提高 log-level；核对该应用是否需要鉴权、是否使用 IPv6、是否依赖特定出网接口。失败时下一步：恢复日志级别，检查 allow-lan、bind-address 以及 lan-allowed-ips、lan-disallowed-ips 是否把该应用所在地址排除；禁止段的优先级高于允许段。