Clash 故障排查：从症状定位到恢复连接

一、Clash 已连接但无法上网

先区分客户端未启动、代理未接管与配置不可用

“无法上网”只是浏览器看到的结果，故障可能发生在三个不同位置。第一层是客户端内核没有成功运行，本地代理端口并未监听；第二层是内核正常，但浏览器或应用没有把请求交给 Clash；第三层是流量已经进入 Clash，却因为节点、规则或 DNS 失败而无法到达目标网站。排查时先观察客户端状态页或日志页。如果日志完全没有新增记录，通常说明应用流量没有进入客户端，应检查系统代理、浏览器代理扩展和 TUN 模式。若点击网页时日志持续出现请求，但结尾是 timeout、connection refused 或 DNS error，则应继续检查节点和解析链路。

确认本地端口是否监听，可以从客户端设置中找到混合端口，常见配置名是 mixed-port。端口并不要求固定为某个数字，关键是客户端显示的端口与系统代理、浏览器扩展或终端环境变量保持一致。Windows 可在终端执行 netstat，macOS 与 Linux 可使用 lsof。命令有输出说明端口由某个进程占用，但还要核对占用进程是否确实是当前客户端；如果旧客户端残留进程占住端口，新客户端可能启动失败。

netstat -ano | findstr LISTENING
lsof -nP -iTCP -sTCP:LISTEN

用本地连接与代理连接做对照

先关闭系统代理和 TUN，访问一个本地网络原本可以直接打开的网站，确认基础网络本身可用。随后只开启系统代理，再访问同一网站并查看 Clash 日志。这个对照可以排除 Wi-Fi 未认证、网线断开、网关异常或运营商网络中断。如果关闭代理也无法访问，继续调整 Clash 不会解决问题，应先修复系统网络连接；如果关闭代理正常、开启后全部失败，问题集中在本地端口、规则、节点或 DNS。

还可以用命令明确指定本地代理进行测试，避免浏览器缓存和扩展干扰。将端口替换为客户端设置页显示的混合端口。若命令能返回响应而浏览器不能，内核和节点大概率正常，应转向浏览器代理扩展、HTTPS 检查软件或系统代理覆盖设置。若命令也超时，查看同一时刻的日志，确认请求选中了哪个策略组和节点。

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

检查规则模式与策略组选择

规则模式会根据域名、IP 和规则集决定直连、代理或拒绝。订阅更新后，策略组可能恢复为默认选项，也可能引用已经失效的节点。打开代理或策略组页面，逐层检查当前组最终落到哪个节点，不能只看最外层组名。为了判断是不是规则命中错误，可以短时间切换到全局模式并选择一个已确认可用的节点测试。全局模式恢复而规则模式失败，说明客户端本身与节点可用，重点应放在规则集、策略组引用和规则顺序；全局模式仍失败，则继续检查节点和 DNS。

不要长期用全局模式掩盖规则问题。规则从上到下匹配，靠前的宽泛规则可能截获后续更精确的域名规则。例如把全部私有地址直连通常合理，但错误的 IP 段或过宽的域名后缀会让目标请求绕过代理。查看连接记录中的命中规则，比反复切换模式更有效。自定义规则修改后应重新载入配置，并确认客户端没有因为 YAML 语法错误回退到旧配置。

排除回环代理与防火墙拦截

部分安全软件会拦截本地回环连接，表现为客户端显示运行中，但所有指向 127.0.0.1 的代理请求都失败。可以临时暂停相关网络过滤功能进行一次对照测试，而不是直接删除防火墙规则。企业设备还可能由管理策略锁定系统代理，此时设置开关看似成功，几秒后又被恢复。检查系统代理页面是否持续保留本地地址与端口，并确认没有两个代理工具同时写入系统设置。

如果问题发生在休眠唤醒、切换 Wi-Fi 或 VPN 断开之后，先退出客户端并确认进程结束，再重新打开。网络接口变化时，旧连接与旧 DNS 缓存可能仍绑定在已经失效的接口上。重启客户端比不断点击系统代理开关更能完整重建监听端口和连接池。仍无法恢复时，再重启系统网络接口或操作系统，并保留重启前日志用于判断问题是否重复。

二、节点超时、握手失败与连接被拒绝

先判断单节点故障还是整组故障

节点测试显示超时，不等于客户端整体损坏。首先在同一策略组中选择至少两个不同地区、不同入口的节点，并使用同一个测试地址重复检查。如果只有某个节点失败，其他节点可以建立连接，通常是该节点下线、入口地址变化、端口不可达或订阅信息已经过期；直接切换可用节点，并等待服务提供方更新订阅即可。如果同一订阅的全部节点失败，但另一份配置正常，问题集中在该订阅或服务线路。如果所有配置、所有节点同时超时，才需要检查本地网络、防火墙、系统时间和协议兼容性。

