Clash 高级用法：策略、规则与流量接管

配置阅读方法与变更顺序

先分清配置的五个处理层级

一条连接进入 mihomo 后，并不是直接落到某个节点。内核先取得目标地址；如果应用只提交 IP，域名嗅探可能补回域名；DNS 模块决定解析方式并维护真实地址或 Fake-IP 映射；规则系统按照从上到下的顺序查找第一条匹配项；匹配结果再指向策略组，由策略组选择具体代理、直连或拒绝。TUN 位于更靠近系统网络的一侧，负责把原本不会进入系统代理的流量送进内核。理解这条链路后，排错就能按“有没有接管、有没有域名、有没有解析、规则匹配哪条、策略最终选谁”的顺序进行。

配置文件通常由端口、运行模式、DNS、TUN、代理提供者、策略组、规则提供者和规则组成。字段位置本身不是执行顺序，但 YAML 的层级和缩进决定字段是否属于正确模块。两个空格是常见缩进方式，列表项使用短横线。布尔值写成 true 或 false，不要加引号；端口写整数；包含冒号、井号或特殊字符的普通字符串适合加引号。保存前可利用客户端的配置检查功能，先排除格式错误，再判断网络行为。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

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

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,节点选择

上面的骨架只说明层级关系，不构成完整订阅。mixed-port 同时接受 HTTP 和 SOCKS 连接，适合本机应用统一填写一个端口；mode: rule 表示按规则处理；store-selected 用于记住策略组选择；MATCH 是最终兜底。若客户端已从订阅生成代理和策略组，不要为了套用示例而删除原有部分，只需在覆写区加入需要调整的字段。

建立可回退的变更流程

稳定的配置修改应当保留三个状态：订阅原始配置、当前可用配置、正在测试的修改。订阅原始配置用于确认上游内容；当前可用配置是回退点；测试配置只承担一个明确目标，例如“让开发域名直连”或“用 TUN 接管命令行工具”。客户端支持覆写时，优先把本地改动写进覆写文件，不直接编辑订阅下载结果。订阅刷新通常会替换主配置，直接修改的内容可能随更新消失，而独立覆写更容易审查和迁移。

每次变更后先做低成本验证：配置能否加载、日志是否出现解析错误、系统代理或 TUN 是否成功启动、一个直连目标和一个代理目标能否分别工作。然后再验证规则命中与 DNS。不要只以“网页打开了”作为成功标准，因为浏览器缓存、已有连接和系统 DNS 缓存都可能掩盖问题。测试规则时可换一个新域名或重启目标应用；测试 DNS 时可清理应用连接并观察内核日志中的查询与匹配记录。

日志级别建议日常使用 info。需要追踪规则和 DNS 时短暂切换到 debug，完成后再恢复，避免大量日志影响定位。遇到界面提示与内核日志不一致时，以内核是否载入配置、实际连接是否出现为判断依据。仍无法确认问题时，可前往 FAQ 对照基础故障分类；若是系统代理和 TUN 的选择问题，可继续阅读 TUN 模式与系统代理的工作机制对比。

策略组类型与实际组合

选择、自动测试与故障转移

策略组是规则结果与具体代理之间的中间层。规则最好指向有业务含义的组名，例如“节点选择”“流媒体”“开发服务”，而不是直接指向某个会随订阅变化的节点。这样更新订阅、删除节点或临时换线路时，只需调整策略组，不必修改大量规则。最常用的 select 由用户明确选择成员，行为稳定，适合总入口和需要固定出口的业务。组内既可以放具体代理，也可以引用其他策略组，因此可构成“业务组 → 地区组 → 自动测速组”的层级。

url-test 会按设定地址周期性测试组内代理，选择测试结果较优的成员。它适合日常自动选择，但测试结果只代表到测试地址的连通状况，不保证目标网站一定采用同样路径。fallback 更强调可用性顺序，通常从前往后选择首个可用成员，适合准备主线路和备用线路。load-balance 会把连接分配给多个成员，适用于确实需要分散连接的场景；它可能让同一业务在短时间内出现不同出口，因此登录、支付或依赖会话一致性的服务不应随意使用。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

  - name: 自动选择
    type: url-test
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    tolerance: 80
    lazy: true

  - name: 故障转移
    type: fallback
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    lazy: true

