CLASH / TROUBLESHOOTING

Clash 故障排查大全

连接、订阅、DNS、系统代理与移动端问题，按症状查阅。首次配置先走Clash 入门指南的下载、导入与连接主线；已经完成导入但运行异常，再回到本页定位。教程负责建立可用连接，本页负责解释连接在哪一层中断。

排查前记录平台、客户端名称、当前配置、代理模式与故障时间。Clash Plus 可作为新用户的首推入口；已经使用 Clash Verge Rev、FlClash 等客户端时，不必先换软件。界面名称可能不同，以下以内核行为和配置字段为准。安装文件集中在Clash 下载页。

无法上网：先区分底层网络与代理链路

关闭接管，建立直连基线

先退出其他代理、加速器与 VPN，再关闭当前客户端的系统代理和 TUN。打开平时可以直连的网站，并尝试访问路由器管理地址。如果两者都失败，优先检查无线连接、网线、网关和网络认证页面。公共无线网络经常要求先在浏览器完成认证；代理提前接管后，认证页面可能打不开。此时先恢复系统自动获取地址与 DNS，完成认证，再启动客户端。

直连测试必须包含两个层次。能够打开路由器页面，只能证明设备到局域网的路径存在，不能证明运营商出口正常。其他设备使用同一网络也无法访问外部站点时，应先处理路由器或上游网络；只有当前设备异常时，再检查本机防火墙、残留代理和静态路由。不要在底层网络尚未恢复时反复更新订阅，否则会把网络错误误判为链接失效。

按入口、规则、出口拆开测试

恢复直连后启动客户端，先确认内核运行，再确认配置已加载。界面能够打开不等于代理端口已监听。查看启动日志是否存在配置解析失败、端口被占用或权限不足。随后只启用系统代理，不同时开启 TUN。查看客户端实际显示的混合端口，并用下方命令显式指定代理入口。示例端口仅用于演示；如果配置不同，命令也要同步修改。

# macOS / Linux；Windows 可使用 curl.exe 执行同类命令
curl --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  --head https://example.com

# 不经过环境变量中的代理，作为对照
curl --noproxy '*' --connect-timeout 10 --max-time 20 \
  --head https://example.com

显式代理请求成功，而浏览器失败，说明内核入口到目标站点的路径至少对这次请求可用，应转查浏览器代理、扩展程序或系统代理接管。显式请求提示连接本机端口失败，则先处理监听地址与端口。已经连接代理但随后超时，需要查看本次连接命中的规则、策略组和节点。测试站点的返回状态不必一定为成功状态码；收到正常的 HTTP 响应，已经能说明请求到达了某个服务端。

规则模式下单个网站失败，可以暂时将相关策略组切到一个已知可用节点，再对照连接记录中的目标域名与最终策略。临时全局代理可用于判断规则差异，但不能证明所有规则都错误；恢复规则模式后还要定位具体命中项。若连接命中 REJECT，应核对规则来源与顺序；若误走 DIRECT，应检查域名是否被提前匹配。不要删除整套规则来掩盖一条错误匹配。

恢复网络时避免留下半套配置

开启 TUN 后全部断网，而仅系统代理可用，优先检查虚拟网卡、路由和 DNS 接管，而不是重新输入节点密码。管理员权限不足、其他 VPN 的默认路由、同网段冲突，都可能让流量进入虚拟接口却无法正常返回。先关闭 TUN 并确认路由恢复，再根据客户端提示检查服务模式。不要连续安装多个虚拟网卡驱动；保留一个客户端接管网络，更便于复现。

退出客户端后仍无法上网，检查系统代理是否还指向本机旧端口，同时检查手动 DNS 是否残留。清理时记录原值，不要把公司网络要求的静态配置直接改掉。恢复成功后重新打开一个新连接，旧浏览器连接可能仍沿用之前的会话。最终应得到明确结论：直连异常、入口异常、规则异常或出口异常。带着这一结论进入后续章节，比仅描述“全部打不开”更容易继续排查。

节点超时：确认测试对象与失败阶段

区分延迟测试失败与真实访问失败

