Clash
故障排查手册

建立可重复的排查基线

故障排查的第一步不是修改配置，而是确定故障边界。先记录出现问题的时间、当前网络类型、客户端名称、代理模式、所选节点、目标网站以及报错原文。桌面设备还应记录系统代理和 TUN 是否开启；移动设备应记录 VPN 标志是否出现、应用是否被系统限制后台活动。若只写“不能用”，后续很难判断修复来自哪一步，也无法区分偶发网络抖动与稳定配置错误。

把网络路径拆成六段

一次连接通常经过应用、操作系统代理或虚拟网卡、Clash 监听端口、规则与策略组、远端节点、目标服务。任何一段失败，浏览器看到的结果都可能只是连接超时。排查时应按从近到远的顺序检查：客户端进程是否运行，端口是否监听，配置是否成功载入，策略组是否选中可用节点，节点是否能建立连接，目标地址是否允许当前出口访问。不要同时更换客户端、订阅和 DNS；多个变量一起变化会破坏判断依据。

先关闭系统代理和 TUN，用浏览器直接访问一个平时可用的站点。如果直连也失败，应优先处理 Wi-Fi、网线、网关、认证页面或系统 DNS，而不是修改 Clash。直连正常后，再启动客户端但暂不接管系统流量，观察日志是否完成配置加载。最后开启系统代理或 TUN，并分别测试域名和纯 IP 请求。域名失败而 IP 可达，通常指向 DNS；两者都失败，则继续检查端口、节点和路由。

收集端口与日志证据

常见配置会开放 mixed、HTTP 或 SOCKS 监听端口。具体数字以当前配置和客户端界面为准，不能只按网上示例判断。Windows 可在 PowerShell 中检查监听状态，macOS 和 Linux 可使用 lsof。若命令没有输出，说明内核未成功监听、配置未载入，或端口已经被其他程序占用。

# Windows PowerShell：把 7890 替换为界面显示的端口
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

# 通过本地 HTTP 代理发起测试
curl -I --proxy http://127.0.0.1:7890 https://example.com

日志级别建议先使用 info。它足以显示配置加载、规则命中、DNS 查询和连接错误，又不会像 debug 那样快速产生大量输出。需要追踪单次请求时，可临时提高日志级别，完成复现后恢复。重点保存错误发生前后十几行，不要只截最后一条；例如“连接超时”之前可能已经出现域名解析失败、策略组为空或配置字段不兼容。

完成基线后，应能回答三个问题：客户端是否成功启动、本地代理是否能独立完成请求、问题是否只发生在某个节点或某类域名。若仍无法回答，继续收集日志，不要跳到高级参数。稳定的证据链比反复点击“更新”“修复”更快，也便于在不同客户端之间复现同一问题。

开启 Clash 后完全无法上网

此类症状通常表现为系统代理或 TUN 开启后，浏览器、即时通信和应用商店同时失去连接；关闭接管后网络恢复。先不要判断节点一定失效。系统流量已被送到本地代理，但内核没有可用出口、监听端口不一致、规则把流量送进空策略组，都会造成相同现象。应先证明本地代理链路是否成立，再检查系统接管。

先验证客户端内部状态

查看配置页面是否显示当前配置已载入，策略组中是否存在节点，以及活动策略是否实际选中了一个节点。有些订阅更新后会改变策略组名称，旧的选择记录无法对应新组；界面看似仍在规则模式，实际组内没有有效目标。手动切换到另一个节点并执行延迟测试只能作为初筛，不能把延迟测试成功等同于网页一定可用，因为测试地址、协议和真实访问路径可能不同。

随后关闭系统代理，只保留客户端运行，使用 curl 显式指定本地代理。若该命令成功，说明内核、配置和节点基本可用，故障集中在系统代理或应用侧。若命令返回 connection refused，检查界面端口与配置中的 mixed-port、port 是否一致；若返回 timeout，则继续检查节点；若出现 proxy connect aborted 或配置错误，回看启动日志。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

# 单独验证本地代理，不依赖系统代理设置
curl -v --proxy http://127.0.0.1:7890 https://example.com

检查端口冲突与回环地址