use 引用代理提供者，适合订阅节点动态变化的情况；proxies 则列出固定成员或其他组名。interval 是测试间隔，设置过短会增加网络请求和移动设备耗电，过长则可能延迟发现不可用线路。tolerance 用于减少数值轻微波动造成的频繁切换：新结果只有达到足够差异时才触发选择变化。lazy 启用后，组长期未使用时可减少不必要的主动测试。

按业务建组，不按规则数量建组

策略组名称应描述决策，而不是描述规则来源。一个名为“视频规则集”的组会把规则与策略耦合；改成“流媒体”后，无论匹配来自域名规则还是规则集，出口含义都清晰。基础结构通常只需要总入口、自动选择、故障转移和直连，再按确有差异的业务增加组。组越多，刷新订阅后需要检查的选择越多，也更容易形成循环引用。mihomo 不能从循环策略中得到最终代理，例如 A 引用 B、B 又只引用 A，这种结构应在设计阶段避免。

地区组可以通过代理提供者过滤得到，但过滤依赖节点名称。名称来自订阅上游，可能包含地区中文名、英文缩写或图形符号。只写一个过窄的表达式会漏掉节点，写得过宽又可能误收。配置完成后应在客户端中打开该组，确认成员列表而不是只看语法是否通过。对于首选固定出口的服务，应使用 select 并手动锁定；对于普通浏览，可让总入口默认指向自动选择。

proxy-groups:
  - name: 开发服务
    type: select
    proxies:
      - 节点选择
      - 故障转移
      - DIRECT

  - name: 本地直连
    type: select
    proxies:
      - DIRECT
      - 节点选择

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,development,开发服务
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,节点选择

DIRECT 与 REJECT 也是可作为规则目标的内置策略。直连并不等于绕过内核：在规则模式下，连接仍可能先进入 Clash，再由内核建立直连。若局域网设备访问异常，要同时检查规则是否直连、TUN 是否生成冲突路由，以及操作系统防火墙。拒绝策略适合明确不需要的域名，但规则集过宽时可能导致页面资源缺失，修改后要测试主页面、登录、图片和接口请求，不能只确认首页能打开。

排查策略组时先确认组内是否有成员，再确认当前成员是否能建立连接，最后检查规则是否确实指向该组。若订阅更新后组变空，常见原因是代理提供者加载失败或过滤条件没有匹配新名称。若组能工作但每次重启都恢复默认，检查 profile.store-selected 是否启用，以及客户端是否用临时配置覆盖了持久化目录。客户端选择可在 下载页 按平台比较，图形界面用户优先使用 Clash Plus，再根据系统需求选择 Clash Verge Rev 或 FlClash。

规则集订阅化管理

规则顺序决定最终结果

Clash 规则采用从上到下、首次命中即停止的处理方式。规则数量不是首要问题，优先级才是。通常把范围最明确的自定义规则放在前面，例如单个域名、特定后缀和局域网地址；随后放业务规则集；靠后处理地域 IP、常规直连和最终兜底。若把 MATCH 放在中间，后续规则永远不会执行。若宽泛的域名后缀排在精确规则之前，精确规则也会失去覆盖机会。

DOMAIN 匹配完整域名，适合单一主机；DOMAIN-SUFFIX 匹配域名及其子域，适合一个站点体系；DOMAIN-KEYWORD 范围更宽，容易误匹配，只有在域名结构确实不固定时才使用。IP-CIDR 与 IP-CIDR6 处理地址段。IP 规则可能触发解析，若前面已通过域名完成判断，或规则目标只关心现有目标 IP，可根据场景添加 no-resolve，减少额外查询。

rule-providers 的行为类型

规则提供者把外部规则文件独立于主配置维护。behavior: domain 适合只包含域名类条目的集合；behavior: ipcidr 用于地址段集合；behavior: classical 支持带规则类型和参数的完整条目，表达能力最强。行为类型必须与文件内容一致。把 DOMAIN-SUFFIX,example.com 放进只接受域名载荷的文件，或把纯地址段按 classical 使用，都会产生加载失败或无法命中的结果。

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

  local-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/local-network.yaml

rules:
  - DOMAIN,build.internal.example,DIRECT
  - RULE-SET,development,开发服务
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,节点选择

