Clash Meta 全平台安装配置大全

通用准备：订阅、内核与配置边界

先区分客户端、内核与订阅

客户端负责配置管理、界面操作、权限申请与系统集成；mihomo 内核负责监听端口、解析规则、选择出站并转发连接。订阅提供节点或完整配置，安装客户端本身不会自动产生可用的代理服务。开始前应确认已有合法可用的订阅，能够访问订阅来源，并知道它提供的是完整配置还是仅包含节点的列表。

完整配置通常包含代理节点、策略组、规则和 DNS 设置；节点列表需要客户端的配置模板补齐其余部分。两者都可能以 YAML 返回，不能只看文件后缀判断。若导入后有节点却没有可选择的策略组，先检查导入方式和模板，不要直接修改节点服务器地址。网页订阅管理地址也不等于订阅接口地址，应复制服务提供方明确标注的客户端订阅链接。

订阅链接往往具有账户访问能力，应按敏感信息保存。不要贴入公共转换网站、截图或问题讨论区；分享配置前删除节点密码、订阅地址和控制接口密钥。确认泄露后，应在订阅来源重新生成链接。排错截图只保留必要的错误类型、配置段名和脱敏域名，完整日志也应先检查再发送。

建立可以回退的测试环境

安装前记录操作系统版本、处理器架构、当前网络以及已有的代理或 VPN 软件。首次测试先关闭其他接管流量的程序，保留一套清晰的网络路径。企业设备可能受管理策略限制，不能用授予更高权限的方式绕过组织要求。需要管理员权限的服务安装、虚拟网卡与路由修改，应在明确作用后再执行。

先在默认规则模式下启用系统代理，验证浏览器访问，再按实际需要增加 TUN。这样出现异常时能判断问题来自基础出站还是流量接管。保存一份可以正常使用的配置副本，并记录原系统代理状态；每次只改一个配置段。直接覆盖所有 DNS、规则和路由参数，会让后续日志失去可比较的基线。

先确认配置可解析，再确认能够连接

下面是仅直连的最小诊断配置，用于验证 mihomo 能否启动和监听本机端口，不包含代理节点，也不能代替订阅。混合端口同时提供 HTTP 与 SOCKS 入口；关闭局域网访问可将监听范围限制在本机。已有客户端占用相同端口时，应停止其中一个实例，或为测试实例选择其他空闲端口。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

运行内核的配置检查命令，只能证明语法与部分引用关系能够通过检查，不能证明订阅中的服务器可达。图形客户端可能生成实际运行配置，因此检查对象应是内核最终加载的文件，而不一定是订阅缓存。日志出现缩进或未知字段错误时，从提示的配置位置向前检查，注意上一行也可能是原因。

mihomo -t -f config.yaml

YAML 使用空格缩进，不混用制表符。规则中的策略名称必须与已定义的策略组或节点名称一致，大小写和空格也要对应。远程规则集、节点提供器和地理数据库还需要能够下载；完整配置即使成功加载，也可能因这些依赖不可用而表现异常。排错时应区分配置解析成功、资源加载成功与请求转发成功这三个阶段。

Windows：安装、系统代理与服务权限

选择安装包并完成首次启动

从Windows 客户端入口选择 Clash Plus，其他选项依次包括 Clash Verge Rev、FlClash 与 Clash Nyanpasu。Clash for Windows 已停止维护，归档包主要用于理解旧环境，不宜作为新部署的默认选择。先在系统信息中确认处理器与系统类型，再核对下载页提供的架构和系统要求，不要把其他平台的安装包当作兼容包使用。

安装完成后先正常启动客户端，不必一开始就以管理员身份运行整个界面。若客户端需要安装服务组件，应通过其服务管理入口执行并确认系统授权。受限账户无法安装服务时，可先用系统代理验证基本连接；服务安装失败与订阅不可用是两类问题，不能通过反复重新导入订阅解决。

