Clash 配置字段参考

YAML 结构总览

Clash 配置不是一组互不相关的开关，而是一张有引用关系的工作表。通用字段决定内核怎样监听连接，DNS 决定域名如何解析，节点提供真实出口，策略组组织这些出口，规则再把请求交给某个策略。理解这条链路，比背下全部键名更有用。排查时也沿着这条链路走：先确认请求进入内核，再看规则目标，最后检查被选中的节点。

先读层级，再读字段

YAML 用缩进表示从属关系。顶层的 dns、proxies、proxy-groups 与 rules 处在同一级；nameserver 属于 DNS，因此要缩进。列表中的短横线表示一个新条目，不是装饰符号。建议统一使用两个空格，不使用制表符。编辑器显示对齐，不代表实际字符一致，复制网页内容后尤其要检查行首是否混入全角空格。

下面是一份仅含直连出口的结构示例，可以用于观察配置加载、监听端口和策略引用。它不会凭空提供代理服务，也不能替代服务提供方给出的连接参数。先让这份小配置通过检查，再逐段加入自己的节点和规则，比把大量来源不同的片段一次拼在一起更容易定位问题。

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

dns:
  enable: false

proxies: []

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

rules:
  - MATCH,PROXY

字符串、列表与引用

节点名和策略组名属于字符串引用。规则写了 PROXY，配置中就应存在这个策略组或同名出口；名字相近不算相同，大小写、空格与标点也会参与匹配。建议采用短而稳定的名称，不把会变化的流量提示或日期当作核心引用名。节点改名后，策略组列表和直接引用该节点的规则也要一起检查，否则文件语法正确，语义检查仍可能失败。

布尔值通常写成 true 或 false，端口和间隔写数字，密码等文本建议加引号。含有冒号加空格、井号、方括号或其他特殊字符的字符串，更应明确引用。引号本身不会隐藏敏感信息，只是在说明数据类型。不要把全角冒号当作键值分隔符；中文输入法产生的引号也不能代替 YAML 所需的半角引号。

同一层级不要重复声明同一个键。例如前面写了一段 DNS，文件末尾又粘贴一个 dns:，并不表示两段会自动累加。不同解析器可能拒绝重复键，也可能只留下后面的值，最终结果不值得依赖。需要追加解析服务器时，应编辑原来的列表；需要客户端合并配置时，应使用明确的覆写机制，并查看它最终生成了什么。

完整配置与节点列表的区别

完整配置包含监听、策略组与规则等运行信息，节点列表则主要描述连接参数。两者都可能是 YAML，但用途不同。proxy-providers 引用的通常是提供器格式，不能仅凭文件扩展名就拿它当完整订阅使用。导入失败时，先检查返回内容是否实际变成登录网页、错误提示或一串编码文本；格式差异可继续看订阅链接与 YAML 格式说明。

阅读后续示例时，把代码看作某一段字段的写法，而不是每段都可以独立运行的文件。尤其是含有策略组名、提供器名的片段，必须与自己的实际定义对应。每次保存前确认该片段应处于顶层还是某个列表项内部；层级放错时，最危险的结果不是立即报错，而是字段被忽略后继续按旧行为运行。

端口与运行模式

端口设置解决的是“应用把连接交到哪里”，不是“最终从哪个节点出去”。系统代理通常把应用指向本机的 HTTP 或混合端口，应用内的 SOCKS 设置则需要对应的 SOCKS 入口。先确认入口类型，再填写地址和端口。把代理服务器的远端端口填成本机监听端口，或反过来，都可能得到连接失败，但这两种端口位于完全不同的链路位置。

port、socks-port 与 mixed-port

port 用于 HTTP 代理监听，socks-port 用于 SOCKS 代理监听，mixed-port 可以在同一个端口接收 HTTP 与 SOCKS 请求。日常使用通常保留一个混合端口就够了，不必为了“功能完整”把所有入口都开启。多个监听入口不能抢占相同的地址与端口组合；如果已有客户端或后台服务占用端口，新内核就可能启动失败。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false
profile:
  store-selected: true

