Mihomo Config.yaml 高级配置指南：从入门到灵活调优的详尽解读

引言：Mihomo 配置哲学与文件结构概览

Mihomo，作为一款基于 Clash 内核的高级代理软件，其核心功能和行为都由一份名为 config.yaml 的 YAML 格式配置文件驱动。这份配置文件不仅是软件的指令集，更体现了其模块化和分层设计的精髓。理解其结构是进行高效配置的基础。

YAML 文件使用缩进来表示层级关系，键值对通过冒号分隔，并且严格区分大小写。例如：

port: 7890

表示设置 HTTP 端口为 7890，而其上级 listeners 或 general 等则通过缩进确定其所属关系。

config.yaml 的配置节之间存在清晰的逻辑关联，共同构建了 Mihomo 的流量处理流程。例如，proxies 定义了可用的代理节点，proxy-groups 则将这些节点组织成具有特定行为的策略组，而 rules 则决定了何种流量应由哪个策略组处理。这种设计将“数据”（代理节点）与“逻辑”（规则和策略）解耦，使得配置文件具有高度的灵活性和可维护性。用户可以独立管理和更新代理节点列表和规则集，而无需频繁修改核心配置。

第一章：基础与通用配置（General Section）

1.1 入站代理服务端口与模式：基础网络拓扑构建

general 配置节负责定义 Mihomo 服务的入站端口和核心行为，是整个代理服务的基础。端口配置是其中最直接且关键的部分。

port: 7890 用于开启 HTTP 代理服务
socks-port: 7891 用于 SOCKS5 代理
mixed-port: 7890 允许在同一个端口上同时支持 HTTP(S) 和 SOCKS5 协议

这种集成式的设计降低了新用户的入门门槛，体现了开发者对易用性的考量。

对于更高级的应用场景，尤其是需要实现系统级透明代理时，Mihomo 提供了 redir-port: 7892 和 tproxy-port: 7893。这些端口配合特定的内核功能（如 Linux 的 TProxy 或 Redirect），能够将所有网络流量透明地重定向到 Mihomo，而无需在每个应用中单独设置代理。

在这些复杂的网络环境中，文档建议使用 Clash Premium 等内置了路由表和 nftables 自动管理功能的版本，以简化配置和运维。这反映了技术产品在易用性和功能深度之间进行的分层设计：通用功能被高度集成以方便大众用户，而专业或复杂功能则保留给高级用户，甚至通过更完善的商业版本提供简化的解决方案，这是一种商业模式与技术实现相互促进的体现。

1.2 局域网共享与安全控制

Mihomo 能够通过 allow-lan: true 参数，使其代理服务可供局域网内的其他设备（如手机、智能电视等）访问。在开启此功能后，需要通过 bind-address 来指定服务绑定的 IP 地址。例如：

bind-address: "*" 表示绑定到所有可用的 IP 地址
也可以指定一个具体的 IPv4 或 IPv6 地址，如 192.168.1.100 或 [aaaa::a8aa:ff:fe09:57d8]

然而，开启局域网共享也带来了安全风险。因此，Mihomo 提供了 authentication 选项，允许为 HTTP(S)、SOCKS5 和混合代理设置用户名和密码认证。

在家庭网络中，为了方便通常会直接开启 allow-lan，但在公共网络或不受信任的环境中，则应严格配置 authentication，或者将 allow-lan 保持为 false。

配置文件中还有一个独立的 secret 参数，用于保护 Mihomo 的外部控制 API。这与保护代理流量的 authentication 是两个不同层面的安全措施。

authentication 确保只有授权用户能使用代理
secret 则确保只有授权管理员能通过 API 管理和修改 Mihomo 的配置

这种分层防御的设计要求用户不仅要保护代理的出口流量，也要保护代理服务的控制入口，从而构建一个更健壮的安全屏障。

1.3 核心行为模式与管理

Mihomo 的 mode 参数决定了流量的宏观处理策略，是其核心行为模式的切换开关。

mode 默认值为 rule，表示 Mihomo 将根据配置文件中的规则对流量进行分流。这是最常用也是最灵活的模式，适用于大多数需要区分国内外流量的场景。
还有 global 模式，该模式下所有流量都会被发送到 GLOBAL 策略组所选择的代理节点。
direct 模式则相反，所有流量都将直连，不经过任何代理。