如果系统安全提示阻止运行，应核对下载来源、文件属性和组织安全策略，再决定如何处理。不要为启动某个客户端而长期关闭系统安全功能。安装目录、配置目录和内核运行目录也不是同一位置；迁移旧配置时应使用客户端的导入功能，避免将旧内核或缓存目录整体覆盖到新安装中。

导入订阅并选定当前策略

进入配置管理页面，新增远程订阅，粘贴完整链接并保存。等待下载完成后，明确选择这份配置为当前配置，再检查代理页面是否出现策略组。如果订阅使用重定向或需要特定访问条件，失败日志可能是网络错误而非 YAML 错误；先确认响应内容，不要把返回的登录页面当作配置文件继续导入。

在主要代理策略组中选择一个可用节点，运行客户端提供的连通性或延迟测试。测试成功只说明测试请求能够完成，不代表所有网站、UDP 或终端都已接管。自动选择组还可能在稍后切换出站；排错阶段可以先固定一个节点，观察同一目标的结果，再恢复自动选择，避免多个变量同时改变。

启用规则模式后，打开系统代理开关，并在 Windows 的网络代理设置中核对地址和端口是否与客户端一致。混合端口、控制接口端口和订阅地址不能互换。系统代理通常是当前用户的设置，其他用户会话、系统服务以及部分独立应用不一定遵循它，因此浏览器可用不能证明整台设备的流量都经过内核。

命令行与 TUN 分开验证

终端工具可能读取环境变量，也可能要求显式指定代理。下面的命令只对这一次请求指定本机代理；端口必须与实际运行配置一致。先使用它确认代理入口，再决定是否为终端设置环境变量。长期保存变量前，应了解工具对大小写变量、代理协议和例外列表的支持，避免关闭客户端后终端仍尝试连接旧端口。

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

需要覆盖不读取系统代理的程序时，再启用客户端的 TUN 模式。先确认服务状态正常，授权创建虚拟网络接口，并观察内核日志是否报告接口或路由错误。使用自动路由时要特别检查企业内网、局域网打印与其他 VPN 的访问；出现冲突应调整排除路由或接管范围，而不是同时打开更多网络加速工具。

TUN 开关打开后仍无法连接，先关闭 TUN，保留系统代理复测。如果浏览器随即恢复，重点检查虚拟接口、默认路由、DNS 和其他 VPN；若两种方式都失败，则回到节点与配置检查。休眠恢复或切换网络后出现的问题，也应按这一对照方式处理，先观察接口状态，再考虑重启内核或服务。

退出、更新与系统代理残留

Windows 上点击窗口关闭按钮可能只是缩到托盘，不能据此判断内核已经停止。准备卸载或切换客户端时，先关闭系统代理与 TUN，再从托盘正常退出。若异常结束后浏览器仍连接本地代理，应检查系统代理设置是否残留；恢复原状态后再启动客户端，不要将关闭软件后无法上网直接归因为订阅失效。

更新前导出自定义规则和覆写设置，更新后核对当前配置、策略组选择与服务状态。旧服务可能仍占用端口，也可能指向已经移动的内核路径。出现端口冲突时，在任务管理器或客户端日志中确认占用来源，只保留一个预期实例。浏览器与终端的进一步分支可查阅系统代理不生效排查。

macOS：架构、网络服务与后台组件

按处理器安装客户端

进入macOS 下载入口，优先选择 Clash Plus，也可按使用习惯选择 Clash Verge Rev 或 FlClash。ClashX Meta 已停止维护，归档用途与持续维护的客户端应分开考虑。在关于本机中确认是 Apple Silicon 还是 Intel，再选择对应安装包。能够通过兼容层运行不等于所有后台组件和虚拟网卡依赖都与当前系统匹配。