局域网访问需要同时满足条件

allow-lan: false 适合只供本机使用。需要让另一台设备连接时，除了允许局域网接入，还要使用可访问的监听地址，并在对方设备上填写运行客户端那台机器的局域网地址，而不是填对方自己的回环地址。随后检查操作系统防火墙与无线网络的设备隔离。开了局域网访问不等于自动获得认证，也不等于可以把监听端口直接暴露到公网。

共享入口时应明确使用者与网络边界，必要时配置入口认证及客户端支持的访问限制。管理接口与代理入口也要分开理解：external-controller 是控制内核的接口，不是给浏览器填的代理地址。若并不需要远程控制，就让它只在本机可达；不要照抄公开监听的控制接口示例，更不要把控制凭据放进可公开下载的配置。

模式与接管方式是两件事

rule 表示按规则选择出口，global 表示使用全局策略，direct 表示直连。全局模式不是强制让所有软件进入代理，它只改变已经进入内核的请求如何选路。应用绕过系统代理时，即使界面显示全局，该应用也可能仍然直连。因此应先确认连接是否出现在客户端的连接列表中，再判断模式选择有没有问题。

系统代理通常覆盖遵循系统代理设置的应用，TUN 则通过虚拟网络接口接管流量，两者不是同一个字段的不同名称。TUN 还涉及权限、路由、DNS 劫持与其他虚拟网卡，不能仅把开关设为开启就认定全部准备完成。初次验证建议先用明确支持代理的应用测试混合端口，再单独启用 TUN，避免入口问题与路由问题同时出现。

配置中的模式和策略选择可能被客户端持久化状态接管。示例中的 store-selected 用于保存策略组选择，能减少重启后重新点选，但也会让改过的默认列表顺序不一定直接变成当前选择。检查时以界面显示的实时模式、策略组当前出口和内核运行配置为准，而不是只盯着订阅文本中某一行。

端口冲突时先退出重复运行的客户端，确认后台内核是否仍在监听，再决定换端口。换完以后，系统代理、浏览器扩展和应用内手动填写的地址也要同步修改。只修改 YAML 而保留应用里的旧端口，会表现成“内核正常、网页打不开”。这一类问题不需要重装软件，恢复入口与应用设置的一致性通常就能解释现象。

DNS 解析配置

DNS 决定域名怎样得到地址，也会影响依赖域名或地址的分流判断。网页打不开不一定是节点失效：可能在连接远端之前，域名解析就已经失败。排查时先区分目标网站域名、代理服务器域名、DNS 上游服务器域名，它们未必走同一条解析路径。用一个解析服务器同时承担所有角色，配置看似简单，却容易在网络条件变化时形成依赖循环。

启用内置解析与 fake-ip

dns.enable 控制内置 DNS 功能。listen 指定监听地址，但有了监听并不代表操作系统自动把查询发过来，还要由系统 DNS 设置、客户端接管或 TUN 劫持把请求送入内核。enhanced-mode: fake-ip 会为域名分配虚拟地址，内核保留域名映射，再在实际连接时处理出口；虚拟地址不是网站真实服务器地址，不能拿它当节点地址使用。

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"
    - "localhost"

上面的地址用于演示字段关系，是否适合当前网络要实际验证。default-nameserver 常用于解析 DNS 上游自身的域名，因此需要选择当前网络能直接访问的引导解析入口。proxy-server-nameserver 为代理服务器域名指定解析路径，可以帮助避免“为了连代理先解析节点，而解析节点又要求代理已连接”的循环。它不是所有网站查询的统一出口。

解析策略与连接策略分别检查

nameserver 是主要上游列表，nameserver-policy 可按域名或受支持的规则条件指定上游。需要更细控制时，先写一个范围小、结果可验证的策略，再逐步扩展。DNS 请求使用某条路径，不等于随后的网站连接必然使用相同出口；最终连接仍要经过分流规则。把两者混在一起，会误以为“解析成功就证明代理成功”。