客户端显示 timeout，通常表示针对指定测试地址的请求未在时限内完成，不等于节点在所有场景下都不可用。先选中该节点，通过浏览器或显式代理命令请求一个可访问的 HTTPS 站点，再对照延迟测试结果。如果实际访问正常，重点检查测试地址、测试超时设置以及站点是否限制自动请求。不要只凭一个测试地址的结果删除整份订阅。

全部节点同时超时时，先比较故障是否发生在同一网络、同一客户端或同一时间段。设备时间明显错误会影响 TLS 证书判断，先启用系统自动校时并确认时区。接着检查本机是否能解析节点服务器域名。网页域名解析正常，不代表服务器域名解析正常；两者可能使用不同的解析路径。日志中出现服务器域名解析失败时，应先修复解析，再讨论节点线路质量。

从解析、端口到协议逐层确认

服务器域名能够解析后，再测试服务器对应端口的 TCP 可达性。下方使用文档示例域名与端口，实际排查时替换为订阅中的服务器地址和端口，并仅在本机执行。TCP 测试成功只能证明连接到达对应端口，不能验证认证、加密参数或 UDP 路径。对于主要依赖 UDP 的协议，TCP 探测失败也不能单独作为节点失效的证据。

# Windows PowerShell：仅测试 TCP
Test-NetConnection -ComputerName example.com -Port 443

# macOS / Linux：系统安装 nc 时可用
nc -vz -w 5 example.com 443

日志出现连接拒绝，通常意味着目标端口没有接受连接，或中间设备主动返回拒绝；持续等待后超时，更可能是路径丢弃、远端不可达或返回流量受阻。两者处理方式不同。拒绝时先核对服务器端口和远端监听状态；超时时再换一个本地网络对照。公司网络、校园网络与公共无线可能限制部分端口或协议，不要在这些环境下仅凭结果认定配置损坏。

传输层可达但握手失败，应逐项核对节点类型、密码或标识、传输方式、TLS 开关、服务器名称与路径。部分协议还要求额外的公钥、指纹或传输参数，字段缺失可能被客户端忽略，也可能直接报解析错误。优先重新导入服务方提供的兼容配置，避免把面向其他内核的字段凭名称拼接进来。不要通过关闭证书验证来长期绕过握手错误，应先确认域名和证书是否匹配。

通过对照实验缩小责任范围

单个节点失败、其他节点正常，通常优先检查该节点参数和远端状态；所有节点都在同一设备失败，而另一设备正常，应比较内核兼容性、安全软件和本机网络接管。换网络测试时保持节点与配置不变，换节点测试时保持网络不变。一次同时换网络、软件和订阅，即使恢复，也无法判断是哪一项起作用，后续很容易再次遇到同样的问题。

还要检查节点选择是否真的生效。策略组可能嵌套另一个组，自动选择组可能重新选回其他节点，部分连接也会复用已经建立的会话。查看连接详情中的完整策略链，必要时只关闭目标应用的旧连接，再重新请求。不要频繁终止全部连接来做常规测速，正在下载或进行通话的应用会被中断，测试结果也容易受到并发重连影响。

向服务方反馈时，提供故障时间、接入网络类型、协议类型、失败阶段和脱敏错误，不发送整条订阅链接。若需要更细的排查顺序，可阅读节点全部显示 timeout 的检查流程。恢复后保留一次成功访问的日志片段，并把临时调整的测试地址和日志级别恢复，避免下一次排查混入本次遗留设置。

订阅失败：分开检查拉取、解析与应用

先确认链接返回了什么

订阅问题至少分为三个阶段：客户端能否下载内容，下载内容能否解析，解析后的配置能否被启用。先读错误原文。连接超时与域名解析失败属于拉取问题；出现行号、缩进或字段类型错误属于解析问题；导入成功但节点不显示，则还需检查是否选中了新配置以及策略组是否引用了节点。不要把这些情况统一处理为重新安装客户端。

从服务方页面重新复制订阅地址，确认没有混入换行、首尾空格或聊天软件附加的标点。链接通常含账户凭据，不应粘贴到公共转换网站、截图或在线调试工具。浏览器打开后出现登录页、验证码页或服务提示页，说明拿到的可能是 HTML，而不是配置。即使服务器返回成功状态，内容格式仍可能错误，因此不能只检查状态码。

