Clash 核心配置

先理解流量如何进入内核，再决定规则把它送往哪里。客户端负责操作入口，内核负责执行配置；界面相似，不代表每个配置字段都能通用。

规则分流：按目标选择出口

规则模式适合日常使用：内核按配置顺序检查域名、地址与规则集，命中后交给指定出口。具体域名放前面，兜底放最后，避免宽泛条件提前截住请求。排查时打开连接记录，看实际命中的规则，不要只看浏览器能否打开页面。下面片段只演示直连规则，不包含代理服务；需要代理出口时，应在完整配置中先定义对应节点或策略组，再用规则引用它。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

策略组切换：手动选择与自动测试

策略组把多个出口组织成一个可被规则引用的目标。手动选择用 select，按测试结果选择用 url-test，需要故障切换则考虑 fallback。自动测试衡量的是指定地址的响应表现，不等于下载带宽；测试地址、超时与网络环境都会影响结果。下面把直连作为演示成员，并定义供规则引用的“自动选择”组；实际使用要换成完整配置里存在的节点名，不能只复制组名就期待产生代理连接。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
rules:
  - MATCH,自动选择

TUN 全局接管：补足系统代理范围

有些程序不读取系统代理，单开系统代理无法接住它们的连接。TUN 通过虚拟网卡与路由接管补足这部分范围，通常需要管理员权限或客户端服务支持。它改变的是流量进入内核的方式，不会自动把规则模式改为全局代理。先确认普通连接可用，再启用 TUN，逐项检查路由、DNS 与其他虚拟网卡的冲突。下面是 mihomo 配置片段，具体协议栈与权限仍需按客户端和系统调整。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

订阅管理：区分完整配置与节点集合

完整配置订阅通常带有节点、策略组和规则，导入后仍需选中对应配置才能生效。proxy-providers 则用于加载节点集合，不能替代完整配置。更新前保留本地规则与覆写，避免直接编辑的内容被下次订阅覆盖。下面展示本地提供器的结构：路径对应的文件必须实际存在，并按提供器格式包含 proxies 列表；还要在完整配置的策略组里通过 use 引用它。远程订阅地址可能包含访问凭据，不要公开分享。

proxy-providers:
  local-proxies:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 手动选择
    type: select
    use:
      - local-proxies

外部控制面板：查看内核运行状态

控制接口用于查看连接、切换策略组和管理运行状态，适合服务器或独立内核部署。桌面客户端通常已经集成管理界面，不必为了日常使用额外开放接口。监听地址优先限制在本机回环范围，确需远程访问时，再配合认证与受控网络通道。下面只演示本机监听地址；端口不能与混合端口重复。配置控制接口并不等于部署了网页面板，面板文件、访问方式与认证需要另外设置。

external-controller: 127.0.0.1:9090
log-level: info

系统代理、代理模式与端口，分开看

系统代理决定应用是否把请求送到客户端；规则、全局与直连决定内核收到请求后怎样处理；混合端口则是本机接收 HTTP 与 SOCKS 连接的监听入口。这三项解决的问题不同。浏览器没有使用系统代理时，切换策略组可能毫无变化；规则已经指定直连时，换节点也不会改变该请求的出口。排查应从入口向出口逐层确认，而不是同时修改多个开关。

界面中的设置窗口是静态示意。7897 是常见混合端口示例，不是所有客户端的固定值。实际端口以当前客户端设置为准；手动配置浏览器或其他应用代理时，地址通常为本机回环地址，端口必须与客户端一致。改端口之后，要同步检查系统代理和应用内单独保存的代理设置。局域网共享还涉及监听地址与防火墙，普通本机使用不需要先打开共享。

查阅策略组、DNS 与 TUN 进阶配置 →

Clash 客户端下载入口

先匹配操作系统与处理器，再看功能需求。Clash Plus 是本站跨平台选型的首推入口；桌面端也可对照 Clash Verge Rev、FlClash 等客户端。下载页集中列出安装包入口与要求。

Windows

浏览器与常规桌面应用先使用系统代理。需要接管不遵循代理设置的程序，再检查客户端服务与 TUN 权限。可从 Clash Plus 开始，也可比较 Clash Verge Rev、FlClash 与 Clash Nyanpasu 的配置管理方式。

安装前在系统设置中确认架构，不要把桌面安装包与独立内核压缩包混用。旧 Clash for Windows 入口属于停止维护的归档选项；迁移时先备份订阅、规则和脚本，再验证新客户端是否支持原有字段。