mihomo 的 respect-rules 可以让 DNS 上游连接遵循路由规则，但启用前应先安排好代理服务器域名的解析，并确认规则没有反过来依赖尚未完成的解析。对新手而言，保留清晰的引导路径比堆叠多个加密上游更重要。如果当前网络无法访问某个上游，增加相同路径上的更多地址也未必提高可用性，反而使日志更难阅读。

fake-ip-filter 适合处理不应获得虚拟地址的域名，例如某些局域网发现服务或依赖真实地址的应用。但过滤只改变解析表现，不直接等于直连规则。若某个域名需要直连，应另外确认连接规则指向 DIRECT。不要把所有遇到问题的网站都加入过滤列表；列表过大可能掩盖真正的接管错误，也会削弱域名映射带来的可观察性。

IPv6、缓存与故障边界

顶层 ipv6 与 DNS 内部的同名字段不应视为完全相同的开关，前者涉及内核对 IPv6 的使用，后者影响内置解析器的地址查询与返回行为。系统、应用和其他 DNS 服务还可能保留自己的 IPv6 路径。遇到部分网站时好时坏，应检查是否存在只有 IPv4 被接管、IPv6 仍绕行的情况，而不是直接断定某个节点不稳定。

修改 DNS 后，已有连接不会自动重新解析，应用缓存和系统缓存也可能继续保留旧结果。应先重新加载配置，再关闭相关应用连接并重新发起请求；确有需要时再清理对应缓存。若使用 fake-ip，避免把旧缓存长期带到另一套不兼容的地址映射中。能够解析出一个地址只说明这一阶段有结果，还要继续检查连接列表中的目标、规则与出口。

需要比较多种 DNS 配置时，每次只改一个维度，例如先换上游，再测试过滤，最后调整规则遵循方式。记录失败域名、测试时间和日志中的错误阶段，不要只记录“网页慢”。这样才能判断是引导失败、上游不可达、域名映射异常，还是解析完成后目标连接失败；最后一种情况应该回到节点与规则章节，而不是继续增加解析服务器。

代理节点字段

proxies 描述真正连接远端服务所需的信息。节点名称只是本地标识，不能决定协议；协议由 type 指定，其他必需字段也随协议变化。一个名字里写着某种协议的节点，未必真的采用该协议。排查时应读取实际字段，并确认当前内核支持对应类型。图形界面能导入文本，不代表内核一定能建立连接，这两步需要分别验证。

通用信息与协议专属信息

大多数节点包含 name、type、server 和 port。服务器可以是域名或地址，端口必须与远端服务匹配。认证方式则因协议而异，有的使用密码，有的使用用户标识或其他凭据。不要把不同协议的字段混合拼装，也不要认为把 type 换一个名字就能转换协议。服务端与客户端必须对连接方式达成一致。

proxies:
  - name: SS-示例
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

这个片段展示 Shadowsocks 节点结构；example.com 与示例密码不是可用服务。实际使用时必须替换为服务方提供的信息，并把节点名称加入策略组引用。cipher 要与服务端一致，不能凭“看起来更强”自行选择另一种方法。服务器地址正确但认证不符时，底层连接可能建立，应用数据仍然无法正常转发。

TLS 与传输层不要混着改

支持 TLS 的协议还可能使用 servername、证书校验和应用层协议等参数；某些传输方式另有路径、请求头或传输选项。它们描述的是不同层次：服务器地址决定连向哪里，服务名参与 TLS 握手，传输路径则影响服务端如何识别上层连接。直接把服务器地址改成某个解析出来的地址，却没有保留原有服务名，可能让证书校验失败。

证书相关错误应优先检查系统时间、服务名是否正确、证书链是否完整，以及网络中是否存在其他中间设备。跳过证书校验不应作为普遍修复方式，更不能因为暂时能连接就当作问题已经解决。若服务方提供了特定参数，按其说明核对，并保留失败日志中发生错误的阶段；握手失败、认证失败和目标站超时，对应的处理方向并不相同。

