Clash 配置文件
参考大全

01 · YAML 结构与配置入口

Clash 配置文件通常采用 YAML。它不是按行执行的脚本，而是一份带层级的数据：顶层键描述内核行为，嵌套映射保存某项功能的参数，列表保存多个节点、策略组或规则。阅读时先找与左边界对齐的字段，再向下查看所属内容。不能只凭某行离上一行很近，就认定两者存在从属关系。

映射、列表与缩进

映射使用冒号分隔键和值，冒号后通常保留一个空格；列表项以短横线开头。缩进必须使用空格，不要混入制表符。本文统一采用两格缩进，这是一种便于维护的约定，并非字段名的一部分。同一层级要对齐，尤其要区分节点列表中的第二个节点，以及第一个节点内部的附加参数。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

这里的 proxy-groups 是列表，第一项包含名称、类型和可选出站；其中的 proxies 又是一个列表。顶层 proxies 表示代理节点定义，组内同名字段表示引用哪些出站，含义取决于所在层级。将组内引用错放到顶层，即使文本仍能被解析，也可能产生类型错误或引用错误。

字符串、布尔值与重复键

端口通常写整数，开关通常写 true 或 false。密码、域名、节点名称等按字符串处理；包含井号、冒号加空格或其他容易引起歧义的内容时，建议加引号。井号在合适位置表示注释，未经引用的密码可能被截短。双引号会处理转义字符，普通文本可以优先使用单引号，减少反斜杠引发的误解。

同一映射中不要重复定义同一个键。例如在文件开头写一段 dns，末尾再补一段 dns，并不代表两段必然合并。解析器可能拒绝重复键，也可能只保留其中一个值。需要增加子字段时，应回到原来的块中修改。列表可以分行书写，也可以采用方括号形式，但排错阶段分行更容易看清归属。

源文件与运行文件的区别

桌面客户端往往同时存在订阅原文、编辑副本、覆写规则和交给内核的运行配置。编辑器中保存成功，只能说明该文件被写入；真正生效还取决于客户端是否使用它，以及后续生成流程是否覆盖了修改。排查时先确定当前启用的配置名称，再查看运行配置或内核日志，避免一直修改未被选中的副本。

用命令行运行 mihomo 时，可以通过 mihomo -t -f ./config.yaml 做配置测试。命令中的可执行文件名与路径需按实际安装位置调整。测试通过主要说明结构与部分引用能够被接受，不代表远端服务器可连接，也不代表所有规则达到预期。客户端内置测试入口与终端命令使用的内核还可能不同，应核对实际加载对象。

建立一份可恢复的基线很重要：保留原文件，把每次修改限制在一个功能块，并记录修改目的。遇到错误先还原本次变更，再逐项重加。不要同时调整 DNS、TUN 和规则顺序，否则一次连接失败可能对应多条原因。若目标只是完成首次导入，先按订阅导入步骤走通，再回来扩展配置。

02 · 端口、模式与通用字段

通用字段控制内核怎样接受连接、向谁开放入口、按哪种模式选择出站。它们属于顶层配置，通常不会因为写在文件前半部或后半部而改变含义。初次调整应先保持最小监听范围，只让本机应用使用代理；确认链路正常之后，再考虑局域网访问、控制接口或其他接入方式。功能开启越多，排查时需要核对的边界也越多。

代理端口与监听地址

port 提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 则允许同一端口接收这两类代理请求。普通桌面使用可先配置一个混合端口。端口值不是固定答案，必须与本机实际空闲端口以及应用中的代理地址一致；写成另一个数值后，旧地址不会自动转到新端口。

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

上例面向本机使用。应用手动填写代理时，地址可使用 127.0.0.1，端口使用对应数值。若出现地址已被占用，应先查看是否启动了第二个客户端或另一个内核进程，再决定关闭冲突程序还是修改端口。单纯反复重启通常不能解决占用，反而可能让多个后台进程更难区分。