同一台设备上同时运行两个代理客户端时，后启动的内核可能无法绑定端口。典型日志包含 address already in use、bind failed 或 listen error。退出其他客户端后重新启动；若必须并存，为每个实例分配不同端口。不要把监听地址随意改成局域网地址。本机使用时优先保持回环监听；只有明确需要向局域网设备提供代理时才开启 allow-lan，并同时检查防火墙和可信网络边界。

如果显式代理请求成功，但所有应用仍无法上网，关闭后重新开启系统代理，让客户端重新写入操作系统设置。检查代理服务器是否指向 127.0.0.1，端口是否与客户端一致。曾使用 PAC、其他 VPN、浏览器扩展或企业网络工具时，可能存在多套设置互相覆盖。浏览器若配置了独立代理，也可能绕过系统设置。此时应暂时恢复浏览器默认网络设置，只保留一种接管方式测试。

TUN 模式下的额外分支

TUN 会接管比系统代理更广的流量，因此权限、路由和 DNS 任一环节不成立，影响范围都会更大。Windows 检查服务权限和虚拟网卡状态；macOS 确认系统扩展或 VPN 配置获得授权；Linux 检查进程是否具备创建 TUN 设备和修改路由的权限。不要同时开启两个创建默认路由的 VPN。若关闭 TUN、改用系统代理后恢复，说明节点与配置未必有问题，应集中检查虚拟网卡、路由表和 DNS 劫持。

还要排除规则误判。临时将模式切到全局，只用于一次短测试：全局可用而规则模式不可用，说明请求被规则交给了错误策略或 DIRECT。查看连接日志中的规则命中项，检查 MATCH 最终策略、规则集是否加载成功、策略组是否存在。测试结束应恢复规则模式，不要用长期全局代理掩盖规则错误。

修复顺序应保持明确：确认基础网络可用，确认客户端载入配置，确认本地端口监听，确认显式代理请求成功，最后恢复系统代理或 TUN。每一步都成功后才进入下一步。若需要更换客户端，到下载页核对平台与架构；迁移时先导出订阅地址和自定义规则，不要直接复制未知来源的整个配置目录。

节点超时、握手失败与连接被重置

节点列表显示 timeout 只说明测试请求没有在限定时间内完成，不等于本地客户端必然损坏。可能原因包括节点服务器不可达、端口被阻断、域名解析到错误地址、系统时间偏差、协议参数不匹配，或测试 URL 在当前网络下不可用。首先比较多个节点：只有一个节点失败，优先视为节点侧问题；同一订阅全部失败，再检查订阅内容、本地网络和协议支持。

区分 TCP、TLS 与应用层失败

日志中的 i/o timeout 通常表示连接或读写超过时限；connection refused 表示远端地址可达但端口没有服务；connection reset by peer 表示连接建立后被远端或中间设备重置；TLS handshake timeout 指向握手阶段；certificate 或 server name 相关错误则常与系统时间、SNI、证书名称和订阅参数有关。不要把这些错误统一归结为“节点失效”，不同阶段需要不同处理。

若节点地址是域名，先用系统工具解析，确认能得到合理的 A 或 AAAA 记录。解析结果频繁变化并不必然异常，但完全无结果、返回保留地址或只返回当前网络不可达的 IPv6 地址时，需要检查 DNS。随后测试目标端口的 TCP 连通性。命令只能说明端口是否可连接，不能验证协议认证，因此端口成功但客户端握手失败时，继续核对节点参数。

# Windows PowerShell
Resolve-DnsName node.example.net
Test-NetConnection node.example.net -Port 443

# macOS / Linux
dig node.example.net A
dig node.example.net AAAA
nc -vz node.example.net 443

核对时间、协议与内核能力

TLS 依赖正确的系统时间。设备时间相差过大时，证书可能被判断为尚未生效或已经过期。开启系统自动校时并重新建立连接。然后检查订阅中的协议类型是否被当前内核支持。旧客户端或停止维护的软件可能无法识别较新的字段，表现为配置载入失败、节点被忽略或握手参数缺失。遇到此类情况，优先使用仍在维护的 Clash Plus、Clash Verge Rev、FlClash 或兼容 mihomo 的客户端；具体平台选择可查阅下载页。