udp: true 表示在该节点配置中允许相关 UDP 能力，但能否实际使用，还取决于协议、远端服务、入口方式和本地网络。它不是让所有应用立即获得 UDP 代理的万能开关。浏览器能访问网页，只能证明部分 TCP 或应用连接可用；游戏、语音与其他 UDP 应用仍需单独验证，也应观察是否存在应用绕过当前代理入口的情况。

节点提供器与订阅更新

节点多、更新频繁时，可以使用 proxy-providers 将节点来源与策略组定义分离。提供器负责读取或拉取节点列表，策略组通过 use 引用提供器名称。这里引用的是提供器，不是单个节点。文件格式、可访问路径和更新方式都要与当前内核及客户端的支持情况一致；不能把完整客户端配置直接塞进只接受节点列表的入口。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

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

对应文件应以顶层 proxies: 列表组织节点。路径通常相对于内核工作目录解析，但图形客户端可能限制允许读取的位置或重新安排目录，因此不能只看文件与订阅是否“放在一起”。文件找不到时先看运行日志记录的实际路径；健康检查没有结果时，再区分提供器未加载、列表为空和测试请求失败，避免直接把所有节点判为不可用。

订阅更新后，节点改名或删除会影响直接按名称引用的策略组。长期自定义配置更适合保持稳定的提供器引用，或通过客户端支持的筛选方式管理节点。不要在每次刷新都会被覆盖的原始节点列表里反复手改；如果更新本身失败，先按订阅刷新排查流程确认链接、网络与返回格式，再检查节点参数。

策略组与健康检查

策略组是规则与节点之间的中间层。规则不必知道当前哪台服务器可用，只需把请求交给一个稳定的组名；组内再决定手动选择、自动选择或故障切换。这样换节点时不用逐条改规则，也能把用途分开。例如日常浏览与特定服务可以引用不同策略组，但组名本身不赋予特殊能力，实际效果仍由组内出口、测试方式和规则命中共同决定。

四种常用类型怎样选

select 用于明确的手动选择，适合希望固定出口的场景。url-test 根据测试结果自动选择，适合愿意让内核在候选节点中调整的场景。fallback 更关注按列表顺序使用可用候选，而不是始终追求最小测试值。load-balance 用于按受支持的策略分配连接，不代表单个下载会自动叠加多条线路的带宽。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自动选择
      - DIRECT
  - name: 自动选择
    type: url-test
    proxies:
      - SS-示例
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

此片段需要前章同名节点定义才能一起使用。外层手动组把控制权留给使用者，内层自动组负责测试候选。自动组只有一个候选时仍能检查它，但没有其他节点可供切换。interval 是检查间隔，tolerance 用于减少测试值轻微变化造成的频繁切换；它不是下载速度门槛，也不承诺每个网站都得到相同体验。

测试成功只回答一个问题

健康检查回答的是“这个候选是否能按指定方式访问测试目标”，并不替代真实业务验证。测试目标不可达、目标对当前网络限制访问，或该目标的解析异常，都可能让一组原本可用的节点显示失败。反过来，测试请求成功也不能证明某个账户服务、流媒体或游戏一定可用。测试目标应稳定、轻量，并与自己的用途保持合理关联。

把检查间隔调得很短，会增加持续请求，未必带来更好的选择。频繁变化的网络本身也可能让测试结果波动。应先观察失败是否具有规律，例如只在休眠恢复后出现、只在特定网络下发生，或只有某个测试地址失败。需要定位时，临时切到手动组固定一个节点，减少自动切换对日志与实际体验的干扰，再单独验证候选。

提供器的健康检查与策略组的检查属于不同层面，配置时要知道检查由谁发起、针对哪些候选。不要看到提供器中有结果，就推断所有引用它的组都采用完全相同的选择行为。使用 use 引用节点来源时，还要确认提供器成功加载；若同时使用名称列表与提供器，应检查是否出现重复候选或意外包含直连出口的情况。