如果安装包以磁盘映像提供，挂载后将应用移入应用程序目录，再从该目录启动，不要长期从映像内部运行。启动前确认下载来源，遇到系统安全提示时按系统提供的应用打开流程处理，不使用关闭整套安全检查的命令。已经安装过旧客户端时，先正常退出旧实例，避免多个状态栏程序同时修改代理设置。

客户端申请辅助工具、后台服务或网络权限时，应核对请求的应用与当前操作是否一致。某些功能通过特权辅助程序设置路由，普通代理界面则不需要持续以高权限运行。授权被拒绝后，应检查客户端提供的服务状态和系统设置中的相关项目，不要反复点击连接按钮来代替权限诊断。

订阅导入与网络服务核对

在配置页面添加订阅，等待解析完成后将其设为当前配置。接着在代理页面检查主要策略组，先固定一个节点进行请求测试。迁移其他客户端的配置时，特别核对相对路径、规则集缓存和提供器文件；原客户端已经下载过的文件不一定会随导入一起迁移，新客户端仍需要重新获取依赖。

启用系统代理后，检查当前正在使用的网络服务。macOS 可以同时保存 Wi-Fi、以太网以及其他接口的设置，客户端修改的服务不一定与当前实际出网接口相同。切换扩展坞、有线网卡或网络位置后，应重新核对，而不是仅观察状态栏图标。系统代理地址应指向本机监听端口，不能填控制接口地址。

可先运行下面的只读命令查看系统当前代理配置，再使用显式代理请求作对照。输出中存在代理信息并不代表应用一定遵循它；浏览器扩展、独立应用设置和终端环境变量都可能形成另一条路径。排错时分别记录系统设置与应用设置，避免只修改其中一处却期待所有程序立即改变。

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

TUN 与其他网络扩展的边界

需要接管不读取系统代理的应用时，再启用 TUN，并确认客户端的后台组件已正常安装。不同客户端的安装与授权方式不同，应以其当前提示为准。启动后查看接口与路由相关日志，确认不是只有界面开关变化。若同时运行企业 VPN、网络过滤工具或另一套代理客户端，应先了解它们的路由接管范围。

局域网访问异常时，先检查目标是否在本地网段，以及该请求实际命中了什么规则。系统代理绕过列表只影响读取该设置的程序，不能直接代替 TUN 的路由排除或内核规则。对公司域名与内网地址，应保留所需的 DNS 和直连路径；不要把所有私有地址访问都归因于节点故障。

合盖、休眠恢复或从 Wi-Fi 切换到有线网络后，旧连接可能仍绑定先前的网络路径。先重新发起目标请求，再观察是否出现新的连接记录。必要时重新连接客户端或重启内核，但不要直接删除全部配置。若只有旧页面失败，新建连接正常，问题更可能在连接复用与网络切换，而不是订阅本身。

终端环境与卸载恢复

终端的代理环境变量只作用于相应进程及其子进程，不会自动改变整个系统。不要在不知道已有变量用途时覆盖 shell 配置。需要长期设置时，应同时保留清除方法，并为内网目标设计适当例外。图形界面启动的应用也不一定继承终端环境，因此终端可用和浏览器可用应分别验证。

卸载前先关闭系统代理、TUN 和登录时启动选项，再按客户端提供的方法移除辅助服务。直接将应用拖入废纸篓可能留下后台组件或旧代理设置。迁移到新客户端后，确认活动监视器里没有旧内核继续运行，检查当前端口、配置与实际出站。需要了解两种接管方式的原理，可阅读TUN 与系统代理的逐层对比。

Android：VPN 授权、应用分流与后台运行

安装前确认架构与配置兼容性

从Android 下载入口优先选择 Clash Plus，其他选项包括 Clash Meta for Android、FlClash 与 Surfboard。先核对设备架构及客户端最低系统要求，再安装相应软件包。安装包来源授权应限制在本次需要的浏览器或文件管理器，完成后可恢复原设置；企业管理设备还应遵守其应用安装政策。