type: http 表示从 URL 更新，type: file 表示只读取本地文件。path 是缓存或本地文件位置，建议为每个提供者设置独立文件名，避免多个规则源互相覆盖。interval 使用秒作为更新周期。规则内容变化不频繁时，没有必要设置很短的周期；一天更新一次更容易控制请求量。远程地址应使用稳定的 HTTPS 来源，组织内部规则可放在受控服务中，避免依赖临时链接。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,developer.example
  - PROCESS-NAME,git
  - IP-CIDR,192.0.2.0/24,no-resolve

这是 classical YAML 规则文件的常见结构。提供者文件只写匹配条件，不写最终策略；策略在主配置的 RULE-SET,development,开发服务 中指定。这样同一规则集可以在不同设备上指向不同策略，例如桌面端交给“开发服务”，服务器上交给固定出口。若需要更换策略，只改主配置，不必复制和维护第二份规则数据。

订阅化规则的维护边界

规则集不应无限拆分。每个提供者都带来下载、解析、缓存和故障定位成本。适合独立成集的内容通常具有明确责任边界：由不同人员维护、更新频率不同、需要在多个配置间复用，或需要单独启停。只有三四条且长期稳定的本地规则，直接放在主规则顶部更清楚。命名要表达用途，例如 work-services、private-network，不要使用含义不明的 rules1。

更新失败时，先区分“远程下载失败”和“文件解析失败”。前者检查 URL 是否可达、DNS 是否正常、代理提供者是否需要通过代理更新；后者查看行为类型、格式、缩进和载荷结构。已有缓存时，部分客户端可能继续使用旧文件，因此页面暂时仍能访问并不代表更新成功。查看日志中的提供者名称和更新时间，手动更新后确认是否出现新错误。若 GeoIP 或 GeoSite 数据相关规则异常，可继续阅读 GeoIP 和 GeoSite 数据库更新方法。

规则维护完成后，应建立固定测试集：一个明确直连的域名、一个明确代理的域名、一个局域网地址、一个只有 IP 的连接和一个最终兜底目标。每次更新规则源后执行同一组测试，能够快速发现顺序变化、规则源失效和误匹配。测试结果要看命中规则与策略名，不以网页观感代替。这样规则集即使持续增长，仍能保持可解释性。

DNS 配置优化与分流

先明确 mihomo DNS 的职责

启用 mihomo DNS 后，内核可以按规则处理域名查询，并把查询结果与后续连接关联起来。它解决的不是单纯“换一个 DNS 地址”，而是让域名解析与代理决策处于同一条链路。若应用自行使用加密 DNS、直接连接固定地址或读取独立 hosts 文件，查询可能绕过内核；此时仅修改 nameserver 不一定改变应用行为，需要结合 TUN 的 DNS 劫持、浏览器设置和域名嗅探判断。

default-nameserver 主要用于解析其他 DNS 服务器自身的域名，常使用可直接访问的 IP 地址，避免出现“要访问加密 DNS，先要解析它；但当前又没有可用 DNS”的循环。nameserver 处理常规查询。proxy-server-nameserver 可专门解析代理服务器域名，减少代理节点域名解析依赖普通分流。nameserver-policy 按域名指定解析服务器，适合内部域名、局域网域名或确有解析差异的业务。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.example.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "*.lan"
    - "+.internal.example"
    - "time.*"

示例中的地址应根据所在网络替换。listen 只在确实需要让本机其他程序查询时设置；若绑定到所有接口，还要确认系统防火墙和局域网访问边界。桌面客户端通常会自动管理监听地址，不必为了复制配置强行开放。ipv6: false 表示 DNS 模块不返回 IPv6 结果，适合当前网络没有稳定 IPv6 路径的情况；若网络和代理均完整支持 IPv6，可开启后分别验证直连与代理目标。

Fake-IP 与 redir-host 的取舍

fake-ip 模式先给应用返回一个映射地址，应用连接该地址时，内核再恢复原域名并执行域名规则。它让规则匹配更直接，也能减少“先解析到某个 IP，随后只能按地址判断”的信息损失。映射地址只在本机内核内部有意义，不应被当作目标的真实地址。抓包、日志或应用诊断界面看到 198.18.0.0/16 一类地址时，要先确认是否来自 Fake-IP 映射，而不是把它判断为异常 DNS 结果。