返回未授权或禁止访问时，核对订阅是否被重置、账户权限是否变化、请求是否受到频率限制。找不到资源时，检查地址是否完整；服务器错误则应记录时间后稍后重试。重试应留出间隔，不要连续点击更新。若直连无法拉取、现有代理能够访问，可在客户端支持的情况下指定更新使用的出口；现有配置已经失效时，则需先取得一份可用的本地配置建立恢复路径。

识别完整配置与节点提供器

完整 Clash 配置可以包含节点、策略组、规则和 DNS；节点提供器文件通常只提供节点列表，由主配置中的 provider 引用。两者用途不同。把提供器地址直接作为完整配置导入，可能得到空界面或缺少策略组；把完整配置放进只接受节点列表的入口，也可能报格式错误。先确认服务方给出的链接类型，再选择客户端对应的配置导入或提供器入口。

# 完整配置的结构示例；proxies 为空时不会产生远端代理节点
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手动选择

上方示例用于确认配置结构，默认走直连，并不包含可用的代理服务器。真实节点应来自自己的服务配置。YAML 缩进使用空格，同级字段对齐，列表项放在正确父字段下。报错行附近不仅要看当前行，还要看上一行是否缺少冒号或引号。不要用全角冒号替换英文冒号，也不要把网页代码块的围栏符号一起复制进文件。

请求头也可能影响返回格式。某些订阅服务根据 User-Agent 生成不同配置，浏览器能下载不代表客户端会得到相同内容。只在服务文档明确要求时修改请求头，并使用其支持的客户端标识；随意伪装其他软件可能让服务端返回不兼容字段。出现不支持的协议或未知字段时，应检查当前客户端使用的内核，以及订阅是否针对该内核输出，而不是简单删掉所有报错字段。

确认新配置实际进入运行状态

导入成功后，查看配置列表中的更新时间和选中状态，再进入代理组确认节点是否存在。提供器还可能需要独立更新，主配置更新时间变化并不代表子资源已经刷新。组内筛选表达式若只保留特定名称，也会造成节点列表为空；这时检查筛选条件、提供器加载错误和名称变化，不要先认定服务方没有返回节点。

本地覆写、脚本和合并配置可能在导入后再次改写规则或节点。排查时先备份，再暂时停用这些处理，比较原始配置与最终运行配置的差异。不要直接编辑客户端自动生成的运行文件，因为下一次加载可能覆盖修改。需要长期保留的调整，应放入客户端明确支持的覆写入口，并保留最小改动范围。

订阅恢复后，先手动更新一次并启用，再建立一个新连接验证。检查规则、DNS 与策略组是否符合预期，不仅看节点数量。更细的格式和请求头检查见订阅更新失败与 YAML 自查清单。如果服务方已经重置链接，应同步清理旧地址，避免多个设备仍在使用已失效凭据反复请求。

速度慢：定位首包、吞吐与应用差异

先定义慢在哪个环节

网页很久才开始显示、下载开始后速度低、视频播放间歇停顿，是三种不同症状。前者常涉及 DNS、连接建立或 TLS 握手；持续吞吐低还可能涉及链路拥塞、远端限速和本机资源；间歇停顿则需要观察丢包、无线干扰和应用缓存。先固定一个目标、一个节点和一种网络，记录开始等待时间与持续传输表现，避免把不同网站的结果混在一起比较。

客户端延迟测试不是带宽测试。一个节点对测试站点响应较快，不代表到视频服务或文件服务器的路径也更好。测速站本身还可能选择不同地区的服务器，使两次结果没有可比性。优先用真实业务对照：同一文件、同一时段、同一设备分别走直连与代理，记录是否只有代理路径变慢。不要同时运行大文件下载和多节点测速，否则测试流量会抢占正在观察的带宽。

用连接阶段与策略记录判断

下方命令输出解析、连接、TLS 与首字节等累计耗时。经过 HTTP 代理时，部分数值描述的是到代理入口的阶段，不能直接解释为远端节点的独立耗时。它更适合在相同条件下比较修改前后，而不是单独计算某条线路的真实延迟。先确认请求成功，再看时间；错误页面或缓存命中也可能产生很短的结果。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out 'DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} FIRST:%{time_starttransfer} TOTAL:%{time_total}\n' \
  https://example.com