不要自行修改订阅生成的密码、UUID、端口、传输方式、TLS 开关、server name 或网络类型。哪怕只差一个字符，TCP 仍可能连接成功，但认证阶段必然失败。若订阅服务提供网页端节点详情，可与客户端解析后的字段逐项比较。仅在确认订阅转换器丢失字段时，才需要更换订阅格式或联系订阅提供方。

同一批节点在家庭宽带全部超时，但在移动热点可用，说明问题更可能位于当前接入网络、路由器 DNS、IPv6 路径或端口策略。反向测试也有价值：手机热点失败而固定网络可用，可能是移动网络 IPv6、NAT 或省电限制导致。不要连续进行大量延迟测试；密集并发可能触发远端限制，还会让日志难以阅读。选择两个节点，逐个复现真实网页请求即可。

测试地址与实际访问分开判断

延迟测试通常访问一个固定 URL。该地址不可达时，节点会被标记超时，但其他网站仍可能正常。先通过浏览器访问真实目标，再更换测试 URL。测试地址应使用稳定、响应体较小、支持 HTTPS 的站点，不应使用需要登录或可能返回复杂跳转的页面。URL Test 策略组还应设置合理的间隔，过短会增加节点和电量消耗，过长则无法及时发现出口变化。

最终判断应基于交叉验证：不同节点、不同网络、不同目标地址至少形成两组对照。只有单节点失败就移出当前策略；所有节点只在一个网络失败就处理网络路径；所有网络均失败且日志显示字段不支持，则处理客户端兼容性。这样可以避免在远端故障时反复重装本地软件，也能避免把本地 DNS 问题误报为整份订阅失效。

订阅导入、更新与配置解析失败

订阅问题至少分为四类：链接无法请求、服务器返回登录页或错误页、返回内容不是客户端支持的配置格式、配置下载成功但解析失败。界面中的“更新失败”往往没有显示完整原因，必须查看日志或在浏览器中检查响应。不要公开粘贴完整订阅链接；其中可能包含用于识别账户的访问参数。排查截图应遮住链接路径和查询参数。

确认链接本身是否可访问

先检查复制过程中是否混入空格、换行或中文标点。部分聊天软件会截断长链接，也可能把末尾字符纳入文本格式。将链接粘贴到纯文本编辑器，确认从协议头到末尾连续完整。浏览器访问后若跳转到登录页面、套餐提示、验证码或 HTML 错误页，客户端自然无法把它解析成 YAML。此时应在订阅服务页面重新生成链接，而不是修改客户端配置。

如果浏览器能下载文件，检查响应内容开头。Clash YAML 常见顶层字段包括 proxies、proxy-groups 和 rules；某些链接返回编码文本或其他客户端专用格式，需要服务端选择 Clash、Meta 或 mihomo 兼容输出。不要仅靠文件扩展名判断，服务器可能用无后缀地址返回配置。下载到本地后可使用文本编辑器查看，但不要让编辑器自动改变缩进或制表符。

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - "Example Node"

rules:
  - MATCH,PROXY

上例只用于说明 YAML 层级。列表项前使用空格缩进，不能使用制表符；引号必须成对；同一级字段保持一致缩进。解析日志若给出 line 和 column，应从报错行向上检查，因为真正的缩进错误可能发生在前一行。duplicate key 表示同一映射中出现重复字段；cannot unmarshal 常表示字段类型不符合预期，例如本应为数组却写成字符串。

区分远程更新与本地覆盖

许多图形客户端允许在订阅之上添加覆写、脚本或混入配置。远程原文有效，但应用覆写后启动失败，说明问题位于本地加工层。暂时关闭覆写并重新载入；若恢复，再逐段启用自定义 DNS、规则和策略组。不要直接编辑客户端缓存中的订阅文件，因为下次更新会覆盖修改，也会让问题难以复现。长期自定义内容应放在客户端明确提供的覆写机制中。

订阅更新成功却没有节点时，先查看返回内容是否包含 proxies，再检查客户端是否选择了新配置。有些客户端会下载成功但仍保持旧配置活动状态，需要手动切换；另一些客户端会因部分字段不兼容而拒绝整份配置。观察配置列表中的更新时间只能证明请求发生过，不能证明内核已经应用。内核日志出现配置载入完成，且策略组能列出节点，才算更新链路完成。