allow-lan 与 bind-address 应一起理解。前者控制是否允许局域网访问，后者控制监听地址；此外还受操作系统防火墙影响。只改成允许局域网，并不保证其他设备一定能连入。确需共享时，还要配置合适的认证和访问边界，避免把本应只在可信网络内使用的代理入口暴露到公共网络。

规则、全局与直连模式

mode: rule 表示根据规则列表决定出站；全局模式使用全局选择的出站；直连模式则不按普通代理规则选择远端代理。全局模式并不等于接管设备所有流量，它只影响已经进入内核的连接。没有设置系统代理、没有单独配置应用代理、也没有被 TUN 接管的程序，仍可能完全不经过内核。

客户端界面的模式按钮可能通过控制接口即时改变运行状态，而源文件中的 mode 仍保留原值。因此，修改文件后看到界面仍处于全局模式时，应检查客户端是否恢复了上次选择，或者是否有独立的设置项优先生效。排查规则未命中之前，先确认当前真正运行的是规则模式，避免在错误前提下调整整个规则列表。

日志、控制接口与持久状态

log-level 常用 info，需要定位细节时再临时提高到 debug。详细日志可能包含访问域名、节点名称和本地地址，分享前应删去敏感内容。控制接口与代理端口用途不同：前者管理内核，后者转发应用连接。不要把管理端口填入浏览器的 HTTP 代理设置，也不要为解决连接失败而扩大管理接口的监听范围。

如果需要控制接口，应优先限制在回环地址，并设置足够强的 secret；真实密钥仅保存在自己的设备上。某些客户端会自行生成和管理这些字段，手动覆写可能导致界面连接不上内核。配置选项同时涉及客户端偏好和内核文件时，优先采用客户端提供的设置入口，再从运行配置核对结果。

持久化选择也会影响观察结果。例如启用保存策略选择后，重载配置可能恢复以前选过的节点，而不是组列表中的第一项。判断是否生效应同时检查运行模式、策略组当前选择和连接记录，不能只看文件里排在最前面的名字。端口占用、系统代理遗留等问题可继续参考帮助中心。

03 · DNS、Fake-IP 与解析路径

DNS 配置决定域名如何转换为地址，也影响内核能否保留域名信息用于规则匹配。需要把三个问题分开：应用把查询发给谁，内核收到查询后向哪个上游解析，以及连接远端节点时节点服务器域名由谁解析。三条路径可能不同，因此浏览器能查到网页地址，并不等于代理服务器域名也已经成功解析。

基础字段与上游职责

dns.enable 开启内置 DNS，listen 指定监听地址与端口。监听成功不代表操作系统已经开始使用它，仍需客户端或系统网络设置把查询送入该入口。本文使用回环地址上的非特权端口作为示例，便于与系统已有 DNS 服务区分；是否采用这个端口，应以实际接管方式和权限条件为准。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'

nameserver 是常规解析上游，可以配置普通 DNS 或受支持的加密 DNS 地址。加密上游自身使用域名时，内核需要先知道其地址，default-nameserver 可承担这类引导解析。不要把引导解析器也写成必须依赖同一条未建立链路才能访问的地址，否则容易形成先有代理还是先有解析的循环。

proxy-server-nameserver 用于代理服务器域名解析，适合把节点地址解析与普通网页解析区分开。配置后仍需保证解析器从当前网络可达。如果日志显示无法解析节点服务器，应先检查节点域名和此处上游，不要直接往网页域名过滤列表里添加条目。解析目标不同，修改位置也应不同。

Fake-IP 与真实地址解析

Fake-IP 模式为域名分配保留地址，并在内核中保存域名与地址之间的映射。应用连接该地址时，内核可找回域名，再根据规则决定出站。这个保留地址不是远端网站的真实公网地址，看到它并不代表网站 DNS 被错误修改。理解这一点，可以避免把正常映射现象误判为异常解析。