部分局域网服务、设备发现、网络连通性检测、时间同步或依赖真实地址的应用不适合 Fake-IP，应加入 fake-ip-filter。过滤后，这些域名返回真实解析结果。过滤范围不宜一开始写得过宽，例如直接排除大量顶级域名会削弱 Fake-IP 的域名关联优势。遇到兼容问题时，先从具体域名开始，查看日志确认后再加入后缀。redir-host 返回真实 IP，兼容思路更接近传统解析，但域名与连接的关联方式不同；只有在明确遇到 Fake-IP 兼容问题且过滤无法解决时再整体切换。

nameserver-policy 与解析路径

内部服务常要求通过路由器或企业 DNS 解析，公开 DNS 并不知道其记录。可用 nameserver-policy 把指定后缀送往内部服务器，同时在规则顶部将对应域名直连。DNS 分流和连接分流必须一致：域名由内部 DNS 得到私有地址，却被规则送到外部代理，通常无法访问；域名由公开 DNS 解析为公网地址，却被期望当作内网服务，也会产生错误。配置时把“由谁解析”和“连接走哪条策略”作为一组审查。

respect-rules 让 DNS 连接遵循规则时，要保证解析代理节点域名的路径不会依赖尚未建立的代理。为此应配置可直接工作的 proxy-server-nameserver，并避免 DNS 规则形成循环。若启动后所有连接都卡在解析阶段，可暂时改用一个可直连的基础 DNS，确认代理服务器域名能解析，再逐步恢复加密 DNS 和按规则分流。

排错时先用日志确认查询是否到达 mihomo。如果完全没有查询记录，检查系统 DNS 是否已指向内核、TUN 的 DNS 劫持是否生效，以及应用是否启用了独立 DNS。若有查询但失败，检查上游服务器能否访问、域名型 DNS 地址能否由 default-nameserver 解析。若解析成功但连接仍失败，继续看规则策略与实际目标，不要停留在 DNS 层。若只有局域网设备名失败，检查搜索域、路由器 DNS 和 Fake-IP 过滤，而不是把所有域名改为直连。

DNS 优化没有单一通用答案。稳定配置通常具备三点：基础解析路径可独立启动；内部域名的解析与连接策略一致；Fake-IP 例外有具体原因和明确范围。完成设置后分别测试普通网页、局域网域名、代理服务器域名和只支持 IPv6 的目标。记录每类目标的预期解析服务器和策略，后续更换网络时就能快速判断是本地网络变化还是配置退化。

TUN 与 Fake-IP协同配置

什么时候需要 TUN

系统代理只对主动读取操作系统代理设置的应用生效。命令行程序、部分游戏、虚拟机、固定使用直连套接字的软件可能绕过系统代理。TUN 在操作系统网络层创建虚拟接口，通过路由把更多 TCP、UDP 流量送入内核，因此更适合需要统一接管的场景。它并不天然比系统代理更快，也不应作为所有问题的默认修复。浏览器和常规桌面应用已经稳定使用系统代理时，保持简单配置通常更容易维护。

TUN 启动涉及虚拟网卡、路由表、DNS 和系统权限。桌面客户端一般会请求安装服务或授权网络扩展；移动端则使用系统 VPN 接口。开关显示已启用，不代表所有流量都成功进入内核。应查看日志中 TUN 接口、路由和 DNS 劫持是否创建成功，并检查目标连接是否出现。macOS 若遇到网络扩展或钥匙串授权问题，可阅读 macOS 网络扩展与钥匙串处理步骤。

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

auto-route 让内核自动写入必要路由；auto-detect-interface 根据当前网络选择出口接口，适合在有线、无线和移动热点之间切换的设备；strict-route 用于减少流量绕过，但可能与虚拟机、容器和其他 VPN 的路由发生冲突。启用后若局域网或公司网络突然不可达，应先查看路由冲突，再决定是否关闭严格路由或增加明确排除，而不是直接改代理节点。

stack、MTU 与 UDP 行为

TUN 栈由内核版本和平台能力决定，常见选项包括 system、gvisor 和 mixed。系统栈通常利用操作系统网络实现，兼容性与性能表现受平台影响；gVisor 用户态栈提供另一条处理路径，遇到特定系统栈问题时可用于对照；mixed 组合处理不同流量，是许多桌面场景的起点。不要仅根据名称判断优劣，应使用同一网络、同一目标分别测试 TCP、UDP、局域网和休眠恢复。

