开始前:先分清四个状态
Clash 客户端通常由图形界面、Clash 或 mihomo 内核、配置文件、系统网络设置四部分共同工作。窗口能够打开,只能说明图形界面已启动;配置导入成功,也不等于流量已经进入代理。判断是否完成初始化,应依次确认配置、节点、代理入口和实际请求。
- 配置状态:当前配置文件能够被内核加载,界面没有显示 YAML 解析错误或字段不兼容。
- 策略状态:代理策略组已有可用节点,并且需要手动选择的策略组不是空值。
- 接管状态:系统代理或 TUN 模式至少启用一种,应用流量能够进入 Clash 监听端口。
- 连接状态:连接列表产生新记录,日志显示规则匹配结果,目标请求获得正常响应。
如果只盯着“已启动”或托盘图标,很容易把配置问题、节点问题和系统代理问题混在一起。下面十个问题按实际操作顺序展开,遇到故障时也可以直接跳到对应章节。
订阅与配置:导入不是连接
问题一:订阅地址导入后,为什么没有节点?
订阅地址本质上是远程配置入口。客户端需要访问该地址、下载响应内容,再把内容解析成代理节点、策略组和规则。导入动作完成但列表为空,常见原因包括地址复制不完整、订阅已失效、当前网络无法访问订阅服务器、服务器返回网页而不是配置,以及客户端不支持返回内容使用的格式。
先在配置或订阅管理页面执行一次手动更新,观察更新时间和错误提示。如果提示超时,应检查当前网络与订阅服务器之间的连通性;如果提示解析失败,应确认导入的是订阅地址,而不是登录页、控制台地址或二维码图片链接。部分服务会分别提供通用订阅、Clash 配置与单节点链接,桌面 Clash 客户端通常应选择明确标注为 Clash 或兼容 Clash 的配置入口。
还要区分“节点为空”和“策略组未选择”。节点可能已经存在于配置中,但首页只展示策略组。进入代理或 Proxies 页面,展开具体策略组后再查看成员。如果策略组由规则提供方动态生成,也应等待配置下载和解析结束后再操作。
问题二:订阅更新会覆盖手动修改吗?
通常会。远程订阅更新相当于重新下载一份配置,直接修改订阅生成的节点名称、规则或 DNS 字段,下一次更新时可能被远端内容替换。不同客户端对覆写、混入配置、脚本处理和配置补丁的实现不同,但基本原则一致:远程配置负责可更新内容,本地定制应放在客户端提供的覆写层中。
新手不宜一开始就大幅编辑 YAML。先保留原配置并确认基础连接可用,再根据客户端功能添加本地规则。编辑后若出现启动失败,优先检查缩进、冒号后的空格、列表符号和字段层级。YAML 使用空格表达层级,制表符、全角标点和错误缩进都可能导致整个文件无法加载。
节点与延迟:测试数字不等于实际速度
问题三:延迟最低的节点一定最快吗?
不一定。延迟测试主要反映客户端到测试目标完成一次连接或请求所需的时间,适合判断节点是否在线以及交互响应是否敏捷。下载速度还受到节点出口带宽、线路拥塞、跨网路由、目标站限速、协议开销和本地网络质量影响。一个延迟为几十毫秒的拥塞节点,实际吞吐量可能低于延迟稍高但线路稳定的节点。
选择节点时可分三步:先排除超时节点,再从低延迟节点中进行实际网页或文件请求,最后观察一段时间内是否出现频繁断流。游戏、远程终端和实时通话更关注延迟与抖动;视频和大文件下载更关注持续吞吐;普通网页则需要兼顾 DNS、握手速度和稳定性。
客户端中的 URL Test 策略组可以按固定地址周期测试并选择结果较好的节点,但测试结果只对该测试目标和测试时刻负责。Fallback 策略更偏向故障切换,负载均衡策略则可能按配置把不同连接分配到多个节点。具体行为取决于配置中的策略组类型,不应把所有“自动选择”都理解成单纯挑选最低延迟。
问题四:节点显示可用,网页为什么仍然打不开?
节点测试成功只证明某个测试请求能够通过该节点,不代表浏览器请求一定走了同一路径。首先查看连接列表中是否出现浏览器发起的域名。如果完全没有记录,问题通常位于系统代理、浏览器独立代理设置或 TUN 接管层;如果有记录,则继续查看命中的规则、最终策略和错误信息。
还可能出现测试地址可访问而目标网站不可访问的情况。目标域名可能被规则分配到 DIRECT,策略组可能选中了另一个节点,DNS 解析结果也可能与连接路径不一致。切换到全局模式可作为短时定位手段:若全局模式可用而规则模式不可用,应检查规则匹配和策略组;若两种模式都不可用,则优先检查节点、DNS、系统时间和本地网络。
规则模式与系统代理:确定流量从哪里进入
问题五:Rule、Global 和 Direct 三种模式有什么区别?
Rule(规则)模式会按配置中的规则逐条判断请求,例如按域名、IP、进程或规则集合决定直连、拒绝或交给某个策略组。它是日常使用中最常见的模式,前提是配置中的规则和策略组完整可用。
Global(全局)模式通常把进入 Clash 的请求统一交给全局策略组,适合临时验证节点是否能够工作。它并不表示设备上的每一条流量都会自动进入 Clash;流量仍需先经过系统代理、应用代理或 TUN 接口。
Direct(直连)模式让已经进入 Clash 的请求直接连接目标,不经过代理节点。它适合测试代理节点是否导致异常,也可用于暂时保留 Clash 接管状态而停止节点转发。Direct 不等同于彻底退出客户端,因为 DNS、监听端口和连接记录仍可能由内核处理。
排查时可使用简单对照:规则模式失败而全局模式成功,重点检查规则;全局模式也失败,重点检查节点和接管入口;Direct 模式失败,则本地网络、DNS 或目标服务本身也可能存在问题。测试结束后应恢复原来的规则模式,避免长期改变预期分流结果。
问题六:开启系统代理后,为什么有些应用仍然直连?
系统代理是操作系统向应用提供的一组代理设置。浏览器和许多桌面程序会读取这些设置,将 HTTP 或 HTTPS 请求发送到 Clash 的混合端口或对应代理端口。但并非所有应用都遵循系统代理:部分游戏、命令行工具、虚拟机、容器程序和自行实现网络栈的软件会直接建立连接。
先确认系统代理开关打开后,操作系统代理地址指向本机监听地址,端口与客户端当前端口一致。端口被其他程序占用、内核未运行或客户端切换配置后监听失败,都会造成系统代理存在但连接无法进入。浏览器若安装过独立代理扩展,也可能覆盖系统设置,应暂时停用扩展后再测试。
需要覆盖更多 TCP、UDP 或不读取系统代理的应用时,可以考虑 TUN 模式。TUN 会建立虚拟网络接口,由系统路由把更多流量送入内核处理,通常需要管理员权限。它的覆盖范围更广,但也更容易与其他 VPN、虚拟网卡、安全软件和自定义路由发生冲突。新手应先让系统代理模式正常工作,再按实际需求启用 TUN,而不是同时改变多项网络设置。
连接失败:按入口、规则、节点、目标分层检查
问题七:日志里的 timeout、connection refused 和 DNS error 分别说明什么?
timeout 表示某个网络阶段在限定时间内没有完成,可能发生在访问订阅、连接节点、建立目标连接或等待响应时。它通常指向线路不通、丢包严重、目标响应缓慢或防火墙拦截,但仅凭一个 timeout 不能直接确定故障位置。应结合日志中的目标地址、策略名称和连接链路判断。
connection refused 表示目标地址明确拒绝了连接。若拒绝发生在本机端口,可能是 Clash 内核没有监听对应端口;若发生在代理服务器,则节点服务可能停止或端口配置不匹配;若发生在最终目标,则目标服务可能没有开放该端口。
DNS 相关错误表示域名解析阶段没有获得有效结果,常见表现包括解析服务器不可达、增强模式配置不匹配、网络拦截 DNS 请求,或域名本身不存在。遇到这类错误,不要只反复切换节点。先确认普通网络能否解析域名,再检查配置中的 DNS 开关、监听设置、nameserver 与 fallback 等字段。修改 DNS 后应重新载入配置,并重新发起连接,旧连接不会自动采用新结果。
问题八:系统代理已经开启,连接列表为什么仍然是空的?
连接列表为空意味着当前观察到的请求没有进入 Clash。先刷新一个从未打开过的网页,避免浏览器直接使用缓存。随后检查客户端内核是否处于运行状态、系统代理是否指向正确端口,以及操作系统设置中是否残留旧客户端的代理地址。
如果浏览器使用隐私代理、扩展代理或企业管理策略,它可能绕过系统代理。命令行工具也常有独立环境变量,例如 HTTP 代理与 HTTPS 代理变量;这些设置可能指向另一个端口。TUN 模式下连接列表为空,则应查看虚拟网卡是否创建成功、路由是否生效,以及管理员权限是否授予。
还应排除局域网设备测试方式错误。Clash 默认监听本机地址时,其他设备不能直接连接。只有在客户端允许局域网访问、监听地址覆盖局域网接口,并且操作系统防火墙允许对应端口后,手机或其他电脑才能把该设备作为代理服务器。开放局域网监听前,应确认所在网络可信并限制可访问范围。
更新与维护:避免配置状态逐步失真
问题九:更新客户端后配置无法加载,应该怎么办?
图形客户端、内核和配置规范并不是同一个版本概念。更新客户端可能同时更换内核,也可能继续使用原内核;而订阅配置可能包含只被特定内核支持的字段。出现更新后无法加载时,先记录完整错误行,不要连续修改多个字段。
如果错误指向未知字段或策略类型,应确认当前客户端使用的是 Clash、Clash Meta 或 mihomo 内核,以及配置是否面向该内核生成。mihomo 延续并扩展了 Clash Meta 的能力,但旧版客户端内置的内核未必支持较新的配置项。若错误指向 YAML 行号,则检查该行附近的缩进、引号和列表结构,因为真正的结构错误可能出现在提示行之前。
处理顺序建议保持固定:备份当前文件,切换到一份已知可用的基础配置,确认内核能够启动,再重新更新订阅。若基础配置可用而订阅配置失败,问题集中在订阅内容或兼容性;若所有配置都失败,则检查客户端权限、内核文件、监听端口和升级过程。这样可以避免把配置错误误判为安装错误。
问题十:怎样判断 Clash 已经正确工作?
不要只用单个网页作为结论。一个完整验证应包含本地状态、代理路径和分流结果三个层面。首先确认内核运行、配置无错误、策略组已经选定节点;其次确认系统代理或 TUN 已启用,打开网页时连接列表出现新记录;最后查看不同请求是否命中预期规则,例如本地服务走 DIRECT,需要代理的目标进入指定策略组。
可以按照下面的检查表逐项确认:
- 配置页面显示最近更新时间,手动更新没有返回下载或解析错误。
- 代理页面至少有一个可用节点,当前策略组不是空值或失效节点。
- 规则模式已经启用,日志能够显示域名、规则和最终策略。
- 打开新网页时连接计数发生变化,上传与下载流量不再持续为零。
- 关闭系统代理后请求路径发生预期变化,重新开启后能够恢复。
- 重启客户端后配置仍可自动载入,系统代理状态符合客户端设置。
若以上项目都正常,说明安装、配置、节点和流量入口已经形成完整链路。此后再处理延迟、规则细化、DNS 优化或 TUN 兼容问题,会比反复重装客户端更有效。
- 确认客户端与内核正在运行。
- 手动更新订阅并检查解析结果。
- 选择一个已通过测试的节点。
- 暂用全局模式判断节点链路。
- 检查系统代理端口或 TUN 路由。
- 查看连接列表、规则命中和错误日志。
- 恢复规则模式,再处理具体分流问题。
每次只改变一个条件,并记录改变前后的现象。这样才能判断问题来自配置、节点、规则还是本地网络。