客户端内置的延迟测试通常是通过指定 URL 发起一次 HTTP 请求，它衡量的是“完成该测试请求”的时间，不是单纯 ICMP ping。测试地址在当前网络不可达、被重定向或要求特殊握手时，也会让可用节点显示超时。因此应同时进行真实网页访问与连接日志观察，不要只凭一个红色延迟标记下结论。节点能打开目标网站但测试失败时，可更换为稳定、响应体较小的测试地址，或保留实际访问结果作为主要判断依据。

读懂常见错误方向

检查系统时间、IPv6 与协议字段

TLS 类节点依赖正确的系统时间。时间误差过大时，证书可能被判定为尚未生效或已经失效。启用系统自动校时，并确认时区正确；虚拟机、双系统和长时间休眠设备尤其容易出现时间漂移。若日志指向证书名称或握手参数，再检查订阅生成的服务器名称、传输方式和端口是否完整。手工编辑节点时，字段拼写、缩进或布尔值类型错误都可能导致内核载入了与预期不同的参数。

IPv6 是另一类常见分支。节点入口域名可能同时返回 IPv4 与 IPv6 地址，而当前网络只提供不完整的 IPv6 连通性，于是客户端优先尝试 IPv6 后持续超时。可以先在系统中测试目标域名的 IPv4 与 IPv6 解析结果，再短时关闭客户端的 IPv6 选项做对照。如果关闭后立即恢复，说明应修复本地 IPv6 路由、调整 DNS 返回策略，或在配置中明确选择可用地址族，而不是把所有节点都标记为失效。

排查网络类型与出口限制

公司、学校、酒店和公共 Wi-Fi 可能限制非常用端口或要求先完成网页认证。先关闭 Clash，打开任意 HTTP 页面触发认证页并完成登录，再重新测试节点。手机热点可作为很有价值的对照网络：同一设备、同一客户端、同一配置在热点下正常而在固定网络下失败，说明客户端配置基本正确，故障位于原网络的 DNS、路由或访问控制。反过来，如果不同网络都只让同一个节点失败，节点端问题的可能性更高。

不要用不断增加超时时间来掩盖不可达问题。超时时间适合容忍高延迟线路，但不能修复错误地址、关闭端口或缺失路由。需要长期观察时，可选择固定节点连续访问稳定站点，记录失败发生在连接阶段还是传输阶段。连接阶段立即拒绝通常是服务端口状态；等待较长时间后超时更接近丢包、路由黑洞或入口被过滤；连接成功后频繁中断则要检查 MTU、网络切换和线路质量。

订阅更新后的兼容问题

如果节点在更新订阅后全部变为错误，而更新前仍可使用，先切回最近一份可用配置或从备份恢复。订阅内容可能引入当前内核不支持的协议字段，也可能改变策略组名称，导致规则引用不存在的组。查看配置载入日志，重点寻找 unknown field、unsupported、proxy group not found 等信息。确认问题来自客户端兼容性后，应从下载页选择仍在维护的客户端，桌面与移动平台可优先查看 Clash Plus，并重新导入原始订阅，不要在损坏的缓存配置上连续覆盖。

三、订阅导入失败、更新失败或配置为空

确认地址完整并区分订阅与网页

订阅失败首先要确认复制的是完整订阅地址，而不是服务后台首页、使用教程页面或浏览器地址栏中被截断的跳转链接。订阅地址通常包含路径和查询参数，聊天软件换行、二维码识别、浏览器翻译或文本清理工具都可能删掉末尾字符。把地址粘贴到纯文本编辑器中，检查开头协议、域名、路径和查询部分是否完整，同时留意首尾空格。不要把订阅原文发布到截图、日志分享或公开论坛，它可能包含用于识别账户的访问参数。

在浏览器中打开订阅地址时，返回结果可能是 YAML 文本、编码内容或文件下载；如果看到登录页、验证码、套餐说明或 HTML 错误页，客户端自然无法把它解析成配置。浏览器能下载不代表客户端一定能更新，因为浏览器可能使用了已有代理、登录 Cookie 或不同 DNS。反过来，浏览器打不开也不等于地址失效：有些服务要求特定请求头。最可靠的判断仍是查看客户端更新日志中的 HTTP 状态和解析错误。

根据 HTTP 状态定位请求阶段

处理首次导入时的网络依赖

