全球网络加速服务｜低延迟海外网络连接｜https://www.lvpn.cc 欧米伽

Mihomo Meta 配置文件怎么写：从最小 YAML 到订阅与规则配置

更新于 2026-11-12 · oumei.store

简答：先复制最小模板，替换订阅地址或节点占位符，保存为 config.yaml；再用 mihomo -t 校验、查看启动日志、确认代理组已选中实际节点，最后用客户端实际端口执行 curl 并对比出口 IP。仅看到本地端口返回 204，不代表请求一定经过代理。

定义：Mihomo Meta 配置文件是供 Mihomo 内核读取的 YAML 文件，用来定义监听端口、节点或订阅集合、代理组、DNS、分流规则以及可选的 TUN 入站。

先复制模板：5 步确认配置是否真正生效

先不要同时开启 TUN、fake-ip 和复杂规则。建议按下面 5 步确认基础链路：

  1. 日志无解析错误：使用 mihomo -t -d ./mihomo-config 校验配置；其中 ./mihomo-config 替换为包含 config.yaml 的工作目录。具体参数以当前内核执行 mihomo -h 的输出为准。
  2. provider 有节点：在客户端面板或 API 中确认订阅已下载，且 provider 列表不是空的。
  3. 代理组不是 DIRECT：如果选择器的首项是 DIRECT，本地请求可能默认直连；测试前要手动选中实际节点或 Auto 组。
  4. curl 使用实际端口：配置中的端口只是示例。图形客户端可能覆盖配置端口，应以客户端设置页面显示的 mixed-port 为准。
  5. 对比出口 IP：先记录直连结果，再通过代理端口请求同一出口 IP 服务。HTTP 请求返回 204 只能说明请求获得了该状态，不能单独证明代理链路已打通。
curl https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

# 如果客户端只提供 SOCKS 代理，可改用：
curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

如果两次出口结果相同，先检查代理组当前选择、客户端端口和连接日志，再判断节点是否真的建立了连接。Mihomo 官方文档说明，mixed-port 可以同时接受 HTTP(S) 和 SOCKS5 代理请求；TUN 则属于另一种接管系统流量的入站方式，不能把两者混为一谈。查看 Mihomo 官方代理端口说明。

订阅引用模板：适合节点较多、需要定期更新

下面是一份不含真实服务地址的最小订阅模板。把 https://example.com/your-subscription 替换为你自己的订阅链接，并将配置保存为工作目录中的 config.yaml。代码块保留了 YAML 的真实换行和缩进，可以复制后再修改。

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

proxy-providers:
  my-provider:
    type: http
    url: "https://example.com/your-subscription"
    path: ./proxy-providers/my-provider.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      expected-status: 204

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT
    use:
      - my-provider

  - name: Auto
    type: url-test
    use:
      - my-provider
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000

rules:
  - MATCH,Proxy

这里把 Auto 放在 DIRECT 前面，但导入后仍应在客户端面板确认当前实际选择。模板中 provider 的 health-check 用于订阅节点集合的健康检查；代理组自身的 url 用于该组测试逻辑。官方 proxy-groups 文档明确写明，组的 url 只检查该组 proxies 字段，不检查通过 use 引入的 provider 节点；因此不要仅凭组内 url 的结果推断 provider 节点都已测速，最终应结合面板和日志复核。查看 Mihomo 官方 proxy-groups 说明、查看 Mihomo 官方 proxy-providers 说明。

手写节点模板：没有订阅时逐字段核对

手写节点适合只有少量节点、需要逐项检查参数的场景。下面仅使用占位符，不包含真实服务器、密码、UUID、密钥或可用节点信息；占位符必须替换成服务端提供的实际参数。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "SS-占位节点"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "替换为实际密码"
    udp: true

  - name: "VLESS-占位节点"
    type: vless
    server: vless.example.com
    port: 443
    uuid: "替换为实际 UUID"
    udp: true
    tls: true
    servername: example.com
    client-fingerprint: chrome
    network: ws
    ws-opts:
      path: "/替换为实际路径"
      headers:
        Host: example.com

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - SS-占位节点
      - VLESS-占位节点
      - DIRECT

rules:
  - MATCH,Proxy

手写节点至少要核对 name、type、server 和 port，节点名称还应保持唯一。Shadowsocks 的加密方法和密码必须与服务端一致；VLESS 使用 WebSocket 时，ws-opts.path 与请求头也必须匹配。若使用 Reality，公钥、short-id、SNI 和 client-fingerprint 等字段应以服务端参数和当前 Mihomo 文档为准，不要从其他协议模板直接复制。查看 Mihomo 官方通用节点字段、查看官方传输层字段、查看官方 TLS 与 Reality 字段。

