mihomo wiki 怎么用？从配置校验到连接排错
简答：mihomo wiki 主要用于查配置字段和排查运行问题，不是一个单独的下载包。最稳妥的做法是：先确认资料页面，再按设备选择 Release 文件，准备配置并校验，最后从端口、代理组、DNS 和 TUN 逐层确认连接状态。本文是第三方使用指南，不代表任何项目的官方页面。
定义：mihomo 是负责接收流量、加载节点与规则并执行代理策略的核心程序，客户端负责管理它，配置文件负责告诉它监听什么、使用哪些节点以及如何处理请求。
先做四步速查：不要把 Wiki、Release 和客户端混为一谈
搜索 mihomo wiki 时，最容易遇到的问题不是不会写 YAML，而是打开了错误类型的页面。先按任务分层，再开始配置。
| 你要完成的事 | 优先查看 | 完成判据 |
|---|---|---|
| 查字段和配置结构 | 配置资料 | 能找到对应字段的类型、可选值和示例 |
| 下载核心文件 | GitHub Releases | 系统、CPU 架构和文件格式相互匹配 |
| 确认历史 Wiki 状态 | GitHub Wiki 页面 | 页面是否提示内容已转移，以及转移到哪里 |
| 管理核心和策略组 | 图形客户端或 Dashboard | 核心已经运行，配置已经加载，策略组能够显示节点 |
| 读取运行状态 | API 资料 | 当前配置中的控制地址可访问，且认证设置正确 |
- 先打开当前配置资料，确认字段名称和可选值。
- 再打开 Releases，按系统与架构选择文件，不依据搜索摘要中的旧版本号下载。
- 准备一份脱敏后的配置文件，先做格式校验，再启动核心。
- 最后确认代理端口、策略组、DNS 和规则是否真的让请求成功。
截至 2026 年 11 月 9 日，Release 页面仍属于动态页面，具体版本号、预发布状态和资产列表应以页面当时显示内容为准，本文不写死某个版本。
mihomo、客户端、配置文件和 Dashboard 分别负责什么
mihomo 核心：负责读取配置、建立代理连接、执行规则、处理 DNS，并对外提供代理端口或控制 API。
图形客户端：负责安装、启动、切换配置、选择策略组和展示日志。客户端菜单不一定覆盖核心支持的全部字段，因此看到核心资料中有某个字段，并不代表所有客户端都有对应开关。
配置文件：通常是 YAML 文件，负责组合端口、节点、代理组、规则、DNS、Provider 和可选的 TUN。配置能被读取，只代表文件路径或格式没有立即出错。
Dashboard：通常通过控制 API 查看核心运行状态、策略组和节点信息。控制地址、认证方式和是否允许跨域，都以当前配置为准；不要把控制接口直接暴露到公网，也不要公开 secret。
GitHub Wiki 页面当前显示内容已转移到资料站；但资料页面本身可能随内容维护而变化，遇到页面内容异常或与当前核心不一致时，应以仓库 Release、配置页面和当前程序日志交叉核对。
配置文件怎么开始：先用最小结构，不要一次启用所有功能
首次排查建议只保留一个已核验节点、一个代理组、一条兜底规则和一个普通代理端口。下面的结构只用于理解字段关系，不包含真实节点、账号或订阅地址。
mode: rule
mixed-port: <替换为未占用端口>
allow-lan: false
log-level: info
proxies:
- name: "示例节点"
type: <按节点资料填写>
server: <按节点资料填写>
port: <按节点资料填写>
proxy-groups:
- name: "PROXY"
type: select
proxies:
- "示例节点"
- DIRECT
rules:
- MATCH,PROXY
这段结构的关键关系是：节点先在 proxies 中定义，代理组通过名称引用节点，规则再把请求交给代理组。节点名称、代理组名称和规则中的名称必须保持一致。代理组的 use 用于引用 Proxy Provider，具体写法应对照代理组资料。
校验方式不要凭网上文章硬套。先运行当前二进制的帮助命令，确认它支持的配置检查参数；如果当前构建提供配置测试选项，再执行该选项。校验通过只说明配置可以解析，不代表节点可用、端口已监听或网页请求一定成功。
建议按以下顺序判断：文件能读取 → YAML 能解析 → 核心已启动 → 端口正在监听 → 代理组有可选节点 → 规则命中正确 → DNS 能解析 → 实际请求成功。
订阅 URL、Proxy Provider 和本地 YAML 有什么区别
| 对象 | 作用 | 常见误区 |
|---|---|---|
| 订阅 URL | 从某个地址获取配置或节点内容 | 把 URL 当成本地配置文件，或把完整链接公开提交 |
| Proxy Provider | 由主配置引用并更新节点集合 | Provider 更新成功，就以为策略组已经引用它 |
| 本地 YAML | 组合端口、Provider、代理组、DNS 和规则 | 只有节点或 Provider，没有规则和策略组 |
Proxy Provider 的字段应以当前配置资料为准。配置中常见的关系是：Provider 负责取得节点，代理组通过 use 或其他引用方式使用 Provider，规则再把请求交给代理组。如果节点在 Provider 中存在，但策略组为空，应检查引用名称、过滤器、排除类型、文件路径以及 Provider 内容是否真的包含可解析节点。
安全排查时只保留脱敏信息：隐藏订阅令牌、账号、密码、认证请求头和私钥。可以记录响应状态码、是否超时以及返回内容类型，但不要上传完整订阅链接或完整响应。
DNS、普通代理端口和 TUN：按故障现象逐层排查
mihomo 支持多种入站方式，包括普通代理端口、TUN 和 listeners。入站配置资料说明了不同方式的适用范围。首次排查建议先使用普通代理端口，确认核心和节点工作后，再启用 TUN。
| 现象 | 先检查 | 如何判断 | 恢复方式 |
|---|---|---|---|
| YAML 报错 | 缩进、冒号、引号、列表层级 | 核心在加载阶段退出 | 删除最近增加的字段，分段恢复 |
| 订阅无法解析 | 响应状态、返回格式、令牌和有效期 | 返回的不是预期 YAML 或节点内容 | 核对来源页面，保留脱敏后的状态信息 |
| 节点为空 | Provider 更新、路径、过滤器和代理组引用 | Provider 有记录但策略组没有成员 | 暂时关闭过滤器，确认 Provider 名称完全一致 |
| 核心运行但打不开网页 | 代理端口、策略组、规则和 DNS | 日志正常但请求没有成功 | 先用单节点和普通代理端口测试 |
| TUN 不生效 | 系统权限、路由、防火墙和 DNS 劫持 | 普通代理可用，系统流量没有进入核心 | 关闭 TUN 回滚，再按当前系统资料逐项启用 |
DNS 字段不要整段复制。当前资料区分了 nameserver、fallback、proxy-server-nameserver、direct-nameserver 和策略字段，它们处理的解析场景不同。先保持结构简单，再根据“域名无法解析”“节点域名无法解析”或“直连与代理解析结果不一致”等具体现象增加设置，可参考DNS 配置资料。
TUN 的协议栈、DNS 模式、自动路由和系统权限会受到平台及客户端实现影响。不要直接复制旧文章中的 stack、MTU 或 DNS 劫持值；先查看当前 TUN 页面和客户端支持情况。若启用后出现断网，先关闭 TUN，恢复普通代理端口，再一次只修改一个字段。
用 API 只做本机状态确认
如果配置了控制 API，可以用它确认核心版本、运行配置、代理组和 Provider 状态。当前 API 资料列出了 /version、/configs、/proxies 以及 Provider 相关接口，但实际访问地址并不是所有安装方式都固定相同。
排查时先读取当前配置中的控制地址，再确认是否需要 secret。不要把控制地址绑定到不必要的公网网卡，也不要在截图、日志或工单中展示 secret。API 返回“核心运行中”仍不等于网页请求成功，还要结合代理组状态、规则命中和 DNS 结果判断。
完成配置后建议做一次回滚测试：备份当前 YAML，关闭 TUN、复杂 DNS 和 Provider 过滤器，只保留一个节点和一个代理组。普通代理请求成功后，再按 TUN、DNS、规则和自动选择策略的顺序逐项恢复。
常见问题 FAQ
mihomo wiki 和 GitHub Releases 是同一个东西吗？
不是。Wiki 或配置资料用于查字段和行为，Releases 用于查看发布标签和下载资产，客户端则负责启动和管理核心。三者解决的问题不同。
为什么配置校验通过，网页还是打不开？
配置校验主要检查文件是否能被解析，不能证明节点可用、代理组已选择、规则命中正确或 DNS 正常。请依次确认核心进程、代理端口、策略组、规则、DNS 和目标请求。
Provider 已经更新，为什么策略组里没有节点？
检查代理组是否引用了正确的 Provider 名称，再检查过滤器、排除类型、文件路径和 Provider 返回内容。Provider 存在不代表它已经被代理组使用。
可以直接复制网上的 TUN 配置吗？
不建议。TUN 会受到系统权限、路由、防火墙、DNS 和客户端实现影响。先关闭 TUN 验证普通代理，再根据当前资料逐项增加设置，并保留关闭 TUN 的回滚路径。
如何检查订阅而不泄露权限？
只检查脱敏后的域名、响应状态和返回格式。令牌、账号、密码、认证请求头和完整响应内容不要提交给不必要的第三方服务。
如何判断问题来自 mihomo 核心还是客户端？
先查看客户端日志和核心是否启动，再用同一份配置在独立核心或另一种管理方式中做最小测试。若核心和配置均正常，而客户端无法切换策略或端口，问题更可能位于客户端管理层；最终仍应以当前日志为准。
参考资料与下一步
本文只提供配置识别、字段核对和连接排查方法，不提供未经核实的版本排名、价格、测速或服务状态。相关字段发生变化时，应以当前资料页面和 Release 页面为准。
可继续阅读站内的mihomo 内核与客户端区别、仓库、Release 与下载文件核验指南、订阅配置导入失败排查和连接成功但打不开网页排查。
参考资料：GitHub Wiki 页面、GitHub Releases、配置资料、入站配置资料、DNS 配置资料、API 资料。
常见问题
mihomo wiki 和 GitHub Releases 是同一个东西吗？
不是。Wiki 或配置资料用于查字段和行为，Releases 用于查看发布标签和下载资产，客户端负责启动和管理核心。
为什么配置校验通过，网页还是打不开？
配置校验主要检查文件是否能被解析，不能证明节点、代理组、规则或 DNS 正常。请依次确认核心进程、代理端口、策略组、规则和 DNS。
Provider 已经更新，为什么策略组里没有节点？
检查代理组是否引用了正确的 Provider 名称，再检查过滤器、排除类型、文件路径和 Provider 返回内容。
可以直接复制网上的 TUN 配置吗？
不建议。TUN 会受到系统权限、路由、防火墙、DNS 和客户端实现影响。先验证普通代理，再按当前资料逐项启用。
如何检查订阅而不泄露权限？
只检查脱敏后的域名、响应状态和返回格式，不要提交令牌、账号、密码、认证请求头或完整响应内容。