Windows 使用 curl.exe 时，可将输出目标改为 NUL，并将命令写成单行执行。观察到首字节等待很长但传输开始后正常，应先查解析、握手、目标服务响应和节点到目标的路径。开始很快但持续传输明显下降，则比较其他节点、其他文件来源和本机无线质量。不要仅根据一次短请求推断长时间下载性能，两者承受的拥塞与限速条件可能不同。

打开连接面板，确认目标请求确实经过预期节点。网页主域名与图片、视频、下载域名可能命中不同规则，出现“页面快、视频慢”时尤其需要逐个看。自动策略组可能在测试间切换出口；为了对照，应暂时固定节点，并在结束后恢复原策略。部分服务会限制跨地区会话，频繁切换节点还可能触发额外验证，反而让访问体验更差。

检查本机、协议与网络边界

先观察处理器、内存和磁盘使用情况。大量调试日志、连接数量过多、实时扫描或其他下载任务，都可能成为本机瓶颈。笔记本节能模式与移动设备高温降频也会影响加密处理。测试时关闭不相关的重负载任务，把日志恢复到日常级别，再观察同一请求。不要为了测速长期关闭防火墙；应根据明确的拦截记录添加必要规则。

只有实时通话、游戏或部分视频异常时，进一步检查 UDP 支持与接管方式。浏览器可能使用 QUIC，而系统 HTTP 代理未必覆盖这条路径。可以在受控测试中让应用改用 TCP，观察是否恢复，再决定是否调整 TUN 或相关规则。协议切换只是定位工具，不应直接推广成所有设备的固定优化。MTU 也只在出现大包传输停顿、小请求正常等证据时检查，先记录接口原值再小范围对照。

局域网无线信号强不等于干扰少。靠近路由器、改用有线或换到另一接入网络，是区分无线与代理瓶颈的有效方法。若不同设备、不同客户端通过同一节点访问同一资源都慢，更可能是远端或中间链路问题。此时应向服务方提供目标类型、时间段和对照结果，而不是继续堆叠本机优化参数。恢复后撤销临时限流、固定节点和协议测试设置，保持配置可解释。

DNS 问题：确认解析入口与 Fake-IP 映射

先确定域名在哪一层解析

域名打不开而部分已建立连接仍可用，可能与 DNS 有关，但不能直接下结论。先记录日志中的解析错误，再检查系统使用的 DNS 地址、客户端 DNS 是否启用，以及应用是否自带加密解析。系统、浏览器、代理内核和路由器可能各有缓存与解析路径。只改其中一层而测试另一层，容易得到互相矛盾的结果，因此每次测试都要说明查询交给了谁。

代理请求还可能由代理端解析目标域名，因此本地查询失败与代理访问成功可以同时发生。节点服务器域名的解析又是另一个问题：如果连接节点前就需要 DNS，而所选解析器必须先通过该节点访问，会形成启动依赖。排查时先确保解析器自身的域名有可用的引导解析路径，再检查普通业务域名。不要把所有解析请求都强行送进尚未建立的代理连接。

用明确端口测试内核 DNS

以下为 mihomo DNS 字段示例，监听仅限本机，并使用独立测试端口。公共解析器只是配置示例，不保证在当前网络可达，也不代表隐私或线路建议。把片段放入现有配置前，确认没有重复的 dns 根字段，客户端是否会覆写该字段。仅开启监听不会自动让系统使用它，还需要客户端接管或显式查询。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

# macOS / Linux，安装 dig 后测试指定 DNS 入口
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

Fake-IP 模式返回保留地址段中的映射地址，是预期行为，不代表网站服务器真的位于该地址。内核通过映射找回域名，再应用规则与转发。若应用取得映射地址后绕过内核直接连接，就可能失败。因此判断 Fake-IP 是否正常，不能只看解析结果像不像公网地址，还要确认后续连接被同一个内核接管，以及映射表是否仍然存在。

切换增强模式、重启内核或更换配置后，系统和应用可能保留旧映射。先关闭目标应用，再清理对应缓存并重新建立请求。Windows 可用 ipconfig /flushdns 清理系统缓存，但浏览器、应用和路由器仍可能有独立缓存；其他平台按系统提供的方法处理，不要把某个平台命令直接套用到所有设备。清缓存前先修复解析路径，否则只是重复产生相同错误。