常见节点字段对照
协议重点字段容易出错的地方
Shadowsocksserver、port、cipher、password加密方法、密码和 UDP 能力需与服务端一致
VMessuuid、alterId、TLS、传输参数WebSocket 要核对 ws-opts；不能只写 network: ws
VLESSuuid、TLS、SNI、传输方式Reality 参数必须与服务端对应，字段以当前文档为准
Trojanpassword、TLS、SNI证书校验相关字段不要无依据关闭
Hysteria2服务器、端口、密码、TLS 参数端口、SNI、带宽或混淆参数需按服务端配置核对

Trojan 和 Hysteria2 的官方示例分别列出了密码、TLS、SNI、传输或带宽相关字段；这些字段不能通过把 type 改成另一种协议来复用。查看官方 Trojan 示例、查看官方 Hysteria2 示例。

配置文件、订阅和客户端覆写怎么选

三种配置方式对比
方式适合谁自定义内容放在哪里注意事项
手写 proxies节点少、需要逐字段核对主配置的 proxies 数组所有服务器、认证、TLS 和传输字段都要自己维护
引用 proxy-providers节点较多、需要自动更新主配置定义 provider，订阅文件由内核保存检查 URL、保存路径、更新结果和节点是否被代理组引用
客户端覆写或合并订阅会更新但要保留规则、DNS 或代理组客户端的覆写、合并或编辑界面菜单名称因客户端而异，先备份并以当前版本界面为准

不要直接把订阅下载文件当作长期手改的主配置。订阅更新可能重新生成或覆盖该文件；更稳妥的做法是让订阅只提供节点集合，把自定义代理组、DNS 和规则放在主配置或客户端覆写层。具体合并优先级取决于客户端实现，需在当前客户端中查看生成后的最终配置。

截至 2026-11-12 查阅的 Mihomo 官方资料，示例字段以当前文档为准，不绑定某一个小版本。Mihomo 的发布版本和兼容字段会变化，升级后如果出现字段错误，应以实际内核的 mihomo -h、启动日志和官方配置页面复核。

端口、模式和规则：先把基础流量跑通

mixed-port 适合先做本机 HTTP 或 SOCKS 测试；allow-lan 控制是否允许局域网设备访问；mode: rule 让请求按照 rules 从上到下匹配；log-level: debug 适合临时排错，定位完成后可以改回 info。配置文件中的端口不是所有客户端的最终端口，图形客户端可能使用自身设置覆盖它。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

规则通常按从上到下匹配，最后用 MATCH 兜底。过宽的规则放在前面，可能使后面的精细规则没有机会执行。rule-providers 用来读取外部规则集，再通过 RULE-SET 引用；使用时要确认规则集类型与内容相符，例如 domain、ipcidr 或 classical。查看 Mihomo 官方规则配置、查看 Mihomo 官方 rule-providers 配置。

DNS、fake-ip、IPv6 和 TUN 的保守写法

DNS 负责解析，TUN 负责接管系统流量，两者不是同一个开关。新手可以先使用较简单的 DNS 配置，确认普通代理端口可用后，再增加 fake-ip、DNS 劫持或 TUN。

dns:
  enable: true
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query

上面只是结构示例，DNS 地址是否适合当前网络需要自行测试。官方 DNS 文档列出了 redir-host、fake-ip、fake-ip-filter、nameserver 等字段；如果启用 fake-ip，应根据实际应用增加过滤项，而不是盲目复制大段规则。查看 Mihomo 官方 DNS 配置说明。

  • 普通应用代理：先使用系统代理或应用代理，不同时开启 TUN。
  • 需要接管不支持系统代理的应用：再配置 TUN，并检查 VPN、管理员或系统权限。
  • 域名异常：先在日志中区分 DNS 解析失败和节点连接失败，再切换 enhanced-mode: redir-host 与 fake-ip 做对比。
  • IPv6 异常：可暂时设置 ipv6: false 进行对照，但这只是定位手段，不代表所有网络都应永久关闭 IPv6。

TUN 可能涉及自动路由、DNS 劫持、网卡冲突和系统权限。每次只改一个选项，保存后查看日志并复测，才能判断问题来自 DNS、路由还是节点本身。查看 Mihomo 官方入站与 TUN 说明。

Windows、macOS、Linux、Android 的导入与校验路径

  1. Windows：将文件命名为 config.yaml，在所用兼容客户端的 Profiles、配置或导入页面加载；重新加载后查看客户端设置中的实际 mixed-port。若使用原生内核，在包含配置的目录执行校验命令。
  2. macOS：在图形客户端的 Profiles 或配置页面导入 YAML；原生内核则用启动参数指定工作目录，并在终端查看启动输出。菜单名称以当前客户端版本为准。
  3. Linux：把配置放入启动参数 -d 指定的目录；使用 systemd 时通过服务状态和 journal 日志确认加载结果。官方服务示例也使用工作目录和日志查看方式。查看 Mihomo 官方启动与服务说明。
  4. Android：在兼容 Mihomo 内核的客户端中打开配置、订阅或覆写页面导入，并授予 VPN 权限；确认客户端面板显示的实际端口和当前代理组。不同 Android 客户端的菜单不能相互套用。