在日常使用中，rule 模式是标准选择；而在调试网络连通性或处理特殊任务时，可以通过仪表盘或 API 快速切换到 global 或 direct 模式，这为用户提供了快速应对不同网络需求的工具。

log-level 参数控制着 Mihomo 输出日志的详细程度，是排查配置问题和观察软件运行状态的重要工具。可选项从 silent（无输出）到 debug（输出尽可能多的信息）不等，在日常使用中通常设置为 info，而在需要详细排查问题时则可暂时提升到 debug 级别。
find-process-mode 参数用于控制 Mihomo 是否进行进程匹配。strict 为默认值，Mihomo 会自行判断是否启用进程匹配，而 off 则会完全禁用此功能，这是在路由器等资源受限环境中推荐的设置。
ipv6 参数默认值为 true，控制 Mihomo 是否支持并处理 IPv6 流量，这反映了其对未来网络协议的兼容性考虑。

配置项	类型	默认值	功能描述	典型应用场景
port	整数	7890	HTTP 代理端口	独立 HTTP 代理服务
socks-port	整数	7891	SOCKS5 代理端口	独立 SOCKS5 代理服务
mixed-port	整数	(无)	HTTP/SOCKS5 混合代理端口	简化个人电脑客户端配置
redir-port	整数	(无)	透明代理端口（Linux/macOS）	路由器透明代理
allow-lan	布尔	false	允许局域网设备访问代理服务	家庭网关代理
bind-address	字符串	127.0.0.1	服务绑定的 IP 地址	局域网 IP 绑定，或绑定所有 IP (*)
mode	字符串	rule	核心工作模式	规则分流、全局代理或全局直连
log-level	字符串	info	控制日志输出级别	调试和日常运维
ipv6	布尔	true	是否支持 IPv6 流量	应对 IPv6 网络环境
secret	字符串	””	API 访问密钥	保护外部控制 API 的安全

第二章：代理节点与服务配置（Proxies & Proxy-Providers）

2.1 手动配置核心代理协议（Proxies）

proxies 配置节是 Mihomo 代理节点的核心定义部分。用户可以在此手动配置各种代理协议的详细参数。例如，VMess 和 VLESS 协议需要配置 uuid、alterId 和 cipher 等核心参数，并可通过 network 字段指定传输层协议，如 ws、h2 或 grpc。Trojan 协议则需要配置 password 并通常需要启用 tls: true。

此外，Mihomo 还支持一些新兴的、以高性能和抗审查为特点的现代协议。例如，Hysteria2 是一种基于 UDP 的代理协议，其配置需要指定 server、port 和 password，并且可以配置 skip-cert-verify 来跳过证书验证。TUIC v5 也是一个基于 UDP 的协议，它通过 users 字段来管理用户，并可通过 certificate 和 private-key 配置 TLS。

这些现代协议的配置通常比早期协议（如 Shadowsocks）更为复杂，因为它们引入了更多用于性能优化（如 BBR 拥塞控制）和流量伪装的参数，这反映了代理技术正在从简单的流量加密向追求极致性能和更高安全性的方向发展。

为了应对日益复杂的流量审查，许多代理协议都依赖于 TLS 来伪装流量。因此，Mihomo 提供了一系列通用的 TLS 配置选项，包括 tls（启用 TLS）、servername（SNI）、alpn（应用层协议协商）、skip-cert-verify（跳过证书验证）和 client-fingerprint（客户端 TLS 指纹）。其中，client-fingerprint 参数尤为重要，它允许代理流量伪装成来自特定浏览器（如 chrome 或 firefox），以规避基于 TLS 指纹的流量分析。skip-cert-verify 选项虽然方便了自建代理用户，但其跳过证书验证的行为也带来了中间人攻击的风险，因此在配置时必须权衡便利性与安全性。

2.2 动态管理代理节点（Proxy-Providers）

手动管理大量代理节点会非常繁琐，尤其当节点信息频繁变动时。proxy-providers 机制正是为了解决这一问题而设计的。它允许用户通过订阅链接或本地文件动态地获取和管理代理节点列表。

在 config.yaml 中，proxy-providers 是一个顶层配置节，每个提供者都可拥有一个唯一的名称。一个典型的 proxy-providers 配置包括：