MTU 过大时，某些链路上的分片或路径发现异常会表现为“小页面能开，大文件或特定请求卡住”；设置过小则增加包数量和额外开销。默认值工作正常时不必修改。怀疑 MTU 时，应先确认问题是否只发生在 TUN，切回系统代理进行对照，再逐步降低数值测试，不要同时切换栈和 DNS。UDP 异常也要确认所选代理是否支持对应传输，TUN 只负责接管，不会为不支持 UDP 的代理补出能力。

Fake-IP 为什么常与 TUN 配合

TUN 会接收到大量原本不经过系统代理的连接。如果连接建立前的 DNS 查询也被劫持到 mihomo，Fake-IP 可以保留域名信息，使这些连接继续使用域名规则。若 DNS 查询在内核外完成，TUN 只看到真实 IP，规则可能退化为 IP 匹配或最终兜底。因而 TUN、DNS 劫持和 Fake-IP 应作为一条链检查：应用查询是否进入内核、返回映射是否被保存、应用连接映射地址后是否恢复域名、规则是否命中预期项。

有些应用自行连接硬编码 IP，从源头就没有域名。此时 Fake-IP 无法创造域名，需要依赖 IP 规则、进程规则或域名嗅探能否从协议内容中识别目标。进程规则在不同平台的可用程度不同，移动端限制通常更多。配置应保留最终兜底，并根据日志中实际可见的信息选择规则类型，不要假定每条连接都能恢复域名。

常见冲突来源包括其他 VPN、虚拟机桥接、容器网络、局域网代理工具和安全软件。多个程序同时修改默认路由或 DNS 时，后启动者可能覆盖先启动者。排查时记录启动顺序，暂时关闭其他网络工具，再单独启用 Clash。若休眠恢复后失效，可先重启 TUN 接口；若切换 Wi-Fi 后失效，检查出口接口自动检测。只有确认路由创建正常后，才继续分析规则和代理。

移动设备持续启用 TUN 会让内核常驻，测速周期、复杂规则和频繁 DNS 查询都会影响耗电。可减少自动测试频率、精简不用的规则提供者，并允许客户端在系统后台策略中稳定运行，避免反复被停止和重建连接。安卓端的具体检查顺序可参考 安卓后台策略与耗电排查清单。

域名嗅探与规则补全

嗅探解决的是信息缺失

当连接进入 mihomo 时，目标有时只有 IP。域名嗅探会检查连接初期的协议信息，从 HTTP Host、TLS ClientHello 中的服务器名称等位置恢复域名，再让域名规则参与决策。它不是读取所有应用内容，也不是 DNS 的替代品。加密连接中可识别的是握手阶段公开的目标名称；如果协议不包含域名、握手被进一步加密或连接直接使用 IP，嗅探就无法得到结果。

嗅探适合补足“DNS 在内核外完成，但连接仍携带域名信息”的场景。例如应用使用自己的 DNS 得到真实地址，随后发起 TLS 连接，内核可能从握手恢复服务器名称。恢复后仍要经过规则顺序判断。若嗅探得到的域名与原目标 IP 对应关系特殊，贸然覆盖目的地址可能造成连接异常，因此配置应从常见 HTTP 与 TLS 端口开始，不要一开始覆盖所有端口和协议。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  force-domain:
    - "+.example.com"
  skip-domain:
    - "Mijia Cloud"
    - "+.push.example"
  skip-src-address:
    - 192.168.0.0/16

parse-pure-ip 允许对只有 IP 目标的连接尝试解析协议域名；force-dns-mapping 会结合 DNS 映射信息；override-destination 控制是否用嗅探结果改写原目标。初次启用时可先保持目的地址不改写，只观察日志中的域名恢复结果。确认特定服务需要依赖嗅探域名路由后，再评估是否开启覆盖。字段支持情况会随客户端内核而异，载入配置后应检查日志是否接受这些参数。

force-domain 与 skip-domain 的边界

force-domain 适合明确需要嗅探处理的域名，skip-domain 用于已知兼容性不佳或不应改写的目标。两者都应基于日志和复现结果维护，不要复制一份来源不明的大型排除表。设备发现、局域网服务、推送长连接和某些使用证书特殊校验的应用，可能需要跳过；但表现为连接失败时，还要先排除 DNS、规则和代理本身，不能把所有失败都归因于嗅探。

源地址排除适合局域网设备通过本机转发、且不希望进行域名识别的场景。设置网段时要确认实际局域网范围，过宽会让大量连接失去域名规则。端口范围同样要克制：HTTP 嗅探放在典型明文端口，TLS 放在常见加密端口，QUIC 主要处理 UDP。把所有端口同时交给所有协议尝试，会增加不必要的判断，也会让日志变得难读。