嵌套引用与状态保存

策略组可以引用其他策略组，但不能形成循环。甲组指向乙组、乙组又回到甲组，即使名字都存在，也无法得到确定出口。设计时尽量保持少量层级：用途组指向选择组，选择组再指向节点即可。层数太多会让连接记录难读，也使“界面上明明选了节点”与最终实际出口之间隔着多次选择，增加理解成本。

登录、支付或长时间会话对出口变化可能敏感。自动切换或连接分配让不同请求使用不同出口时，服务端可能要求重新验证；这不一定意味着节点失效。此类用途可采用独立的手动选择组，保持策略稳定。修改组类型后，应建立新连接再验证；已存在的长连接未必立即迁移，界面上的新选择和旧会话可以短时间并存。

若切换订阅后策略组选择与预期不同，检查客户端是否恢复了历史选择，原节点是否已被删除，以及组名是否复用了旧配置的名称。稳定组名有利于保留习惯，但也会继承状态。排错时记录当前选中的实际节点，不要只写“使用自动选择”；这样在重新加载或自动切换之后，仍能准确复现当时那条连接的条件。

规则语法与匹配顺序

规则列表从上到下检查，通常由第一条命中的规则决定出口。范围较小的例外要放前面，范围较大的分类放后面，最后用 MATCH 接住剩余请求。没有一个关键词能代替顺序设计：同样几条规则，前后交换后就可能得到不同结果。编写自定义规则时，先用一句话说明希望覆盖哪类请求，再选择能够精确表达它的规则类型。

域名规则与地址规则

DOMAIN 匹配指定域名，DOMAIN-SUFFIX 匹配域名及其子域范围，DOMAIN-KEYWORD 按关键词扩大匹配。关键词太短容易覆盖无关网站，因此日常例外通常优先使用完整域名或后缀。规则中的域名不要带协议、路径或查询参数；网页地址是一条完整 URL，而域名规则处理的是其中的主机名部分。

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

示例中的 router.example.com 会先命中精确直连规则，不再被后面的后缀规则改成代理。地址段规则适合局域网或明确的网络范围，GEOIP 则依赖地理数据进行分类。地理位置并不等同于网站用途，内容分发网络也可能让同一服务对应多个地区的地址，因此不能把某个地址分类结果当作永久不变的业务标签。

no-resolve 的实际边界

no-resolve 常用于地址类规则，表示不要仅为匹配这条规则而主动进行域名解析。它不是“整个请求禁止 DNS”，也不代表这条规则一定跳过所有域名请求。如果内核已经掌握目标地址，仍可能进行地址匹配。使用这个参数的目的应是减少不必要的解析或控制匹配过程，而不是靠它绕过所有解析问题。

域名规则需要内核知道域名。请求直接使用地址、应用自己完成加密解析，或入口没有携带可用主机名时，域名规则可能缺少匹配条件。部分情况下可以借助 DNS 映射或嗅探补充信息，但嗅探也有协议、加密方式与配置边界。先查看连接详情中是否存在域名，再判断是规则写错，还是根本没有足够信息供域名规则匹配。

GEOSITE 与 RULE-SET

GEOSITE 借助域名分类数据表达一组服务范围，RULE-SET 则引用规则提供器。两者都依赖可用的数据来源，分类名称也必须实际存在。仅把网上看到的类别名称写进规则，不会自动获得对应数据。导入较大的规则方案之前，要确认数据格式、更新路径与内核支持情况，避免配置本身能读入，运行时却缺少所引用的资源。

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

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

上述提供器文件可使用顶层 payload:，列表中放域名匹配内容，例如带引号的 "+.example.com"。behavior: domain 面向域名集合，ipcidr 面向地址段集合，classical 面向受支持的完整规则条目；它们不能不经转换就互换。完整规则条目也不应误放进只接受域名的列表，否则会得到格式错误或不符合预期的匹配。