type: http 或 type: file：指定提供者类型，前者从远程 URL 获取，后者从本地文件获取
url：当 type 为 http 时必须提供的订阅链接地址
interval：指定 Mihomo 自动更新代理列表的间隔，以秒为单位
path：保存代理列表的本地文件路径

出于安全考虑，Mihomo 限制了所有路径参数必须在工作目录下，并可通过设置 SAFE_PATHS 环境变量来扩展允许的目录。

filter 和 exclude-filter：这是 proxy-providers 的强大功能之一，它允许用户通过正则表达式或关键字来筛选节点。例如，filter: "(?i)港|hk|hongkong" 可以自动筛选出所有名称中包含“港”、“hk”或“hongkong”的节点，并创建一个独立的节点集合。

proxy-providers 与规则配置中的 rule-providers 共同构成了 Mihomo 高度模块化和可插拔的设计哲学。这种设计将“做什么”的代理节点数据与“怎么做”的流量分流逻辑分开，使得用户可以独立地维护和更新配置文件的不同部分，极大地提高了配置的灵活性和可维护性。特别是 filter 和 exclude-filter 参数，它将节点管理从手动分类提升到了自动化筛选，极大地简化了拥有大量节点的用户的配置工作，是 Mihomo 核心能力的关键体现。

参数	必填项	描述	示例值
name	是	代理提供者的唯一名称	my-proxy-provider
type	是	提供者类型	http（远程URL）或 file（本地文件）
url	type: http时必填	远程代理列表的 URL	“https://example.com/sub.yaml”
path	type: file时必填	本地代理列表的路径	”./local-proxies.yaml”
interval	否	自动更新间隔，单位秒	3600
filter	否	筛选节点名称的正则表达式	(?i)日本	jp
exclude-filter	否	排除节点名称的正则表达式	(?i)已用尽

第三章：策略组：流量路由的核心编排（Proxy-Groups）

proxy-groups 是 Mihomo 配置文件中负责流量调度和代理选择的“大脑”。它将 proxies 节中定义的代理节点组织成具有特定行为的策略组，并由 rules 节中的规则引用。这种设计将“代理”与“策略”解耦，使得配置更加灵活和易于管理。

3.1 策略组类型与核心功能

Mihomo 提供了多种内置的策略组类型，每种类型都旨在解决特定的网络问题：

select (手动选择)：这是最基本的策略组类型，它向用户呈现一个可选的代理节点列表。用户可以通过 Mihomo 的仪表盘（如 Yacd）手动切换和选择最合适的节点。
url-test (自动测速)：该类型定期对组内所有代理节点进行健康检查和延迟测试，并自动选择延迟最低的可用节点。这对于追求低延迟的用户体验至关重要，是很多日常配置中的“自动选择”组的基础。
fallback (故障转移)：fallback 策略组按顺序测试列表中的代理节点，当当前节点连接超时或失败时，它会自动切换到列表中第一个可用的节点。这为高可用性场景提供了保障，确保当首选节点失效时，服务能自动切换到备用节点，避免网络中断。
load-balance (负载均衡)：此策略组根据不同的算法在多个代理节点之间分发流量，以分摊负载、提升整体性能。它支持 round-robin（轮询）和 consistent-hashing（一致性哈希）等策略，其中一致性哈希可以确保同一目标地址的请求始终被路由到同一个节点，有助于保持会话一致性。
relay (中继)：此类型用于构建链式代理，即流量经过多个代理节点的中转。但文档已明确指出此类型正在被弃用，并推荐使用 dialer-proxy 作为替代方案。

所有策略组都共享一系列用于健康检查的通用字段，如 url（测试地址）、interval（测试间隔）、timeout（超时时间）和 max-failed-times（最大失败次数）。这些参数允许用户精细化配置代理节点的存活判断逻辑。

策略组的设计将“节点”和“如何使用节点”解耦。它将一组代理节点从一个简单的列表，提升为具有智能调度能力的策略实体。这不仅为用户提供了应对不同网络需求的工具，也使配置结构更清晰。

值得注意的是，routing-mark 和 interface-name 等参数已从 proxy-groups 中移除，并建议直接在代理节点中配置。这一变化表明 Mihomo 的核心设计正在向更细粒度的配置控制演进，即代理节点是配置的最小单元，而策略组只负责选择和调度这些节点，从而避免了配置上的歧义。