校验命令可先在终端执行：

# Linux/macOS
mihomo -t -d ./mihomo-config

# 查看当前二进制支持的参数
mihomo -h

如果配置目录中没有名为 config.yaml 的文件，或客户端使用了自己的配置目录，应把 -d 后的路径改成实际工作目录。mihomo -t 通过后，还要启动内核并检查 provider、代理组、连接日志和出口 IP；语法通过不等于节点参数正确。

常见现象：检查、判断、处理与回滚

配置排障表
现象检查判断与处理回滚方式
启动时报 YAML 或字段错误检查缩进、冒号、引号、重复名称和字段拼写删除最近新增的一段，重新执行 mihomo -t；字段支持以当前文档为准恢复上一个可启动的备份
本地端口有响应，但出口 IP 没变化检查客户端实际端口、代理组当前选择、是否选中了 DIRECT改选实际节点或 Auto 组，再看连接日志；不要把 204 当作代理成功证明关闭 TUN，仅保留 mixed-port 测试
url-test 组没有预期测速结果检查 provider 是否更新、provider 的 health-check、测试地址和网络组的 url 与 provider 的健康检查作用不同；结合当前版本面板和日志判断临时改用 select 组手动选节点
订阅更新失败检查 URL、HTTP 状态、返回内容、证书和保存路径若返回 Base64、JSON 或错误页面，不要直接当 YAML 导入；先确认订阅格式使用最近一次成功保存的 provider 文件
开启 TUN 后断网检查 VPN 或管理员权限、自动路由、DNS 劫持和网卡冲突关闭 TUN，先确认普通代理端口可用，再逐项恢复 TUN 设置恢复到 mixed-port、无 TUN 的配置

当配置能够加载、provider 能显示节点但所有节点都连接失败时，应分别检查订阅是否有效、节点参数是否匹配、系统时间、DNS 解析和当前网络环境。完成这些检查后，仍无法建立连接，才适合更换节点或联系订阅提供方。

本站说明

本站是第三方使用指南站，不是 Mihomo 或任何客户端的官方网站。本文侧重从零编写、导入和验证配置；如果你要处理配置备份、订阅更新后的覆写保留，可继续阅读Mihomo 配置文件修改、备份与覆写。端口、DNS 和节点选择问题，还可以参考连接问题排查指南与代理节点稳定性测试方法。

常见问题

Mihomo Meta 和 Clash Meta 是不是完全不同的配置格式？

MetaCubeX 的官方资料将 mihomo 描述为 Clash Meta 相关内核与生态，配置字段仍可能随版本变化。能否直接使用，应以当前内核文档、实际启动日志和客户端兼容情况为准，不要只根据文件名判断。

只写 proxy-providers、不手写 proxies 可以吗？

可以。需要确认 provider 下载成功、代理组通过 use 正确引用，并在客户端面板中选中实际节点。provider 健康检查和代理组 url 的作用不同，本地端口有响应也不能代替节点连通性验证。

为什么订阅更新后手写的代理组消失了？

常见原因是直接修改了订阅生成文件，而更新时文件被重新下载或覆盖。应把自定义代理组、DNS 和规则放在主配置或客户端覆写层，订阅文件只作为节点来源。

DNS 一开始就应该使用 fake-ip 吗？

不建议一开始同时启用 fake-ip、TUN、DNS 劫持和复杂规则。先用较简单的 DNS 与普通代理端口确认基础链路，再逐项增加功能，出现异常时按变量回滚。

为什么 curl 返回 204 但仍然像没有走代理？

204 只说明该 HTTP 请求获得了预期状态，不能证明代理链路已打通。应检查客户端实际端口、代理组是否选中非 DIRECT 节点，并对比直连和代理请求下的出口 IP。

配置文件应该放在哪个目录？

原生 Mihomo 通常从启动参数指定的工作目录读取配置，例如使用 <code>-d</code> 指定目录；图形客户端和 Android 客户端通常有自己的 Profiles、配置或导入页面，应以当前客户端显示的路径为准。

相关阅读

参考资料

  1. Mihomo 官方代理端口说明
  2. Mihomo 官方入站与 TUN 配置说明
  3. Mihomo 官方 proxy-groups 配置说明
  4. Mihomo 官方 proxy-providers 配置说明
  5. Mihomo 官方通用节点字段说明
  6. Mihomo 官方传输层配置说明
  7. Mihomo 官方 TLS 与 Reality 配置说明
  8. Mihomo 官方 Trojan 配置说明
  9. Mihomo 官方 Hysteria2 配置说明
  10. Mihomo 官方 DNS 配置说明
  11. Mihomo 官方启动与 systemd 服务说明
  12. MetaCubeX 官方面板与 mihomo -t 校验说明