判断嗅探是否真正生效

验证时选择一个已知域名，先在日志中确认连接初始目标是否为 IP，再检查嗅探后是否出现域名，以及最终命中的是域名规则还是 IP 规则。若连接一开始就有域名，成功命中不能证明嗅探发挥了作用。可以对比关闭嗅探后的同一应用行为，但要清理已有连接，避免复用旧会话。浏览器通常有连接池，单纯刷新页面不一定创建新连接。

若日志没有嗅探结果，确认流量是否进入 mihomo、端口是否在配置范围内、协议是否属于 HTTP、TLS 或 QUIC。若能恢复域名却没有按预期分流，检查规则顺序和域名写法。若开启 override-destination 后连接失败，先关闭覆盖并保留解析，确认问题来自目的地址改写，再将目标加入跳过列表。排除项应写具体域名或后缀，并注明原因，方便以后复查。

长期维护时，把嗅探例外与对应应用、协议和故障表现记录在一起。只保留域名而不写原因，几个月后很难判断排除项是否仍有必要。客户端或内核迁移后，先使用较小范围重新验证，而不是原样复制全部历史排除。通过“观察信息缺失 → 开启有限协议 → 验证恢复域名 → 决定是否覆盖”的顺序，嗅探才能成为可控工具，而不是增加另一层不确定性。

本地覆写与多订阅合并

把订阅视为输入，不直接当成最终配置

远程订阅通常负责提供代理节点、基础策略和部分规则，但它不一定了解本机局域网、内部域名、应用习惯和平台权限。把订阅内容作为输入，再通过本地覆写形成最终配置，更适合长期维护。订阅更新可以替换节点列表，本地覆写则保留 DNS、TUN、自定义规则和策略组调整。支持覆写的客户端可能提供 YAML 覆写、脚本处理或合并界面，具体入口不同，但目标都是避免直接编辑会被刷新覆盖的主配置。

覆写应尽量只包含需要改变的键。整份复制主配置虽然直观，却会把上游新增字段挡在外面，也容易保留已经失效的节点名。对映射字段可按键合并；对数组字段要特别小心，因为不同客户端可能采用替换、前置、后置或脚本化处理。rules 是最典型的顺序数组：简单替换会丢失订阅规则，简单追加又可能落到 MATCH 后面而永远不生效。使用客户端的“规则前置”能力，或在合并脚本中明确插入最终兜底之前。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "+.internal.example"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

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

这类本地覆写不包含订阅代理，适合让节点更新与本机网络设置分离。保存后要查看最终生效配置，而不是只检查覆写文件。客户端若提供“预览合并结果”或“打开运行配置”，应确认 DNS 和 TUN 字段只出现一次、缩进正确，规则插入位置符合预期。遇到同名键时，明确哪一层优先，不要靠尝试猜测。

多订阅合并的结构设计

多订阅并不等于把所有节点文本拼在一起。更稳妥的做法是为每个来源建立独立 proxy-providers，设置不同缓存路径，再由策略组通过 use 引用。这样某个来源更新失败时，不会影响另一个来源的缓存，也便于查看成员来自哪里。提供者名称要稳定，策略组只引用提供者，不直接枚举会变化的节点名。

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.com/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.example.com/
      interval: 900

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

proxy-groups:
  - name: 节点选择
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    use:
      - provider-main
      - provider-backup
    url: https://www.example.com/
    interval: 600
    tolerance: 80

示例 URL 是结构示意，实际应使用自己的订阅地址，并把订阅地址当作敏感信息管理。不同提供者必须使用不同 path。如果路径相同，后更新的内容可能覆盖前一个缓存。健康检查与策略组测速是两个层次：提供者健康检查标记成员可用性，url-test 决定组内选择。两者周期都设置过短会产生重复测试；移动设备尤其应放宽间隔。

多个来源可能包含同名节点。界面只显示名称时，很难判断选中了哪一份。可在合并阶段添加来源前缀，或按提供者拆成“主订阅”“备用订阅”两个中间组，再由总入口引用。不要依赖节点排列顺序，因为订阅更新可能重排。过滤规则也要按来源验证，确保某个来源命名变化后不会让地区组突然变空。