规则提供器负责提供匹配条件，RULE-SET 这一行再决定把命中的请求交给哪个策略。这样同一份域名集合可以用于不同配置，而不用在集合内部硬编码所有出口。多个集合存在交集时，仍然遵循外层规则顺序；不能因为某个集合名称更具体，就认为它自动拥有更高优先级。要改变优先级，直接调整引用规则的位置。

用连接记录解释命中结果

遇到误分流，先找一条具体连接，记录域名、目标地址、命中的规则和最终出口。若命中 MATCH，说明前面的条件没有匹配，而不是兜底规则坏了；若命中正确但出口错误，应该检查策略组当前选择。若请求根本不在列表中，就返回入口接管排查。更完整的组合思路可看GEOIP、GEOSITE 与 RULE-SET 分流实战。

覆写与配置合并

覆写解决的是“订阅会更新，但本地设置需要保留”。如果直接修改订阅原文，下一次刷新就可能恢复服务方内容；如果直接修改运行时生成文件，客户端重新启动时也可能重建文件。正确位置通常是客户端提供的持久化覆写、扩展配置或合并设置。不同客户端实现不同，不能把某个界面里的覆写格式当成所有内核都认识的标准字段。

先确定谁生成最终配置

配置链路通常包含订阅原文、本地持久设置、客户端加工、内核运行状态几层。客户端可能固定监听端口、补充控制接口、替换 DNS，或在加载时插入规则。订阅中某行没有生效，并不必然说明字段不受支持，也可能是在后续阶段被覆盖。应先找到客户端提供的运行配置预览、导出或日志入口，再比较修改前后实际交给内核的结果。

Clash Plus 可以作为多平台客户端的优先选择，具体支持的配置入口以实际界面为准；需要安装时到客户端下载页按平台选择。Clash Verge Rev、FlClash 等客户端的扩展配置名称与执行顺序也可能不同。不要照着另一款客户端的按钮名称操作，更不要为了保留本地规则，去改客户端每次都会自动生成的临时文件。

对象合并与列表合并不同

对象字段可能采用递归合并，也可能整段替换；列表则可能替换、前插、后插或去重。比如只覆写 DNS 的一个子键，有的机制会保留原来的其他 DNS 字段，有的机制要求重新提供完整对象。规则列表尤其敏感：把自定义规则追加在原有 MATCH 后面，文件看起来已经包含规则，实际却永远没有机会命中。

# 仅作为支持对应合并语义的客户端覆写示意
# 不是可直接交给所有内核的通用字段
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
append-proxies:
  - name: 本地SOCKS
    type: socks5
    server: 127.0.0.1
    port: 1080

prepend-rules、append-proxies 一类名称表示客户端可能提供的合并操作，不应未经确认就放到普通 config.yaml 顶层。内核原生运行配置最终仍应得到常规的 rules 和 proxies 列表。如果当前客户端没有支持这些键，就使用它自己的合并入口或扩展方式，而不是不断重复粘贴相同片段。

本地 SOCKS 片段还要求对应服务真实监听在指定地址与端口；新增一个节点定义不会启动那个服务。追加节点之后，通常也要把它加入某个策略组，才能在界面选择。若组由提供器自动生成，还需确认本地追加节点是否会被纳入。配置中存在一个节点，与规则能够到达这个节点，是两件需要分别检查的事。

按小范围修改保留可维护性

长期维护时，应优先覆写少量明确字段，而不是复制整份订阅再长期分叉。完整复制会把节点变化、策略组调整和规则资源更新的责任也带到本地。若需求只是让一个域名直连，就保留一条可解释的前置规则；若需求只是固定端口，就只改入口字段。改动越小，订阅结构变化后越容易发现冲突，也更容易回退。

需要脚本式加工时，把它视为配置构建程序，而不是一段随意粘贴的文本。脚本可能因字段不存在、列表为空或名称变化而失败，必须有明确的输入假设与失败行为。不要让脚本把认证信息写到控制台，也不要依赖节点列表中的固定下标。可使用稳定的组名或明确条件进行处理，但处理后仍要检查是否出现空组、重复名称和失效引用。