前往下载

macOS

先在“关于本机”中确认是 Apple Silicon 还是 Intel，再选对应安装包。Clash Plus、Clash Verge Rev 与 FlClash 可作为比较对象；系统代理适合先验证浏览器连接，TUN 则需要额外确认权限与路由。

运行前阅读系统给出的应用来源提示，按项目发布说明处理，不要为打开一个程序而长期关闭系统保护。若原来使用 ClashX Meta，下载页会标明归档状态；迁移重点是订阅格式、策略组选择与本地覆写，而不是照抄旧界面里的所有开关。

前往下载

Android

移动设备通常通过系统 VPN 接口接管流量，首次连接需要确认授权。选型可先看 Clash Plus，再比较 Clash Meta for Android 与 FlClash。安装包架构要匹配设备，后台运行还会受到系统电池管理策略影响。

手机已有其他 VPN 应用时，先确认当前由哪个应用建立连接，避免把接管冲突误认为节点故障。Surfboard 也是下载页的备选工具，但其配置格式与 Clash YAML 不同；订阅能否直接导入应看提供方格式，不能仅凭链接结尾判断兼容性。

前往下载

iOS

首推 Clash Plus，下载页提供 App Store 入口与官网 clashplus.io。安装后导入已有订阅，再按应用提示确认 VPN 配置授权。系统内的 VPN 状态只说明接管已建立，不代表订阅中的每个出口都可连接。

移动端的权限模型与桌面端不同，不必照搬桌面混合端口和系统代理操作。验证时先用一个明确的目标页面，再检查应用的连接记录与策略选择。订阅更新失败和连接失败应分别处理，前者优先核对链接与服务状态，后者再看规则与出口。

前往下载

Linux

桌面用户可从 Clash Verge Rev 与 FlClash 选择，按发行版与包格式安装。不同桌面环境对系统代理的支持存在差异，终端程序也未必读取桌面代理设置；需要分别确认环境变量、应用代理或 TUN 的接管范围。

服务器与路由器用户再考虑独立 mihomo 内核。内核部署需要自行管理配置路径、服务启动、权限与日志，没有桌面界面代为处理这些环节。先在前台验证配置能够加载，再接入服务管理器，故障时保留启动日志比反复重装更有帮助。

前往下载

选型优先级：维护状态、格式、权限

客户端名字里带有 Clash，不代表来自同一个开发者，也不代表功能完全一致。先确认项目是否仍有维护，再确认内核与订阅格式，最后看自己是否需要覆写、规则集或 TUN。只为浏览器配置代理时，能稳定管理订阅与系统代理的客户端通常已经足够，不必把高级功能全部开启。

本站是客户端选型与配置资料入口，不是所有客户端的开发方。安装包说明、商店要求与项目发布记录应结合查看。遇到订阅兼容性问题，先识别是完整配置还是节点集合；遇到程序接管问题，先区分系统代理与虚拟网卡。把问题分类后，再去对比客户端，选择会更明确。

查看客户端对比与官方来源说明 →

查看全部客户端 →

Clash 快速上手

安装并不等于连接已经准备好。先完成配置导入，再确认接管方式，最后用连接记录验证结果。首次设置尽量保持默认参数，一次只改变一个环节。

01 / 配置来源

导入订阅，选中配置

打开客户端的订阅或配置页面，粘贴已有订阅链接，保存并等待下载完成。出现配置条目后，将它设为当前配置，再查看策略组是否正常加载。链接需要来自可信提供方，客户端本身不会凭空生成可用代理服务。

若收到的是本地 YAML 文件，使用文件导入入口。下载失败时先核对链接是否完整、是否失效、返回内容是否为配置；不要把登录网页或错误页面当作配置文件。导入前可保留原文件，方便恢复。

02 / 流量入口

选择规则，开启接管

先选规则模式，在需要手动选择的策略组中指定一个可用出口。桌面端开启系统代理，移动端按提示确认 VPN 授权。没有特殊需求时，先保持局域网共享关闭，避免增加额外的监听与访问范围。

某个程序没有进入连接列表时，再考虑它是否忽略系统代理。确有需要才启用 TUN，并确认管理员权限、客户端服务与 DNS 设置。全局模式适合临时对照排查，不应被当作修复所有问题的默认办法。

03 / 连接验证

查看连接，逐项排查

打开目标页面，同时查看客户端连接记录，确认请求进入内核、命中预期规则并使用正确出口。延迟测试只提供特定测试地址的响应参考，不能代替实际页面、下载或会议应用的体验验证。