更新、失败与回退

订阅更新前先确认当前缓存可用。更新失败时，客户端通常可能继续使用旧缓存，此时不应删除缓存反复重试；先检查订阅地址解析、网络路径和返回格式。若远程内容能下载却无法载入，查看它是完整 Clash 配置还是仅代理提供者格式，两者结构不同。完整配置不能直接当成 provider 文件使用，除非客户端提供转换能力。

本地覆写升级时采用小步迁移：先合并基础 profile 与 DNS，确认加载；再加入规则前置；最后启用 TUN 和嗅探。若一次性复制旧设备整份配置，平台专属字段、路径和接口名称可能不兼容。Windows、macOS、Android 与 Linux 的权限和网络栈不同，同一逻辑可以保留，但具体监听地址、TUN 权限和本地路径应重新确认。

迁移客户端时先导出订阅地址和自定义覆写，再记录策略组当前选择。不要把客户端内部缓存目录视为长期备份，因为目录结构可能随平台改变。原版客户端停止维护后的迁移思路，可参考 FlClash 与 Clash Verge Rev 迁移方案对比。新安装优先从 客户端下载页选择 Clash Plus，并按系统与处理器架构安装，再逐层导入上述配置。

外部控制面板与安全边界

控制接口能做什么

mihomo 的外部控制接口用于读取运行状态、切换策略组、更新提供者、查看连接和日志。图形客户端自身也可能通过这个接口与内核通信。独立控制面板只是接口的前端展示，不替代内核，也不会改变配置文件的权限边界。接口是否可访问，由 external-controller 的监听地址、系统防火墙和认证密钥共同决定。

只在本机使用时，应监听回环地址，例如 127.0.0.1:9090。这样其他局域网设备不能直接连接。需要从另一台设备管理时，才考虑监听局域网地址，并同时设置强认证、限制防火墙来源、确认当前网络可信。把接口监听到所有网卡会扩大访问范围，不能仅依赖控制面板页面“看起来需要输入密钥”来判断安全，真正的保护必须发生在 API 连接层。

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui

log-level: info
allow-lan: false

secret 示例必须替换为本机独立值，不要与订阅地址或其他账号凭据共用。若客户端已经自动生成控制接口配置，应优先在客户端设置中修改，避免手工覆写与界面设置相互覆盖。external-ui 指向本地静态面板目录；部分客户端会自动下载和管理面板资源，另一些只提供 API，需要自行准备兼容前端。路径应位于客户端可读取的配置目录内。

连接面板的检查顺序

面板打不开时先区分静态页面与 API。浏览器无法打开面板文件，检查 external-ui 路径和客户端资源管理；页面能打开但显示无法连接，检查控制地址、端口、密钥和浏览器访问来源。若控制接口监听在回环地址，从另一台设备输入本机局域网 IP 仍无法连接，这是预期边界。若改为局域网监听，应确认操作系统防火墙允许指定来源，而不是开放给整个网络。

控制面板地址使用 HTTP 还是 HTTPS，取决于部署方式。回环地址上的本机使用与局域网远程管理风险不同。需要跨设备管理时，更稳妥的方式是通过受控的本地网络或已有安全隧道访问，不要把控制端口直接映射到公网。接口能切换策略、读取连接目标并修改运行状态，因此应按管理接口对待，而不是普通状态页面。

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/proxies

命令用于验证本机 API 是否响应。第一条可确认接口与认证是否工作，第二条读取策略和代理结构。若返回未授权，检查密钥是否一致；若连接被拒绝，检查内核是否运行、端口是否监听；若能连接但路径无响应，确认当前内核接口兼容性。调试完成后不要把带认证信息的命令保存到共享脚本或公开日志。

连接信息与日志的正确使用

控制面板中的连接列表适合回答三个问题：流量是否进入内核、目标信息是域名还是 IP、最终采用哪条规则和策略。看到大量连接并不代表异常，现代网页会并发请求多个资源。排错时按目标应用或域名过滤，关闭旧连接后重新发起一次请求，比盯着不断滚动的全量列表更有效。

切换策略组后，既有 TCP 连接通常不会自动迁移到新代理。若测试结果没有变化，应关闭对应连接或重启目标应用，再观察新连接使用的策略。更新规则提供者后也要确认新连接命中，不能只看更新按钮完成。面板显示的是运行状态，配置文件则决定下次载入状态；临时切换是否在重启后保留，取决于 profile.store-selected 和客户端持久化机制。