首次安装时尚未有可用节点，订阅域名如果在当前网络无法直连，就会形成“需要代理才能下载配置，但下载配置后才有代理”的闭环。可以在另一条可访问的网络上完成首次导入，例如手机热点；也可以由可信设备下载配置后通过客户端支持的本地导入方式载入。完成后再回到原网络更新。不要随意把订阅内容交给在线转换网站，配置中可能包含节点凭据和策略信息。

已经有旧配置时，可以先选择一个可用节点并开启系统代理，再执行订阅更新。有些客户端提供“通过代理更新”或更新代理选项，应确认它引用的策略组最终选中了可用节点。如果更新动作仍然直连，可在日志中查找订阅域名对应的连接记录，观察其命中了 DIRECT 还是代理策略。规则模式下，订阅域名被错误直连是很常见的更新失败原因，可以添加精确域名规则后重新加载配置。

配置下载成功但列表为空

更新提示成功而节点或策略组为空，说明网络请求可能完成了，但返回内容不是客户端期望的结构。先打开配置管理页查看文件大小和更新时间；极小的文件往往只是错误信息或空响应。若客户端允许查看原始配置，检查是否存在 proxies、proxy-groups 和 rules 等顶层字段。仅含远程提供者的配置还可能依赖 proxy-providers，此时主文件载入成功后仍需继续下载提供者文件，后续请求失败也会让节点列表为空。

mixed-port: 7890
mode: rule
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 使用空格缩进，不能用制表符；同一级字段缩进必须一致；包含冒号、井号或特殊字符的名称适合用引号包围。解析器给出行号时，应先检查报错行上一行，因为真正缺少引号或缩进的位置常在前一行。

缓存、覆盖与重复配置

客户端可能同时保留远程订阅、本地副本和当前运行配置。更新了订阅却没有切换到新配置时，运行中的内容不会变化；多个同名配置也容易造成误判。更新后确认当前激活项、更新时间和配置来源一致，再执行一次重新载入。若配置管理页持续显示旧内容，可先导出必要的自定义规则，删除失败的订阅条目后重新添加，而不是反复覆盖同一个损坏缓存。

订阅能更新但每隔一段时间又失败，应记录失败时使用的网络、系统代理状态和返回状态。不要频繁点击更新按钮，服务端可能对短时间请求进行限制。合理的自动更新间隔应以服务方建议为准。关于导入入口与基础配置流程，可回到快速上手指南核对；下载页的常见问题也适合处理安装包与客户端选择问题。

四、连接正常但速度慢、卡顿或下载不稳定

把节点、线路和本地设置分开测试

速度慢最容易被直接归因于节点，但实际链路包括本地设备、路由器、接入网络、节点入口、节点出口和目标网站。先关闭代理测试基础网络，再开启代理固定一个节点，使用相同网站、相同文件和相近时间重复测试。不要同时用多个测速网页下结论，因为测试服务器位置、并发方式和缓存策略不同。若直连本身已经拥堵，应先解决 Wi-Fi 信号、路由器负载或运营商线路问题；若直连稳定、代理明显变慢，再进入节点与配置层排查。

测试节点时应固定策略组，避免 url-test 在过程中自动切换。先比较同一地区的两个节点，再比较不同地区节点，这样能区分单节点负载与跨境路由差异。延迟适合判断交互响应，不能代表可持续带宽。一个延迟稍高但丢包少的节点，实际网页和视频体验可能比低延迟、高抖动节点更稳定。完整的三层检查流程可继续阅读节点、线路与本地设置排查清单。

观察拥堵时间与目标差异

只在晚间或特定网络环境变慢，通常与线路拥堵有关。记录正常和异常时段，不要在一次测试后永久修改配置。如果所有目标网站都变慢，优先考虑入口线路、节点负载和本地网络；如果只有一个网站慢，可能是节点出口到该网站的路由、目标站限速或内容分发区域不匹配；如果网页正常但大文件慢，应检查持续带宽、并发连接限制与传输协议，而不是只看首页打开速度。

策略组自动测试过于频繁也会造成不稳定。url-test 会根据测试结果选择节点，网络抖动时可能反复改变出口，已建立连接与新连接使用不同路径，登录状态或长连接会受到影响。需要低延迟时使用 url-test，需要可用性优先时考虑 fallback，需要分摊连接时才选择 load-balance。三者的工作方式和参数差异可参考策略组配置详解，不要把自动切换频率设置得远小于实际网络变化周期。

检查 DNS、IPv6 与连接复用

网页首次打开慢、刷新后变快，常见原因是 DNS 查询或首次连接建立耗时。查看日志中请求在 DNS 阶段停留多久，并分别测试本地 DNS 与加密 DNS。DNS 服务器不是越多越好；并行查询多个不稳定服务器会增加结果差异，错误的 fallback 过滤还可能让每次查询都等待额外超时。先保留一组稳定主服务器与清晰的回退策略，再评估效果。