处理内网域名、IPv6 与路由冲突

打印机、公司内网和家庭存储域名，通常依赖局域网 DNS 或特定搜索域。把所有域名交给公共解析器，可能导致这些服务失效。应为确实需要本地解析的域名设置解析策略，并在必要时加入 Fake-IP 过滤，让其返回真实地址。过滤项必须来自已确认的问题域名，不要添加过宽的通配符，否则会改变大量正常请求的处理方式，也让故障更难复现。

同时检查 IPv4 与 IPv6。域名返回 AAAA 记录而本机 IPv6 路径不可用时，应用可能先等待失败再回退，表现为首开很慢。可以临时对照禁用某一层的 IPv6 行为，但要分清是系统接口、内核解析还是节点出口的问题。最终应修复路径或使用明确策略，而不是在每一层同时关闭后失去判断依据。企业网络还可能使用与 Fake-IP 地址段冲突的路由，修改地址段前先确认现有网段。

浏览器安全 DNS 与系统 DNS 接管可能并存。若只有浏览器异常，先比较其安全 DNS 设置；若只有内网异常，先查分域解析与局域网路由。恢复标准是：新查询有结果，新连接经过预期策略，内网服务仍可用。DNS 请求能够返回答案，并不能单独证明答案正确或连接路径安全。需要理解字段含义时，可到概念速查查看 DNS 与网络栈相关术语。

系统代理不生效：检查应用是否进入入口

系统代理、环境变量与 TUN 各有边界

系统代理通常向遵循系统设置的应用提供 HTTP 代理入口，并不保证接管设备上的所有流量。命令行工具、游戏、服务进程和自带网络栈的应用，可能忽略这一设置。TUN 则通过虚拟接口与路由接管流量，但受权限、排除规则与其他网络软件影响。先确认目标应用使用哪一种入口，再选择方案；不要把系统代理开关当作全设备代理状态的证明。

最直接的分界测试，是使用显式代理命令。如果显式请求成功，目标应用却完全不出现在客户端连接记录中，优先检查应用入口，而不是更换节点。若请求已经出现在记录中但走 DIRECT，问题在规则或策略；若走预期节点后失败，再查出口。观察连接记录时要重新发起请求，已经建立的长连接可能不会随着系统设置立即迁移。

核对监听、环境变量与平台设置

本机代理常监听回环地址。客户端与应用在同一操作系统环境时，使用 127.0.0.1 即可；容器、虚拟机和部分子系统中的回环地址指向它们自己，不一定指向宿主机。此时应根据实际网络模式确定宿主地址与访问权限，不能直接复制本机命令。确需开放局域网访问时，再设置监听范围、防火墙与认证，不要为了容器测试就向整个网络暴露代理端口。

入口	主要覆盖对象	排查重点
系统代理	遵循系统设置的应用	代理地址、例外列表、浏览器扩展
环境变量	支持对应变量的命令行程序	当前进程环境、变量优先级
TUN	进入虚拟接口的流量	权限、路由、排除项与 DNS
应用内代理	该应用自身	协议类型、端口与远端解析方式

终端工具可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也可能只读取小写形式，具体行为以工具文档为准。修改变量后，已经运行的进程通常不会自动获得新环境。先在当前终端临时设置并测试，不要立即写进全局启动文件。还要检查 NO_PROXY，过宽的例外会让目标绕过代理。为避免遗留问题，下方示例采用只对单次命令生效的写法。

# macOS / Linux：仅对当前这次请求设置环境变量
HTTP_PROXY=http://127.0.0.1:7890 \
HTTPS_PROXY=http://127.0.0.1:7890 \
curl --head --max-time 20 https://example.com

# Windows：观察当前用户与 WinHTTP 设置，二者并非同一入口
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
netsh winhttp show proxy

Windows 用户代理与 WinHTTP 服务代理不是同一套设置，查看命令的结果也不能互相替代。不要看到服务程序不走代理就直接导入全局设置，应先确认服务运行账户和支持方式。macOS 的代理按网络服务分别配置，切换无线与有线后可能使用另一套设置；Linux 桌面环境的代理设置也不保证被后台服务继承。每次切换网络后，应重新确认目标应用的实际入口。