处理网络、证书与更新频率

订阅域名本身可能需要代理才能访问，而客户端启动时又依赖订阅才能获得节点，形成循环依赖。解决方法是保留一个最近可用的本地配置，先启动旧配置建立网络，再更新订阅。不要删除唯一可工作的配置。证书相关错误应先校准时间并检查系统证书环境；企业网络若使用受管代理，需遵循该网络的证书和访问策略。

频繁点击更新不会修复服务端限流。遇到 HTTP 429 应等待后再试；401 或 403 通常指向链接失效、账户状态或访问参数；404 表示路径不存在；5xx 则偏向服务端故障。客户端只显示简短错误时，可通过开发者日志或命令行请求查看状态码，但输出中仍需隐藏订阅地址。

稳定修复后的验收包括：订阅请求返回正确格式，客户端未启用有问题的覆写，日志显示配置成功载入，策略组能够看到节点，重启后仍能恢复同一配置。快速导入的基本步骤可回到快速上手核对；若需要理解不同内核对字段的兼容边界，可阅读Clash 原版、Meta 与 mihomo 内核差异。

连接成功但网页慢、下载慢或视频卡顿

速度问题不能只看节点列表中的延迟。延迟描述一次小请求的往返时间，下载速度还受远端带宽、路由拥塞、丢包、协议开销、目标站限速和本地设备性能影响。一个延迟较低的节点可能带宽很小，另一个延迟略高的节点反而更适合大文件。排查时先明确是哪类慢：首次打开域名慢、建立连接慢、持续下载慢，还是只有视频和特定网站慢。

建立直连与代理对照

在同一设备、同一网络、相近时间内分别测试直连和代理。不要跨设备比较，也不要把 Wi-Fi 与有线网络结果混在一起。测试应包含一个小网页和一个持续下载任务，并记录稳定阶段而非瞬时峰值。如果直连同样慢，先处理无线信号、路由器负载、运营商链路或目标服务；如果只有代理慢，再比较节点和协议。

关闭后台同步、系统更新和云盘上传。上传带宽被占满时，确认包无法及时返回，会让下载和网页访问一起变慢。Wi-Fi 环境应靠近接入点测试，区分 2.4 GHz 干扰与代理问题。有线可用而无线慢时，不需要修改 Clash。移动热点则要注意信号切换和套餐侧限速，短时测速不代表持续传输质量。

检查 DNS 首包与连接复用

网页点击后长时间空白、随后加载速度正常，常见原因是 DNS 或首次连接握手慢。日志中若域名解析耗时明显，先处理 DNS 章节的问题。若同一域名每次都重复建立大量连接，检查浏览器扩展、安全软件或网络中间层是否破坏连接复用。不同客户端的并发与连接池由内核管理，不建议为了追求速度随意套用来源不明的所谓优化参数。

策略组自动测试也可能引入误判。URL Test 只依据指定测试地址选择节点，目标视频站的实际路由可能完全不同。对于持续传输，手动比较两到三个节点更可靠。Fallback 适合在当前节点不可用时切换，Load Balance 则会改变不同连接的出口；登录态敏感的网站可能因出口变化要求重新验证。速度问题排查期间优先使用固定节点，减少策略自动切换带来的变量。

识别 MTU、IPv6 与 TUN 性能问题

TUN 模式下，小网页可打开但大文件停滞、部分图片始终加载不全，可能与 MTU 和路径分片有关。不要先盲目设置极小 MTU。应比较系统代理与 TUN：系统代理正常而 TUN 异常，再检查虚拟网卡默认值、底层 VPN 叠加和路由器路径。某些网络的 IPv6 可达性不完整，也会出现先尝试 IPv6、等待失败后回退 IPv4 的延迟。可通过日志和 DNS 结果确认是否存在此过程。

# 查看请求阶段耗时，重点比较 name lookup、connect 与 start transfer
curl -o /dev/null -s \
  -w "dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  --proxy http://127.0.0.1:7890 \
  https://example.com