IPv6 路径质量不佳时，域名返回 IPv6 地址可能导致请求先等待失败，再回退 IPv4，表现为每个新网站都慢几秒。短时关闭 IPv6 做对照能确认方向，但长期方案应是修复 IPv6 连通性或让 DNS 与路由策略保持一致。仅在 DNS 中关闭 IPv6 返回，却保留其他应用直接使用 IPv6，可能产生新的行为差异，因此每次改动都要配合连接日志验证。

排查 TUN、MTU 与局域网设备

TUN 模式需要把数据封装到虚拟接口，MTU 不合适时，小请求可能正常，大响应或上传则频繁重传。典型表现是部分网站打开、部分网站卡在加载中，或者文字出现但图片和视频失败。可在客户端支持的范围内逐步降低 TUN 接口 MTU，每次只调整一个小范围并测试同一目标。不要直接套用其他网络环境的固定值，因为宽带、移动网络、虚拟机和叠加 VPN 的可用 MTU 不同。

局域网中若由路由器运行代理，还要确认终端流量确实经过该路由器，旁路由网关和 DNS 地址配置一致。终端使用了其他 DNS 时，域名解析可能绕过预期策略；双路由或 Mesh 漫游也可能让设备切换到不同出口。桌面客户端同时开启局域网共享和本机 TUN 时，应避免与路由器代理形成重复转发。重复代理会增加握手、改变源地址，并让问题日志分散在两台设备上。

本地资源与后台任务

客户端界面卡顿不一定代表代理吞吐不足。系统正在同步文件、备份照片、更新游戏或运行虚拟机时，CPU、磁盘与网络都会竞争资源。任务管理器或活动监视器可以确认是否有后台进程占满网络。安全软件的 HTTPS 扫描会检查每条连接，也可能显著增加延迟；采用临时对照测试判断影响，不要在缺少组织授权的设备上修改管理策略。

最终应记录“基础网络速度、固定节点表现、异常时段、目标类型、是否启用 TUN”五项信息。只说“很慢”无法判断是延迟、带宽、丢包还是解析耗时。获得可重复条件后，再选择更稳定节点、调整策略组、修复 DNS 或 MTU。节点长期不可用时直接更换比堆叠复杂参数更可靠；本地配置已经多次修改且难以追踪时，可备份后新建一份最小配置逐项恢复功能。

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

先确认是域名问题还是连接问题

DNS 故障常被误认为节点超时。最直接的区分方法是比较域名与 IP：域名访问失败、已知 IP 可以建立连接，说明解析链路值得优先检查；域名能够解析出地址，但连接仍超时，则应转向节点、路由和防火墙。使用 nslookup、dig 或系统自带解析命令查看返回记录，同时在 Clash 日志中确认查询由系统 DNS、Clash DNS 还是远程 DNS 处理。

nslookup example.com
dig A example.com
dig AAAA example.com
ipconfig /flushdns
sudo dscacheutil -flushcache

命令行结果与浏览器可能不同。浏览器可能启用自己的安全 DNS、缓存或扩展，而终端通常使用系统解析器。排查时先关闭浏览器自定义 DNS进行一次对照，确认所有应用是否使用同一路径。如果只有浏览器异常，修改 Clash 全局 DNS 往往不是第一选择；如果浏览器、终端和客户端更新都失败，系统 DNS 或网络出口问题的可能性更高。

理解 redir-host 与 fake-ip 的差异

redir-host 返回真实解析地址，行为直观，但规则判断可能依赖解析结果，且不同网络的返回可能不一致。fake-ip 会向应用返回保留地址，再由 Clash 保存域名映射并接管后续连接，因此能够在更早阶段按域名分流。fake-ip 模式下看到保留地址通常是正常现象，不应把该地址当成真实服务器地址。真正的问题是应用绕过 Clash 直接访问 fake-ip，或者映射记录失效后连接没有被正确还原。

部分局域网发现、打印机、游戏和依赖真实 IP 的应用不适合 fake-ip，可通过过滤列表让指定域名返回真实地址。过滤规则应从出现问题的具体域名开始，不宜一次加入过宽后缀，否则大量请求会绕开 fake-ip 的域名映射优势。修改后清理客户端 DNS 缓存和应用缓存，再重试原始场景。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

示例展示常见字段结构，实际 DNS 地址应根据所在网络的可达性选择。若 DNS 服务器本身必须经过代理访问，应确保启动阶段仍有可用的基础解析路径，否则客户端为了连接加密 DNS 先要解析其域名，而解析该域名又依赖尚未建立的代理，最终形成循环依赖。