处理 UWP、扩展程序与异常退出残留

部分 Windows 沙盒应用访问本机回环受到限制。只有确认内核入口可用、普通桌面应用正常、特定应用无法连接回环端口时，才考虑 UWP 回环豁免。优先使用客户端提供的管理入口，按应用选择，而不是对所有应用一并开放。豁免改变的是本地网络访问权限，不会修复节点认证、订阅或远端连接问题；不再需要时应撤销对应应用的例外。

浏览器代理扩展、自动配置脚本和系统手动代理可能互相覆盖。排查时暂时停用扩展，只保留一个来源，并检查例外列表是否包含目标域名。客户端异常退出后，系统可能仍指向已经关闭的本机端口，导致整个浏览器无法访问。恢复原系统设置后再重启客户端，确认开关与实际地址一致。若每次退出都残留，应收集退出日志，而不是长期保留错误代理并靠反复启动绕过。

客户端崩溃：分清界面、内核与服务故障

先判断哪个进程停止工作

窗口消失、界面空白、内核退出与服务启动失败，处理方式不同。窗口打不开但代理仍可用，可能只是界面层异常；界面正常而代理端口没有监听，则应查内核日志；只有 TUN 无法启动，可能是服务权限或虚拟接口问题。先在任务管理器或系统活动监视器确认进程状态，再记录最后一条错误。不要看到窗口异常就删除全部配置，这会丢失最有价值的复现条件。

记录故障发生的动作：启动即退出、加载某个配置后退出、开启 TUN 后退出，还是长时间运行后退出。每种触发方式对应不同检查范围。启动即失败先看文件权限、架构与运行依赖；配置触发先看解析和自定义处理；长时间运行后退出再观察内存、连接数量与日志增长。系统事件查看器或崩溃报告可以补充客户端日志，但分享前仍要清理用户名、路径和访问数据。

通过配置检查与最小化运行定位

能独立运行 mihomo 的环境，可先用内核的配置测试功能确认文件是否可解析。命令需要指向实际配置文件；如果配置引用外部规则或节点提供器，还要确保相关资源路径存在。测试通过只代表配置检查通过，不代表所有远端节点可连接，也不代表 GUI 覆写后的最终配置相同。客户端支持查看运行配置时，应优先检查那一份，而不是仅检查订阅原文件。

# macOS / Linux：在内核所在目录执行
./mihomo -t -f ./config.yaml

# Windows PowerShell：在内核所在目录执行
.\mihomo.exe -t -f .\config.yaml

配置检查报告端口占用时，先查是谁在监听，再决定是否退出旧进程或更换端口。不要直接结束名称相近的所有进程，系统服务或其他应用可能正在使用它。更换 mixed-port 后，系统代理、应用内代理和命令行环境变量也要同步更新。控制接口端口与代理端口用途不同，把浏览器指向控制接口不会产生正常代理连接。

最小化运行应保留可回退路径。先复制整个配置目录，再临时停用脚本、覆写、自定义规则与额外提供器，每次只恢复一项。若最小配置可以运行，逐步添加原有部分，直到复现故障。不要在没有备份的情况下清空应用数据；订阅、策略选择与本地规则可能都在其中。目录位置以客户端设置或日志为准，不同平台与安装方式未必使用相同路径。

检查系统条件，保留可恢复现场

安装文件需要匹配处理器架构与系统类型，Linux 还要区分发行版包格式。安全软件阻止启动时，先查看明确的拦截记录与文件来源，不要为了运行而整体关闭防护。目录不可写、磁盘空间不足、用户配置目录被同步工具锁定，都可能导致保存或启动失败。可用普通用户可写的独立目录做对照，但不要把所有程序都长期设为管理员运行。

界面空白还可能涉及系统 WebView 或图形驱动，适用于依赖这些组件的客户端，而不是所有 Clash 客户端都一样。先确认系统组件是否正常，再按对应客户端文档处理。内核日志持续输出而窗口失去响应时，记录是否伴随大量连接刷新或日志滚动。降低界面刷新负担可以作为对照，但不要把日志全部关闭后继续猜测故障原因。