客户端本身的资源占用也要纳入观察。大型规则集、密集日志、频繁健康检查和复杂脚本会增加 CPU 与内存负担，低功耗设备尤其明显。先关闭调试日志，减少过短的健康检查间隔，停用不必要的覆写，再比较性能。路由器或旧手机运行完整 TUN 时，还可能受单核性能限制。此时更换节点无法解决本地处理瓶颈。

最终记录应包含直连结果、代理结果、节点、接管模式、DNS 阶段耗时和测试时段。若问题集中于 TUN 与系统代理的差异，可继续阅读TUN 模式和系统代理的工作机制对比。有了这些数据，才能判断应更换节点、修正规则、调整 DNS，还是处理本地无线网络。

DNS 解析失败、污染、泄漏与循环查询

DNS 故障的表现不只是一句“找不到服务器”。常见现象包括域名间歇打不开、同一网站在不同应用结果不同、代理开启后仍走系统解析、fake-ip 地址无法被应用正确处理、内网域名失效，以及解析请求在本地代理和系统解析器之间形成循环。排查时先画出解析路径：应用把查询交给谁，Clash 是否监听 DNS，上游服务器通过直连还是代理访问，结果最终由哪个组件返回。

先确认是解析问题还是连接问题

使用 nslookup、dig 或系统解析命令检查域名是否有结果，再通过日志观察 Clash 是否收到查询。若解析得到地址，但连接仍超时，问题可能在节点或目标路径；若纯 IP 请求可用而域名失败，DNS 的可能性更高。浏览器可能启用独立的安全 DNS，结果与系统命令不同。排查期间应暂时关闭浏览器自定义 DNS，统一走系统或 Clash 路径。

# 查询系统当前使用的解析路径
nslookup example.com

# macOS / Linux 查看 A 与 AAAA 记录
dig example.com A
dig example.com AAAA

# 指定本地 DNS 监听端口时
dig @127.0.0.1 -p 1053 example.com

如果本地 DNS 端口没有监听，检查配置是否启用 DNS、端口是否被占用、内核是否有足够权限绑定。使用 53 端口通常需要更高权限，也容易与系统服务冲突；桌面客户端常通过内部转发或高位端口处理，不应按示例强制改成 53。日志中的 bind failed、address already in use 和 permission denied 应分别按占用或权限处理。

理解 fake-ip 与 redir-host 的边界

fake-ip 会向应用返回保留地址，再由内核维护域名映射，便于规则按域名匹配并减少部分解析绕行。某些局域网设备发现、旧程序、游戏平台或需要直接获得真实地址的服务可能不兼容，需要加入 fake-ip-filter。不要把所有域名都加入过滤列表，否则会失去 fake-ip 的主要作用。应从日志确认具体域名，只添加必要的内网后缀、设备发现域名或明确不兼容项。

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 127.0.0.1:1053
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

示例中的上游仅用于展示语法，实际选择要结合网络可达性和隐私要求。加密 DNS 地址本身也需要解析，这一过程依赖 bootstrap 或 default-nameserver。若把所有引导解析都指向一个必须经过代理才能访问、但代理节点域名又依赖该解析器的地址，就会形成启动循环。合理路径是让节点域名和加密 DNS 主机名能够通过一个启动阶段可达的解析器获得地址，再由 Clash 接管后续请求。

处理 DNS 泄漏与多解析器并存

所谓 DNS 泄漏，重点是应用查询是否绕过预期路径，而不是测试页显示了多少服务器。系统代理通常只接管支持代理的应用连接，并不自动接管所有系统 DNS；TUN 配合 DNS 劫持覆盖范围更广，但也更依赖正确路由。先查看浏览器安全 DNS、操作系统加密 DNS、其他 VPN 和安全软件，确保没有多个组件争抢查询。完整检测方法可参考Clash DNS 泄漏检测与防泄漏配置。

内网域名无法解析时，不要直接删除全部 Clash DNS 设置。企业或家庭网络的私有域名通常只能由局域网 DNS 解析，可以通过 nameserver-policy 或专用域名规则送到内网解析器。设备离开该网络后，内网解析器不可达，应允许配置回退。与搜索域相关的短主机名也可能依赖 DHCP 下发的域后缀，完整域名可用而短名称失败时，应检查系统搜索域而非代理节点。