确认持久化是否成功，要做两次验证：先重新加载本地配置，看本次运行是否正确；再执行一次订阅更新，确认本地改动仍然存在且位置正确。最后关闭并重新打开客户端，检查历史状态是否影响结果。只在编辑后立即测试一次，无法证明更新链路正常。保留原始订阅和本地覆写的分工记录，后续迁移客户端时也能更清楚地重建配置。

配置验证与故障定位

验证应分成三个层次：文件能否解析、内核能否启动、真实请求是否走到预期出口。通过第一层不代表后两层成功，测试目标可达也不代表所有应用都已被接管。把这三层分开，排查通常比反复重装更快。每次只改一个问题相关的字段，并保留修改前的配置与一条可复现请求，才能判断变化到底带来了什么。

先做静态检查，再重新加载

使用独立 mihomo 内核时，可以用配置测试参数检查文件；图形客户端则优先使用自身提供的检查与重新加载功能。命令需要在拥有相应程序和文件的目录中执行，程序不在环境变量里时使用实际路径。以下命令不会替应用自动设置系统代理，也不能证明远端节点在线，它主要用于提前发现解析、引用及相关配置错误。

mihomo -t -f ./config.yaml

若使用 Windows 的命令环境，程序名和路径可能需要写成实际的可执行文件形式。错误消息指向某一行时，除了看该行，也要检查前一条列表、引号是否闭合，以及上一层缩进是否正确。若错误是引用不存在的策略，搜索该名称的定义与所有使用位置，不要只把报错行删掉；直接删掉规则可能让流量落到另一个兜底出口。

按连接经过的阶段读日志

重新加载后，先确认配置加载成功，再看监听是否建立。端口被占用、权限不足、提供器文件无法读取，都可能出现在发起网页请求之前。若客户端无法启动，可以先看启动崩溃的逐项处理。内核已经工作后，再发起一个新请求，沿着 DNS、规则命中、策略选择、远端连接的顺序核对，不要把所有错误统称为网络问题。

日志中的超时需要结合目标与阶段解释。解析服务器超时，先查 DNS 上游路径；连接代理服务器超时，先查节点地址、端口和当前网络；代理已建立但目标站超时，则继续看服务端出口与目标可达性。单独一行错误通常不足以下结论，前后几行及同一时间的连接详情更有价值。阅读方法可参考运行日志含义与定位步骤。

用最小实验区分问题

先固定一个手动节点，关闭不必要的自动切换，再选择一个明确支持代理的应用发起请求。若这个入口可用，而启用 TUN 后失败，就把注意力放在权限、路由、DNS 劫持与其他虚拟网卡，而不是继续改节点密码。若直连与代理都不能解析同一域名，则先处理解析路径。每一步只改变一个条件，实验结果才有可比较性。

测试自定义规则时，用一条精确域名规则放到前面，并建立新连接观察命中。若精确规则有效而大规则集合无效，检查集合格式、加载状态和外层顺序；若精确规则也不命中，检查请求主机名是否与预期相同。网页可能请求多个域名，首页打开不代表页面中的全部资源都使用同一出口，因此应针对实际失败的那条连接检查。

重载配置后还要考虑旧连接、DNS 缓存与历史选择。长连接可能继续使用原出口，浏览器可能复用现有连接池，客户端也可能恢复此前保存的策略。需要干净实验时，先保存现场，再结束相关连接并重新发起请求。不要一边保留旧会话，一边仅根据界面上的新组名推断所有流量已经迁移，否则很容易得到互相矛盾的观察。

回退与分享排查信息

修改失败时回到最近可用配置，而不是在错误基础上连续叠加更多开关。可以按端口、DNS、节点、策略组、规则、覆写的顺序重新加入改动，每次记录成功与失败边界。请求帮助时说明操作系统、客户端名称、所用内核、失败阶段和最小相关片段即可。订阅地址、密码、用户标识及控制凭据应先移除，公开截图也要检查侧栏和日志中的敏感内容。