处理 DNS 循环与启动依赖

节点服务器使用域名时，Clash 必须先解析节点入口才能建立代理。如果所有 nameserver 都要求通过该代理访问，就会出现启动阶段无可用解析器的问题。解决思路是为节点域名准备可直连的 bootstrap 解析，或在配置支持时使用明确的 default-nameserver。基础解析器的职责是帮助建立代理，不一定承担全部应用查询。配置完成后查看启动日志，确认节点入口解析发生在代理连接之前且没有重复超时。

TUN 模式还可能接管系统的全部 DNS 流量。如果系统 DNS 指向 Clash，而 Clash 上游又错误地指回系统监听地址，查询会在本机循环。检查上游地址不能是当前客户端自己的 DNS 监听端口，也不能被另一代理软件再次转发回来。局域网路由器、广告过滤器和客户端同时提供 DNS 服务时，画出请求顺序很有帮助：应用到系统、系统到 Clash、Clash 到上游，每一跳都应有明确且不重复的目标。

DNS 泄漏与分流一致性

DNS 泄漏通常指域名查询走了与实际连接不同的网络路径。它不一定造成断网，但可能使解析结果与代理出口地区不匹配，出现内容分发错误、网站跳转异常或访问速度不稳定。规则模式下，可让需要代理的域名由合适的远程解析路径处理，直连域名使用本地解析；关键是 DNS 规则与连接规则保持一致。仅把所有查询强制发往单一远程服务器，可能让本地服务和局域网域名失效。

检查泄漏时不要只依赖单个网页结果。网页看到的是特定请求使用的解析服务，浏览器安全 DNS、预连接和缓存都可能影响结果。更可靠的方法是清理缓存后，发起一个新域名查询，同时观察 Clash DNS 日志、系统抓包或上游查询记录。确认查询经过预期路径后，再判断是否存在隐私或区域匹配问题。

清缓存与恢复最小配置

修改 DNS 后需要清理多个层级：客户端自身缓存、操作系统缓存、浏览器缓存以及可能的路由器缓存。通常先重启 Clash 内核，再刷新系统 DNS，最后完全退出并重开浏览器即可。频繁重启路由器不是第一步，因为它会同时改变公网地址、无线连接和 DHCP 状态，反而增加变量。若清理后短时间正常、随后再次失败，应检查自动覆写配置、DHCP 下发 DNS 和浏览器策略是否把旧设置重新写回。

复杂配置难以定位时，建立最小 DNS 配置：一个可达的基础解析器、一个增强模式、关闭额外脚本和覆写，只测试普通域名。确认稳定后再逐项加入 fallback、分流与过滤规则。每增加一项就记录对应行为。这样虽然比复制一份大型配置慢一些，却能准确找到触发问题的字段，并避免把网络环境差异误认为内核缺陷。

六、系统代理已开启但浏览器或终端不生效

系统代理只影响遵循系统设置的应用

系统代理并不是操作系统层面的全部流量接管。浏览器和部分桌面应用会读取系统 HTTP、HTTPS 或 SOCKS 设置，终端命令、游戏、虚拟机和某些跨平台应用则可能完全忽略它们。因此“浏览器能用、终端不能用”通常不是 Clash 故障，而是两类应用使用了不同代理入口。需要覆盖更多流量时可考虑 TUN 模式；只处理单个命令时，显式设置环境变量更容易控制和撤销。

先打开操作系统代理设置，确认服务器地址是本机回环地址，端口与 Clash 当前混合端口一致。客户端切换配置或端口后，旧系统设置可能没有同步更新。还要检查自动代理脚本、企业配置和其他代理软件是否覆盖手动设置。Windows 中不同网络设置入口可能最终写入同一组代理项，反复在多个位置修改容易造成认知混乱，应以客户端状态和系统实际值为准。

浏览器扩展与独立 DNS

代理扩展可以覆盖系统代理。扩展处于直连、自动切换或引用旧端口时，系统代理开关不会产生预期效果。排查时用浏览器隐私窗口并临时停用代理类扩展，只保留系统代理测试。如果恢复，再统一选择一种控制方式：由 Clash 写系统代理，或者由扩展明确指向 Clash 本地端口，避免两套规则同时判断。

浏览器内置的安全 DNS 也可能绕开系统解析路径，造成网页域名解析与 Clash 设置不一致。它通常不影响代理 TCP 连接是否建立，却会影响规则命中、区域结果和故障判断。测试阶段可以暂时使用系统默认 DNS，确认浏览器和终端行为一致后，再决定是否开启浏览器独立解析。关于浏览器与终端两条排查线，可参阅系统代理不生效排查。