修复后应清理必要的系统和浏览器 DNS 缓存，重启一次客户端，再分别验证系统命令、浏览器和实际应用。日志应能看到查询进入预期监听器，上游请求可达，返回地址与连接规则一致。若重启后问题复现，检查是否有其他网络工具在登录时重写 DNS。DNS 排查的终点不是测试页显示某个名称，而是解析路径清楚、应用行为一致、内网与公网域名均按策略工作。

系统代理开启但应用不生效

系统代理不是强制所有流量进入 Clash。它只是向支持该机制的应用公布 HTTP、HTTPS 或 SOCKS 代理地址。浏览器通常会读取，部分游戏、命令行工具、商店应用和自带网络栈的软件可能忽略。看到客户端中的“系统代理已开启”，只能证明写入动作执行过，不能证明目标应用已经采用。应同时检查操作系统设置、应用设置和本地代理日志。

确认系统记录的地址与端口

打开系统网络设置，确认代理服务器为回环地址，端口与客户端当前监听值一致。更换配置、切换内核或同时安装多个客户端后，旧端口可能残留。Windows 还要区分系统代理、WinHTTP 代理和应用自身设置；macOS 的代理按网络服务保存，Wi-Fi 与有线网络可有不同配置；Linux 桌面环境的全局代理不会自动影响所有终端程序。

# Windows：查看 WinHTTP 代理状态
netsh winhttp show proxy

# macOS：查看 Wi-Fi 网络服务的 Web 代理
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

# Linux / 通用终端：检查环境变量
env | grep -i proxy

命令行程序通常读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，但具体支持情况由程序决定。环境变量只对启动后继承它的进程生效，已经打开的终端和编辑器可能仍保留旧值。设置后重新打开终端，完成测试后清除，避免客户端退出后命令仍指向不存在的本地端口。

# 当前终端临时使用 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# SOCKS5 并让代理端解析域名
export ALL_PROXY=socks5h://127.0.0.1:7890

# 测试完成后清理
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

处理绕过列表、PAC 与应用独立代理

系统绕过列表会让匹配的地址直接连接。若列表包含过宽的通配规则，目标站点可能从未进入 Clash。PAC 脚本也会按 URL 返回 DIRECT 或 PROXY；脚本缓存、地址失效或规则错误都会造成部分网站不生效。排查时先关闭 PAC，使用固定系统代理验证。如果固定代理有效，再单独检查 PAC 内容和下载状态。

浏览器扩展、开发工具、容器环境和 IDE 可能配置独立代理。独立设置优先级高于系统代理时，客户端切换不会影响它们。检查目标应用的网络选项，恢复“使用系统设置”或直接填写当前本地端口。对于完全不支持系统代理的程序，使用 TUN 可能更合适，但要先确认权限、路由和 DNS 已按前述章节工作。

区分规则直连与真正的未接管

应用请求出现在 Clash 连接日志中，但出口显示 DIRECT，说明系统代理已经生效，只是规则决定直连。此时应查看匹配规则和策略组，而不是继续修改系统设置。若日志完全没有请求，才说明应用绕过代理或未被接管。把模式临时切到全局可以验证规则分支，但测试后应恢复，并修正具体域名或规则集。

局域网地址通常应保持直连。不要为了让所有流量都出现在日志中而删除本地网段绕过，否则打印机、NAS、路由器管理页和设备发现可能受影响。系统代理中的“绕过本地地址”与 Clash 规则中的私有网段 DIRECT 可以同时存在，它们作用于不同层。排查公网目标时选择明确的公网域名，避免被局域网例外干扰。

验收时选一个浏览器和一个命令行工具：浏览器通过系统代理访问，命令行通过显式代理访问，两者都应在日志中出现。随后关闭 Clash，确认系统代理被清除且直连恢复。若系统代理无法覆盖目标程序，再评估 TUN，而不是把“系统代理开启”当成强制接管。不同接管方式的边界可在代理模式对比文章中继续查阅。

客户端启动失败、闪退与内核反复退出

