CLIENTS / 平台选择
先确认操作系统与处理器架构，再选客户端。图形界面负责配置管理，内核负责连接处理；相同的配置字段，不代表所有客户端都有相同的设置入口。
从 Clash Plus 开始选择，也可对照 Clash Verge Rev、FlClash 与 Clash Nyanpasu 的界面和服务模式。安装前在系统设置中查看处理器类型，不要只根据文件图标判断安装包是否适用。
首次连接先使用系统代理，确认浏览器请求进入连接记录后，再按需要启用 TUN。旧客户端迁移时，应先退出原程序并关闭原有代理设置，避免端口占用或两个服务同时修改路由。Clash for Windows 已停止维护，归档入口用于旧环境对照。
前往下载 Windows 客户端按 Apple Silicon 与 Intel 区分安装包。Clash Plus、Clash Verge Rev 和 FlClash 提供不同的配置管理方式；是否需要后台服务，应结合系统代理、TUN 权限及开机启动需求判断。
将客户端放入应用程序目录后，再完成首次启动与系统授权。连接异常时，先检查当前网络服务中的代理地址与端口是否对应正在运行的客户端。更换无线网络后也要复查，不能仅凭菜单栏图标判断流量已接管。ClashX Meta 的归档状态在下载页单独标明。
前往下载 macOS 客户端可比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard。安装包架构要与设备匹配；订阅格式也要先确认，不能因为同属代理客户端，就直接把其他格式的配置当作 Clash YAML 导入。
首次启动连接时，系统会请求建立 VPN 连接的授权。连接后若出现切后台即断开的情况，检查电池优化与后台运行限制，再观察客户端日志。已有其他 VPN 应用运行时，先确认接管关系；反复切换两个应用，容易让测试结果失去可比性。
前往下载 Android 客户端下载页提供 Clash Plus 的 App Store 入口，并列出官网 clashplus.io。安装前阅读商店详情中的系统要求，导入前确认订阅提供的配置类型与客户端支持范围一致。
添加配置后，按系统提示允许创建 VPN 配置，再回到客户端选择当前订阅与出站。无线网络和蜂窝网络应分别验证：若其中一种网络异常，记录网络环境、解析结果与连接日志，再决定是否调整 DNS。系统出现 VPN 标识，只能说明隧道已启用，不能替代规则命中与目标访问检查。
前往下载 iOS 客户端桌面用户可选择 Clash Verge Rev 或 FlClash，按发行版的软件包格式安装。服务器与路由器用户可转到下载页的 mihomo 内核区，先确认处理器架构、运行权限和配置目录，再安排服务启动。
桌面环境的系统代理不一定覆盖命令行工具。终端程序需要检查自身代理参数或环境变量，TUN 则需要检查权限和路由。部署为系统服务时，配置路径应明确写出，同时保留可读取的日志；不要假设服务进程与当前终端使用相同的工作目录和用户权限。
前往下载 Linux 客户端CONFIGURATION / 配置能力
按问题选择设置，而不是同时打开所有开关。以下片段展示字段关系，不包含可用代理服务器；实际配置需要补充自己的订阅或出站信息。
mode: rule
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTmode: global
GLOBAL
→ 所选出站mode: direct
DIRECT
→ 目标地址规则模式按列表顺序匹配域名、地址或规则集，命中后交给指定出站；末尾的 MATCH 接住剩余连接。需要临时对照代理链路时，可切换全局模式，并确认 GLOBAL 中实际选择的出站。直连模式用于比较本地网络，不等同于关闭客户端。与只提供统一代理地址的工具相比，Clash 的分流依据可在配置中检查。排查时先看命中项，再改规则顺序，避免把出站故障误判为规则失效。
TUN 通过虚拟网络接口接收流量，适合不读取系统代理的应用。启用前应先验证订阅和出站可用，再确认客户端具备所需的服务或管理员权限。与系统代理相比，TUN 的接管范围更广，也更依赖路由、DNS 与防火墙设置。示例使用自动路由和 DNS 劫持，但不代表每个平台都采用相同实现。若启用后局域网访问异常，先检查路由冲突与排除规则，不要重复开启多个接管服务。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53订阅用于更新服务器信息或完整配置，导入后还要选中并启用，不能把下载成功当作连接完成。完整配置订阅与 proxy-providers 的代理集合并非同一层级，导入入口应与内容类型对应。与直接修改远程文件相比，本地覆写适合保留端口和自定义规则，减少下次更新覆盖设置的风险。更新失败时记录请求错误与配置解析错误，分别检查网络路径和 YAML 语法；不要公开带有访问凭据的订阅链接。
proxy-providers:
remote:
type: http
url: "https://example.org/proxies.yaml"
path: ./providers/remote.yaml
interval: 3600
proxy-groups:
- name: PROXY
type: select
use:
- remoteexample.org 仅用于说明字段位置，不能作为实际订阅源。
DNS 决定域名如何解析，规则决定连接交给哪个出站，两者需要配合。fake-ip 使用保留地址建立域名映射，方便内核关联后续连接；nameserver-policy 则可为指定域名选择解析器。与单纯修改系统 DNS 相比，内核 DNS 能结合接管路径处理解析请求，但应用自带的加密解析仍需单独检查。修改后应重新建立连接并观察解析日志，必要时清理缓存。解析成功不代表代理出站成功，应分开验证。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.alidns.com/dns-query
nameserver-policy:
"+.example.org":
- https://dns.alidns.com/dns-queryClash 生态保留了相近的 YAML 结构，但不同内核支持的协议和字段并不完全相同。mihomo 延续了 Clash 风格配置，并扩展了部分协议与规则能力；旧内核遇到新字段时可能拒绝加载，也可能无法按预期执行。与只比较客户端外观不同，迁移应同时核对内核名称、配置语法和功能支持。若客户端提供内核选择入口，应先备份配置再切换。示例仅使用基础字段，迁移后仍需逐项验证 DNS、出站组与最终规则。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- GEOIP,CN,DIRECT
- MATCH,DIRECT同一套出站组和规则可以作为多设备配置的基础，但系统权限、文件路径与流量接管方式需要分别处理。桌面系统常从系统代理开始，移动设备通常通过系统 VPN 接口连接，服务器则更适合明确的服务配置。与整份文件直接复制相比，把通用规则和设备专属设置分开维护，更容易保留端口与接管差异。迁移后先检查出站组引用是否存在，再验证解析和连接；桌面可用的绝对路径不能直接搬到手机。
# 各设备分别确认本地端口
mixed-port: 7890
allow-lan: false
# 可共同维护的规则结构
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY先让请求进入客户端，再确认域名解析、规则命中与出站选择。配置画布中的 PROXY 是组名，不是随安装包提供的代理服务。
QUICKSTART / 三步检查
首次配置先建立一条可验证的连接路径。每完成一步再进入下一步，出错时就能知道问题位于导入、接管还是出站环节。
在客户端的订阅或配置页面添加链接，也可导入本地 YAML。保存后检查解析结果，确认出现预期的出站组，再将该配置设为当前使用项。只有订阅条目出现在列表中，并不表示内核已经加载它。
如果导入失败，先看错误属于网络请求还是配置语法。网页形式的说明地址不能当作订阅内容；字段缩进错误则需要回到文件中修正。首次使用保留原始配置副本，自定义内容优先通过客户端支持的覆写功能添加，便于之后区分远程更新与本地修改。
日常使用从规则模式开始，在实际使用的选择组中指定出站。桌面端先开启系统代理，并核对监听端口；移动端按系统提示允许建立 VPN 连接。需要覆盖不遵循系统代理的程序时，再查阅对应平台的 TUN 设置。
全局模式只是改变已进入内核的连接如何选择出站，不能让尚未接管的程序自动进入客户端。切换模式后，应重新发起请求再看日志。若要验证差异，保持目标地址与网络环境不变，每次只调整一个变量，避免把偶发的网络波动当成设置效果。
打开需要测试的目标地址，在连接记录中查找对应域名，确认命中的规则和最终出站。随后再测试一个预期直连的地址，检查规则是否按顺序执行。对应用和浏览器分别测试，可以发现代理设置仅覆盖部分程序的情况。
没有连接记录，优先排查系统代理、应用设置或 TUN 接管；有记录但连接失败，继续检查解析、出站可用性与远端响应。结束使用时先关闭客户端中的接管开关，再退出程序，避免系统仍保留指向本地端口的代理设置。完整操作路径与恢复步骤见教程。
SOURCE / 开源生态
客户端名称、内核名称与订阅服务需要分开理解。判断一个功能是否可用，应以项目文档、实际内核与本地日志为依据，而不是只看软件名称是否带有 Clash。
Clash 最初以基于规则的代理内核形成配置生态，后续出现了面向不同桌面和移动系统的图形客户端。原 Clash 项目及部分早期客户端已停止原有维护，今天的客户端名称相近，却不一定具有相同的维护状态。旧教程中的按钮位置、服务安装方式和协议支持，不能直接套到所有新客户端。
选择时先确认项目是否仍有发布记录，再核对系统要求与配置支持。已经能在旧环境运行的程序，也可能无法识别新订阅字段。迁移前保留配置、组选择与本地规则，迁移后重新验证连接，不要仅以成功启动作为完成标准。
mihomo 是 Clash 生态中持续发展的内核项目，负责解析配置、匹配规则和建立出站连接。图形客户端则组织订阅列表、系统代理开关、服务安装与日志界面。两个客户端使用相同内核时，核心配置能力可能接近，但本地覆写、权限处理和系统集成仍可能不同。
因此，界面中某项开关是否出现，不能直接代表内核是否支持对应字段。遇到说明与界面不一致时，先在客户端信息页确认内核，再查对应文档。下载页展示的是客户端选择，完整文档进一步区分安装流程与内核配置，便于按实际环境查阅。
mihomo 使用 GPL-3.0 许可，代码、问题讨论和发布说明可在项目仓库查阅。许可约束针对该项目本身，不能据此推断所有图形客户端、订阅服务或附加组件都使用相同许可。需要分发或修改软件时，应阅读对应项目的许可文件及依赖说明。
查看源代码与问题记录，适合确认字段行为、平台限制和已知问题。本站不展示未经确认的下载量、用户评分或连接效果统计。开源代码提供可检查的实现依据，但网络表现仍受本地环境、目标服务与所选出站影响，不能用项目热度替代实际测试。
客户端更新、内核更新和订阅更新是三种不同操作。客户端更新可能改变界面与系统服务；内核更新可能改变字段支持和连接行为；订阅更新主要替换服务器、规则或配置内容。出现异常时，先记录是哪一层发生了变化，再决定恢复设置或对照发布说明。
更新前导出本地覆写与自定义规则，并记下端口和接管方式。更新后先检查配置能否加载，再检查代理组引用、DNS 与路由。若只更新订阅后出现问题，应优先比较订阅内容，而不是立即重装客户端。将修改分层记录，能减少重复排查。
安装 Clash 客户端不会自动获得代理服务器。可用出站来自自行部署的服务或已有的订阅，客户端只按配置处理连接。订阅中的地址、访问凭据和账户信息应作为私密资料保存；分享排查信息时，保留错误类型与必要字段，移除可用于访问服务的内容。也不要将完整订阅直接提交到公开仓库。
本页编辑窗口仅演示字段结构，选择组内的 DIRECT 表示直连，不代表已经配置代理线路。遇到陌生术语，可先阅读术语手册中的内核、出站组与网络模式说明，再到横向评测对照客户端差异。需要处理特定平台的权限与服务问题时，使用完整文档按系统查阅。
以下命令克隆项目仓库，适合阅读源码与文档；普通安装用户直接选择客户端即可。构建源码还需要项目文档指定的工具链与环境。
git clone https://github.com/MetaCubeX/mihomo.gitNOTES / 最近文章
从具体环境出发记录操作路径。排查文章按连接链路展开，先确认问题发生在哪一层，再调整配置；修改前后的测试应使用相同网络与目标地址。
从安装包选择、导入订阅到开启系统代理与 TUN 服务模式，逐步讲清 Windows 上的完整配置流程，并整理端口占用、服务安装失败等常见报错。
阅读安装指南 →先用检测页确认解析请求的真实去向，再通过 fake-ip、nameserver-policy 与 TUN 劫持 DNS 三步收口，附可直接对照修改的 dns 段示例。
阅读 DNS 配置 →按节点质量、中转线路、本机配置三层逐一排除：切换节点对比、观察出站链路、检查 TUN 栈与 DNS 设置，定位网速瓶颈所在环节。
阅读排查步骤 →查阅时先区分“无法连接”与“连接较慢”：前者应优先确认请求是否进入内核，后者需要保持测试条件一致。配置字段的完整解释与各平台恢复路径见配置常见问题。