与之相比，redir-host 更接近向应用返回实际解析地址的方式，但域名信息能否完整关联，还取决于连接进入内核的路径及其他识别机制。两种模式没有适用于所有环境的统一胜负。部分局域网服务、依赖真实地址进行发现的应用或特殊网络检测逻辑，可能需要真实地址响应，此时可针对性调整，而不是一概更换所有上游。

过滤、分流与故障定位

过滤项应围绕已确认的问题添加。示例中的局域网后缀只是常见思路，并不保证适合每个网络；如果路由器使用自己的内部域名，还需要让查询到达能够回答它的本地解析器。仅把内部域名加入过滤，不会让公共 DNS 自动认识这些记录。排查时应同时确认过滤结果与实际使用的上游。

需要按域名指定上游时，可研究 nameserver-policy；需要 DNS 连接遵循路由规则时，可结合 respect-rules 及节点域名解析设置评估。它们改变的是解析流量路径，不只是查询结果。启用前要画出依赖关系，特别注意不能让获取代理连接所必需的解析，反过来依赖尚未建立的代理连接。

测试 DNS 时先区分“没有回答”“返回地址但连接失败”“只有某个应用失败”。第一类检查监听、接管和上游可达性；第二类继续检查规则、出站和 IPv6；第三类检查应用缓存、内置加密 DNS 或其他绕开系统 DNS 的路径。修改映射方式后，旧连接和缓存可能继续沿用旧结果，应重建测试连接再观察。

顶层 ipv6 与 dns.ipv6 不应混为一谈，分别涉及内核整体 IPv6 行为与 DNS 的 IPv6 应答处理。关闭其中一项不等于系统所有 IPv6 流量已经被妥善处置。关于保留地址映射和过滤边界，可继续阅读Fake-IP 模式详解，再按实际网络选择配置。

04 · 代理节点字段与提供器

代理节点定义描述内核如何连接一个远端服务。它与策略组不同：节点保存协议、服务器和认证参数，策略组只组织和选择出站。节点配置即使通过语法测试，也可能因为凭据不匹配、服务器不可达或传输参数错误而无法建立连接。排查时应先确认单个节点可用，再把它加入复杂策略组，减少选择逻辑对判断的干扰。

名称、协议与服务器参数

常见公共字段包括 name、type、server 和 port。名称用于组与规则引用，建议唯一且便于辨认；协议类型必须与服务端一致；服务器可以是地址或域名；端口则必须是远端服务实际监听的端口。本地混合代理端口和远端节点端口属于两端，不应因为数值不同就强行改成一样。

proxies:
  - name: SS-DEMO
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

这是字段形态示例，域名与密码均为教学假值，不能直接用于远端连接。实际参数应来自有权使用的服务器配置。不要根据网页能够访问就推断代理端口可用，也不要根据端口常被 HTTPS 使用就擅自添加 TLS。加密方法、密码和协议类型需要成套匹配，任何一个字段写错都可能表现为超时或握手失败。

字段支持范围由实际内核决定，不是由客户端名称单独决定。同一个界面产品在不同构建中，可能包含不同的内核能力；老配置中的协议也不一定与较新示例兼容。遇到未知协议或未知字段时，先核对正在运行的内核及其文档，再修改配置。各分支关系可参考mihomo 与原版功能差异。

TLS、传输层与 UDP

对于使用 TLS 的协议，服务器地址、证书验证名称与传输层主机字段可能分别承担不同职责。servername 通常关系到 TLS 握手中的名称，WebSocket 相关路径与请求头则属于传输层。不能把订阅里所有域名都替换成同一个值，也不能仅凭某个字段看起来重复就删除。应按服务端实际配置逐项核对。

不要把跳过证书验证作为通用修复。证书错误应先检查设备时间、服务器名称、证书有效性以及是否连接到了错误端口。关闭验证会改变安全边界，还可能暂时遮住错误服务器或配置不匹配的问题。只有在理解具体测试环境和风险时才讨论此类设置，日常配置应保持合理的验证流程。