类型	决策逻辑	典型应用场景	配置示例
select	手动选择列表中的一个节点	日常使用，灵活切换不同地区的节点	`proxies: [节点1, 节点2]`
url-test	自动选择延迟最低的可用节点	对延迟敏感的场景，如游戏或实时通信	`url-test: {proxies: [节点1, 节点2], url: '...', interval: 300}`
fallback	顺序选择第一个可用的节点	高可用性场景，确保主节点失效后自动切换	`fallback: {proxies: [主节点, 备用节点], url: '...', interval: 300}`
load-balance	根据策略分发流量	需要分摊流量的场景，或保持会话一致性	`load-balance: {proxies: [...], strategy: round-robin}`

第四章：流量分流：精细化路由规则（Rules & Rule-Providers）

4.1 规则匹配机制与优先级：理解规则引擎

rules 是 Mihomo 流量分流的核心，它定义了流量如何根据不同的条件被路由到特定的策略组。规则的匹配机制遵循自上而下的原则，即配置文件中排在前面的规则具有更高的优先级。当流量到达时，Mihomo 会从头到尾遍历规则列表，一旦有规则被匹配，就会立即执行相应的策略（如 DIRECT, PROXY, REJECT 等），而忽略后续的所有规则。因此，配置时应将最具体、最优先的规则放在最前面，而将通用或兜底的规则放在最后，例如 MATCH 规则总是应该位于列表的末尾。

在规则中，no-resolve 选项是一个重要的性能优化和安全考量。它用于指示 Mihomo 在处理 IP 相关规则时跳过 DNS 解析。当流量匹配一个 DOMAIN 规则时，Mihomo 会先进行 DNS 解析以获取目标 IP，如果后续规则是基于 IP 的（如 GEOIP），则可以利用之前解析得到的 IP 信息，而无需再次进行解析。no-resolve 的存在使得用户可以灵活控制解析行为，尤其是在处理大型 IP 规则集时，可以显著提高匹配效率。

4.2 核心规则类型详解与示例

Mihomo 提供了丰富的规则类型，以支持各种精细化的流量分流需求：

DOMAIN 家族：
- DOMAIN,ad.com,REJECT：精确匹配域名 ad.com
- DOMAIN-SUFFIX,google.com,auto：匹配域名后缀为 google.com 的所有域名，如 www.google.com 或 mail.google.com
- DOMAIN-KEYWORD,google,auto：匹配包含关键字 google 的域名
IP 家族：
- IP-CIDR,127.0.0.0/8,DIRECT：匹配 CIDR 格式的 IP 地址段
- GEOIP,CN,DIRECT：根据 IP 所属的国家代码进行匹配，例如 CN 代表中国
- GEOSITE,youtube,PROXY：引用 geosite 数据库中预定义的域名集合，如所有与 youtube 相关的域名，并将其流量路由到 PROXY 策略组

GEOSITE 和 GEOIP 规则的有效性依赖于外部维护的 geodata 数据库文件，这使得 Mihomo 的功能深度与其社区生态系统紧密相连。

逻辑规则：
- AND, OR, NOT 等逻辑运算符可以组合多个规则，创建复杂的匹配条件。例如，AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT 规则要求流量同时满足域名为 baidu.com 和网络协议为 UDP 这两个条件才生效。在使用这些规则时，必须注意括号的正确使用。

4.3 规则动态管理（Rule-Providers）

与 proxy-providers 类似，rule-providers 机制允许用户通过远程 URL 或本地文件来动态管理和更新大型规则集。这极大地提高了配置文件的可读性和可维护性，尤其是在规则数量庞大或需要频繁更新时。

配置 rule-providers 需要指定 type（http, file 或 inline）和 behavior（domain, ipcidr 或 classical）。behavior 参数用于告诉 Mihomo 规则文件内部的格式。例如，domain 行为对应的是只包含域名通配符的规则文件，而 classical 则可以包含所有类型的规则。当 type 为 http 时，用户必须提供 url 和 interval 参数，让 Mihomo 自动下载和更新规则文件。

