内核定位：Clash Meta 与 mihomo 的配置边界

mihomo 是由 Clash Meta 延续而来的代理内核。客户端负责配置管理、系统代理和界面交互，内核负责监听连接、解析规则、建立代理链路。客户端名称中带有 Clash，不代表它一定使用 mihomo；能导入 YAML，也不代表它支持 YAML 中的每一种协议与扩展字段。

本文中的“新增特性”指相对早期 Clash 开源内核的能力扩展，不指某一个版本在同一天新增的功能。规则提供器在 Clash Premium 等分支中也有实现，不能将 rule-providers 简单视为 mihomo 独占字段。迁移时应核对当前内核，而不是只比较客户端外观。

能力主要配置入口启用前提
外部规则集rule-providers、RULE-SET规则格式与 behavior 对应，资源可读取
域名嗅探sniffer连接已进入内核，流量含可识别的域名信息
VLESS 出站type: vless服务端协议、传输层与 TLS 参数一致
Hysteria2 出站type: hysteria2服务端支持 Hysteria2，网络允许相应 UDP 通信

先确认正在运行的内核

独立部署可以执行以下命令。图形客户端则应先查看其内核信息页与启动日志；系统终端中的同名程序，可能并不是客户端实际调用的那个二进制文件。

mihomo -v
mihomo -t -f config.yaml

-v 用于查看内核版本，-t 用于测试指定配置。配置测试能发现不少字段和引用错误，但不能证明远端节点可连接，也不能代替实际的 DNS、TCP 与 UDP 测试。遇到字段不识别时，保留完整版本输出，再对照该版本的配置文档。

rule-providers：把规则内容与分流策略拆开

大量域名逐条写进 rules 会增加维护成本。规则提供器把“需要匹配的集合”移到独立资源中，主配置只保留集合名称、更新方式和最终动作。规则集不是节点订阅：前者提供匹配条件，后者提供代理服务器；两者不能互相导入。

HTTP 规则集与 RULE-SET 引用

下面使用公开的域名规则集说明字段关系。远端资源由对应项目维护，部署前应审阅内容及用途。示例将匹配结果交给 REJECT，其余连接直连，目的是验证规则集加载，不是一套完整的境内外分流方案。

mode: rule
log-level: info

rule-providers:
  reject-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt
    path: ./ruleset/reject-domains.yaml
    interval: 86400

rules:
  - RULE-SET,reject-domains,REJECT
  - MATCH,DIRECT
  • type: http：通过 HTTP 或 HTTPS 获取资源；首次使用仍需网络可达。
  • behavior: domain：按域名集合解释内容，不按完整规则语句解释。
  • format: yaml：指定资源编码格式。URL 末尾是 .txt 并不意味着内容一定是纯文本格式。
  • path：本地缓存位置。应确保内核工作目录允许写入，并避免不同规则集共用同一个文件。
  • interval: 86400：更新间隔为 86400 秒，即 24 小时，不是毫秒。

behavior 与文件内容必须匹配

domain 用于域名集合，ipcidr 用于 IP 网段集合，classical 用于 DOMAIN-SUFFIX、IP-CIDR 等规则语句。三者不能只改名称而沿用同一份文件。以下是本地 classical YAML 文件的结构，可用于理解它与普通域名列表的差别：

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.50.0/24,no-resolve

这里的 example.com 是保留示例域名，192.168.50.0/24 是私有网段示例。该文件只列匹配条件；走直连、代理还是拒绝，由主配置里的 RULE-SET,集合名称,策略名称 决定。需要不同出口时，应把条件拆成不同集合，而不是在集合条目后随意拼接策略组。

域名嗅探：从连接内容补充域名线索

连接以目标 IP 进入内核时，域名规则可能缺少匹配依据。嗅探会尝试读取 HTTP 的 Host、TLS ClientHello 中可见的 SNI，或受支持 QUIC 握手中的信息，补充目标域名。它不是 HTTPS 解密，不会因此获得加密后的网页正文，也不保证每条连接都能识别域名。

HTTP、TLS 与 QUIC 配置示例

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]

ports 是尝试识别对应协议的目标端口范围。只列 443，不会自动覆盖运行在其他端口的全部 TLS 服务。parse-pure-ip 允许对纯 IP 目标尝试嗅探，force-dns-mapping 用于在相关 DNS 映射场景中继续尝试嗅探；两者都不代表一定能提取域名。

示例将 override-destination 设为 false，避免把嗅探出的域名直接用于覆盖原目标，适合先观察匹配变化。改为 true 会改变连接目标处理方式，应单独测试。域名结果可能影响规则选择，但规则仍受当前模式与顺序约束；全局模式下不能据此期待完整的按域名分流。

与 Fake-IP、TUN 的关系

  • Fake-IP：通过内核维护的 DNS 映射关联域名与假地址。应用 DNS 已进入内核时，通常已有可用域名信息，嗅探属于补充机制。
  • TUN：负责把网络流量接入虚拟网卡。它扩大接管范围，不会自动让所有连接携带域名。
  • 嗅探：处理已进入内核的连接，不会接管绕过系统代理、也未经过 TUN 的流量。
  • 识别边界：ECH 等加密机制、非标准握手、缺少 SNI 或协议不受支持，都可能导致无法提取预期域名。

排查时先确认连接是否出现在客户端连接列表，再看目标 IP、识别域名、命中规则和最终策略。只有连接进入内核之后，调整 sniffer 才有意义。某个应用未被接管时，应先排查系统代理或 TUN 路由，而不是不断扩大嗅探端口范围。