客户端属于同一代理生态，不代表配置格式完全相同。Clash Plus、Clash Meta for Android 与 FlClash 的具体支持范围也应以各自实现为准；Surfboard 使用不同的配置体系，不能把任意 mihomo 完整配置原样导入后就期待所有规则生效。订阅来源提供多种格式时，应选择明确适配目标客户端的格式。

从旧应用迁移时，先导出需要保留的自定义设置，再安装新应用。Android 通常不允许包名不同的应用直接覆盖安装，卸载原应用也可能删除其私有配置与缓存。不要只依赖剪贴板保留订阅；应在可信位置保存导入信息，并确认新客户端可以加载配置后再移除旧环境。

导入订阅与建立 VPN 连接

进入配置列表，添加远程订阅并等待下载完成，然后选择该配置作为活动配置。先检查策略组是否出现、节点是否能够测试，再点击启动。首次运行通常会出现系统 VPN 授权对话框；授权的含义是允许应用建立本地流量接管通道，不等于系统已经确认远端节点可靠，也不表示所有应用请求都经过代理出站。

Android 一般同一用户空间同时只能有一个活动 VPN 服务。其他 VPN、防火墙或基于本地 VPN 的过滤工具可能与客户端冲突，表现为连接被替换、刚启动就断开或某个应用失去网络。测试时先停用冲突程序，只保留一个接管入口。工作资料与个人资料可能具有不同限制，应分别检查实际运行位置。

移动端的 VPN 接管与桌面系统代理不是同一种设置。通常不需要再到 Wi-Fi 页面手工填写代理；叠加一个指向本机的 Wi-Fi 代理，反而可能形成难以追踪的路径。系统显示 VPN 已连接，也只能证明隧道服务存在，仍应通过连接日志核对请求命中的规则、策略组及实际出站。

应用分流先确认列表语义

启用按应用分流前，确认列表表示仅代理选中应用，还是绕过选中应用。两种模式的相同勾选结果可能具有相反含义。先用一个浏览器做测试，关闭已有页面并发起新连接，再观察日志。列表改变后，部分客户端需要重建 VPN 才能应用，不能只看勾选状态判断系统接管范围已经更新。

应用列表决定哪些流量进入客户端，规则决定进入之后走什么策略，这两层不能互相替代。被排除的应用通常不会再经过内核规则评估；被纳入的应用也可能因为规则命中直连而直接访问目标。想确认某个应用是否经过代理，应同时检查接管列表、命中规则和最终出站，而不是只看主界面的连接按钮。

后台、电池与网络切换排查

如果亮屏时正常、锁屏后中断，应先检查系统是否限制后台运行、电池使用或自启动。按设备厂商的设置为客户端保留必要后台权限，同时理解这可能增加耗电。后台通知能帮助判断服务是否仍在运行，不宜为隐藏通知而破坏系统要求。设备重启后，也应确认客户端确实恢复连接，而不只是恢复了界面。

从 Wi-Fi 切换到移动网络后，旧连接可能中断，应用需要重新建立请求。先确认移动数据权限和当前节点在新网络下是否可达，再检查 VPN 是否仍活动。若开启了始终开启 VPN 或阻止未经过 VPN 的连接，客户端断开时可能按系统策略直接阻止网络；这属于保护行为，应按预期设置处理。

订阅更新失败时，先检查手机时间、订阅有效性、当前网络与存储空间，再观察是否只有更新失败而已有节点仍可连接。只有某个应用异常时，应检查其分流归属、独立 DNS、UDP 使用和自身缓存，避免清除客户端全部数据。处理完毕后重新启动该应用并建立新连接，才能确认修改影响的是新请求而非旧会话。

iOS：商店安装、配置导入与 VPN 验证

安装客户端并确认订阅格式

iPhone 与 iPad 优先选择 Clash Plus。可从本站 iOS 客户端入口查看说明，也可直接打开Clash Plus 的 App Store 页面。客户端官网为 clashplus.io。安装前查看商店列出的系统兼容性、功能介绍与权限说明，不要将桌面端的菜单路径照搬到移动端。