客户端崩溃要先区分图形界面退出、内核进程退出和系统主动终止。界面关闭但代理仍可用，说明内核可能在后台继续运行；界面正常但无法监听端口，则可能是内核启动失败；整个程序突然消失，还要检查系统崩溃报告、内存压力和安全策略。不要在未保存日志前反复重启，连续启动可能覆盖最有价值的首次错误。

从空配置与最近变更开始

回忆崩溃前最后一次操作：更新订阅、启用 TUN、导入覆写、切换内核、升级客户端或修改主题。若客户端提供安全模式，先禁用自动载入最后配置；否则备份配置目录后，将最近配置移出，再启动空白环境。空配置能启动，说明程序主体基本正常，应逐个恢复订阅和覆写。空配置仍崩溃，则检查运行库、权限、安装文件和系统日志。

配置导致的内核退出通常会留下解析错误、未知字段、策略组引用不存在节点、规则集文件缺失或端口绑定失败。按日志中的第一条 fatal 或 error 处理，不要只看随后出现的“内核已退出”。如果配置来自订阅，先关闭本地覆写；如果只有某个订阅触发，保留一份脱敏后的最小配置用于定位。删除节点密码和订阅参数后再分享日志。

检查端口、文件权限和磁盘状态

端口占用会让内核启动后立即退出。完全关闭其他代理程序，检查任务管理器或活动监视器中是否仍有旧内核。配置目录不可写时，客户端可能无法更新缓存、数据库和日志；磁盘空间不足也会造成写入失败。不要长期以管理员身份运行来绕过所有权限问题，应把配置目录放在当前用户可读写位置，并让 TUN 所需的提权操作通过客户端正式机制完成。

Windows 可查看事件查看器中的应用程序错误，重点记录故障模块；macOS 可查看系统生成的崩溃报告；Linux 桌面从终端启动客户端，通常能看到缺失库、权限和图形后端错误。服务器环境运行 mihomo 时，使用 systemd 查看最近日志，确认退出码和重启次数。

# Linux：查看服务状态与最近日志
systemctl status mihomo --no-pager
journalctl -u mihomo -n 120 --no-pager

# 检查配置语法，路径按实际安装位置调整
mihomo -t -f /etc/mihomo/config.yaml

升级、迁移与兼容性处理

跨客户端迁移时不要复制整个程序数据目录。不同客户端的数据库、界面设置、覆写格式和内核路径并不相同。更稳妥的做法是导出订阅地址、自定义规则和必要的 DNS 片段，在新客户端中重新建立配置。桌面平台优先选择 Clash Plus；也可按需求使用 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 与 ClashX Meta 已停止维护，不适合作为处理新配置兼容问题的首选。

升级后启动失败，先查看发行说明中是否改变配置目录、内核接口或系统要求。本站不在正文写死具体版本号，当前可用安装包由下载页统一提供。重新安装前先备份用户配置，然后通过系统正常卸载并安装匹配架构的软件。不要混用 ARM 与 x64 安装包；macOS 还需区分 Apple Silicon 与 Intel。安装包架构错误可能直接无法启动，也可能通过转译运行但出现性能和扩展权限问题。

系统安全软件拦截时，应查看明确的拦截事件和文件路径，不要凭猜测关闭整套防护。企业管理设备可能禁止创建 VPN、安装网络扩展或运行未批准程序，这类限制需要由设备管理员处理。若文件被隔离，先确认下载来源是本站提供的对应客户端入口，再按系统策略恢复或重新安装。不要从不明转载页面补齐缺失组件。

崩溃修复的验收不只是“界面能打开”。应确认内核持续运行、本地端口稳定监听、配置能通过语法检查、系统代理可正常开关，并在重启系统后再次验证。若换成空配置稳定、恢复某段自定义设置后再次退出，继续缩小该段内容，直到得到最小触发条件。这个过程比反复安装多个客户端更容易得到确定结论。

Android 与 iOS 移动端专项排查

移动端客户端通过系统 VPN 接口接管流量，问题经常来自系统生命周期管理，而不是配置语法本身。屏幕关闭后断线、从 Wi-Fi 切换到蜂窝网络后卡住、只有某些应用无法连接、VPN 标志反复消失，都需要检查后台权限、始终开启 VPN、低电量模式、数据节省和其他 VPN 冲突。移动端一次通常只能保持一个 VPN 隧道，广告过滤器、企业 VPN 和 Clash 客户端不能同时占用同一接口。