udp: true 表示允许该节点处理相应 UDP 请求，并不保证服务端、协议实现和整条网络路径都支持 UDP。HTTP 代理接入的普通浏览器请求也不能替代 UDP 测试。遇到语音、游戏或部分 DNS 请求异常时，应检查应用如何进入内核、节点是否支持所需传输，以及服务端防火墙是否放行，而不是只看开关是否开启。

代理提供器与健康检查

proxy-providers 可以把节点列表从主配置中分离。文件提供器读取本地文件，HTTP 提供器从指定地址获取内容；主配置中的策略组通过 use 引用它们。这样更新节点时可以不改整套规则，但提供器文件有自己的结构要求，不能把包含模式、规则和 DNS 的完整订阅直接当成任何提供器格式使用。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - local-nodes

上例依赖真实存在的本地文件，其内容应包含 proxies 列表以及有效节点。相对路径基于内核工作目录解析，不一定是编辑器当前打开文件的目录。若日志提示找不到文件，先确认客户端使用的工作目录与访问权限，再调整路径；不必因此把所有节点手工复制到主配置，掩盖原本的路径问题。

健康检查需要一个从所选出站访问的测试地址，它衡量的是该路径到测试目标的表现，不是整个互联网的保证。检查失败可能来自目标限制、DNS、超时或节点问题。订阅地址还常包含访问凭据，不能把完整链接贴到公开日志或截图中。分享配置前应保留结构，替换密码、订阅参数和其他可识别信息。

05 · 策略组、引用与选择状态

策略组把多个出站组织成一个可以被规则引用的名称。规则把连接交给组之后，组再根据当前选择或测试逻辑决定实际节点。组名叫 PROXY 并不天然代表一定经过远端代理，名字叫 DIRECT 的普通自定义组也不应与内置直连出站混淆。配置时应根据引用关系判断行为，而不是根据名字的字面含义推测。

手动选择与完整引用

select 是手动选择组，适合将决定权交给用户。组内 proxies 可以列出已有节点、其他组以及受支持的内置出站，use 则引用提供器。名称必须完全一致，注意空格、大小写和中文标点。给节点改名时，要同步检查所有引用位置；否则可能出现文件语法正确，但内核无法找到目标的错误。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

  - name: MEDIA
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,MEDIA
  - MATCH,PROXY

这份片段只使用直连和组间引用，用于演示结构，不包含真实代理节点。访问示例域名时先进入 MEDIA；如果 MEDIA 选择 PROXY，则继续使用 PROXY 当前选择的出站。组之间可以形成层级，但必须避免循环。例如甲组引用乙组，乙组又引用甲组，会破坏出站决策链，不能用来实现所谓双向备用。

自动测试与故障转移

url-test 根据测试结果选择出站，常用于自动选择；fallback 更强调按候选顺序寻找可用项；load-balance 则按照支持的策略分配连接。它们不是三种同义写法。需要稳定优先级时，故障转移组通常比频繁追逐测试结果更容易解释；需要手动固定业务出口时，可以在外层再放一个选择组。

自动组通常要配置测试地址、检查间隔等参数。地址应由使用者根据网络环境选择，并确认预期响应稳定。测试值只说明到该目标的路径，不应被当作所有业务的速度排名。某些节点到测试站点表现较好，却未必适合长连接、流媒体或其他目的地，因此需要把自动测试与实际业务体验结合起来判断。

检查间隔也不是越短越好。间隔过短会增加请求与设备唤醒，移动设备尤其需要考虑后台限制。部分检查机制支持按需检测，长时间未被使用的组未必持续刷新结果。看到旧测试状态时，先确认该组是否实际执行过检查，再判断节点是否异常，避免把缓存的观测结果误认为实时事实。

选择持久化与业务组