rule-providers 的引入解决了大型规则集维护的痛点。它将规则的内容（即规则文件本身）与使用（即 rules 节中的引用）解耦。用户可以将一些常用的、不常变动的规则直接写在 config.yaml 中，而将那些由社区维护、需要频繁更新的规则集（如广告拦截、GFW 列表）通过 rule-providers 动态引入。这种设计不仅提高了运维效率，还使得 Mihomo 的功能深度依赖于其开放的社区生态，社区的集体智慧能够高效地维护和更新规则集，从而将复杂的规则管理工作从个人转移到社区。

第五章：DNS 配置：流量劫持与防污染（DNS Section）

Mihomo 的 DNS 配置是其实现精细化流量分流和应对 DNS 污染的关键。dns 节不仅提供基础的 DNS 服务，还通过先进的模式和智能过滤机制，从根本上解决 DNS 相关的问题。

5.1 基础配置与高级模式选择

要启用 Mihomo 的内置 DNS 服务，需要将 enable 设置为 true，并指定监听地址，例如 listen: 0.0.0.0:1053。其核心功能在于 enhanced-mode 参数，它提供了两种流量处理模式：

fake-ip：此模式下，Mihomo 会充当一个权威 DNS 服务器，将所有需要代理的域名解析为一个虚拟 IP 地址，这些地址通常来自 fake-ip-range 参数配置的私有网段，例如 198.18.0.1/16。当客户端连接到这些虚拟 IP 时，Mihomo 会在内部根据原始域名将流量路由到相应的代理节点。这种机制从根本上绕过了外部 DNS 污染，但缺点是某些依赖真实 IP 地址进行连接的应用可能会出现兼容性问题。为了解决这个问题，用户可以利用 fake-ip-filter 参数配置域名白名单或黑名单，让这些域名不被 fake-ip 模式处理。
redir-host：这是 Mihomo 的默认模式，它更接近传统的 DNS 代理行为。在此模式下，Mihomo 会将域名解析请求直接发送给上游 DNS 服务器，并根据解析结果的 IP 地址进行路由。这种模式的兼容性更好，但在面对 DNS 污染时效果不如 fake-ip。

这两种模式各有优劣，用户应根据自身需求选择。对于注重抗污染能力但能容忍部分兼容性问题的用户，fake-ip 是更先进的选择；而对于追求最大兼容性的用户，redir-host 则更为稳妥。

5.2 多层级 DNS 服务器配置与智能过滤

Mihomo 的 DNS 解析流程是多层级的，旨在提供智能且抗污染的解析能力。这个流程的核心是 nameserver、fallback 和 nameserver-policy。

nameserver：定义了默认的 DNS 解析服务器，通常配置为国内的 DoH（DNS over HTTPS）或 DoT（DNS over TLS）服务，以确保国内网站的快速访问。
fallback：定义了备用的 DNS 解析服务器，通常配置为海外的无污染 DNS 服务，如 8.8.4.4。Mihomo 会并发地使用 nameserver 和 fallback 进行查询，并利用 fallback-filter 来判断结果是否被污染。
nameserver-policy：这是优先级最高的 DNS 配置。它允许用户为特定域名或规则集指定专用的 DNS 服务器。例如，可以将所有与 apple 相关的域名强制通过一个海外 DNS 解析，以确保访问的正确性。

fallback-filter 是 Mihomo 智能 DNS 的核心。它通过一系列规则来筛选 DNS 结果，并判断是否需要采纳 fallback 服务器的结果。

fallback-filter 的子选项包括：

geoip：当主 nameserver 解析出的 IP 不属于 geoip-code 指定的国家（默认为 CN）时，该结果会被视为污染，并转而使用 fallback 的结果。
geosite：如果域名匹配 geosite 中定义的集合（如 gfw），则会直接使用 fallback 解析。
ipcidr 和 domain：允许用户自定义 IP 段或域名黑名单，这些地址或域名被解析时也会直接使用 fallback。

Mihomo 在处理代理节点本身的域名解析时，还会遇到一个被称为“鸡蛋问题”的特殊情况。代理服务需要先解析代理节点的域名才能建立连接，但如果域名解析本身也需要经过代理，就会形成死循环。Mihomo 通过 proxy-server-nameserver 参数解决了这个问题，它专门用于解析代理节点的域名，确保这部分流量可以被正确处理。

第六章：实践案例：灵活调优与故障排查

