策略组类型与实际选择
策略组决定一条命中规则的连接最终交给哪个节点或出口。排查分流时先看规则指向的组名，再看组当前选中的成员；只看代理列表里哪个节点显示可用，不能推断这条连接会使用它。常见配置把节点放入「手动选择」，再让「自动选择」「故障转移」等组引用相同节点，最后让业务规则指向这些上层组。组名必须与规则末尾写的目标完全一致，包括大小写和空格。订阅更新带来新节点后，也要核对节点筛选是否仍能覆盖预期名称。
四种选择逻辑
select 保留用户指定的成员，适合需要固定出口的登录或远程访问；它不会因为测试结果改变而自行换节点。url-test 按测试 URL 的响应时间选择成员，适合可接受出口变化的日常浏览。fallback 按成员顺序使用第一个可用项，更适合希望主线路优先、断开后才切换的场景。load-balance 把不同连接分配到不同成员；同一网站若依赖稳定出口，先不要把其登录流量交给负载均衡组。测试通过只表明测试地址可达，不代表所有目标站点都可用；遇到单站失败，仍需查看实际连接记录。
| 类型 | 出口何时改变 | 优先检查 |
|---|---|---|
select | 用户手动选择成员时 | 当前选中项、成员名称 |
url-test | 定期测试后选出较快成员时 | 测试地址、间隔、容差 |
fallback | 前序成员测试失败时 | 成员排列顺序、测试状态 |
load-balance | 新连接进入组时 | 分配策略、目标网站会话 |
把节点放进可核对的组
下面假定配置中已有名为「节点甲」和「节点乙」的代理。实际使用时，以订阅提供的节点名称替换这两个成员，且不要同时创建两个同名策略组。interval 的单位为秒；tolerance 为自动选择时允许保留当前成员的延迟差值，用于减少相近结果造成的频繁切换。测试 URL 应当是自己网络中稳定可访问、返回简短响应的地址，不宜拿需要登录的网站做探测目标。
proxy-groups:
- name: 手动选择
type: select
proxies:
- 节点甲
- 节点乙
- DIRECT
- name: 自动选择
type: url-test
proxies:
- 节点甲
- 节点乙
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 故障转移
type: fallback
proxies:
- 节点甲
- 节点乙
url: http://www.gstatic.com/generate_204
interval: 300
rules:
- DOMAIN-SUFFIX,example.org,手动选择
- MATCH,自动选择选择逻辑还有一层容易忽略的区别：节点测试是对组成员进行的，实际请求则先经过规则匹配。若一条直连规则排在示例的域名规则前面，该请求根本不会进入「手动选择」。诊断时打开客户端「连接」，找到目标域名和命中的规则，确认规则指向哪个组；随后在「代理」里检查该组成员及选中状态。改动后若旧连接仍显示原出口，断开这条连接再发起新请求，因为已建立的连接通常不会在中途改道。
最后检查兜底规则。MATCH 通常放在规则列表末尾；它决定前面规则都未匹配时的出口。把它放在前面，会使后续细分规则失去作用。若希望临时诊断规则是否生效，可以让某个明确域名指向手动组，发起新连接并观察记录，而不是直接把全部流量切到全局模式。测试完删除诊断规则，恢复原有顺序和选中项，这样变更范围可追踪。
规则集订阅化管理
规则集把频繁变化的域名或 IP 条目从主配置中拆出来，由 rule-providers 描述来源、格式和本地缓存位置，再在 rules 中用 RULE-SET 指向它。这样更新规则内容时不必逐条改写主配置，但也多了一条加载链路：规则集下载、解析、缓存与引用，任何一步失败都可能使预期分流落空。先确认自己需要的是远程规则集，还是少量长期不变的本地规则；只有几条自定义域名时，直接写在 rules 里更容易维护。
区分规则集的内容格式
behavior: domain 用于域名条目，behavior: ipcidr 用于网段，behavior: classical 则可承载完整的经典规则表达式。format: yaml 与 format: text 要与下载内容一致，不能只看文件扩展名。一个 YAML 规则集一般在 payload 下列出条目；经典规则集可以含 DOMAIN-SUFFIX 等类型前缀。把经典规则文本按域名规则集加载，或把网页错误提示当成规则文件缓存，都会导致解析失败。首次引用远程地址前，先在浏览器中确认返回的是规则内容，而非登录页或重定向后的说明页。
示例使用文档域名展示字段关系，地址不是可订阅的规则源。实际部署须换成自己信任的规则集地址，并根据该文件调整 behavior 与 format。缓存 path 使用配置目录下的相对路径，多个 provider 不应写到同一个文件；interval 控制更新检查周期，而不是每次请求都重新下载。
rule-providers:
work-domains:
type: http
behavior: domain
format: yaml
url: https://example.com/rules/work-domains.yaml
path: ./rules/work-domains.yaml
interval: 86400
rules:
- RULE-SET,work-domains,手动选择
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,自动选择与上例对应的 work-domains.yaml 可以写成如下形式。域名规则集中写域名条目，不要在每一行重复添加主配置 rules 列表使用的策略组名；出口由引用它的 RULE-SET 行指定。同一规则集也可以被多个规则行引用，但应检查顺序，前一条已命中时后一条不会再参与选择。
payload:
- example.net
- '+.example.org'按加载链路排错
更新后先看客户端是否报告规则集下载或解析错误，再看缓存文件是否存在、内容是否仍是预期格式。能下载但规则不生效时，检查 RULE-SET 写的 provider 名称、对应的策略组名称，以及它在 rules 中的位置。域名类规则依赖可供匹配的域名信息；只有目标 IP 的连接不一定会按预想命中域名规则。IP 类规则还要注意 DNS 解析及 no-resolve 等选项对匹配路径的影响，不应为了让某一条规则命中就一次性改动全部 DNS 设置。
订阅本身也可能提供规则和规则集。若客户端每次更新订阅都会覆盖主配置，直接修改下载后的配置只是一次临时变更，应改用客户端的覆写功能，或在自己维护的配置中固定规则来源。迁移规则时先保留一条已知可验证的域名，重载后在「连接」中确认它命中了新的 RULE-SET，再批量迁移其他条目。不要同时启用两套作用重叠、优先级不明的远程规则；先弄清楚谁在前、谁负责兜底。
DNS 配置与解析路径
DNS 设置影响两件不同的事：目标域名如何解析，以及代理服务器自身的域名如何解析。先分清浏览器发出的 DNS 请求是否进入客户端，再讨论解析服务器列表。系统代理通常接管应用的 HTTP 或 SOCKS 流量，但并不等于接管系统里所有 DNS 查询；TUN 模式及其 DNS 劫持设置又是另一条路径。若域名能解析却连不上，应同时检查规则命中、节点可达性和目标连接日志，不能只凭「网页打不开」判断 DNS 出错。
认识几组服务器字段
default-nameserver 主要用于解析 DNS 服务器本身的域名等引导阶段，宜使用能直接访问的 IP 地址。nameserver 是常规查询使用的服务器列表；proxy-server-nameserver 可以单独指定解析代理节点域名的服务器，避免节点解析受业务域名分流设置影响。nameserver-policy 则按域名指定解析器。不要把服务器 URL、普通 IP 和带端口地址的写法混为一谈：填入的协议形式要与当前内核支持的 DNS 上游一致，且相关网络必须能够到达上游。
下面片段展示最小的分工，不要求把自己的解析器全部换成示例地址。启用前先核对当前网络能否访问这些地址，尤其是在受限网络或需要内部 DNS 解析办公域名的环境中。respect-rules 等进一步影响 DNS 出站路径的选项，应该在已经确认基础解析正常之后再评估，避免解析器与代理节点的域名解析相互依赖。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 1.1.1.1
nameserver:
- 1.1.1.1
- 8.8.8.8
proxy-server-nameserver:
- 1.1.1.1
fake-ip-filter:
- '*.lan'
- localhost.ptlogin2.qq.comipv6: false 只是示例选择，不表示所有网络都应关闭 IPv6。如果本机、上游解析器和代理链路都能正常使用 IPv6，应结合实际访问需求决定。fake-ip-filter 用于让部分域名返回真实解析结果，适合依赖局域网发现或不能接受 Fake-IP 的应用；条目越多，越需要确认是否意外绕开预期匹配路径。内部域名最好由能解析该域名的内部 DNS 处理，而不是期待公共解析器返回局域网地址。
用一条请求定位问题
先确认客户端 DNS 功能已启用，重载配置后查看日志是否提示上游不可达。接着用目标域名发起新连接，记录它是拿到真实地址、Fake-IP，还是根本没有得到响应。若客户端日志没有该查询，检查应用是否使用了自己的安全 DNS、系统是否仍指向其他解析器，以及当前代理模式是否接管了这类请求。若日志有查询但返回不合预期，检查 nameserver-policy 命中项、Fake-IP 过滤和本地缓存；改变配置后可按客户端提供的缓存清理方式重新测试，避免把旧答案误认为新设置的结果。
DNS 服务器的响应正常也不意味着后续连接一定正常。测试时最好选一个确知域名和出口策略的请求，同时在「连接」里查看最终规则；若连接命中 DIRECT，就沿直连网络继续检查，若命中某个策略组，再核对该组节点。办公网络尤其需要保留内网域名解析路径：先记下原有 DNS 设置，再逐项调整，不要在排查过程中同时修改 DNS、规则和 TUN。这样至少能知道问题从哪一次变更开始出现。
TUN 模式与 Fake-IP 配合
系统代理与 TUN 的覆盖范围不同。系统代理要求应用遵循操作系统的代理设置；TUN 建立虚拟网络接口，让更多未主动读取代理设置的流量进入客户端。开启 TUN 不是让所有问题自动消失：路由安装、DNS 劫持、其他 VPN、局域网访问和系统权限都会影响结果。首次启用时，先确认普通系统代理下已经能完成连接，再记录当前的 DNS 和路由状态；这样 TUN 开启后出问题，可以分辨是原有配置问题还是新接管路径的问题。
从最小配置开始
auto-route 让内核尝试配置路由，auto-detect-interface 用于识别实际出站接口；网络接口经常变化的设备尤其需要核对识别结果。dns-hijack 中的 any:53 表示接管符合条件的传统 DNS 查询，但它不能保证接管应用自己建立的加密 DNS 连接。不同客户端可能用界面开关写入这些字段，也可能要求系统授予网络扩展或虚拟接口权限；以客户端显示的生效配置为准，不要只看开关表面状态。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16stack: mixed 是一种可供测试的网络栈选择。若特定应用握手或局域网访问异常，可以在记录症状后比较客户端支持的其他栈，而不是同时调整所有路由参数。设备已有企业 VPN、另一套透明代理或虚拟机网桥时，要留意路由优先级与接口冲突：两套软件都试图接管默认路由，可能导致反复断连，甚至让本应走内网的地址进入错误出口。先暂时停用另一套接管工具作对照，再决定是否需要排除路由或调整接口。
理解 Fake-IP 的对应关系
Fake-IP 不把目标域名立即解析成真实地址，而是给应用一个合成地址，并在内核中保留域名与该地址的对应关系。后续连接到达时，内核据此恢复域名，让域名规则可以参与匹配。这个机制依赖 DNS 查询和随后的连接都沿着可关联的路径进入客户端；如果应用使用另一条 DNS 通道，或缓存了旧地址，域名与连接可能对不上。遇到某应用只显示 IP、不命中域名规则的情况，先比较它的 DNS 查询与连接是否都出现在日志中。
局域网设备发现、打印机、投屏或某些只认真实地址的应用，可能不适合收到 Fake-IP。先针对明确的域名添加过滤项，再测试设备发现和连接，不宜把整个域名后缀列表大范围排除。若局域网 IP 仍无法访问，查看规则是否将私有地址送入代理组，并检查操作系统防火墙与本地网络权限；Fake-IP 过滤只能处理解析结果，不能代替路由规则。诊断完成后分别测试浏览器、一个不遵循系统代理的应用及一个局域网服务，确认 TUN 确实解决了需要接管的流量，同时保留了本地访问。
域名嗅探与规则命中
当客户端只看到目标 IP，却需要依据域名规则判断出口时，域名嗅探可以尝试从连接的协议握手中取得域名。它主要观察 HTTP 请求或 TLS、QUIC 握手中可见的信息，不是读取网页内容，也不能凭空得知所有加密连接的原始域名。嗅探到的域名是否替换连接目标、是否参与路由，要由相应选项决定。启用前先看「连接」：如果目标域名本来就完整可见，且规则命中正常，就不必为了显示更多域名而扩大嗅探范围。
限定协议与端口
下面示例只展示常见的 HTTP、TLS 与 QUIC 入口。ports 限制检查范围，override-destination 决定是否根据嗅探结果覆写目标；先保留与当前应用相符的端口，再针对异常连接测试。QUIC 基于 UDP，若你的网络或客户端未接管相关 UDP 流量，单独写一个 QUIC 嗅探项不会使这些连接进入内核。HTTP 的非标准端口同理，需要按实际服务端口逐项核对。
sniffer:
enable: true
sniff:
HTTP:
ports:
- 80
- 8080-8880
override-destination: true
TLS:
ports:
- 443
QUIC:
ports:
- 443
skip-domain:
- '+.lan'示例中跳过局域网域名，是为了避免对已明确应走本地网络的目标做额外判断。实际配置还应结合自己的应用：某些程序通过 IP 连接服务器，却在 TLS 握手里携带与访问目的不同的域名；若强制以嗅探结果覆写目的地，可能改变原来的路由行为。发现特定服务启用嗅探后才失败时，先对照开启前后的目标地址、命中规则与错误日志，再为该目标设置排除条件，不要直接关闭所有规则分流。
把嗅探放进完整排查链
一条连接最终能否按域名分流，至少要核对三处：DNS 是否提供了可关联的域名，嗅探是否取得并采用了域名，规则列表是否在兜底规则前命中相应域名条目。若「连接」里只显示 IP，先确认这是不是应用本来就使用的固定 IP；若有域名但仍走错出口，优先查规则顺序和策略组，而不是继续增加嗅探协议。对于启用了 Fake-IP 的流量，还要排除应用 DNS 与连接未走同一接管路径的情况。
嗅探不适合用作「把所有 IP 都变成域名」的通用开关。不是所有协议都有可识别的主机名，协议更新也可能改变握手中可见的字段。日志中没有嗅探结果，不等于客户端没有处理该连接；应回到连接目标、规则命中和最终出口三项可验证的信息。调整时按应用测试：一次只改一个协议或排除项，断开旧连接后重新发起请求。如果问题仅在浏览器出现，还应确认浏览器是否启用了独立 DNS 或 QUIC，与其他应用的流量路径是否相同。
本地覆写与多订阅合并
订阅文件由提供方更新，直接编辑下载后的副本往往只会保留到下一次刷新。本地覆写的目的，是把自己长期维护的端口、DNS、规则和策略组调整，与会更新的节点信息分开。不同客户端对覆写的实现不完全相同：有的在导入配置后执行补丁，有的按字段合并，有的通过脚本生成最终 YAML。先在客户端界面找「覆写」「配置合并」或同类入口，弄清执行顺序，再用一个容易观察的字段做试验。不要假设数组一定会追加；规则和策略组若被整体替换，原有分流可能消失。
先辨认最终生效文件
可靠的检查对象不是编辑器里那份片段，而是客户端加载后的完整配置。核对 mixed-port、mode、dns、proxy-groups 和 rules 是否都只保留了预期内容。下例是一段可以放入自管配置的顶层设置示意；若客户端覆写界面只接受某种补丁格式，应按该界面要求转换，不能把下例当成所有客户端通用的覆写文件。端口发生冲突时，先确认哪个进程占用该端口，再修改配置并同步更新使用该端口的应用。
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info多订阅合并还涉及节点命名。两份订阅可能都提供「自动选择」「默认节点」或相同地区名称；如果合并工具依名称覆盖，最终配置可能引用了另一份订阅的成员。合并前先保留原始订阅，记录各自节点命名和更新频率；合并后检查最终 proxies、proxy-providers、proxy-groups 的名称引用。节点列表只是原料，仍需要明确谁负责选择节点、规则指向哪个组，以及订阅更新时新节点怎样进入组。
固定更新后的验证步骤
先让每份订阅分别完成一次更新，确认原始配置可解析；然后应用本地覆写，查看最终配置能否加载。接着检查一条直连规则、一条代理规则和最后的 MATCH，分别新建连接确认命中结果。最后刷新订阅再测一次：如果首次成功、更新后失效，重点检查覆写是否被重新应用，以及组成员筛选是否匹配更新后的节点名称。记录失败发生在下载、合并、解析还是连接阶段，可以避免把四类问题混在一起处理。
对于规则列表，建议明确由一个位置负责最终顺序。若订阅甲的 MATCH 排在订阅乙的细分规则前，乙的规则永远不会被执行；若合并工具把多个同名组直接拼接，也可能出现引用不明确。保留一份能正常连接的原始配置，并在每次大幅改动前复制当前可用的覆写内容。需要理解订阅链接究竟提供完整 YAML 还是节点列表时，可参阅订阅格式与转换说明；格式转换并不保证原有规则和策略组会完整保留。
外部控制面板与配置检查
外部控制接口让兼容的面板读取连接、规则和策略组状态，也可能允许切换策略或重载配置。它和混合代理端口不是同一种服务：mixed-port 接收应用流量，external-controller 提供管理接口。诊断配置时，面板适合用来核对当前组的选择、查看实际连接与规则；但面板里看到的结果仍以正在运行的内核为准。如果客户端内置界面已提供这些信息，可以先使用内置界面，不必额外开放网络管理入口。
先绑定本机地址
只在当前电脑访问面板时，把控制接口绑定到 127.0.0.1，不要为了连接本机面板就改成对所有网卡监听。示例中的空 secret 只适用于本机隔离的测试情形；如确需让局域网设备访问，应设置独立的管理密钥、限定可访问的网络，并检查系统防火墙。不要把订阅链接、管理密钥或含节点凭据的完整配置粘贴到不明来源的在线面板。
external-controller: 127.0.0.1:9090
secret: ""
mixed-port: 7890
mode: rule控制接口地址由内核提供，面板自身还需要知道连接地址；有的客户端内置面板会自动读取，有的独立面板要求手动填写。连接不上时，先确认内核确实加载了这段配置，再确认端口没有被其他进程占用、面板连接的是同一台设备，以及浏览器或系统代理没有把本机控制请求送到远端。修改端口后应同时修改面板里保存的地址。出现鉴权错误时核对控制接口的密钥设置，不要把节点订阅密码误填为面板密钥。
从面板结果回到配置文件
面板能显示某组，不代表规则已经引用它；某组能切换，不代表新连接必然走这个组。逐项核对时，先在「配置」确认当前载入的是哪份文件及其更新状态，再在「规则」检查目标域名对应的规则，最后在「连接」查看这次请求的匹配结果。若客户端切换配置后面板仍显示旧组，可以刷新面板并核对控制接口连接的是不是另一个正在运行的内核实例。不要仅凭面板缓存的展示内容改写配置。
配置加载失败时，先看日志中出现的字段和行号，检查 YAML 缩进、重复顶层键、规则指向的组名，以及 provider 的本地路径。YAML 使用空格表达层级，列表项的短横线必须位于预期层级；从网页复制配置时，混入制表符或全角标点也会让解析失败。先回退到保存的可用配置，再逐段加入本页示例并重载，比在已经失效的完整文件上连续猜测更稳妥。如果只是首次安装后不知道如何完成连接，回到快速上手；若需要更换图形客户端，在安装包页面按平台选择，Clash Plus 是其中的首推选项。