为终端设置环境变量

许多命令行工具读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。变量只对当前终端会话或从该会话启动的进程生效，写入 shell 配置文件后才会在新会话持续存在。排查时先临时设置，测试完成后删除，避免日后客户端未启动时所有命令都指向失效端口。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

curl -I https://example.com

unset HTTP_PROXY
unset HTTPS_PROXY
unset ALL_PROXY

socks5h 中的字母 h 表示域名也交给代理端解析，适合避免本地 DNS 与代理路径不一致。不同工具支持的变量和协议不完全相同，有些只识别小写变量，有些拥有自己的配置文件。若 curl 成功而包管理器失败，应查看该工具的代理文档，而不是继续修改 Clash。Windows PowerShell 可以使用当前会话环境变量，关闭窗口后自然失效，更适合测试。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -I https://example.com
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

何时改用 TUN 模式

应用没有代理设置、忽略系统代理，或需要接管 UDP 流量时，TUN 模式更合适。TUN 创建虚拟网络接口并通过路由接收流量，覆盖范围比系统代理广，但也更容易与 VPN、虚拟机、容器和安全软件冲突。启用前先关闭其他网络接管工具，确认基础系统代理模式已经可用，再开启 TUN。这样如果问题出现，可以明确归因于虚拟接口、路由或权限，而不是节点本身。

启用 TUN 后检查系统是否新增虚拟接口、默认路由是否合理、DNS 是否被正确接管。某些系统需要管理员权限创建接口；权限不足时，界面开关可能打开，但内核日志会报告设备创建失败。休眠、切换网络或 VPN 连接后，路由优先级可能变化，表现为部分流量绕过或全部断开。关闭再开启 TUN可以重建路由，但若频繁发生，应检查冲突软件和接口优先级。

局域网连接与远程设备

让手机或其他电脑使用本机 Clash 时，需要开启允许局域网连接，并在远程设备中填写运行 Clash 设备的局域网 IP，而不是 127.0.0.1。回环地址永远指向当前设备自身。主机防火墙还要允许对应端口从受信任局域网进入。先在主机上确认端口监听地址：只监听回环地址时，其他设备无法连接；监听局域网接口后，再从远程设备测试端口可达性。

局域网共享应限制在可信网络。公共 Wi-Fi 下不需要共享时关闭该选项。远程设备可以连接本地端口但无法上网时，查看主机 Clash 日志是否出现来自该设备的请求；没有日志说明请求未到达，检查 IP、端口、客户端隔离和防火墙；有日志但失败，则按节点、规则与 DNS 分支继续排查。区分“远程到主机”和“主机到节点”两段路径，可以避免在错误设备上反复改设置。

七、客户端无法启动、反复崩溃或端口被占用

区分界面退出与内核退出

Clash 客户端通常由图形界面和代理内核两部分组成。界面窗口关闭后，内核可能仍在后台运行；反过来，界面可以正常打开，但内核因为配置错误或端口冲突不断退出。任务栏、菜单栏图标和进程列表能帮助区分。无法启动时先结束同类客户端和残留内核进程，再只启动一个客户端。不要同时运行 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等多个会写系统代理的程序，否则端口、系统代理和 TUN 路由会互相覆盖。

日志是判断退出位置的第一依据。界面完全不出现时，可从系统事件查看器、崩溃报告或终端启动输出中找信息；界面出现但代理状态反复停止时，查看内核日志。配置解析错误通常会给出字段或行号，端口冲突会出现 address already in use，权限问题会出现 permission denied，动态库或组件缺失则会在应用启动阶段报告加载失败。

定位端口占用

混合端口、控制端口和 DNS 监听端口都可能冲突。先在客户端设置中记录相关端口，再使用系统命令查询占用进程。Windows 的 PID 可在任务管理器详情页中对应进程，macOS 与 Linux 的 lsof 会直接显示进程名。不要看到端口被占用就立即结束系统进程；先确认它是否是旧 Clash 内核、其他代理工具或业务服务。若端口属于必要程序，应在 Clash 设置中改用未占用端口，并同步更新系统代理和终端变量。

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

端口修改后仍提示冲突，说明配置文件可能覆盖了界面设置，或者客户端同时载入多个监听配置。检查当前生效配置中的 mixed-port、port、socks-port、external-controller 和 DNS listen。具体的进程定位与端口修改步骤可参阅端口被占用启动失败处理。

处理损坏配置与不兼容字段

