01 · 建立可复现条件
排查基线：先确认故障发生在哪一层
把连接路径拆成六段
Clash 的一次访问并不是“客户端到网站”两点直连。完整路径至少包含应用程序、系统代理或 TUN 接管、本机监听端口、Clash 规则匹配、代理节点和目标站点六段。浏览器打不开页面，只能说明其中至少一段失败，不能直接得出节点失效或订阅损坏的结论。正确做法是从离设备最近的一段开始验证：先确认普通网络可用，再确认 Clash 进程存在，然后检查端口、代理组、规则命中、节点连接和目标站点状态。由近到远排查，可以避免在远端节点上反复切换，却遗漏本机端口冲突这类基础问题。
开始前记录当前环境。至少写下操作系统、客户端名称、网络类型、代理模式、所选代理组、问题只影响单个应用还是全部应用，以及关闭 Clash 后网络是否恢复。Windows 和 macOS 桌面端可优先使用 Clash Plus；其他可选客户端与系统要求见下载中心。如果问题出现在刚安装后的第一次连接，应先按快速上手教程完成基础配置，再进入故障分支。若此前能够使用，还应记录最近一次变更，例如系统升级、订阅更新、切换 WiFi、安装安全软件或修改配置文件。
建立最小测试环境
最小测试环境只保留一个浏览器、一个已知可用的配置文件和一个代理节点。先退出其他代理、VPN、网络过滤器、抓包工具与本地开发代理，避免多个程序同时改写系统代理或占用同一端口。关闭浏览器中的独立代理扩展，使用普通窗口测试；扩展可能绕过系统设置，也可能保留旧端口。临时切到规则模式，代理组选定一个具体节点，不要先用自动选择或负载均衡组。自动组会在后台切换目标，使两次测试条件不一致，不利于判断故障究竟来自节点还是策略。
基础配置应保持简单。常用监听字段可以先缩减到混合端口、局域网开关、规则模式和日志等级。修改前备份原文件，修改后在客户端中重新载入，而不是只保存文本。下面的片段适合本机验证；若客户端通过图形界面管理这些字段，应以界面生成的配置为准，避免界面设置与手写文件相互覆盖。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090mixed-port同时接受 HTTP 与 SOCKS 连接，便于减少端口混淆；allow-lan: false把测试范围限制在本机；mode: rule保留真实规则路径；log-level: info通常足以观察规则命中与连接错误。排查完成后再恢复局域网共享、脚本、覆写和复杂 DNS。不要一开始把日志调到极高详细度，大量重复输出会淹没最早出现的关键错误，也会增加移动设备的存储与耗电压力。
日志要看第一处失败
日志阅读顺序是时间、目标、规则、策略、节点和错误。先清空或记住当前时间，再只发起一次访问。若日志完全没有新增记录，问题通常发生在应用到 Clash 之间，应检查系统代理、浏览器代理或 TUN 接管。若日志出现目标域名和规则，却没有建立出站连接，应继续看代理组与节点。若连接已发出但返回证书、重置、拒绝或超时，则应检查时间、DNS、网络限制和远端状态。不要只截取最后一行；上一行往往包含使用了哪条规则、哪个代理组以及实际目标地址。
每轮只改变一个变量，并把结果记为“恢复、无变化或症状改变”。例如先换节点，确认结果后再改模式；不要同时换节点、刷新订阅、改 DNS 和重启路由器。症状改变同样有价值：从完全无日志变成连接超时，说明系统代理链路已经恢复，下一步应转向节点与网络层。完成一轮后，可以根据最明显的症状进入后文章节；若同时存在多个症状，优先解决“进程无法启动、无日志、所有节点均失败”这类上游问题。
02 · 页面全部打不开
Clash 无法上网：区分本地网络、代理接管与规则出口
先做关闭与开启对照
无法上网的第一步不是连续更换节点，而是做两组对照。完全退出 Clash，并确认系统代理已关闭，然后访问一个平时稳定的网站。如果此时仍无法访问，故障位于基础网络、路由器、运营网络或系统 DNS，继续调整 Clash 不会解决问题。若退出后立即恢复，说明异常位于代理接管之后。重新启动客户端，但先不要开启系统代理，只观察客户端是否正常载入配置、是否存在解析错误、控制面板是否能显示代理组。客户端本身正常后，再开启系统代理进行第二次访问。
“退出”必须是结束进程，而不只是关闭窗口。部分桌面客户端关闭主窗口后仍留在托盘，并继续保持系统代理。Windows 可检查通知区域和任务管理器，macOS 可检查菜单栏和活动监视器。若强制结束进程后网络恢复，而正常退出后仍断网，通常是退出时未还原系统代理。可先在系统网络设置中把代理服务器关闭，再重启客户端。不要直接删除未知网络配置；先记录原值，尤其是企业网络或开发环境可能本来就使用固定代理。
确认本地监听端口
系统代理指向的地址必须与 Clash 实际监听一致。常见本机地址是 127.0.0.1，混合端口可设为 7890，但具体值以当前配置为准。若系统仍指向旧端口，浏览器会把请求交给一个不存在的服务，表现为所有页面立即失败。端口也可能被另一个进程占用，客户端日志通常会出现地址已被使用或监听失败。此时要么结束占用程序，要么同时修改 Clash 监听端口与系统代理端口，不能只改其中一处。
# Windows：查看 7890 端口
netstat -ano | findstr :7890
# macOS / Linux：查看监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN若命令没有输出，说明端口没有成功监听；若进程不是当前 Clash 客户端，应先确认它的用途。端口可监听并不等于流量一定能出站，还需查看请求是否进入日志。浏览器发起访问时，日志完全静止通常表示系统代理未生效或应用绕过了系统设置；日志出现请求但全部走向 DIRECT，则应检查模式和规则；日志进入代理组后失败，再转到节点超时章节。
用模式切换缩小范围
临时切换到全局模式并选择一个具体节点，只用于诊断。若全局模式可以访问，而规则模式不行，节点和本地端口基本正常，重点检查规则顺序、规则集下载和最终 MATCH。规则由上到下匹配，先命中的规则会终止后续判断。过于宽泛的 DOMAIN-SUFFIX、错误的 GEOIP 出口或提前出现的 MATCH,DIRECT，都可能让目标流量走向错误策略。修正规则后应恢复规则模式，不应长期用全局模式掩盖配置错误。
如果全局模式也失败，再将同一节点用于另一个网络测试，例如从家庭 WiFi 切换到手机热点。热点可用而原网络不可用，说明配置与节点大概率正常，应检查路由器、防火墙、IPv6 路径或当前网络对特定连接的限制。两个网络都失败时，换一个不同线路的节点；若只有一个节点失败，问题局限在节点。若所有节点都失败但直连正常，检查订阅内容是否完整、系统时间是否准确、客户端内核是否正常加载，以及安全软件是否拦截客户端联网。
部分应用使用 UDP、QUIC 或自带网络栈，浏览器正常并不能证明所有应用都正常。可先关闭目标应用的 QUIC 或改用 TCP 测试，再检查节点是否支持 UDP。局域网共享场景还要确认访问设备把代理地址设置为运行 Clash 的主机局域网地址，而不是 127.0.0.1；后者永远表示访问设备自身。共享配置需要同时启用 allow-lan、监听合适地址并放行系统防火墙，具体端口关系可参考混合端口与局域网共享说明。
03 · 节点显示超时
节点超时：判断测试地址、握手阶段与网络路径
延迟测试不是完整速度测试
客户端显示“超时”通常表示在限定时间内未完成对测试地址的连接或 HTTP 请求，不一定表示节点对所有目标都不可用。测试过程会经过本地网络、节点入口、节点出口、DNS 和测试站点，其中任一环节变慢都可能触发超时。不同客户端使用的测试地址、超时阈值和是否复用连接可能不同，因此同一节点在 Clash Plus、Clash Verge Rev 或其他客户端中的结果不必完全一致。延迟数字也不等于下载速度，详细原理可阅读节点延迟测试原理。
先选择一个节点并实际访问两个不同目标：一个普通网页和一个小型静态资源。若实际访问正常，只是面板测试超时，重点检查测试 URL 是否能从该节点出口访问，以及订阅中的健康检查参数。若实际访问同样失败，再观察日志中的错误阶段。连接拒绝通常表示目标端口没有服务或入口拒绝连接；连接超时更像是数据包无响应；TLS 握手错误应检查系统时间、证书链、SNI 与中间网络；名称解析失败则先进入 DNS 章节。
比较单节点、代理组与网络
自动选择组的超时不代表组内所有节点都超时。展开代理组，手动选择具体节点，并在同一网络下连续测试两次。第一次可能包含 DNS 与握手成本，第二次可用于确认是否稳定。随后切换到不同地区或不同协议的节点重复测试。如果只有同一批节点失败，可能是订阅侧线路维护、入口地址变化或协议参数失配；如果所有节点同时失败，优先考虑本机防火墙、网络限制、系统时间和配置解析，而不是逐个删除节点。
再使用手机热点做网络对照。热点恢复说明客户端、配置和节点至少可以建立连接，原 WiFi 路径需要检查。公共网络常要求先完成网页认证；在开启代理前访问一个普通 HTTP 页面，完成认证后再启动 Clash。企业网络可能只允许有限的出站端口，家庭路由器则可能存在 IPv6、MTU 或 DNS 转发问题。不要把“换热点可用”简单归结为节点波动，它明确说明故障与接入网络相关，应保留该证据。
检查时间、IPv6 与 MTU
TLS 连接依赖准确的系统时间。设备时间偏差较大时，证书可能被判断为尚未生效或已经过期，日志会出现握手或证书错误。启用系统自动校时后重启客户端再测。IPv6 场景中，域名可能优先解析到 AAAA 地址，但当前节点或本地网络没有稳定的 IPv6 出口，表现为部分目标长时间等待后失败。诊断时可临时关闭配置中的 IPv6，重新载入并清理 DNS 缓存；若问题消失，再决定是保持关闭，还是修复本地与节点的 IPv6 支持。
小页面能打开、大文件或部分应用卡住，可能与 MTU 有关。TUN 模式会增加封装层，某些网络又不能正确处理分片，导致较大的数据包丢失。可先关闭 TUN，仅使用系统代理测试；若系统代理正常而 TUN 超时，应检查客户端提供的 MTU 设置、系统虚拟网卡和其他 VPN 驱动。MTU 不应凭感觉大幅调整，应逐步降低并用相同目标复测。恢复正常后记录有效值，同时确认局域网与热点是否需要不同设置。
| 日志表现 | 优先检查 | 下一步 |
|---|---|---|
| connection refused | 节点地址、端口、远端服务 | 换同订阅中的其他节点并联系服务提供方 |
| i/o timeout | 接入网络、防火墙、路由路径 | 切换热点，比较不同协议节点 |
| TLS handshake error | 系统时间、SNI、证书与中间网络 | 自动校时，核对节点参数 |
| no such host | DNS 上游与域名拼写 | 按 DNS 章节检查解析链 |
健康检查参数也会造成误判。测试地址应返回稳定、体积小且无需登录的响应，检查间隔不宜短到持续占用移动网络，超时时间也不应低于当前网络正常握手所需时间。配置提供者若下发了多个自动组，应分别确认它们引用的节点集合和测试地址。修改健康检查只能改善检测准确性，不能修复真正失效的节点。最终判断应结合实际访问、日志阶段、不同网络对照和同组其他节点结果。
04 · 配置无法更新
订阅失败：检查链接、响应内容、解析与配置覆盖
先区分下载失败和解析失败
订阅更新包含两个独立阶段：客户端先通过网络下载内容，再由内核解析为配置。下载阶段失败时，常见表现是连接超时、状态码异常、证书错误或无法解析订阅域名；解析阶段失败时，通常已经收到内容，但 YAML 语法、字段类型、节点参数或规则提供器格式不符合要求。两类问题处理方向完全不同。应在日志中找到首次错误，并判断是否出现 HTTP 状态、响应体长度或 YAML 行号。只看到“更新失败”提示时，应打开详细日志或配置管理页查看具体原因。
复制订阅链接时要保留完整查询参数。聊天软件可能截断链接、把特殊字符转义或在末尾加入标点。最稳妥的做法是从服务提供方后台使用复制按钮，再粘贴到纯文本编辑器检查：链接应以 https:// 开头，不应包含空格和换行。若订阅需要临时令牌，旧链接可能在重置后失效。不要把订阅链接粘贴到公开日志、截图或在线解析工具，其中通常包含访问凭据。
验证网络响应而不暴露链接
可以在浏览器中直接访问订阅链接，观察是否下载文本、跳转到登录页或返回错误页面。若浏览器也无法访问，问题不在客户端解析，应检查基础网络、域名解析、账户状态和服务端限制。若浏览器能下载而客户端不能，确认客户端更新订阅时是直连还是经过当前代理。有些订阅域名在当前网络不可达，需要先用已有配置建立连接再更新；也可能相反，错误代理规则让订阅请求走向失效节点，此时可临时关闭代理后更新。
命令行验证时不要把完整链接写入共享终端记录。可在本机临时环境中执行请求，并只查看响应头和前几行。预期响应通常是 YAML 配置或编码后的订阅内容，而不是 HTML 登录页。状态为成功但内容是网页时，客户端仍会在解析阶段失败。遇到多次跳转，应确认最终域名证书正常、设备时间准确，并检查网络认证页面是否劫持了请求。
定位 YAML 行号和字段类型
解析错误通常会给出行号。先在文本编辑器中检查该行及其上一行，因为缺少引号、缩进错误或冒号后没有空格，常在下一行才被发现。YAML 使用空格缩进，不能混用制表符。包含冒号、井号或特殊符号的文本值应加引号。布尔值使用 true 或 false，端口应是数字。代理组引用的节点名必须与节点列表完全一致，大小写和空格都算差异。
proxy-groups:
- name: "节点选择"
type: select
proxies:
- "自动选择"
- "DIRECT"
rules:
- DOMAIN-SUFFIX,example.com,节点选择
- GEOIP,CN,DIRECT
- MATCH,节点选择若订阅原文件能够解析，但经过客户端覆写后失败，应暂时关闭脚本、合并配置、规则覆写和自定义模板，再重新导入原始订阅。不同客户端对覆写顺序的实现可能不同，旧模板还可能引用已经删除的代理组。恢复后逐项开启，每启用一项就重新载入并观察日志。这样可以确定是上游订阅错误，还是本地覆写造成结构冲突。多设备共用配置时，还要留意路径、外部规则文件和平台专属字段，相关取舍可参考多设备配置同步方案。
处理更新后旧配置仍生效
更新成功不代表当前运行配置已经切换。部分客户端把“下载配置”和“激活配置”分成两个动作；订阅列表显示新时间后，还需选择该配置并重新载入。若界面仍展示旧代理组，检查当前配置名称、文件路径和更新时间，避免更新了同名的另一个条目。可以给测试配置临时改一个容易辨认的组名，确认内核实际载入的是哪份文件，完成后再恢复。
订阅频繁自动更新失败时，应适当延长更新间隔，并避免多个设备在同一时刻重复请求。移动系统可能在后台暂停客户端，使定时任务不能准时执行，这不等于链接失效。最终判断标准是手动更新能否取得有效内容、内容能否通过解析、当前内核是否已载入新配置。若服务端明确返回权限或额度错误，应由订阅提供方处理；客户端无法通过本地修改绕过服务端授权。
05 · 能连接但速度慢
速度慢：分别测延迟、吞吐、丢包与规则路径
先定义“慢”的具体表现
速度问题至少分为首屏打开慢、持续下载慢、视频缓冲、游戏抖动和间歇性断流。它们对应的指标不同：首屏更受 DNS 与握手延迟影响，持续下载取决于带宽和拥塞，实时应用更敏感于丢包与抖动。只看客户端显示的毫秒数无法覆盖这些差异。排查时应使用同一设备、同一网络、同一目标和相近时间段，对比直连、一个固定节点与另一个固定节点。自动选择组会改变出口，不适合作为基准。
测试前暂停系统更新、云盘同步、视频播放和其他设备的大流量任务。浏览器测速可能受到扩展、缓存和 QUIC 影响，可使用隐私窗口并重复两到三次。不要连续高频测速，它会占满线路并使后续结果失真。记录首字节时间、稳定下载阶段的速度以及是否存在突然归零。若直连同样慢，应先解决本地 WiFi、路由器负载或运营网络问题；若只有代理慢，再比较节点、协议和规则路径。
确认目标实际走了哪个出口
规则模式下，不同域名可能进入不同代理组。网页主域名走代理，不代表图片、视频分片和 API 使用同一出口。打开连接记录，搜索目标域名，查看命中的规则和策略。错误规则可能让静态资源直连、让本应直连的服务绕远，或把多个大流量域名送入拥挤节点。规则按从上到下的顺序匹配，具体写法和顺序可参考Clash 规则分流实战。
临时切到全局模式并固定同一节点，可以验证规则是否造成差异。全局明显更快时，不要直接长期保留全局模式，而应比较连接记录，找出规则模式下走向不同策略的域名。若两种模式都慢，规则不是主因。再换同地区不同节点，若只有一个节点慢，通常是该线路拥塞或出口质量问题；若所有节点在当前 WiFi 都慢、热点正常，应检查本地网络、MTU、IPv6 和路由器的流量管理。
DNS、连接复用与协议差异
DNS 响应慢会让每个新域名都等待，但已经建立的下载连接可能保持正常。表现为首次打开慢、刷新后较快或页面中部分资源迟迟出现。此时观察日志中域名解析耗时，并比较 Clash DNS 与系统 DNS。不要同时启用多个互相转发的本地 DNS 工具，否则请求可能形成长链甚至循环。Fake-IP 模式下，应用先得到保留地址，再由 Clash 映射真实域名；映射缓存异常或应用绕过系统解析时，也会表现为间歇性卡顿。
部分网络对 UDP 不稳定，而浏览器可能优先使用 QUIC。可临时禁用浏览器 QUIC或让相关流量回落到 TCP，若稳定性改善，说明问题集中在 UDP 路径。节点标注支持 UDP 也不保证当前接入网络、路由器和出口路径都稳定。游戏与语音应用应关注连续丢包，而不是只追求最低延迟。TUN 模式负责接管更多流量，但也引入虚拟网卡与额外封装；系统代理更快而 TUN 较慢时，应检查 MTU、网卡驱动和排除路由。
自动选择组需要合理参数
自动选择通常依据健康检查结果选择节点，但测试地址与真实业务路径不同，最低测试延迟不一定对应最高吞吐。适合网页的节点未必适合大文件或实时应用。可为不同用途建立独立代理组：日常浏览使用自动选择，下载或视频使用手动固定，直连服务保持 DIRECT。不要把几十个质量差异很大的节点放进一个频繁检测的组，持续测试会消耗资源，也可能导致出口反复切换。
速度在固定时段下降，常见原因是线路拥塞或本地无线干扰。使用有线网络或靠近路由器复测，区分 WiFi 与远端路径；同时比较同一节点在非高峰时段的表现。若大文件开始快、随后持续下降，可能是出口限速、拥塞控制或服务端限流；若速度周期性归零再恢复，更像丢包、网络切换或连接重建。应保留时间、节点和目标记录，再决定更换线路，而不是根据单次测速立即重写全部配置。
06 · 域名解析异常
DNS 问题：检查解析入口、模式、缓存与回退链
识别 DNS 故障特征
DNS 问题常表现为输入域名打不开、直接访问已知地址有响应、部分域名正常而另一些域名失败，或切换网络后旧结果持续存在。日志中可能出现 no such host、解析超时、上游不可达或 Fake-IP 映射缺失。证书名称不匹配也可能来自错误解析，但还需排除系统时间和网络认证页面。先选择一个失败域名，分别记录系统解析结果与 Clash 日志中的解析过程，不要用大量不同域名同时测试。
DNS 路径可能经过浏览器安全 DNS、系统解析器、本地过滤程序、Clash DNS、路由器和上游服务器。链路越长，越容易出现循环、缓存不一致与分流错误。排查时应临时关闭浏览器独立安全 DNS和其他本地 DNS 工具，让请求只经过系统与 Clash。若浏览器恢复而其他应用原本正常，问题多半在浏览器独立解析；若所有应用都失败，继续检查 Clash DNS监听、TUN 劫持与上游可达性。
理解 redir-host 与 Fake-IP
redir-host通常返回真实解析地址，再由规则处理连接；Fake-IP 会先从保留地址段返回一个映射地址，使 Clash 能保留域名信息并更早执行规则。Fake-IP 并不是远端节点地址，也不应被手动写入 hosts。某些局域网设备、游戏、企业应用或使用特殊 DNS 行为的软件与 Fake-IP 兼容性较差，可以加入过滤列表，让这些域名返回真实地址。过滤应针对明确复现的域名，不要用过宽通配符把大部分请求排除在外。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 1.1.1.1
- 8.8.8.8示例用于展示字段关系，不代表所有网络都应使用同一上游。ipv6: false适合作为诊断开关；确认 IPv6 路径稳定后可以重新开启。上游 DNS 必须在当前网络条件下可达，若上游本身需要代理，而代理建立又依赖该 DNS，就可能形成启动循环。复杂配置可设置用于解析代理节点域名的独立上游，但应确保这部分能够在代理尚未建立时工作。
排查缓存与监听冲突
修改 DNS 后要同时考虑 Clash 缓存、系统缓存和浏览器缓存。先重新载入配置并重启客户端，再刷新系统解析缓存，最后关闭并重新打开浏览器。只刷新网页可能继续使用旧连接或浏览器内部缓存。Windows 可使用 ipconfig /flushdns，macOS 可通过系统命令刷新缓存，移动端通常通过切换飞行模式或重启网络连接清理部分状态。清理动作只用于验证，不应成为每次连接都必须执行的固定步骤。
若 Clash DNS 需要监听本地 53 端口，系统服务、容器工具或其他 DNS 程序可能已经占用该端口。日志会出现绑定失败，导致 TUN 劫持后的查询没有响应。检查实际监听进程，并决定由哪个程序负责入口解析。不要让两个服务互相把上游指回对方。例如系统 DNS 指向本地过滤器、过滤器指向 Clash，而 Clash 又指回系统默认 DNS，就可能形成循环。最小链路应有明确入口和明确外部上游。
处理 IPv6 与分流解析
域名同时返回 A 与 AAAA 记录时，应用可能优先尝试 IPv6。若本地有 IPv6 地址但出口不完整，请求会等待超时后才回落到 IPv4，看起来像 DNS 很慢。临时关闭 Clash DNS 中的 IPv6 返回可验证这一点。若关闭后恢复，应继续检查路由器前缀、系统默认路由和节点的 IPv6 支持，而不是把所有解析异常都归为上游 DNS 故障。
分流解析配置会根据域名选择不同上游，适合减少错误解析，但规则与代理出口必须一致。某域名由直连 DNS 解析，却最终经代理访问时，返回地址可能不是代理出口最合适的结果；反过来也一样。检查连接记录中的域名、解析地址和规则策略，确认三者符合预期。出现单个域名异常时，先添加精确规则验证，不要立即更换全局 DNS。若只有特定服务持续失败，还应确认该服务是否依赖多个关联域名，而不只是地址栏中的主域名。
07 · 开关已启用但应用直连
系统代理不生效：核对端口、绕过列表与应用代理模型
系统代理只影响遵循系统设置的应用
开启系统代理后，客户端只是把操作系统的 HTTP、HTTPS 或 SOCKS 代理地址指向本地 Clash 端口。是否使用该设置由应用决定。主流浏览器通常遵循系统代理，但游戏、命令行工具、商店应用、虚拟机和部分跨平台程序可能完全忽略。因而“浏览器可用、某个应用直连”不等于系统代理开关失效。先用遵循系统代理的浏览器确认基础链路，再查目标应用是否支持显式代理，或是否需要 TUN 模式接管。
检查系统设置中的服务器地址和端口。地址通常为 127.0.0.1，端口应与当前 mixed-port 或对应 HTTP 端口一致。配置更新或切换客户端后，端口可能改变，而系统仍保留旧值。使用 Clash Plus 与 Clash Verge Rev 等多个客户端时，不要同时开启系统代理；后启动的程序会覆盖设置，退出顺序又可能恢复成更早的旧值。排查期间只保留一个客户端运行。
浏览器与命令行需要分别验证
浏览器可能安装独立代理扩展，扩展设置会覆盖系统代理。临时禁用扩展并重新启动浏览器。隐私窗口不一定禁用所有扩展，应在扩展管理页确认。命令行工具通常读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，系统图形界面的代理设置未必会自动传递。设置变量时要区分 HTTP 与 SOCKS 协议，并注意当前终端与全局环境的作用范围。
# 仅对当前 shell 设置 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
# 完成测试后清除
unset HTTP_PROXY
unset HTTPS_PROXYWindows PowerShell、开发工具和容器各有自己的代理配置入口。不要为了让单个命令生效而同时修改系统、Git、包管理器、容器和编辑器全部设置，否则故障恢复后很难还原。先在当前终端临时设置，确认请求进入 Clash 日志；成功后再决定是否持久化。若日志没有请求，说明该工具仍未使用指定代理；若日志有请求但失败，应转向规则或节点问题。
检查绕过列表与自动配置
系统代理通常允许配置不经过代理的主机列表。localhost、局域网地址和企业内网常被绕过，但过宽的通配符可能误伤普通域名。Windows 还可能同时启用自动检测或 PAC 脚本，macOS 不同网络服务也分别保存代理设置。关闭 Clash 后若系统仍显示代理，检查是否存在自动代理脚本、管理策略或另一个常驻程序。修改前记录原设置，受组织管理的设备不要强行移除策略。
局域网地址通常应直连，避免访问路由器、打印机或文件共享时绕到代理节点。若开启 TUN 后局域网资源消失，检查排除路由、私有地址规则和严格路由设置。系统代理模式与 TUN 模式可以覆盖不同流量，不应把二者简单叠加后再判断问题。诊断时先单独测试系统代理，再单独测试 TUN；两者分别正常后，才考虑是否需要共同开启。
处理退出后的残留代理
客户端崩溃、强制结束或系统关机时，代理设置可能来不及还原。典型表现是重启后所有遵循系统代理的应用立即连接失败，而 Clash 尚未运行。解决时先在系统网络设置中关闭手动代理，再启动客户端并正常切换一次系统代理。若频繁发生，检查客户端是否有服务模式、守护进程或开机自启权限问题，并确保使用当前维护的客户端版本。重新安装前应先导出必要配置，并从下载中心选择对应平台安装包。
企业安全软件可能阻止程序修改系统代理，界面开关看似开启，但系统值没有变化。此时直接查看系统代理页面比观察客户端按钮更可靠。也可能出现相反情况：系统值已修改，但安全软件阻止本地监听端口通信。用端口检查命令确认 Clash 正在监听，再观察浏览器请求是否进入日志。系统设置、端口监听和日志请求三项同时成立，才能确认系统代理链路已经建立。
08 · 无法启动或反复退出
客户端崩溃：分离界面、内核、配置与系统组件
先确认崩溃发生阶段
客户端崩溃可发生在启动界面、载入配置、启动内核、开启 TUN 或执行订阅更新等不同阶段。阶段决定排查方向。双击后完全无窗口，应查看系统事件记录、应用日志目录和安全软件拦截记录；窗口出现后在载入配置时退出，优先怀疑配置语法、超大规则集或覆写脚本；只在开启 TUN 时退出，则重点检查虚拟网卡、服务权限和其他 VPN 驱动。不要只描述“打不开”，应记录最后能看到的界面与最后一条日志。
先关闭自动恢复上次配置或开机自启，避免程序一启动就重复载入故障状态。若客户端提供安全模式或可指定配置路径，可用最小配置启动。没有安全模式时，先退出进程，备份配置目录，再把当前激活配置移出原位置，让客户端以空状态启动。成功进入界面后，不要立刻导回整个目录；先导入一个基础配置，确认内核能够运行，再逐步恢复订阅、覆写和界面设置。
区分图形界面与内核问题
图形客户端负责配置管理和系统集成，实际代理通常由 mihomo 等内核进程完成。界面存在但内核反复停止时，应查看内核日志中的配置错误、端口占用和权限问题；界面自身无响应但内核仍在运行时，网络可能暂时可用，问题则偏向界面缓存、渲染组件或配置列表过大。任务管理器或活动监视器可帮助确认哪个进程退出。不要在内核仍运行时反复启动多个界面实例，它们可能竞争控制端口与配置文件锁。
配置验证应先排除语法，再排除资源规模。大型规则集、过多代理节点和频繁健康检查会增加启动时间与内存占用。程序短暂无响应不一定已经崩溃，可观察 CPU、内存和日志是否继续变化。若每次都在同一个规则提供器加载后停止，临时禁用该提供器或清理其缓存后重试。远程规则文件下载不完整也可能留下损坏缓存，删除前应确认文件可以由订阅重新取得。
检查端口、权限与驱动冲突
混合端口、控制端口和 DNS 端口被占用时，内核可能启动失败。使用前文命令查看占用进程，并核对配置中是否意外重复定义监听地址。低位端口或 TUN 设备可能需要额外权限，但不应把长期以管理员身份运行当作唯一解决方案。先确认客户端提供的服务组件是否正确安装、系统扩展是否获准、虚拟网卡是否存在。macOS 系统升级后可能要求重新授权网络扩展，Windows 安全策略也可能阻止驱动加载。
其他 VPN、虚拟机网络、容器平台、游戏加速器和安全软件都可能安装网络过滤驱动。即使这些程序没有打开，后台服务仍可能运行。出现只在 TUN 模式崩溃或断网的情况，应完全退出相关服务后复测。若普通系统代理稳定，说明基础内核和节点可用，故障集中在虚拟网卡链路。逐个恢复其他网络软件，可以确定具体冲突项，而不是一次性卸载所有工具。
重置与重装的正确顺序
重装程序通常不会自动删除用户配置，因此损坏设置可能在重装后继续生效。正确顺序是先导出订阅地址以外的必要信息，记录自定义规则和端口，然后退出客户端并备份配置目录。重命名原目录，让新安装首次启动生成干净配置；确认空状态稳定后，再从订阅重新导入。不要直接复制整个旧目录覆盖新目录，这会把缓存、窗口状态和故障配置一并恢复。
若系统事件记录显示缺少运行组件、文件权限异常或程序被隔离，应按系统提示修复。安装包必须与处理器架构和系统平台匹配，Apple Silicon 与 Intel、Windows x64 与其他架构不能混用。当前客户端选择与平台支持见下载中心，桌面平台优先考虑 Clash Plus。完成恢复后，再开启开机自启与 TUN，每次只开启一项并重启验证，确保崩溃不是由启动顺序或权限恢复造成。
09 · Android 与 iOS
移动端专项：后台限制、VPN 权限与网络切换
先确认 VPN 配置与系统状态
Android 与 iOS 上的 Clash 类客户端通常通过系统 VPN 接口接管流量。首次连接需要用户明确授权，系统状态栏应出现 VPN 标识。界面显示已连接但状态栏没有标识时，应重新检查系统 VPN 设置，确认没有其他 VPN、企业安全连接或系统级网络工具占用同一接口。移动系统通常只允许一个活动 VPN；启动另一个应用会使当前连接断开，客户端界面可能需要几秒才同步状态。
iOS 可使用 Clash Plus，并通过下载中心的 iOS 入口前往 App Store；Android 可在下载中心比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard。迁移客户端时，不要同时保留两个自动连接配置。先断开旧客户端并关闭其按需连接，再导入新配置。订阅可以重新导入，自定义规则和覆写则应单独记录，避免把平台不支持的字段直接复制过去。
处理后台被停止和锁屏断开
Android 厂商的电池策略可能在熄屏后限制客户端、内核或 VPN 服务。表现为亮屏时正常、锁屏数分钟后无网络，重新打开应用立即恢复。应在系统电池设置中允许客户端后台运行，关闭针对该应用的省电限制，并允许自启动或后台活动。不同厂商入口名称不同，但判断标准一致：锁屏期间 VPN 标识是否消失、系统是否记录应用被限制、通知栏中的常驻服务是否被移除。
iOS 对后台执行有严格管理，但已建立的系统 VPN 通常由网络扩展维持。若频繁断开，检查按需连接规则、低电量模式、系统 VPN 配置和网络扩展权限。不要反复从任务切换器强制划掉客户端，再期待界面定时更新订阅。订阅更新可在打开应用时手动执行，连接稳定性则应通过系统 VPN 状态判断。设备存储空间过低或系统正在更新时，也可能影响配置写入与扩展启动。
WiFi 与蜂窝网络切换
从 WiFi 切到蜂窝网络时，本机地址、DNS、MTU 和 IPv6 环境都会改变，已有连接需要重建。短暂断流属于正常切换过程，持续无法恢复则应手动断开并重连 VPN，观察新网络下是否重新建立节点连接。若蜂窝可用而某个 WiFi 不可用，检查该 WiFi 是否需要网页认证、是否限制 VPN、是否提供异常 IPv6 或 DNS。公共 WiFi 应先断开代理，在浏览器完成认证，再连接客户端。
只在蜂窝网络失败时，检查客户端是否被禁止使用移动数据、系统是否开启数据节省模式，以及订阅或节点域名能否通过蜂窝 DNS 解析。双卡设备还要确认当前数据卡和网络切换策略。部分系统会在信号变化时自动切换数据卡，使既有连接失效。诊断时固定一张数据卡，关闭智能切换，再用同一节点测试。恢复后可以逐步开启自动切换，判断是否需要每次换网后重连。
分应用代理与局域网访问
Android 客户端常提供分应用代理，可选择仅代理指定应用或排除指定应用。配置错误会造成浏览器正常而目标应用直连，或系统组件无法联网。排查时暂时关闭分应用规则，让所有应用使用同一连接；确认正常后再逐个加入排除项。应用更新、包名变化或工作资料空间会导致旧选择失效，主空间与工作空间也可能拥有不同 VPN 权限。查看连接日志能确认目标应用的请求是否进入内核。
访问家庭路由器、投屏设备与局域网服务时，应允许私有地址直连。若连接 VPN 后无法发现局域网设备，检查客户端是否有“允许局域网访问”选项、配置中的私有地址规则以及系统本地网络权限。iOS 对本地网络访问会单独询问授权，拒绝后代理本身仍可能工作，但设备发现和局域网连接失败。Android 上还可能需要附近设备或位置相关权限才能扫描局域网服务，这与代理节点是否可用无关。
移动端的最小恢复流程
移动端发生持续断网时，按固定顺序处理：先断开客户端，再确认关闭 VPN 后基础网络正常；随后切换一次飞行模式，恢复网络；打开客户端，选择一个具体节点，以规则模式重新连接；检查系统 VPN 标识与客户端日志；若仍失败，再换 WiFi 或蜂窝网络做对照。不要同时清除应用数据和删除订阅，因为这会丢失原始故障证据。只有确认配置无法载入或应用状态损坏时，才备份必要设置后重置。
重装后仍失败，通常说明原因位于系统 VPN 配置、网络环境或订阅节点，而不是应用文件。删除系统设置中遗留的旧 VPN 配置，重启设备，再让当前客户端重新申请权限。若单个应用异常，检查该应用的私有 DNS、数据权限和分应用代理；若所有应用异常，回到节点、DNS 与网络切换路径。移动端排查的核心仍是保持变量单一：固定客户端、固定节点、固定网络完成一次成功连接，再逐步恢复自动选择、后台策略和分应用规则。
如果按本页流程仍无法定位，应整理一份最小问题报告：设备与系统平台、客户端名称、发生网络、当前模式、是否启用 TUN、一个可复现目标、从正常到失败的具体步骤，以及隐去订阅信息后的相关日志。问题报告应说明关闭客户端后是否恢复、切换热点是否恢复、其他节点是否正常。这些对照结果比单独一句“连接不上”更能帮助判断故障层级，也能避免泄露订阅链接和私人网络信息。