当控制面板与客户端界面显示不同状态时，先确认它们是否连接到同一个内核实例和端口。设备上可能同时运行旧客户端服务、命令行内核和新客户端，面板连到另一个实例会产生“策略切换没有效果”的错觉。查看进程、监听端口和配置目录，关闭不需要的实例，再重新连接。完成后将控制地址、面板路径和配置文件位置记录在设备说明中，后续迁移会更直接。

配置验证、排错与长期维护

用固定顺序验证完整链路

复杂配置完成后，不要直接用多个应用同时测试。先确认内核载入配置且没有 YAML 或字段错误；再确认系统代理或 TUN 接管成功；随后验证 DNS 查询、域名嗅探、规则命中、策略组选择和代理连接。每一层只回答一个问题。若第一层已经失败，后面的网页错误没有分析价值。固定顺序能避免在策略组里切换节点，实际问题却是 TUN 路由没有建立。

建议准备一张本地测试表，包含目标、预期规则、预期策略和验证结果。目标至少覆盖局域网直连、普通直连、需要代理的域名、只提供 IP 的连接、UDP 应用和最终兜底。测试时在控制面板或日志中记录实际命中项。更新订阅、规则集、DNS 或客户端后重复同一组测试，结果具有可比性，也能快速发现是内容更新还是客户端环境造成变化。

# 检查本地混合代理端口是否监听
curl -x http://127.0.0.1:7890 https://www.example.com/

# 检查外部控制接口
curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

命令只验证端口和请求路径，不代表所有规则都正确。第一条成功说明应用能够通过本地代理发起请求；若浏览器仍不工作，应检查浏览器代理来源和既有连接。命令失败时，根据错误区分连接拒绝、DNS 失败、认证失败或请求超时。不要把所有错误都归纳为“节点不可用”，因为本地端口未监听与远端代理故障的处理完全不同。

按现象建立排错分支

“所有目标都失败”优先检查内核、端口、权限、DNS 基础路径和当前策略成员；“只有一个域名失败”优先查看域名解析、规则命中与该服务的出口要求；“只有某个应用失败”检查它是否进入系统代理、是否使用独立 DNS、是否只走 UDP；“切换网络后失败”检查出口接口、路由和局域网 DNS；“订阅更新后失败”检查提供者格式、策略组成员和规则顺序。

日志中的第一处错误通常比后续连锁错误更有价值。DNS 初始化失败可能继续产生节点域名解析失败、提供者更新失败和所有代理超时。如果只看最后一条，会误以为多个订阅同时失效。临时启用 debug 后，从内核启动阶段开始阅读，找到第一个与本次修改相关的错误。修复后重新启动并确认它消失，再继续处理下一项。

升级与迁移时控制变量

客户端升级、内核替换和配置迁移不要同时进行。先在现有客户端中导出可用配置和本地覆写；安装新客户端后，仅导入订阅并完成基础连接；再加入策略组、规则提供者和 DNS；最后启用 TUN、嗅探与外部控制面板。这样某一步出现问题时，能明确是字段支持、平台权限还是配置内容。跨平台迁移还要重新确认路径分隔、服务权限、网络扩展和防火墙。

不要依赖某个界面名称永久不变。长期维护记录应以配置字段和行为为主，例如“启用 profile.store-selected 保存组选择”，而不是只写“打开第三页第二个开关”。界面升级后按钮位置可能变化，但字段含义更稳定。对必须通过界面完成的系统授权，可以补充平台路径和验证现象。

遇到问题时先保留日志、当前配置和复现步骤，再进行回退。只保留一张错误截图通常不足以判断连接经过了哪些层级。复现步骤应包含客户端、接管方式、目标应用、预期策略、实际命中和网络环境。若基础概念仍不清楚，可到 FAQ 按“基础认知、安装配置、使用技巧、故障排查”查找；若需要重新走一遍订阅导入与模式选择，则返回 使用指南。

一份长期稳定的 Clash 配置通常不复杂：订阅负责提供代理，策略组表达出口选择，规则集承担可复用匹配，DNS 保留域名信息，TUN 只在需要时接管更多流量，嗅探用于补足缺失域名，外部控制接口限制在明确边界内。每次只修改一层并用固定测试集验证，就能在功能增加的同时保持配置可读、可回退、可迁移。