可以按业务创建媒体、开发工具或其他组，再让不同规则引用这些组。这样的分层把“哪些请求属于某类”与“这类请求选哪个出口”分开，修改节点时不用重写所有域名规则。组不宜拆得过细，否则用户需要维护大量选择状态，排查一次连接也要跨越多层引用，反而失去清晰性。

profile:
  store-selected: true

保存选择后，重启或重载可能恢复以前的状态。节点顺序变化不一定改变当前选择，组名变化却可能让旧状态失去对应关系。测试新的默认顺序时，应同时核对持久化记录和客户端是否另行保存了选择。不要以为把某节点移到第一项，就能确保所有已安装客户端下一次都使用它。

策略组显示异常时，推荐按名称定义、引用来源、候选列表、当前选择的顺序检查。提供器尚未加载可能让候选列表不完整，筛选条件过严也可能筛掉全部节点。遇到空组时先核对提供器更新日志和筛选表达式，不要立刻把规则目标改成另一个组，否则只是绕开错误而没有解决来源问题。

还要区分“当前选择存在”和“当前选择可连接”。手动组可以保留一个已经失效的节点，自动组也可能因为所有候选都不可用而无法提供正常连接。确认组结构无误后，再回到单节点连接日志核对服务器、协议和 DNS。关于客户端界面差异，可结合选型指南选择适合自己的配置管理方式。

06 · 规则语法、顺序与规则集

规则模式下，连接按规则列表从上到下匹配，通常由第一条命中的规则决定目标出站。规则不是把所有命中结果投票汇总，也不会因为后面有一条更具体的规则就自动回头重选。因此，阅读配置首先要看顺序，再看单条表达式是否正确。把最宽泛的兜底条件放在顶部，会让后面的大部分规则失去作用。

域名、地址与最终兜底

DOMAIN 匹配指定域名，DOMAIN-SUFFIX 匹配域名及其子域，DOMAIN-KEYWORD 按关键字判断。后缀规则通常比宽泛关键字更容易控制边界。域名规则匹配的是主机名，不是完整网页地址；不要把协议前缀、路径或查询参数放进域名字段，否则看似复制了正确网址，实际却匹配不到。

rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

此处精确域名直连位于后缀代理之前，因此它能作为例外生效。局域网网段按实际网络补充，示例没有覆盖所有地址范围，也不能替代完整的网络边界设计。MATCH 不带匹配内容，作为剩余连接的兜底；它后面的字段是出站名称。若该名称不存在，兜底也无法正常完成决策。

地址类规则面对域名目标时，可能需要解析才能判断。no-resolve 用于避免为了这条地址规则主动触发域名解析，但不表示禁用全部 DNS，也不保证该连接从未进行过解析。连接目标已经是地址时，仍可按地址匹配。调试时应结合日志中的域名和目标地址，看清内核拿到了哪些信息。

进程规则与进入内核的方式

部分环境支持按进程名或路径匹配，但能否取得进程信息与操作系统、权限和接入方式有关。来自局域网其他设备的连接，通常无法像本机连接一样关联到远端应用进程。规则没有命中时，应先确认进程识别条件成立，再检查名称，不要不断增加同义进程规则来补救缺失的元数据。

规则也无法处理没有进入内核的连接。某程序忽略系统代理时，即使写了精确进程规则，也可能完全没有匹配机会。应先查看连接记录是否出现请求；若没有，检查应用代理设置或 TUN 接管路径。若记录出现但目标组不对，再检查当前模式、规则顺序和域名信息。这样能把流量入口问题与规则表达问题分开。

规则提供器与格式对应

rule-providers 把规则内容放在独立文件或远端资源中，主列表通过 RULE-SET 引用。behavior 描述内容语义，例如域名、地址段或经典规则；format 描述文件编码格式。两者都要与实际资源一致。普通网页、完整配置和规则列表不能只凭文件扩展名就互换使用。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