需要重新安装时，从下载页选择对应平台与架构，先用备份中的配置副本测试。Clash for Windows 与 ClashX Meta 属于已停止维护的归档客户端，遇到新系统兼容问题时，可评估 Clash Plus 或下载页中的其他适配客户端，不要假定更换界面就会自动迁移所有配置。Linux 独立内核部署另见mihomo 与 systemd 部署步骤。

提交问题时附上平台、架构、客户端名称、触发步骤、配置检查结果与脱敏错误片段。若只能通过某份配置复现，应裁剪成最小样本，移除真实服务器凭据后确认仍能触发。恢复后再检查系统代理与 TUN 状态，崩溃后的残留设置可能造成第二个网络故障。最后把排查期间提高的日志级别恢复，避免日志持续占用磁盘。

移动端专项：权限、后台与网络切换

Android：检查 VPN 授权与应用范围

Android 客户端通常通过系统 VPN 接口接管流量。首次启动需要确认系统授权；其他 VPN、工作资料中的网络工具或安全应用可能占用同类接口。先关闭其他接管工具，再启动当前客户端，观察系统 VPN 状态与客户端日志是否一致。状态图标只说明系统接口存在，不能证明节点、DNS 和规则都正常，仍需打开一个新请求并检查命中策略。

Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的界面和配置能力不同，不能把某个客户端的字段支持范围直接套用到其他客户端。导入后报协议或规则错误时，先确认订阅输出与所选客户端兼容。Surfboard 的配置形式也不等同于所有 Clash YAML。新用户可先按入门指南建立基础连接，再逐项增加分应用和自定义规则。

启用了分应用代理时，核对模式是仅代理所选应用，还是排除所选应用。两者列表看起来相似，实际含义相反。目标应用没有出现在连接记录中，可能是被排除，也可能是应用缓存了旧连接。修改范围后结束该应用的旧会话并重新打开。浏览器能访问而其他应用不行时，还需检查应用内 DNS、证书要求或独立代理设置，不要直接把所有问题归到后台权限。

iOS：确认配置启用与系统隧道状态

iPhone 可从iOS 下载入口进入 Clash Plus 的 App Store 页面，其官网为 clashplus.io。安装后导入配置并完成系统 VPN 授权，再确认当前启用的是新导入的配置。订阅列表中存在文件，不代表隧道已经使用该文件；更新订阅后应检查策略组，并用新的连接验证出口。

iOS 同样可能存在多个 VPN 配置或其他网络扩展。先保留一个实际运行的接管来源，再观察隧道是否建立。应用前台能够访问、锁屏后中断时，需要区分系统调度、网络切换与远端长连接断开。不要只看客户端返回前台后的状态；记录中断发生时间，并观察重新请求能否自动恢复。短暂重连与持续不可用是不同故障，应分别描述。

只在某个应用异常时，比较普通网页、同一服务的其他入口与该应用的连接记录。应用可能有地区、账户、风控或服务端策略，代理连接成功不保证所有业务功能都可用。避免为一个业务错误频繁切换多个出口，这可能造成更多验证。有关获取与导入的连续步骤，见iPhone 客户端与订阅配置导入。

后台、省电与无线切换的共同检查

Android 锁屏后断开，先检查系统是否限制后台运行、电池优化或后台数据。按设备系统提供的应用设置逐项放行所需权限，不要关闭整个设备的省电管理。部分系统会在清理任务时结束网络进程，可在前台稳定连接后锁屏测试，再查看日志是否出现进程重启。若进程未停止而连接失败，应继续查网络和节点，不要把所有中断都解释为系统清理。

无线与蜂窝切换会改变地址、默认路由和解析环境，原有连接可能无法继续复用。测试时先固定一种网络，确认稳定后再切换，记录是否只有切换瞬间失败，还是之后新连接也无法建立。切换后重建隧道能恢复，说明需要重点观察网络变化处理；固定网络仍周期性失败，则应回到节点、DNS 和后台限制章节。不要一边走动切换热点，一边用结果判断节点稳定性。

移动热点也有接管边界。手机自身经过 VPN，不代表连接手机热点的电脑一定走同一路径；共享流量是否进入隧道取决于系统与客户端能力。先在被共享设备上独立验证，不要只看手机状态栏。使用按流量计费的网络时，还应暂停订阅批量测试与大文件测速，避免排查动作本身持续消耗流量。