Windows
优先面向 Windows 设备。可比较 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 与归档客户端,安装前先区分图形客户端和独立内核。
前往下载首页只做平台分流,不在这里塞安装包清单。点击对应系统会进入下载页并自动切到该平台,客户端型号、适用架构、维护状态和安装方式都在那里展开。先确认设备系统,再挑图形客户端,比拿到一个不匹配的包后返工更省时间。
优先面向 Windows 设备。可比较 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 与归档客户端,安装前先区分图形客户端和独立内核。
前往下载按 Apple Silicon 与 Intel 处理安装包架构。图形客户端适合日常菜单栏操作,独立内核更偏向终端、自动化或服务化部署。
前往下载适合手机和平板。下载前查看设备架构与系统限制,导入订阅后还要授予本地 VPN 连接权限,系统电池策略也可能影响后台连接。
前往下载通过应用商店进入 Clash Plus。安装后从订阅地址导入配置,再按用途选择策略组;系统弹出网络配置请求时需要明确确认。
前往下载桌面环境可选 GUI 客户端,服务器、软路由和容器环境通常直接使用 mihomo 内核。先核对处理器架构,再决定 deb 包或压缩包。
前往下载Clash 的难点通常不是开关本身,而是配置文件、策略组、规则和 DNS 互相影响。下面按实际排查顺序拆开:先确认流量匹配哪条规则,再看策略组选择,最后检查 DNS 与订阅更新。左侧切换主题,右侧保留真实 YAML 或规则片段。
规则模式会从上往下检查请求,命中后立即停止继续匹配。域名规则适合明确服务,GEOIP 可处理地区归属,最后用 MATCH 接住剩余流量。实际配置时,把范围更具体的规则放在前面,把兜底规则放在末尾;否则一条过宽的规则会提前截走流量。与只提供全局开关的客户端相比,Clash 的价值在于能把直连、代理与拦截写进同一份可读规则表,排查时也能从连接记录反推命中项。
DOMAIN-SUFFIX,github.com,PROXY
DOMAIN-SUFFIX,local,DIRECT
GEOIP,CN,DIRECT
MATCH,Fallback
规则中的 PROXY 往往不是某个固定节点,而是一个策略组名称。select 适合手动选择,url-test 用测试结果自动选取,fallback 按可用性依次回退。配置时应先确认 rules 引用的组名确实存在,再检查组内节点或其他子组是否完整。把业务分类与具体节点解耦后,更换订阅节点不必重写整套规则;这也是多配置长期维护时最省事的结构。
proxy-groups:
- name: PROXY
type: select
proxies:
- Auto
- DIRECT
- name: Auto
type: url-test
Fake-IP 模式会先返回保留地址,再由内核在连接阶段恢复原始域名并执行规则。它能让域名规则更稳定地参与分流,但也要求系统 DNS、客户端监听端口和规则配置彼此一致。出现局域网设备异常、特定软件无法连接或解析结果绕过规则时,应先检查 fake-ip-filter、nameserver 与 respect-rules,而不是直接反复更换节点。DNS 问题与代理节点问题要分开诊断。
dns:
enable: true
enhanced-mode: fake-ip
respect-rules: true
fake-ip-filter:
- "*.lan"
REJECT 用于直接拒绝符合条件的连接,适合处理已经确认的追踪域名、遥测端点或不希望访问的目标。规则范围必须克制:优先使用精确域名或经过维护的规则集,避免用过宽后缀误伤登录、支付或消息服务。遇到页面局部加载失败时,先在连接记录里查找 REJECT 命中,再临时切换规则验证。拦截应当可定位、可撤回,而不是靠堆叠模糊规则制造黑盒。
DOMAIN,telemetry.example,REJECT
DOMAIN-SUFFIX,tracker.example,REJECT
DOMAIN-SUFFIX,service.example,PROXY
MATCH,Fallback
订阅链接通常返回完整配置,内容可能同时包含节点、策略组、规则和 DNS。导入后应先查看更新结果,再确认当前激活的 Profile,避免把“更新成功”和“已经切换到新配置”混为一件事。多订阅并存时,用来源和用途命名,不要只保留默认名称;修改远程配置前也要弄清客户端是否会在下次更新时覆盖本地改动。需要长期定制时,可把覆写层与远程订阅分开管理。
profile:
store-selected: true
store-fake-ip: true
mode: rule
log-level: info
“Clash”在实际使用中同时指向规则体系、配置格式、内核分支和多个图形客户端。把这些层次分开,才能判断一个教程到底在讲界面操作、YAML 字段还是内核能力。
原版 Clash 把代理节点、策略组、规则路由与 DNS 放进统一配置模型。大量客户端沿用了这套思路,因此今天仍会看到 proxies、proxy-groups、rules 等熟悉字段。项目历史解释了配置为什么长这样,但安装选择不能只看“Clash”三个字,还要继续确认客户端是否维护、内核来自哪个分支、目标系统是否匹配。
图形客户端提供订阅管理、系统代理开关、策略组选择、连接记录和设置界面;真正解析配置、处理连接与执行规则的是内核。两个客户端即使界面完全不同,只要使用相近内核和兼容配置,底层分流逻辑仍可能高度一致。反过来,界面里出现同名选项,也不代表内核能力、配置兼容范围和更新节奏完全相同。
mihomo 是当前 Clash 生态里常见的活跃内核,延续 Clash.Meta 路线,并继续扩展协议、规则、DNS 与透明代理能力。桌面用户通常通过集成 mihomo 的 GUI 客户端使用这些功能;服务器、路由器和自动化环境则可能直接运行内核。选型时先判断是否需要图形界面,再判断协议和配置功能,别把内核压缩包当成桌面安装程序。
客户端更新修复界面与系统集成,内核更新影响协议、规则和 DNS 行为,订阅更新则改变节点与远程配置。三者不是同一个动作。遇到故障时先记录最近变动发生在哪一层:刚换客户端、刚升级内核,还是刚刷新订阅。这样才能决定回退程序、切换内核还是恢复 Profile,避免把所有问题都归结为节点失效。
先按现象分层,不要一上来重装。客户端界面、订阅配置、系统代理、DNS 和节点链路分别检查,通常能更快锁定故障位置。
先看 Profile 更新提示和返回内容,再确认当前激活的是刚导入的配置。订阅地址失效、格式不兼容、远程内容为空,以及更新后没有切换 Profile,表现都可能是列表空白。不要只重复点击更新,先读错误信息。
查看安装配置问答 →依次检查配置是否成功载入、系统代理或 TUN 是否启用、策略组是否选中可用项、连接记录是否命中 REJECT。若所有请求都失败,再切到 DIRECT 做基线测试,用结果判断问题在代理链路还是本机网络。
查看故障排查 →日常使用优先规则模式,由配置决定 DIRECT、PROXY 与 REJECT。全局模式适合临时验证代理链路,不适合作为长期排查结论;直连模式则可验证本地网络。模式切换是诊断工具,不是越强越好的等级选择。
查看入门操作 →客户端延迟测试通常只反映到测试地址的一次握手路径,不代表持续带宽、丢包、拥塞与目标站点路由。节点选择还要结合地区、倍率、协议和实际业务测试,单个毫秒数字只适合初筛。
查看延迟原理 →不堆“万能参数”。文章按一个具体问题展开,把配置结构、判断顺序和容易误读的概念讲透。下面三篇覆盖订阅格式、节点选择与延迟测试,正好对应日常使用中最常见的三类误判。
对比 Clash YAML、base64 分享内容与通用订阅结构,说明转换时可能丢失的策略组、规则与扩展字段,以及迁移客户端前应检查的兼容项。
继续阅读 →延迟只做初筛,倍率决定流量成本,地区影响内容与路由,协议关系到稳定性和设备负担。文章给出一套比盯着最低数字更可靠的选择顺序。
继续阅读 →拆解客户端延迟测试的真实测法,区分握手往返、持续吞吐、丢包与目标站点路由。数字看起来漂亮,不等于高负载场景下体验稳定。
继续阅读 →