Clash 配置进阶手册

Chapter 01 / Baseline

配置骨架与调试基线

Clash 配置不是一张彼此独立的设置清单，而是一条有先后关系的处理链。客户端先读取监听端口、运行模式和 DNS 等基础项，再装载代理节点与策略组，随后加载规则和规则集，最后由系统代理或 TUN 把流量送进内核。任何一层引用不存在的名称，都会影响后续行为。最常见的例子是规则指向了已经改名的策略组：配置可能仍能解析，但命中的流量无法按预期选择出口。因此，进阶调整的第一步不是增加更多参数，而是先建立一份能解释、能验证、能回退的基线配置。

先分清客户端设置与内核配置

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等图形客户端通常把设置分成两层。第一层属于应用本身，例如开机启动、系统代理开关、配置更新周期、界面主题和服务安装状态；第二层才是传给 mihomo 内核的 YAML。系统代理按钮通常不会改写订阅文件，它只改变操作系统的代理入口。TUN 开关则可能由客户端生成一段运行时覆写，所以在原始订阅里找不到完全相同的字段。排查时应同时查看当前生效配置与订阅原文，不能只盯着下载下来的 YAML。

一份适合调试的基础段落应保持克制。日志级别先用 info，足以看到连接、规则命中和 DNS 错误；只有需要追踪具体请求时再临时切换到 debug。端口是否需要显式填写取决于客户端的管理方式，桌面客户端可能在启动时注入自己的端口。若手工维护裸配置，可以使用下面的结构，但应确认端口没有被其他代理程序占用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
unified-delay: true

profile:
  store-selected: true
  store-fake-ip: true

mode: rule 表示按规则决定直连、代理或拒绝；unified-delay 让测速口径更接近完整连接过程，但它不会改变真实网络质量；store-selected 用于保存策略组选择，重新启动后不必逐组重选；store-fake-ip 保存 Fake-IP 映射，减少重启后短时间内映射变化带来的连接波动。移动端若由系统回收应用进程，持久化设置尤其重要，但仍要由客户端授予正常的后台运行条件。

用最短链路建立验证闭环

每次改动后先确认配置能被内核载入，再确认代理节点能建立连接，然后看一条测试请求命中了哪条规则，最后才检查目标应用。若日志在配置解析阶段已经报错，继续切换节点没有意义；若节点握手失败，优先处理订阅和网络，不要先改 DNS；若浏览器正常而某个应用失败，再检查该应用是否绕过系统代理、使用了独立 DNS 或 QUIC。这样的顺序可以把问题锁定在单一层级。

配置文件中的缩进只使用空格，不要混入制表符。包含冒号、井号或特殊字符的文本可以加引号，策略组名称一旦被规则引用就应保持稳定。若需要更换客户端，先到下载页选择对应平台；全平台优先考虑 Clash Plus，再根据系统和操作习惯选择其他客户端。迁移时先导入同一订阅验证基础连接，再迁移本地覆写，避免把旧客户端生成的运行时字段直接当作通用配置复制。

Chapter 03 / Rules

规则集订阅化管理

当规则从十几条增长到数百条后，把所有内容继续塞进主配置会迅速失去可维护性。rule-providers 用于把不同主题的规则拆成独立资源，由主配置声明下载地址、格式、更新周期和匹配行为。主文件只保留调用顺序，规则内容由对应规则集维护。这样可以单独更新广告拦截、局域网、开发服务或流媒体规则，也能在某个规则集异常时快速停用，而不必重写完整订阅。

provider 定义与 RULE-SET 调用

规则提供者的名称只是本地引用标识，真正影响解析的是 behavior、format 与资源内容。behavior: domain 适合只包含域名类条目的集合；ipcidr 面向 IP 网段；classical 可以容纳带类型前缀的经典规则。格式要与远端文件一致，常见文本规则可使用 text，YAML 规则使用 yaml。不要把 classic 内容声明成 domain，否则加载成功也不代表匹配语义正确。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domain.yaml
    url: https://example.com/rules/private-domain.yaml
    interval: 86400

  developer:
    type: http
    behavior: classical
    format: text
    path: ./ruleset/developer.list
    url: https://example.com/rules/developer.list
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,开发服务
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,总选择

示例域名只表示字段结构，实际使用时应替换成已确认可访问且内容可信的规则来源。path 是本地缓存位置，不同提供者不要共用同一路径。interval 以秒为单位，公共规则通常没有必要数分钟更新一次；过于频繁只会增加请求和写入。更新失败时，内核一般会继续使用已有缓存，因此排查时要区分“首次下载失败”和“更新失败但旧规则仍在生效”。删除缓存后重试会失去这个回退条件，不应作为第一步操作。

规则顺序就是优先级