6.1 案例一：针对流媒体服务的高效分流配置

场景：用户希望国内流量直连，海外流媒体（如 Netflix、YouTube）走代理，且追求低延迟。

配置思路：

代理节点 (proxies)：配置多个位于不同地区（如香港、日本、美国）的低延迟代理节点。
策略组 (proxy-groups)：创建一个名为 Streaming 的 url-test 策略组，并将所有流媒体代理节点放入其中。配置一个可靠的流媒体测试 URL（如 https://www.gstatic.com/generate_204），以便 Mihomo 自动选择延迟最低的节点。
分流规则 (rules)：在规则列表的靠前位置，使用 GEOSITE,youtube,Streaming 和 GEOSITE,netflix,Streaming 等规则，将流媒体服务的域名集合精确地分流到 Streaming 策略组。
兜底规则 (rules)：在规则列表的末尾，添加 GEOIP,CN,DIRECT 确保国内流量直连，最后以 MATCH,Streaming 作为最终的兜底规则，确保未匹配的流量也能够通过代理。

6.2 案例二：应对复杂网络环境的 DNS 优化

场景：用户发现访问某些海外网站时，因 DNS 污染导致解析失败或被劫持。

配置思路：

DNS 模式 (dns)：启用 dns: enable: true，并将 enhanced-mode 设置为 fake-ip，以从根本上避免 DNS 污染。
DNS 服务器：配置一个国内 nameserver 和一个海外 fallback，并开启 fallback-filter。
兼容性处理：如果遇到不兼容 fake-ip 的应用或域名，将其添加到 fake-ip-filter 列表中，让 Mihomo 对这些域名使用正常的 DNS 解析流程。
策略性解析：使用 nameserver-policy，针对特定敏感域名（如 twitter.com）强制使用海外 fallback DNS 进行解析，以确保解析结果的纯净性。

6.3 案例三：组合使用 Providers 构建大型配置

场景：用户拥有多个订阅服务和大型规则文件，希望实现高度自动化的管理，以减少手动维护工作。

配置思路：

节点管理 (proxy-providers)：配置多个 proxy-providers，每个对应一个订阅链接。使用 filter 和 exclude-filter 参数，通过正则表达式按国家/地区（如“日本”、“美国”）或类型（如“Shadowsocks”）自动对节点进行分类和分组。
策略组 (proxy-groups)：利用 proxy-providers 的成果，创建多个策略组。例如，可以创建一个 url-test 类型的 Auto 组，利用 include-all-providers: true 将所有节点动态导入，并自动选择最佳节点。同时，也可以创建 select 类型的 Manual 组，让用户可以手动选择节点。
规则管理 (rule-providers)：配置一个或多个 rule-providers，其 type 为 http，behavior 为 classical，并指向一个远程的规则集 URL。
最终规则 (rules)：在主 rules 节中，通过 RULE-SET,providername,proxy 的形式引用 rule-providers 中定义的规则集，最后用 MATCH 规则进行兜底。

这种配置方式将节点的动态管理、策略组的智能调度和规则集的集中更新完美结合，实现了配置的高度自动化和可维护性。

第七章：结论与展望

Mihomo 的 config.yaml 配置文件不仅仅是一个简单的参数列表，它是一个由多个模块化、分层级配置节构成的流量控制框架。其配置哲学在于将代理节点、策略组和规则进行解耦，通过 proxy-providers 和 rule-providers 机制实现动态管理。这使得用户能够以极高的灵活性，根据自身需求构建出从基础分流到复杂网络优化等各种配置。

报告的分析表明，Mihomo 的设计在易用性、性能和安全性之间进行了多维度的考量。mixed-port 等简化配置的选项降低了入门门槛，而对 Hysteria2 等现代协议的支持则体现了对性能和抗审查性的追求。同时，bind-address、authentication 和 secret 等参数则为不同应用场景下的安全需求提供了保障。

未来的 Mihomo 发展，很可能会继续围绕性能优化（如新的传输协议）和抗审查性（如更高级的 TLS 伪装技术）展开。对 config.yaml 背后设计思想的理解，将帮助用户在面对未来的配置变更时，能够举一反三，灵活变通，而不仅仅是照搬示例。掌握配置文件的模块化、分层级和动态化的精髓，是真正成为 Mihomo 高级用户的必由之路。