客户端在导入新配置后立即崩溃或内核无法启动，应先切回旧配置。若界面打不开，可以在应用数据目录中备份配置后移走最近新增文件，让客户端以默认状态启动。不同客户端的数据目录不同，不建议在未确认路径时批量删除。优先使用客户端提供的重置或安全启动方式；手工处理时只移动文件并保留副本，确认恢复后再清理。

配置不兼容常见于内核字段发生变化、脚本语法不被支持或远程规则格式异常。查看日志中第一个错误，而不是最后一串连锁错误。第一个字段解析失败会导致后续策略组、规则和 DNS 全部无法建立。可以用最小配置验证内核能否运行，再逐块加入代理、策略组、规则和 DNS。若最小配置稳定，问题明确位于原配置；若最小配置也退出，再检查程序文件、权限和系统组件。

权限、应用目录与系统拦截

TUN 服务安装、虚拟接口创建和系统代理写入可能需要更高权限。普通代理端口通常不应要求客户端长期以管理员身份运行，但首次安装服务时可能出现系统授权提示。拒绝授权后，基础系统代理仍可能可用，而 TUN 无法启动。应根据日志确认缺失的是哪项权限，不要把“始终以管理员运行”当作所有问题的通用答案。

应用目录不可写也会引发配置保存失败、更新失败或启动循环。把便携程序放在受保护目录、只读磁盘或同步盘中时尤其常见。将客户端安装到正常应用目录，并确保用户数据目录有写权限。安全软件隔离了内核文件时，图形界面可能不断尝试启动一个不存在的可执行文件；查看系统安全记录并核对来源后，再决定恢复或从下载页重新安装维护中的客户端。

更新后异常与干净重装

更新后出现崩溃，先重启系统，排除旧进程和旧动态库仍被占用。随后备份订阅地址、自定义规则和覆写设置，确认当前安装来源，再执行重装。重装不等于直接删除全部用户数据：如果问题来自程序文件，保留配置通常可以恢复；如果问题来自配置或数据库损坏，保留所有旧数据会把故障一并带回。更稳妥的方式是先备份，再让新安装以空白数据启动，确认稳定后逐项导入。

Windows 可检查事件查看器中的应用程序错误，macOS 可查看系统生成的崩溃报告，Linux 从终端启动通常能直接看到缺失库和权限信息。分享日志时移除订阅地址、节点凭据、本地用户名和目录等敏感内容，只保留错误上下文。若崩溃能够稳定复现，记录“打开哪个页面、导入哪个配置类型、是否启用 TUN、前一步操作是什么”，这比只提供一张退出后的截图更有诊断价值。

建立可回退的稳定状态

恢复后不要立刻启用全部旧设置。先使用一个配置、一个系统代理入口和默认 DNS运行一段时间，再开启 TUN、脚本和自定义覆写。每次调整前保留可用配置副本。客户端选择方面，优先使用仍在维护并适配当前系统的安装包；桌面与移动平台可先查看 Clash Plus，Linux 还可选择 Clash Verge Rev 或 FlClash。已停止维护的软件仅适合处理既有环境，不应作为解决新系统兼容问题的首选。

八、Android 与 iOS 移动端专项排查

确认 VPN 权限与系统状态

移动端 Clash 客户端通常通过系统 VPN 接口接管流量，因此状态栏中的 VPN 标识比应用内按钮更能说明系统是否完成授权。首次连接时系统会弹出 VPN 请求，拒绝后客户端可能停留在连接中或立即断开。进入系统 VPN 设置确认当前配置存在，并检查是否有另一款 VPN、广告过滤或企业安全应用占用同一接口。多数移动系统同一时间只允许一个主要 VPN 连接，两个应用不能简单叠加运行。

Android 还可能启用“始终开启的 VPN”或“阻止未使用 VPN 的连接”。如果该设置绑定到另一应用，Clash 无法建立接口；如果绑定到 Clash，而客户端内核没有启动，所有网络都可能被系统阻断。排查时先关闭强制项完成基础连接测试，确认客户端稳定后再按需要恢复。iOS 中删除旧 VPN 配置后重新授权，有时可以解决系统保存的配置与当前应用状态不一致问题，但操作前应确认没有组织管理配置。

后台限制、电量优化与连接中断

移动系统会限制后台应用。锁屏几分钟后代理断开、重新打开客户端又恢复，通常与电量优化、后台活动权限或厂商清理策略有关。Android 可将客户端设为不受电池优化限制，允许后台运行，并在系统提供的自启动管理中保留必要权限。不同厂商菜单名称不同，但判断方法一致：保持同一网络，分别测试亮屏、锁屏和省电模式，观察 VPN 标识与客户端日志何时消失。