对应的域名规则文件可以采用下方结构。文件内容与主配置中的提供器定义共同决定能否正确加载；只检查主文件而不查看资源内容，容易漏掉格式不一致。文件路径同样基于内核工作目录，首次使用时应先确认资源存在、可读并已加载，再测试域名命中。

payload:
  - '+.example.com'
  - 'router.example.net'

订阅更新与规则集更新是两条独立链路。节点能刷新不代表规则资源也成功刷新；旧缓存可能继续被使用。出现只有某一类网站分流异常时，可以先查看对应提供器的加载日志，再对一个具体域名追踪命中结果。不要用不断扩大关键字范围的方式替代资源排错，这会引入难以察觉的误匹配。

最终验证应使用新建连接。已建立的长连接可能继续保留原有出站，浏览器连接复用也会让规则修改看起来没有效果。记录一个明确测试域名，关闭相关旧连接，重新访问后核对命中规则、策略组与最终节点。日志字段的阅读方法见运行日志定位方法。

07 · TUN、路由与接管边界

TUN 通过虚拟网络接口把符合路由条件的流量送入内核，适合处理不遵循系统代理设置的应用。它与规则模式分属不同层次：TUN 解决流量怎样进入，规则解决进入之后从哪里出去。开启 TUN 不意味着所有请求都要走远端代理，规则仍可以把局域网或指定业务交给 DIRECT，也可以将特定连接拒绝。

基础结构与权限条件

桌面系统通常需要管理员权限、服务模式或相应网络权限，移动系统则通过平台提供的 VPN 接口接管。客户端是否提供图形开关、是否自动安装服务，各平台实现不同。启用失败时应先看虚拟接口和权限相关日志，不能仅根据界面开关呈开启状态，就认定流量已经进入 TUN。

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

这是常见字段组合，不是所有设备的通用成品。auto-route 用于自动设置相关路由，auto-detect-interface 帮助选择出站接口；多网卡、远程桌面、容器或其他隧道并存时，自动结果仍可能不符合预期。修改路由前应保留恢复方式，尤其不要在唯一的远程连接上直接试验未经验证的接管方案。

协议栈、DNS 劫持与实际效果

stack 可按内核支持范围选择 system、gvisor 或 mixed 等实现。它们在系统适配、处理方式和资源开销上存在差异；mixed 使用混合处理思路，并非“越新越快”的标签。应先使用客户端推荐值，再针对已确认的兼容问题调整，避免同时改变栈、路由与 DNS 模式而失去对照。

dns-hijack 将匹配的传统 DNS 请求导向内核 DNS 处理。示例中的端口匹配不代表能识别并重定向所有加密 DNS；应用通过 HTTPS 发送的查询与普通网页连接使用相同传输入口，不能简单按传统 DNS 端口处理。浏览器自带解析机制也可能改变域名可见性，测试时应明确应用采用的解析路径。

开启 TUN 后仍要让内置 DNS 正确工作。如果接管了查询，却没有可用上游，表现可能是应用大面积等待解析；如果查询绕开了预期路径，某些域名规则又可能缺少所需信息。因此，排查顺序宜为虚拟接口、路由、DNS、节点和规则，不要只反复切换 Fake-IP 与真实地址模式。

局域网、其他隧道与排错

局域网访问同时受路由与分流影响。给私有网段写 DIRECT 规则，只决定已进入内核连接的出站，并不必然解决所有系统路由冲突。若打印机、共享目录或内部管理页在开启 TUN 后失效，应比较开关前后的路由、目标地址和连接记录，再考虑合适的路由排除，而不是直接放开全部流量。

与企业 VPN 或另一套网络隧道并用时，默认路由、DNS 和接口优先级可能互相影响。最有效的基线测试是一次只保留一套接管，再分别验证解析和目标访问；确认单独工作正常后，才研究如何划分路由。不要把所有网络接口都排除或都接管，这类极端调整很容易使内核无法建立自己的出站连接。

