Windows
适合需要图形界面、系统代理开关和配置管理的桌面用户。下载前先确认处理器架构与安装包格式，首次启动后再导入订阅并启用系统代理。
前往下载
PLATFORMS / WINDOWS · MACOS · ANDROID · IOS · LINUX
CORE / MIHOMO · CLASH
CONFIG / YAML · RULE PROVIDERS
LICENSE / OPEN SOURCE
核心能力
先理解流量如何被判断与转发
Clash 的使用重点不是反复切换按钮，而是把订阅、策略组、规则和系统接管方式组织成一条可解释的处理链。下面的资料入口先给出概览，后续长幅章节再展开具体结构。
匹配顺序
规则从上到下逐条判断
域名、目标 IP、进程与地理数据可以分别成为匹配条件。请求命中第一条适用规则后便交给对应策略组，因此具体规则应放在范围较大的规则之前，最后再由 MATCH 处理未命中的流量。理解顺序关系后，国内直连、特定服务代理和局域网绕过就能写成清晰、可维护的配置。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy
配置来源
远程内容与本地修改分开管理
订阅更新通常会替换远程配置生成的内容，直接改动原始订阅文件容易在下一次刷新时丢失。更稳妥的做法是保留订阅作为上游来源，把本地规则、DNS 设置和策略调整放入覆写或合并层。更新前记录当前可用配置，更新后检查策略组名称是否变化，再决定是否应用。
出口选择
规则指向策略，而不是固定节点
策略组是规则与具体代理节点之间的中间层。规则只需要写明流量类别应交给哪个组，组内再按手动选择、自动测试或故障切换等方式决定出口。这样可以在不改规则的情况下替换节点，也能让视频、开发服务和普通网页分别使用不同的选择逻辑。
流量入口
系统代理与 TUN 处理范围不同
系统代理主要覆盖遵循操作系统代理设置的应用，配置简单，适合浏览器和多数桌面软件。TUN 模式通过虚拟网络设备接管更广泛的连接，对命令行工具、部分游戏和不读取系统代理的程序更有效。两种方式不必同时启用，先从系统代理开始，遇到覆盖范围问题再检查 TUN 权限与路由。
规则引擎
从具体条件到最终兜底
规则模式会读取配置中的规则列表，并按照书写顺序依次检查当前连接。以域名后缀为例，DOMAIN-SUFFIX 适合覆盖某个站点及其子域名；需要精确匹配单一域名时，可以使用 DOMAIN；目标已经表现为 IP 地址时，则可结合 IP-CIDR 或 GEOIP 判断。规则本身不负责连接，它只把请求交给 DIRECT、REJECT 或某个策略组。
编排规则时，应先写局域网地址、专用服务和明确域名，再放地理范围较大的判断，最后保留 MATCH。若把宽泛规则写在前面，后续细分条件便没有机会生效。排查时可以打开客户端日志，观察请求命中了哪条规则及哪个策略组，而不是只根据网页能否打开来猜测配置状态。
config.yaml / rules
顺序匹配
rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- DOMAIN-SUFFIX,example.cn,DIRECT
- DOMAIN-SUFFIX,example.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy策略名称需要与 proxy-groups 中的名称完全一致。修改后先执行配置检查，再让客户端重新加载。
订阅更新
保留上游配置，隔离本地覆写
订阅链接通常由服务提供方维护，其中可能同时包含代理节点、策略组和基础规则。更新操作的本质是重新拉取上游内容，因此不适合把长期自定义内容直接写进会被替换的文件。支持覆写或合并功能的客户端，可以在订阅之外保存本地设置；命令行环境则可通过独立文件和自动化脚本完成同样的分层。
执行更新前，先确认当前配置能够正常加载，并记住正在使用的策略组。更新完成后依次检查配置解析结果、策略组名称、规则提供器状态和 DNS 相关字段。如果上游调整了组名，本地规则仍指向旧名称，配置可能通过语法检查却无法按预期分流。把更新和切换拆成两个动作，更容易定位问题。
配置结构
把 YAML 拆成可检查的层次
一份常见 Clash 配置大致由通用端口、运行模式、DNS、代理节点、策略组和规则构成。读取配置时不必从第一行一直看到末尾，可以先确认 mode、mixed-port 与 DNS，再检查 proxies 是否被策略组引用，最后检查规则目标是否存在。按引用关系检查，比逐字寻找缩进问题更有效。
YAML 对空格层级敏感，列表项、对象字段和字符串需要保持清晰结构。策略名称包含特殊字符时应使用引号，端口应写为数字，布尔值应使用配置所接受的形式。复杂配置适合拆分为 rule-providers 和 proxy-providers，主文件只保留引用关系，后续更新规则集时不必重写整份配置。
查看配置文件参考大全 →
客户端下载
按设备选择合适入口
不同系统的安装方式、权限模型和后台限制并不相同。这里先按设备定位下载页，具体客户端差异、系统要求和安装包类型放在对应平台标签中说明。
macOS
适合 Intel 与 Apple Silicon 设备。安装时需要按系统提示完成应用权限确认；如使用 TUN，还应检查网络扩展或虚拟网络设备相关授权。
前往下载Android
Android 客户端通过系统 VpnService 接管连接。首次启用会出现系统授权提示；若后台容易中断，应把客户端加入省电白名单并允许后台运行。
前往下载iOS
iPhone 与 iPad 通过系统网络扩展运行代理工具。下载页提供 App Store 入口，并说明订阅导入、网络权限确认和按需连接等基本步骤。
前往下载Linux
桌面环境可使用图形客户端，服务器和路由器环境更适合直接运行 Mihomo 内核。部署前应确认架构、文件权限、服务管理方式与 TUN 能力。
前往下载
快速上手
从安装到连通，按三步主线完成
初次使用不需要立刻修改复杂规则。先让客户端加载一份有效配置并完成系统接管，再根据实际访问结果决定是否调整 DNS、TUN 或自定义分流。
-
01
安装客户端并导入订阅
前往下载页选择与操作系统和处理器架构对应的客户端。安装完成后打开订阅管理，粘贴由服务提供方给出的订阅地址，执行下载或更新。配置加载成功时，客户端通常会显示可选策略组；若立即提示解析失败，应先检查链接是否完整、网络是否可访问以及配置内容是否符合 YAML 结构。
-
02
选择规则模式与可用策略
日常使用优先选择规则模式，让配置根据域名和 IP 条件分别决定直连或代理。进入代理或策略页面，为主要策略组选择一个可用出口。此时不建议同时修改大量规则，因为连接失败既可能来自节点，也可能来自系统代理、DNS 或权限；保持变量较少，排查会更直接。
-
03
启用系统代理并验证路径
桌面端先开启系统代理，移动端按提示授予系统网络连接权限，然后访问几个不同类型的网站验证结果。若浏览器可用但命令行工具没有经过代理，说明该程序可能没有读取系统代理设置，可手动配置环境变量，或在确认权限后改用 TUN。验证完成后再设置开机自启与自动更新。
开源生态
从 Clash 内核到持续维护的实现
Clash 最初建立了基于 YAML 配置、策略组和规则列表的使用方式，随后形成了多个面向桌面、移动端和命令行环境的客户端项目。不同项目可能共享相近的配置概念，但图形界面、内核选择、更新节奏和系统集成方式并不完全相同。选择客户端时，应同时看目标平台、维护状态和所需能力，而不是只比较界面外观。
Mihomo 延续并扩展了 Clash 内核生态，常见图形客户端会把内核能力包装为订阅管理、策略切换、系统代理、TUN、日志和覆写配置等操作入口。内核负责解析配置与处理流量，图形客户端负责系统集成和交互，两者属于不同层次。遇到问题时，先判断是配置解析、内核运行，还是客户端权限与操作系统网络设置，通常能更快缩小范围。
开源仓库能够直接查看提交记录、发布说明、问题讨论和配置文档。阅读资料时应注意项目名称与维护分支，旧教程中的字段可能已经调整，某些客户端也可能更换内核实现。本站按主题整理稳定概念与操作路径，具体安装包和平台差异集中放在下载页，较长的字段说明则放在配置参考页。
更新机制同样需要分层理解：客户端更新解决界面与系统兼容问题，内核更新带来协议、规则和网络栈能力变化，订阅更新则替换节点或服务方配置。这三类更新彼此独立。修改前保留一份能够正常加载的配置，更新后依次检查配置、策略组和系统接管状态，能够减少多个变化同时发生带来的排查困难。
常见问题精选
先判断问题发生在哪一层
安装、配置、系统接管与目标网站状态会互相影响。按层次确认，比连续更换节点或反复重装客户端更容易找到原因。
导入订阅后看不到策略组怎么办？
先确认订阅更新是否成功，再查看客户端日志中的配置解析结果。若 YAML 无法加载，策略组不会出现；若配置正常但组为空，则需要检查代理提供器是否拉取成功。完整排查步骤可在疑难解答页按“安装配置”分类查看。
查看安装配置问题 →规则模式、全局模式和直连如何选择？
规则模式按配置逐条判断，适合日常使用；全局模式把连接统一交给指定策略，适合临时测试出口；直连模式绕过代理，可用于判断故障是否与代理链路有关。切换后应重新发起连接，已有连接未必立即改变路径。
查看基础认知问题 →浏览器可用，其他程序为什么没有经过代理？
部分程序不读取系统代理，或使用独立网络栈。可以先查看程序自身是否支持 HTTP、HTTPS 或 SOCKS 代理；需要接管更多流量时，再检查 TUN 模式的权限、路由与 DNS 设置。不要在原因未明时同时开启多套代理工具。
查看故障排查问题 →订阅更新后自定义规则消失了怎么办？
远程订阅更新可能替换原始配置，因此长期规则应放在客户端的覆写、合并配置或独立规则提供器中。恢复前先对比当前配置与备份，确认策略组名称仍然存在，再逐段加入本地修改，避免旧引用导致加载失败。
查看使用技巧问题 →
近期文章
平台配置与规则实践
从具体设备、代理模式和分流场景切入，补充教程主线之外的操作细节。