iOS 的网络接管通过系统提供的网络扩展能力完成，不是安装桌面 mihomo 可执行文件。客户端对规则、订阅格式和扩展字段的支持取决于自身实现；同一份配置能够在桌面端加载，并不能证明所有字段在手机端具有相同作用。迁移前先确认所需的节点协议、规则类型和 DNS 功能是否受支持。

订阅来源若提供客户端专用链接，应优先使用明确适配的入口。只有管理网页、二维码或分享按钮时，要分清它指向配置内容还是账户页面。二维码只是传递地址的方式，不会自动转换配置格式。导入后应检查配置列表、策略组和节点内容，不能把出现一个新配置名称当作完整导入成功的唯一依据。

远程订阅与本地文件分别管理

远程订阅通常在配置页面通过添加链接完成，保存后等待下载和解析，再将其选为当前配置。本地文件则通过客户端支持的文件导入或系统分享入口打开。文件导入是当时内容的副本，不一定保留后续更新关系；需要持续更新节点时，应确认客户端记录了远程来源，而不是依靠反复导入同名文件。

如果文件在文件应用中可见却无法导入，应检查内容是否真实为配置文本，是否仍处于云端等待下载，以及目标客户端是否支持相应格式。邮件附件或网页下载可能得到压缩包、错误页面或带额外格式的文档，不能只通过重命名后缀解决。应回到订阅来源重新取得正确内容，再查看导入错误提示。

导入后先在策略组中选择一个节点进行测试，再启动连接。自动策略组的测试目标与实际业务目标可能不同，出现测试成功但某个应用失败时，应检查该应用的连接记录和规则，而不是连续切换所有节点。手动固定一个节点有助于建立稳定对照，完成验证后再恢复适合日常使用的策略。

理解 VPN 授权与系统接管范围

首次启动时，系统可能要求添加 VPN 配置并进行设备认证。确认发起请求的是刚安装的客户端后再授权。授权完成与连接成功是两个阶段；如果系统中已存在其他 VPN 配置，应确认当前活动的是哪一个。连接按钮显示启用后，仍需要发起实际请求，观察客户端是否能够记录相应连接。

iOS 上不应套用桌面系统代理的操作习惯。除非正在进行明确的局域网代理测试，否则无需额外修改 Wi-Fi 的手动代理设置。规则模式可以让不同请求分别直连或代理，VPN 图标并不意味着所有目的地都使用同一个代理节点。应用内部的独立网络实现也可能影响日志中可观察到的域名与协议。

受系统管理策略约束的设备可能具有按应用 VPN、受管网络或访问限制。普通个人客户端不能自行覆盖这些策略。遇到某个工作应用始终采用不同路径时，应先确认设备管理范围，再联系相应管理方处理；不应通过删除组织配置来试图统一代理行为，以免影响工作账户与合规要求。

锁屏恢复与应用级故障

锁屏后返回应用时，先等待网络恢复并发起新请求。旧连接超时不等于网络扩展已经退出，也不应期待主界面一直在前台运行。若反复在 Wi-Fi 与蜂窝网络之间切换，记录发生问题时的网络类型、当前策略和 VPN 状态，再分别复测。每次只调整一个条件，可以避免把网络覆盖问题误判为订阅错误。

只有浏览器或某个应用出现异常时，检查它是否保留旧连接、使用独立解析方式或命中了特殊直连规则。可先正常退出目标应用并重开，再观察新连接。不要把清除全部系统网络设置作为第一步；该操作会影响其他网络信息，却未必改变远端节点、规则引用或配置格式错误。

更新或删除客户端前，保存订阅来源和自定义规则。恢复设备备份后也要重新核对当前配置与 VPN 授权，不要假定缓存、订阅和系统权限会以相同状态恢复。完整的获取与导入顺序可查阅iPhone 客户端获取与配置导入步骤；完成后仍应以实际连接日志和目标访问结果作为生效依据。