失败时记录时间、目标与日志信息，按订阅加载、代理入口、DNS、规则、出口的顺序检查。退出客户端前关闭系统代理；否则应用仍可能连接已经停止监听的本机端口，表现为关闭软件后也无法访问网络。

查看完整教程 →

Clash 开源生态与配置来源

判断客户端是否适合长期使用，靠公开代码、维护记录与可解释的配置行为。这里区分项目历史、内核实现、图形客户端与订阅服务，避免把它们混成一个产品。

项目历史：旧名称与新维护分支

Clash 生态围绕规则代理发展，形成了多个内核分支和图形客户端。原 Clash 项目与部分早期客户端停止维护后，仍在维护的分支继续发展协议支持、DNS 与路由能力。mihomo 延续了 Clash.Meta 的技术路线，因此资料里可能同时出现 Clash、Clash Meta 与 mihomo 等名称。阅读教程时应先确认它描述的内核，再判断字段是否适用于当前客户端。

旧教程的截图可以帮助理解操作位置，但不能作为当前功能支持的依据。客户端菜单、服务安装方式和默认端口可能已经变化。尤其是从停止维护的软件迁移时，要把订阅原件、本地规则、脚本与设置分别备份；先在新客户端完成最小连接验证，再逐步恢复高级功能，避免一次搬入全部旧配置后无法定位差异。

内核关系：执行能力与界面入口

mihomo 内核负责解析配置、匹配规则、处理 DNS 和建立连接；图形客户端则负责安装、订阅管理、系统代理与操作界面。客户端是否提供某个开关，与内核是否支持某个字段不是同一回事。桌面软件还可能通过服务进程处理高权限功能，移动端则受系统网络扩展或 VPN 接口限制。

因此，同一份 YAML 在不同客户端里可能需要调整。除了内核差异，还要检查客户端是否覆写 DNS、端口和 TUN 设置，以及提供器路径如何解析。排查应查看最终生效的配置，而不是只盯着订阅原文件。准备反馈问题时，说明客户端名称、操作系统、接管方式与相关字段，比仅说“Clash 不能用”更有利于复现。

开源社区：从代码与文档核对行为

mihomo 以 GPL-3.0 许可发布，代码、议题与发布记录可在项目仓库查阅。开源许可说明代码使用与分发的条件，不代表所有第三方客户端都采用相同许可，也不能替代对维护状态的判断。查看一个配置字段时，优先对照当前内核文档；遇到疑似缺陷时，再搜索公开议题中是否已有相同场景。

本站不展示无法核实的下载量、评分或连接表现。选型建议基于平台、配置方式与使用需求，不以虚构统计作背书。仓库里的问题反馈也不应直接当作软件质量排名：设备、配置与网络环境各不相同。复现步骤、日志时间线和最小配置，才是判断问题是否属于内核、界面或服务提供方的有效依据。

查看 mihomo 项目仓库 →

更新机制：软件、订阅与规则集分开维护

软件更新改变客户端或内核；订阅更新改变节点与配置内容；规则集更新改变匹配条件。三者不是同一个按钮，也不一定使用相同周期。升级前保存有效配置和本地覆写，阅读变更说明，再检查 DNS、TUN 与提供器是否仍按预期工作。订阅刷新后策略组选项发生变化，不一定是客户端升级造成的。

订阅地址可能携带账户访问凭据，截图和日志分享前应移除完整链接与敏感字段。给他人排查时，只提供与问题相关的配置片段。不要把完整订阅提交到公开议题，也不要把陌生人的配置直接覆盖现有配置。规则中引用的策略组、提供器文件与脚本需要配套存在，单独复制一小段语法并不能组成可运行方案。

获取 mihomo 源代码

下面命令用于阅读或开发内核，不是安装图形客户端的步骤。日常使用直接前往下载页；需要编译时，再按仓库文档准备工具链与目标架构。

git clone https://github.com/MetaCubeX/mihomo.git

常见概念：先查术语，再改设置

规则模式是否只代理部分网站？取决于当前规则，而不是模式名称本身。TUN 是否意味着所有请求都走代理？它接管流量，出口仍由规则与策略决定。节点测试有响应是否意味着实际应用可用？测试目标与真实目标不同，仍需检查目标连接。订阅与配置文件是否是一回事？订阅是获取内容的方式，返回内容可能是完整配置，也可能只是节点集合。需要继续辨认这些概念时，使用概念速查，再回到配置页面操作。