VLESS：协议、传输层与 TLS 参数分别核对

VLESS 是代理协议，WebSocket 是可选传输方式，TLS 是连接安全层。三者不是同一个开关。服务端使用 VLESS over WebSocket over TLS 时，客户端必须同时对齐 UUID、端口、WebSocket 路径、Host 与 TLS 服务器名称。

下面使用保留示例域名及演示 UUID 展示字段结构，不对应可用服务。实际部署应采用服务端下发的完整参数，不应通过猜测路径或关闭证书验证来消除连接错误。

proxies:
  - name: VLESS-WS-TLS
    type: vless
    server: vless.example.com
    port: 443
    uuid: 550e8400-e29b-41d4-a716-446655440000
    network: ws
    tls: true
    servername: vless.example.com
    udp: true
    ws-opts:
      path: /proxy
      headers:
        Host: vless.example.com

常见参数错位

  1. 传输类型不一致：服务端使用 TCP，客户端却配置 network: ws，并不能通过修改端口解决。
  2. 域名职责混淆：server 是连接地址，servername 用于 TLS，WebSocket 的 Host 用于 HTTP 请求，三者可以按部署要求不同，但不能随意互换。
  3. 路径不一致：/proxy 与其他路径可能由反向代理转发到不同服务，应保留服务端要求的路径和大小写。
  4. 混用其他方案字段：REALITY、公钥、指纹与 flow 有各自适用条件，不应直接附加到普通 WebSocket TLS 示例。

新增代理条目之后，还要将其名称加入已有策略组，并在规则中引用该组。仅在 proxies 中出现，不代表实际请求会选中它。订阅配置由客户端定期覆盖时，应使用客户端支持的覆写或合并功能保存自定义项，避免下次更新丢失。

Hysteria2：先检查 UDP 路径，再调整传输参数

Hysteria2 基于 QUIC，依赖 UDP 通信。它与第一代 Hysteria 的配置不是一套语法；节点标明 Hysteria2 时，应使用 type: hysteria2。能通过 TCP 连接服务器的 443 端口，并不证明相同端口上的 UDP 服务可达。

proxies:
  - name: HY2-TLS
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: demo-password-for-documentation
    sni: hy2.example.com
    skip-cert-verify: false

此处同样使用保留示例域名与演示认证信息。password 必须与服务端认证设置一致，sni 应符合实际证书和服务端部署要求。若服务端启用了特定混淆机制，还需配置对应字段；不能因为协议名称相同就省略这部分参数。

连接超时的检查顺序

  • 确认服务器地址能解析到预期 IP，特别注意 IPv4 与 IPv6 路径是否都可用。
  • 确认服务端监听 UDP 443，且主机防火墙、云安全组和中间网关允许对应流量。
  • 核对认证信息、SNI、证书有效期以及客户端设备时间。
  • 在另一条网络上做对照测试，判断是否存在当前网络的 UDP 限制。
  • 基础连接建立后，再按服务端要求调整带宽或混淆参数，每次只改一类设置。

Hysteria2 的实际效果受丢包、拥塞、运营商策略和服务端资源影响，协议名称本身不代表固定吞吐量。对比时应使用相同设备、相同网络与相同目标，并分别记录连接成功率和传输表现，不要将一次测速结果推广到所有环境。

配置验证：按解析、资源、连接、规则四层推进

规则集、嗅探与新协议可以组合使用，但初次迁移时不宜同时启用所有功能。先备份原始配置，保留一个已经验证可用的出口，再逐项修改。以下流程能把“配置载入失败”与“节点连接失败”分开处理。

  1. 解析层：执行 mihomo -t -f config.yaml，处理缩进、重复顶层键、未知代理类型及引用不存在的策略组。
  2. 资源层：启动内核，检查规则集是否下载成功。HTTP 错误、写入权限与内容格式不匹配需要分别定位。
  3. 连接层：先选定一个代理节点测试握手。VLESS 重点看传输与 TLS，Hysteria2 重点看 UDP 和认证。
  4. 规则层：切回规则模式，检查目标连接是否命中预期 RULE-SET，最终出口是否与策略组当前选择一致。

用明确端口验证本地入口

若测试配置设置了 mixed-port: 7890，可以用下面的请求验证本地 HTTP 代理入口。mixed-port 同时接收 HTTP 与 SOCKS 代理连接；该端口不是节点服务端口，也不是外部控制器端口。

curl -I --proxy http://127.0.0.1:7890 https://example.com

这条命令只能验证本次请求的处理结果。应同时查看连接记录，确认它到底走了代理节点还是 DIRECT；返回网页响应并不能单独证明分流配置正确。测试期间可以临时将 log-level 调为 debug，结束后恢复 info，并在分享日志前移除订阅地址、认证信息和个人访问记录。

合并 YAML 时保留唯一顶层键

本文的代码块分别展示功能片段，不能不加整理地连续拼接到文件末尾。已有 proxies 时，应把新节点加入原列表；已有 rules 时，应按优先级插入规则。重复定义同名顶层键，可能报错，也可能被解析器覆盖，不能依赖这种行为完成配置合并。

迁移完成的判断标准是：内核版本明确、配置测试通过、规则资源可用、目标协议能完成握手、连接记录显示预期规则与出口。涉及系统接管范围时，再单独启用 TUN，并复测局域网访问、DNS 与应用连接。基础操作可参考本站配置教程，术语含义可查看概念速查。