Clash 从上到下寻找第一条匹配规则，命中后不再继续。具体规则应放在宽泛规则之前：私有域名和局域网通常先直连，业务域名再进入对应策略，IP 规则放在需要解析地址的位置，最后由 MATCH 接住其余流量。把大范围代理规则放在顶部，后面的直连例外就永远不会执行。排查错误分流时，日志中的“命中哪条规则”比猜测域名属于哪个分类更可靠。

no-resolve 表示匹配 IP 类规则时不要为了得到 IP 主动触发 DNS 解析。它可以避免不必要的解析，但不适合机械地加在所有规则后面。域名请求若前面没有域名规则，而后续又依赖 GEOIP 判断，完全阻止解析可能使这条规则无法获得所需地址。是否添加应根据规则类型和 DNS 模式决定。对于已经直接拿到目标 IP 的连接，IP 规则仍可正常匹配。

本地少量例外可以直接写在 rules 顶部，不必为三五条条目创建远端规则集。例如某个工作域名必须直连，或某个应用接口必须固定到“开发服务”，把这些规则放在订阅规则集之前即可。若例外数量持续增长，再迁移到本地 provider。这样既保持主配置可读，也避免为每次微调发布远端文件。

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - DOMAIN-SUFFIX,github.com,开发服务
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,开发服务
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,总选择

规则集故障的定位顺序

先查看 provider 状态是否完成加载，再确认远端响应内容与声明格式相符，随后检查规则集名称是否与 RULE-SET 引用一致，最后检查调用位置。状态正常但始终不命中，常见原因是行为类型错误、规则被前面的宽泛条目截获，或目标连接只暴露 IP 而规则集只有域名。若更新后突然出现大量错误分流，可以恢复上一份本地缓存或临时注释该规则集，验证问题是否来自上游内容变化。

规则来源越多，更新节奏和命名越难统一。更稳妥的结构是按用途选择少量规则集，每个业务只设一个主要来源，本地例外作为最高优先级。不要同时引入多个覆盖范围近似的全集规则，再期待顺序自动解决冲突。需要同步多设备时，可参考多设备配置同步方案，将主配置、订阅链接和本地规则分开管理。

Chapter 05 / Network stack

TUN 模式与 Fake-IP 协同

系统代理只能覆盖主动遵循代理设置的应用。命令行工具、部分游戏、独立网络栈应用以及直接发起 UDP 的程序，可能完全绕过系统代理。TUN 模式通过虚拟网络接口接管系统路由，把这些流量送入 Clash 内核，因此覆盖范围更完整。Fake-IP 则在 DNS 阶段返回一段映射地址，让内核在收到连接时恢复原始域名并执行域名规则。两者经常一起使用，但承担的是不同职责：TUN 负责把流量带进来，Fake-IP 负责保留域名语义。

TUN 字段与系统权限

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  mtu: 1500

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack 决定 TUN 使用的网络栈实现。mixed 在支持的内核中兼顾兼容性与性能，若特定平台出现异常，可分别测试 system 或 gvisor，但不要在没有对照的情况下频繁切换。auto-route 自动写入路由，auto-detect-interface 尝试识别当前出口网卡；设备在 Wi-Fi、移动网络和有线网络之间切换时，这一项能减少手工指定接口的维护。strict-route 会更严格地防止流量绕过，但可能暴露与其他 VPN、虚拟机和容器网络的路由冲突。

TUN 启动需要系统级 VPN 或网络扩展权限。Windows 客户端可能通过服务模式提升网络操作权限；macOS 需要允许网络扩展；Android 与 iOS 会显示系统 VPN 授权。权限被拒绝时，界面开关可能短暂开启后恢复，日志中也会出现设备创建或路由写入错误。此时反复导入订阅没有作用，应先处理系统授权。macOS 的具体弹窗与恢复步骤可参考网络扩展与钥匙串处理指南。

Fake-IP 的映射过程

Fake-IP 模式收到域名查询后，不立即把真实地址直接交给应用，而是从保留地址段分配一个映射值。应用连接该地址时，内核根据映射表还原域名，然后匹配 DOMAIN、DOMAIN-SUFFIX 或规则集。它的优势是即使应用只把目标地址交给网络层，Clash 仍能掌握原域名。映射地址不是远端服务器地址，也不应拿去做公网路由测试。看到 198.18.0.0/16 范围的结果通常表示 Fake-IP 正常参与了解析。

某些局域网发现、时间同步、打印设备、游戏平台或依赖真实 DNS 回答的程序不适合 Fake-IP，需要加入 fake-ip-filter。过滤范围应尽量具体。直接排除过大的域名集合会让大量请求回到真实地址模式，削弱域名还原效果，也可能使规则依赖 IP 匹配。出现兼容问题时先从日志确定域名，再增加单条后缀并复测，不要复制一份来源不明的超长过滤表。

MTU、UDP 与网络切换