Linux：桌面客户端与 mihomo 服务部署

先确定桌面还是服务器场景

桌面环境可从Linux 下载入口选择 Clash Verge Rev 或 FlClash，按发行版与下载页提供的格式安装。服务器、路由器或需要精确管理进程的环境，可使用mihomo 内核。选择二进制时同时核对处理器架构、发行版环境与所需指令集；文件能解压并不代表它适用于当前设备。

桌面客户端中导入订阅、选择配置与策略的流程接近其他桌面平台，但系统代理设置依赖桌面环境。浏览器、终端、容器和后台服务可能读取不同设置，不能把桌面的代理开关理解为整个系统的统一路由。首次测试应使用显式代理请求，再决定是设置应用环境、桌面代理还是启用 TUN。

部署原生内核时，先解压并给可信的二进制执行权限，将其放入预期位置。下面约定可执行文件已经安装为 /usr/local/bin/mihomo，配置位于当前用户目录。先以普通用户运行基础代理，不要一开始就使用根权限。配置文件与其引用的本地规则文件应由运行用户读取，写缓存的目录还需具备写权限。

mkdir -p ~/.config/mihomo
/usr/local/bin/mihomo -t -d ~/.config/mihomo
/usr/local/bin/mihomo -d ~/.config/mihomo

订阅内容不能直接当作 shell 命令

原生内核不会提供图形客户端的订阅管理界面。完整配置应保存为工作目录中的 config.yaml；若只拿到节点列表，需要自行补全策略组、规则和其他必需设置，或使用客户端管理。通过可信方式下载后先检查文件内容与语法，不要将远程返回内容直接交给 shell 执行，也不要在命令历史中留下敏感订阅链接。

自动更新应采用先下载临时文件、检查成功后再替换的流程，并保留上一份可用配置。内核检查通过后，再执行受控重载或重启。直接将远程响应覆盖活动文件，可能在网络失败时把错误页面写入配置。使用远程节点提供器时，也要检查提供器名称、缓存路径、更新间隔和所引用策略组是否一致。

启动后先观察日志，再使用本机混合端口发起请求。若需要让局域网其他设备使用代理，才考虑调整监听地址、防火墙与访问控制；不要默认将入口或控制接口暴露到所有网络。远程服务器尤其要区分本机回环接口、内网地址和公网地址，防止一个便于测试的设置成为长期公开入口。

使用用户服务管理进程

在支持 systemd 用户服务的发行版中，可将下面内容保存为 ~/.config/systemd/user/mihomo.service，先创建其父目录。它适用于前述安装路径和普通代理监听，不为 TUN 授予额外权限。服务应只负责运行内核；订阅更新与权限配置需要单独设计，避免把所有维护行为藏入启动命令。

[Unit]
Description=Mihomo user proxy

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now mihomo.service
systemctl --user status mihomo.service
journalctl --user -u mihomo.service -n 80 --no-pager

用户服务通常随用户会话运行，退出登录后是否继续存在取决于系统的用户管理设置。需要常驻的服务器应按部署政策选择合适的系统服务或用户驻留方式，而不是假定启用服务就等于开机永久运行。修改配置后应先检查再重启，查看服务状态与最近日志，不能只依据启动命令没有报错判断部署成功。

TUN、DNS 与容器边界

Linux TUN 需要可用的虚拟网络设备与相应网络管理权限，普通用户服务不会自动获得这些能力。启用前应理解客户端或服务如何获得权限、写入路由以及恢复退出状态。下面仅展示常见配置段，需合并到已有可用配置；它不提供节点，也不能代替宿主机权限准备，不应直接用于覆盖完整配置文件。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