iOS 对后台网络扩展的管理更统一，但低电量模式、网络切换和系统资源回收仍可能触发重连。若每次从 Wi-Fi 切到蜂窝网络后失效，先等待系统完成接口切换，再手动断开并重连一次。频繁在短时间内点击连接按钮可能留下多个未完成状态，退出应用并在系统 VPN 设置中关闭连接，再重新打开通常更清晰。

Wi-Fi、蜂窝网络与私人 DNS

只在 Wi-Fi 下失败、蜂窝网络正常，说明订阅和节点大概率可用，应检查 Wi-Fi 认证、路由器 DNS、IPv6 和客户端隔离。公共 Wi-Fi 需要先关闭 VPN 完成网页认证，认证成功后再连接 Clash。只在蜂窝网络失败，则可能与移动网络 IPv6、数据节省、运营商接入点或节点入口可达性有关。分别选择支持良好的节点，并短时切换 IPv6 相关设置做对照。

Android 的私人 DNS使用系统级加密解析，可能与客户端 DNS 接管产生路径差异。出现域名打不开但 IP 可达时，可以临时将私人 DNS 调为自动，验证是否冲突。iOS 的加密 DNS 描述文件、内容过滤器和浏览器独立 DNS 也有类似影响。不要同时修改客户端 DNS、系统私人 DNS 和路由器 DNS；先选一层做对照，记录结果后再继续。

分应用代理与绕过列表

Android 客户端常提供分应用代理。某个应用无法连接、浏览器却正常时，检查它是否被排除，或当前模式是“仅代理选中应用”而该应用未勾选。应用更新、克隆应用和工作资料中的同名应用可能拥有不同标识，需要分别选择。切换分应用规则后完全退出目标应用再打开，已有连接不会自动迁移到新路径。

系统服务、局域网设备与支付类应用有时需要直连。应根据明确故障把具体应用加入绕过列表，而不是一次绕过大批系统组件。绕过后如果应用仍通过浏览器内核或共享服务发起请求，实际路径可能不完全由应用列表决定。查看连接日志中的目标域名和进程提示，配合规则设置判断，比只按应用名称猜测更可靠。

订阅更新与存储权限

移动端复制订阅地址时更容易混入换行或被浏览器省略。使用客户端的粘贴导入入口，并检查地址首尾。二维码导入失败时可改用文本方式，以区分摄像头识别与网络请求问题。更新提示成功但节点没有变化，确认当前选中的配置就是刚更新的订阅，并手动重新载入。旧配置仍在运行时，界面中的订阅更新时间并不代表内核已经切换。

部分 Android 版本对文件访问采用系统选择器，本地导入时应选择实际 YAML 文件，而不是只授予目录或云端占位文件。云盘文件尚未下载完成时，客户端可能读到空内容。先在文件管理器中离线保存，再从客户端导入。导出日志或备份时同样注意保存位置，清理应用数据会删除内部配置，因此重置前应先备份订阅与自定义规则。

移动端发热、耗电与流量异常

持续高耗电通常来自频繁重连、不可达 DNS、过短的节点测试周期或大量后台流量。先查看客户端是否不断出现连接失败与重试，再检查系统流量统计中哪个应用持续传输。自动测速间隔过短会让所有节点反复建立连接；规则提供者和订阅更新失败也可能形成重试。把自动任务恢复到合理间隔，并关闭不需要的详细日志，可以减少后台负担。

若流量显著高于预期，核对订阅服务的流量统计口径、节点倍率和设备后台任务。客户端转发的数据通常会同时出现在目标应用与 VPN 应用的系统统计中，不能简单相加。视频自动播放、云相册和系统更新在代理连接稳定后可能恢复后台传输，从而让用户误以为是 Clash 自身产生流量。固定时间窗口、关闭后台同步后再比较更有意义。

移动端恢复流程

建议按固定顺序恢复：先断开 VPN，关闭其他网络接管应用；确认 Wi-Fi 或蜂窝网络直连正常；重新打开 Clash，选择已知可用配置与节点；授权 VPN；观察状态栏与连接日志；最后再恢复私人 DNS、分应用代理和省电设置。如果基础连接在这套最小状态下仍失败，切换 Wi-Fi 与蜂窝网络做交叉测试，可以快速判断是设备配置、当前网络还是订阅节点问题。

需要重新安装时，从Android 下载入口或iOS 下载入口选择与平台一致的客户端，Clash Plus 可作为优先选项。重新安装前保存订阅地址和必要规则，安装后先导入一份配置完成基本访问，再逐步恢复旧设置。移动端问题往往由系统权限、后台限制和网络切换共同触发，保持恢复步骤简单，通常比复制桌面端全部参数更有效。