Android：后台、VPN 权限与应用分流

Android 首次连接会显示 VPN 授权对话框，未授权时客户端可以导入配置，却无法建立系统隧道。连接按钮立即回到未连接状态时，先检查授权是否被撤销。部分厂商系统会在熄屏后限制后台进程，应把客户端加入允许后台运行或不受电池优化限制的列表，并允许自启动。设置名称因设备不同而变化，但目标一致：系统不能在隧道工作时冻结客户端进程。

若只有个别应用不走代理，检查应用分流或绕过 VPN 列表。按应用代理可以选择仅代理指定程序或排除指定程序，模式选反会造成大部分应用直连。启用“阻止未使用 VPN 的连接”前，应先确认客户端能在开机和网络切换后可靠重连，否则客户端短暂退出时设备会表现为完全断网。排查阶段先关闭该限制，稳定后再根据需求启用。

从 Wi-Fi 切到蜂窝网络后无法恢复，先断开并重新连接隧道，观察日志是否重新解析节点域名和建立连接。移动网络可能优先提供 IPv6，而当前节点域名或 DNS 路径只适配 IPv4；也可能存在私人 DNS 与客户端 DNS 同时工作。将 Android 私人 DNS 暂时设为自动，用客户端默认 DNS 路径复测。如果恢复，再决定保留哪一套解析机制。

iOS：VPN 配置、按需连接与系统切网

iOS 首次启用时需要允许添加 VPN 配置。系统设置中若存在多个同类配置，确认当前启用的是 Clash Plus 对应项。本站移动端首推 Clash Plus，应用通过 App Store 安装，官网信息可在iOS 下载入口核对。连接后没有 VPN 状态时，回到系统 VPN 页面查看是否在尝试连接、是否立即断开，再返回客户端读取日志。

低电量模式和系统资源回收可能影响后台维持，但正常的 Network Extension 应由系统管理。若客户端被手动强制退出，隧道可能停止，排查时不要频繁从多任务界面划掉应用。按需连接规则配置不当会造成 Wi-Fi 下连接、蜂窝下断开，或进入特定网络后循环重连。先关闭复杂按需规则，手动建立稳定连接，再逐条恢复网络条件。

移动端订阅与证书问题

移动浏览器复制订阅链接时，容易把页面显示文本而非实际链接复制下来。使用服务页面的复制按钮，粘贴后检查开头和末尾，不要通过截图转录。订阅更新若在 Wi-Fi 失败、蜂窝成功，检查当前 Wi-Fi 的认证页面和 DNS；反之则检查蜂窝数据权限。系统设置中若禁止客户端使用移动数据，隧道界面可能存在，但订阅更新和节点连接都会失败。

系统时间同样影响移动端 TLS。开启自动日期与时区。公共 Wi-Fi 常要求先通过网页认证，VPN 提前接管后认证页可能无法弹出。此时先断开 Clash，完成网络登录，确认直连网页可用，再建立隧道。离开公共网络后若认证状态残留，关闭再开启 Wi-Fi 通常比修改代理配置更有效。

移动端最终应完成四轮验收：Wi-Fi 下连接并访问，切换蜂窝后继续访问，锁屏数分钟后恢复访问，重启客户端后重新载入订阅。每轮都观察 VPN 标志和日志。若 Android 与 iOS 在同一网络、同一订阅下都失败，问题更可能位于节点或订阅；若只有一台设备失败，则检查该设备的权限、DNS 和系统限制。需要重新安装时，Android 可在Android 下载区选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard；iOS 使用 Clash Plus 的商店入口。

完成排查后，保留一份简短记录：设备系统、客户端、接管模式、出错网络、日志关键词、采取的修改和最终结果。下次相同症状出现时，先复用已经验证的步骤，而不是重新尝试全部设置。若问题涉及客户端项目关系和内核来源，可继续阅读Clash 开源生态项目关系图，避免把图形客户端、内核和移动端实现混为一类。