退出 TUN 后如果网络仍异常，应检查客户端是否正常清理接口、路由和系统代理，再确认其他网络工具是否还在运行。可以先恢复客户端中对应设置并正常退出，不宜直接删除不认识的系统路由。有关开启步骤、权限与协议栈的进一步说明，见TUN 模式设置教程。

08 · 覆写、合并与配置验证

订阅配置通常需要定期更新，而本地端口、DNS 和个人分流规则希望长期保留。覆写机制就是在源配置之外保存这些差异，再由客户端生成运行配置。它不是 YAML 自带的统一功能，不同客户端的合并顺序、列表处理和脚本能力可能不同。因此，理解最终结果比记住某个界面按钮名称更重要。

区分替换、递归合并与追加

对单个标量字段进行覆写通常比较直观，例如修改 mixed-port。映射则可能递归合并，也可能整个替换；列表更容易出现差异，可能覆盖原列表、追加到末尾，或通过专用入口插入开头。不能因为两份文件都有 rules，就假定客户端会自动保留两边所有规则。

# 覆写片段：具体合并方式由客户端决定
mixed-port: 7890

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

如果客户端对 dns 整块替换，上例可能让订阅原有上游丢失；如果采用递归合并，则可能保留未出现的子字段。两种结果都不能仅凭这段文本判断。保存后应打开运行配置，检查上游、监听和过滤列表是否完整，再进行解析测试。对于不确定的合并行为，先用一份可恢复的测试副本验证。

规则位置与订阅更新

个人例外规则通常需要放在较宽泛规则之前，尤其要位于最终兜底之前。如果客户端只是把新规则追加到已有 MATCH 后方，这些规则虽然出现在文件中，却几乎不会获得匹配机会。配置界面中的“前置规则”“后置规则”和“替换规则”因此不能混用，必须根据希望改变的优先级选择。

直接编辑订阅原文件可能在下次更新时被覆盖。更稳妥的方式是把节点来源、业务规则和本地环境设置分层管理，使用客户端明确支持的覆写或配置组合能力。若客户端没有所需机制，可以另存为手动配置并接受自行维护的成本，不要一边依赖自动更新，一边假定手工改动永远保留。

节点名称与策略组名称变化也是更新风险。个人规则引用订阅中的某个组名，更新后该组改名，即使个人规则本身没有变化，也会失效。尽可能使用自己维护的稳定业务组，再让它引用可更新节点来源。更新后重点检查所有自定义目标是否仍存在，不要只看客户端提示订阅刷新成功。

以运行配置建立验证闭环

完整验证分为四层：文件能够解析，引用能够解析，外部资源能够加载，连接行为符合预期。前两层可借助配置测试，第三层看提供器与节点相关日志，第四层需要实际请求和连接记录。任何一层通过，都不能代替其他层。特别是测试命令返回成功，不代表服务器凭据有效或规则一定选中预期出站。

mihomo -t -f ./config.yaml

客户端生成的运行文件应尽量使用客户端实际内核进行测试。独立安装的命令行工具可能支持不同字段，导致本地测试与界面结果不一致。运行文件中也可能包含自动生成的控制地址、接口名或缓存路径，不建议不加区分地复制到另一台设备；迁移时应带走需要的逻辑配置，再按新环境重新生成。

变更记录与安全分享

每次修改记录三个信息即可：为什么改、改了哪一层、怎样确认有效。保留能够恢复的旧配置，比保存大量没有说明的副本更有价值。出现问题时先退回最近可用状态，再逐个重做变更；如果同时升级客户端和调整规则，应把两件事拆开验证，避免把内核差异与配置错误混在一起。

请求协助时，提供错误时间、简化后的相关片段、实际运行模式和复现步骤，并替换订阅凭据、密码及管理密钥。公开截图还应检查节点备注、内网地址和访问记录。需要再次确认安装、导入与连接主线，可返回使用指南；需要判断常见错误属于哪类，可转到帮助中心，不用为每次异常重写整份配置。