页面能打开但部分图片、上传或特定应用卡住时，可能是路径 MTU 不合适。TUN 封装会增加额外开销，底层网络若已存在 VPN、PPPoE 或移动网络限制，1500 字节可能导致分片或丢包。可以在保留其他配置不变的前提下逐步降低 MTU，例如先测试 1400 左右的范围，并观察问题是否稳定消失。MTU 不是越小越安全，过小会增加包数量和处理开销，确认有效后应选择能够稳定工作的较大值。

UDP 问题要区分三个层面：应用是否发出 UDP、TUN 是否接管、节点协议和网络是否支持对应传输。DNS 查询、QUIC、游戏和语音都可能使用 UDP。关闭 QUIC 后浏览器恢复，只能说明故障集中在 UDP 路径，不代表 DNS 或节点整体不可用。移动设备在 Wi-Fi 与蜂窝网络切换后，旧会话可能仍绑定原接口，必要时重新连接 TUN，而不是立即清除全部配置。

启用顺序建议是：先用系统代理确认节点和规则可用，再单独开启 TUN，确认路由和权限正常，最后启用 Fake-IP 并处理少量兼容例外。若 TUN 开启后整机断网，先关闭它恢复网络，再检查默认路由、DNS 劫持和其他 VPN。Windows 的服务模式、端口冲突与系统代理步骤可查看Windows 安装配置全流程。

Chapter 07 / Merge

本地覆写与多订阅合并

订阅负责提供远端维护的节点和基础配置，本地覆写负责保存设备或个人环境特有的调整。把两者直接改在同一文件里，下一次订阅更新很可能覆盖本地内容；完全复制成静态配置又会失去节点更新。更合理的结构是把订阅视为上游输入，把端口、DNS、策略组补充、规则前置和 TUN 设置放进可重复应用的覆写层。客户端支持的覆写机制名称不同，可能叫 Merge、Mixin、Script 或全局扩展，但目标都是在更新后重新生成生效配置。

区分替换、追加与深度合并

YAML 对象可以按键合并，数组却存在不同语义。修改 dns.enable 通常只替换单个字段；处理 rules 时则要明确是前置规则、后置规则还是替换全部数组。若合并器把新数组直接覆盖旧数组，一段只含三条本地规则的覆写可能让订阅原有规则全部消失。使用客户端内置合并前，应查看最终生效配置，而不是只看覆写片段是否保存成功。

prepend-rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT

append-rules:
  - MATCH,总选择

override:
  mode: rule
  log-level: info
  ipv6: false

上面的结构用于说明“前置、后置、替换”三种意图，具体键名取决于客户端的合并实现，不能未经确认直接当作 mihomo 原生配置载入。mihomo 最终接收的仍是一份完整配置。验证方法是打开客户端生成的运行时配置，确认本地规则位于预期位置、策略组没有重复、最终只保留一个 MATCH。若客户端提供配置检查功能，应在每次更新后执行一次。

多订阅合并以节点层为主

同时使用多个订阅时，最稳定的方式通常是把它们声明为不同的 proxy-providers，由本地策略组通过 use 引入，而不是把多个完整配置文件直接拼接。完整配置往往都带有自己的端口、DNS、策略组和规则，同名键会覆盖，同名组会冲突，最后结果取决于合并工具的实现。节点提供者只负责节点集合，本地主配置负责统一策略和规则，职责更清楚。

proxy-providers:
  primary:
    type: http
    url: https://example.com/subscription/primary
    path: ./providers/primary.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  backup:
    type: http
    url: https://example.com/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 总选择
    type: select
    use:
      - primary
      - backup
    proxies:
      - DIRECT

示例中的订阅地址是结构示意，使用时应换成自己的有效地址，并避免把带访问凭据的链接公开到文档、截图或共享仓库。两个 provider 必须使用不同的缓存路径。健康检查间隔可以根据设备与节点数量调整，移动端不宜高频轮询大量节点。若上游节点名称重复，界面可能难以区分来源，可以在合并层使用客户端支持的前缀能力，或让不同 provider 进入独立地区组，而不是直接混在一个长列表中。

更新失败与配置漂移

多订阅环境常见的问题不是某次配置无法载入，而是运行一段时间后逐渐偏离预期。上游可能修改节点命名，导致筛选表达式失效；删除某个地区后，策略组变成空组；新增同名节点后，手动选择指向了另一来源。更新后应检查 provider 状态、策略组成员数量是否合理、关键业务规则是否仍指向存在的组。不要用虚构的固定节点数量作为监控条件，应关注“组是否为空”“引用是否存在”和“关键请求是否命中”。

跨设备同步时，不建议直接同步客户端整个数据目录。桌面端和移动端的权限、路径、TUN 接口名以及缓存位置都不同。更适合同步的是订阅入口、本地主配置模板、规则集和覆写逻辑，设备专属项留在各自客户端。WebDAV、订阅分发与手动导入的差异可继续阅读Clash 多设备配置同步方案。