检查 DNS 时，要区分系统解析器、内核 DNS 与应用自己的加密解析。使用 systemd-resolved 的设备，还要注意本地存根解析器与监听地址是否冲突。容器有独立的网络命名空间，容器里的回环地址不等于宿主机；宿主机代理可用时，容器仍可能需要单独设置访问路径、代理环境或路由。

停止服务或回滚配置后，应确认相关路由、解析设置与环境变量恢复到预期状态。连接异常先比较显式代理与 TUN 的结果，再检查接口和防火墙，不要先全局清空规则。远程维护时保留独立管理连接，避免一次路由修改切断当前会话，导致无法继续查看日志与执行回退。

配置常见问题：按请求路径定位

订阅更新失败与配置加载失败

先区分下载失败、响应内容错误和配置解析失败。下载失败通常需要检查网络、地址、账户状态、证书与设备时间；响应成功却是网页内容，应确认链接是否仍为订阅接口；解析失败则应查看 YAML 位置、字段类型和内核兼容性。三类错误的处理方向不同，连续点击更新不会补全缺失的配置段。

已有配置能够连接但无法更新时，可以保留当前可用状态，再单独排查订阅获取路径。订阅域名可能需要直连，也可能受当前网络限制；不要让更新行为依赖一个尚未加载成功的策略组而形成循环。调整更新使用的代理方式前，先记录原设置，成功后检查是否误覆盖本地规则与策略组选择。

遇到规则集或地理数据库错误，应检查引用名称、下载位置和相关日志，而不是先删除所有规则。GEOIP 依赖 IP 数据，GEOSITE 依赖域名数据或对应配置支持；资源缺失与命中结果不符合预期不是同一问题。更新资源之后应重新建立目标连接，并查看实际匹配记录，旧连接不会自动成为新规则的可靠验证样本。

规则顺序、策略引用与 DNS

规则按从上到下的顺序匹配，首个命中项决定所用策略。具体域名规则应放在较宽泛的规则之前，兜底规则放在最后。下面片段中的 PROXY 必须已经在 proxy-groups 中定义，GEOIP 还依赖可用数据库；它只是规则示例，不是完整可连接配置。命名不同的订阅需要同步修改引用，不能直接粘贴后忽略报错。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

规则模式、全局模式和直连模式会改变策略评估路径。排错时先确认当前模式，避免修改 rules 后却仍处于全局模式。自动测速组、故障转移组与手动选择组也有不同决策条件，组名本身不保证实际行为。国内外分流的展开写法可查阅mihomo 规则分流实战。

fake-ip 通过合成地址与映射记录关联域名，看到测试网段地址不必立即判定为 DNS 污染。应用如果缓存旧映射、绕过内核解析或自行使用加密 DNS，规则可观察的信息可能改变。先检查解析路径，再按客户端方式刷新相关缓存；不要将所有域名加入过滤列表来掩盖根因，否则可能降低域名分流的可解释性。

节点测试成功却不能访问目标

延迟测试使用特定目标和协议，成功只说明该测试完成。业务网站可能受到目标侧限制，也可能依赖不同端口、UDP 或区域条件。先固定节点，用浏览器或命令行访问同一目标，再查看连接日志。对比失败请求是否进入内核、命中哪条规则、最终选择哪个出站，远比连续更换测试地址更有诊断价值。

浏览器可用而终端失败，先用显式代理参数验证；终端可用而浏览器失败，检查浏览器扩展、独立代理与缓存。所有应用都失败时，再检查内核监听、节点连通性与 DNS。只有 TUN 失败时，优先排查权限、接口和路由。具体首次验证顺序见选择节点与代理生效验证。

保留有效证据与回退路径

记录问题时保留系统类型、客户端名称、活动配置、接管方式、失败目标和发生步骤，并注明最近一次修改。必要时短暂提高日志级别，复现后恢复，避免长期积累敏感内容。重新安装通常不能修复远端订阅、目标服务或错误规则；优先按请求路径缩小范围，确认修改有效后再保存为新的配置基线。