Clash 配置进阶手册

配置模型、加载顺序与验证基线

先区分客户端、内核与配置来源

Clash 生态中的桌面或移动客户端负责订阅管理、配置编辑、系统权限申请和界面展示，实际处理连接的是内核。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客户端都可能调用兼容内核，但各自对订阅覆写、配置合并和外部界面的实现方式不同。排查时必须先确认问题属于哪一层：下载与安装问题属于客户端层，YAML 字段不被识别属于内核与配置层，节点本身不可用则属于代理链路。将三层混在一起判断，常见结果是反复更换客户端却没有修正错误规则。

配置通常来自四类来源：客户端自身生成的基础字段、订阅返回的节点与策略、用户编写的本地覆写，以及运行时状态。运行时状态包括当前选中的策略、缓存的规则集和 DNS 映射，它们不一定完整写回 YAML。某些客户端在更新订阅时会重新生成配置，如果直接编辑生成后的临时文件，下一次更新就可能覆盖修改。长期配置应放入客户端明确提供的覆写、合并或脚本入口；只用于测试的改动才适合直接编辑当前配置。

理解从入站到出站的数据路径

一个连接进入内核后，通常依次经历入站识别、域名恢复或嗅探、规则匹配、策略组决策和代理出站。启用 TUN 后，系统路由会先把流量交给虚拟接口；启用 Fake-IP 后，DNS 查询可能先得到保留地址，再由内核依据映射表恢复原始域名。规则中的 DOMAIN-SUFFIX、GEOSITE 或域名规则集依赖域名信息，而 IP-CIDR、GEOIP 则处理目标地址。理解这条路径后，才能解释为什么同一个应用在系统代理模式下正常，在 TUN 模式下却命中了不同规则。

规则按顺序匹配，首条命中后停止继续检查。因此具体域名、业务专用规则和拦截规则应位于通用地域规则之前，MATCH 必须放在末尾。策略组只是规则的目标名称，不会主动匹配流量。例如规则写入 DOMAIN-SUFFIX,example.com,工作流量 后，配置中必须存在名称完全相同的策略组或代理节点；全角空格、大小写差异和重命名遗漏都会造成载入失败或无法选择。

建立最小可工作的配置

复杂配置不应从数百行模板直接开始。先保留一个监听端口、一组节点来源、一个手动选择组和一条兜底规则，确认配置能载入并完成连接，再逐步加入规则集、DNS 与 TUN。下面的骨架展示字段之间的引用关系。示例节点地址使用保留域名，仅用于说明结构，不能直接建立代理连接。

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

proxies:
  - name: Example-Node
    type: socks5
    server: proxy.example.com
    port: 1080

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,手动选择

载入时先检查缩进。YAML 使用空格表达层级，Tab 字符、同级字段缩进不一致、冒号后缺少空格都可能导致解析失败。名称中包含冒号、井号、方括号或前后空格时，建议使用引号包裹。数组既可以写成多行列表，也可以写成方括号形式，但同一段保持一种写法更便于审查。布尔值使用 true 或 false，不要混用界面里常见的“开启”“关闭”文本。

配置变更的回归检查

每次修改后至少验证四类流量：明确要求直连的站点、明确要求代理的站点、使用纯 IP 的连接，以及本地局域网服务。浏览器访问成功不能代表所有应用都正常，因为浏览器可能启用独立的安全 DNS 或基于 QUIC 的连接。建议同时使用系统命令检查解析结果和连接路径，例如执行 nslookup example.com 查看系统 DNS，再用 curl -I https://example.com 验证命令行程序是否经过预期入口。若系统代理与 TUN 同时开启，还应分别关闭其中一项复测，排除重复接管。

配置文件的稳定性取决于可回滚性。保留“最近可用”“当前测试”和“计划上线”三份状态，比不断覆盖同一个文件更安全。修改策略组名称时，应全局搜索规则、规则集、子策略组和快捷脚本中的旧名称。删除节点提供器前，应确认没有策略组通过 use 引用它。只有配置能在客户端重启、订阅更新和设备重启后保持一致，才算完成验证。

策略组类型与实际组合方式

select：把最终选择权交给使用者

select 是最基础的策略组类型。组内可以放节点、DIRECT、REJECT，也可以引用其他策略组。它不执行自动测速，只记录当前选择。适合“总出口”“工作业务”“流媒体”等需要明确控制结果的顶层策略。客户端通常会保存选中状态，但保存位置可能是运行时缓存而不是原始配置。若希望重启后延续选择，可启用内核支持的 profile.store-selected，同时确认客户端没有在每次启动时重置配置。

顶层选择组不宜直接堆入数百个节点。更清晰的方式是将自动测速、故障转移和地区节点分别组织成子组，再由顶层组选择这些子组。这样规则只依赖稳定的顶层名称，订阅节点增减不会迫使规则同步改写。对于需要临时直连的业务，可在顶层组加入 DIRECT，但应清楚这会绕开代理链路，不适合要求固定出口的连接。

url-test：按探测结果选择可用节点

url-test 会按设定的 URL 周期性探测节点，并选择响应表现符合条件的节点。测试结果只能反映探测目标的连接情况，不代表所有网站和协议都具备同样质量。测试地址应稳定、响应体小，并使用实际需要的协议。过短的 interval 会增加后台请求和移动设备耗电；过大的间隔则可能在节点失效后较晚切换。tolerance 用于减少多个相近节点之间频繁跳转，数值越大，当前节点在差异较小时越容易被保留。

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 总出口
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

lazy: true 表示策略组在实际使用时再进行必要测试，可减少未使用分组的后台探测。若界面显示所有节点都超时，先不要直接得出节点全部失效的结论。应检查测试 URL 是否可从当前网络访问、DNS 是否正确、系统时间是否准确，以及代理协议所需的握手是否被网络入口阻断。可参考节点超时排查顺序逐层确认。

fallback：优先顺序与故障切换

fallback 关注可用性和列表顺序。它通常优先使用列表中靠前且通过探测的节点，当前节点失效后切换到后续可用项。与 url-test 相比，它更适合固定主备出口、需要保持来源地址相对稳定的服务。将低延迟节点放在最前面并不一定合理；如果业务依赖固定地区或固定供应来源，应先按业务约束排序，再考虑响应时间。

故障转移不是会话迁移。已有 TCP 连接在出口切换后通常需要重新建立，下载、远程终端或长连接可能中断。对连续性要求较高的任务，应在应用层设置重试，并避免频繁健康检查造成误切换。节点短暂抖动时，可适当增加探测间隔或通过组内顺序保持首选出口，不应单纯追求最短测试时间。

load-balance：连接分配而不是带宽叠加

load-balance 会将不同连接分配到多个节点。它不会把单个 TCP 连接拆分后叠加多条线路带宽。常见策略包括按目标地址保持一致的散列方式，以及更均匀轮转连接的方式。需要登录状态、来源地址校验或风控稳定性的业务，应使用能保持同一目标映射的策略，或者直接使用 select 与 fallback。轮转方式适合相互独立的短连接，但可能导致同一服务在短时间看到多个出口地址。

用过滤器管理订阅节点

节点提供器可以通过 filter、exclude-filter 或客户端提供的正则筛选入口生成地区组。正则应匹配订阅中真实存在的命名方式，不要假设所有提供方都使用相同缩写。先在客户端中查看节点原名，再编写表达式；匹配结果为空时，策略组可能没有可选项。地区名称包含多个写法时可使用分组表达式，例如 (香港|HK|Hong Kong)。排除“到期”“剩余流量”等信息节点时，应单独写排除条件，防止其进入测速组。

策略组设计的核心是稳定引用：规则引用少量固定组名，组内再组织不断变化的节点。常用结构可以是“总出口”引用“自动选择”“故障转移”“地区选择”和“DIRECT”；业务规则只指向“总出口”或少数专用组。若每个规则集都创建一个功能相同的策略组，配置会迅速膨胀，更新订阅后也更难确认实际出口。优先保持组名语义清楚、层级不超过三层，并避免两个策略组互相引用形成循环。

规则集订阅化管理与匹配顺序

把规则内容与策略决策分离

规则集提供器 rule-providers 用于从本地文件或远程地址加载一组规则。它解决的是规则内容更新问题，不负责决定使用哪个节点。主配置通过 RULE-SET,规则集名称,策略组名称 将规则内容连接到策略决策。相同规则集可以在不同配置中指向不同策略组，也可以通过更换策略组实现临时调度，而不必修改规则文件本身。

订阅化管理适合体量较大、需要独立更新的域名分类、IP 网段和业务列表。只有几条且长期稳定的本地规则，直接写入 rules 更容易审查。不要为了形式统一，把所有单条规则都拆成远程文件；远程来源增加了下载失败、缓存失效和格式变化三个变量。关键的本地网络、管理地址与最终兜底规则应留在主配置中，即使外部规则集暂时不可达，基础路由仍然可预测。

behavior 决定规则文件的语义

behavior: domain 用于域名集合，内容通常是完整域名、域名后缀或特定域名表达；behavior: ipcidr 用于 IPv4 与 IPv6 网段；behavior: classical 则允许每一项携带完整规则类型，例如 DOMAIN-SUFFIX、PROCESS-NAME 或 IP-CIDR。主配置声明的行为必须与文件内容一致。将 IP 网段按 domain 读取，或把完整经典规则按纯域名集合加载，都可能导致解析错误或规则没有命中。

规则格式还可能是 YAML 文本、普通文本或内核支持的二进制规则格式。二进制格式加载效率较高，但不适合直接人工审阅；文本格式更便于排查和版本比较。客户端与内核支持范围并不完全一致，迁移配置时应先确认目标内核是否识别对应 format。当兼容性比体积更重要时，优先选择目标客户端已验证支持的 YAML 或文本形式。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.com/private-domain.yaml
    interval: 86400

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./rules/service-rules.yaml
    url: https://rules.example.com/service-rules.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,总出口
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,总出口

path 是规则集的本地缓存位置。不同提供器不要共用同一个路径，否则更新时可能互相覆盖。路径所在目录需要具备写入权限，移动端和受限桌面环境则通常由客户端代管。interval 以秒为单位控制更新周期；规则并非越频繁更新越好，过短周期会增加启动请求和来源压力。业务变化不频繁时，按日更新通常比每几分钟刷新更稳妥。

规则顺序比规则数量更重要

内核从上向下匹配。私有网络、局域网域名和必须直连的管理地址应靠前；精确业务规则应位于宽泛地域规则之前；需要拦截的规则必须在可能放行它们的通用规则之前；MATCH 只负责处理此前未命中的连接。若把大范围域名集合放在顶部，后续更具体的规则即使写得正确也不会执行。

域名规则通常不需要先解析 IP，匹配成本与结果也更直接。IP 类规则可能触发域名解析；如果规则仅用于检查已经明确的目标地址，可按内核语法添加 no-resolve，避免为了匹配规则额外发起 DNS 查询。但不能机械地给所有 IP 规则加该参数：当连接只携带域名而规则又需要依据目标 IP 判断时，禁止解析会让规则失去匹配条件。应根据入站是否能提供地址、DNS 模式和嗅探状态决定。

本地规则集的结构与测试

YAML 规则集通常以 payload 作为列表入口。domain 行为的文件只保存域名模式，classical 行为的文件则保存完整规则。更新前先对单个文件做语法检查，再让主配置引用。若远程规则集显示下载成功但没有命中，应检查四项：提供器名称是否与 RULE-SET 一致，behavior 是否对应内容，规则是否被更早条目截获，以及目标连接是否保留了域名信息。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,assets.example.com
  - PROCESS-NAME,example-client
  - IP-CIDR,192.0.2.0/24,no-resolve

规则来源失效时，内核可能继续使用已有缓存，也可能在首次加载时因为没有缓存而缺少该组规则。重要规则应准备本地基线，不应让全部访问控制依赖单一远程地址。订阅地址解析异常与规则集格式错误的表现有时相似，都可能显示更新失败；可按订阅失效与配置解析恢复步骤区分 HTTP 响应、文件内容、缓存和 YAML 结构。

建立可维护的命名与变更记录

提供器名称应表达内容而不是来源，例如 work-domain、private-cidr，避免使用“规则1”“最新规则”等无法长期理解的名字。策略组名称面向界面使用者，可以使用中文；提供器与路径名称更适合使用稳定的 ASCII 字符，减少跨平台路径和脚本处理差异。修改远程地址、behavior 或格式时，应视为结构变更，先清理对应缓存再测试，避免旧缓存掩盖新文件的错误。

规则集规模扩大后，建议记录每个集合的用途、数据类型、更新来源、目标策略和最后一次人工验证结果。重点不是追求规则数量，而是确保每一层都有明确职责。命中异常时，通过日志找到首条匹配规则，再回到对应集合定位内容，比盲目调整全局模式有效。有关国内外直连、代理、拦截和兜底的完整排序，可继续阅读规则分流配置实战。

DNS 配置优化与解析分流

DNS 决定规则引擎能看到什么

DNS 配置不只是更换解析服务器。它同时影响域名解析路径、规则能否保留域名、Fake-IP 映射和代理连接如何解析节点服务器地址。系统先把域名交给哪个监听器、查询通过直连还是代理发出、返回真实地址还是保留地址，都会改变后续规则行为。出现“节点可用但网页打不开”“浏览器正常而命令行失败”“同一域名反复命中不同策略”时，应把 DNS 作为独立链路检查。

nameserver 负责常规域名查询；default-nameserver 主要用于解析加密 DNS 服务器自身的域名或建立初始连接，因此通常填写可直接访问的 IP 形式解析器；proxy-server-nameserver 可专门处理代理节点服务器域名，避免节点域名经错误策略解析；nameserver-policy 则按域名指定解析器。字段支持情况取决于内核，客户端界面可能只暴露其中一部分。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query

  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver-policy:
    "geosite:private":
      - system

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "stun.*.*"

示例展示字段关系，不表示所有网络都应使用同一组公共解析器。选择解析器时应先确认当前网络可达性和隐私要求。加密 DNS 地址本身是域名时，内核仍需要一个初始解析途径，这就是 default-nameserver 的作用。若初始解析器不可达，加密查询甚至无法开始。启用 respect-rules 后，DNS 连接会参考规则路由；此时必须避免 DNS 查询为了选择策略又依赖尚未完成的 DNS 结果，形成循环。

redir-host 与 fake-ip 的差异

redir-host 返回真实 IP，行为接近传统 DNS。它对不兼容 Fake-IP 的程序较友好，但域名在解析完成后可能只剩目标地址，TUN 接管的纯 IP 连接未必还能命中域名规则。fake-ip 则从保留地址段返回一个映射地址，应用连接该地址时，内核恢复原域名并执行规则匹配。这样可以减少真实解析结果提前泄露到系统路径，并让域名规则在 TUN 场景中保持稳定。

Fake-IP 不等于代理地址，也不会直接出现在公网。它只在本机内核映射表中代表某个域名。应用拿到保留地址后必须继续把连接交给 Clash；如果系统路由、旁路由规则或安全软件把该地址段截走，连接就会失败。因此 Fake-IP 与 TUN 的路由接管应一起验证，不能只看 DNS 查询是否返回了地址。

fake-ip-filter 的适用边界

局域网发现、打印机、投屏、时间同步、部分语音通话和依赖 STUN 的程序可能要求真实地址或特殊 DNS 响应。此类域名可加入 fake-ip-filter，让它们绕过 Fake-IP 映射。过滤范围必须尽量具体。将过宽的通配符加入过滤列表，会让大量域名回到真实解析，削弱域名恢复和规则匹配的稳定性。遇到应用异常时，应先从日志或抓包确定实际查询域名，再添加最小规则，而不是复制一份无法解释的超长过滤清单。

部分内核支持黑名单或白名单式的过滤模式。黑名单表示列表内域名使用真实解析，是常见行为；白名单则可能只对列表内域名启用 Fake-IP。迁移配置时必须同时迁移模式字段，否则同一份域名列表会产生相反效果。客户端界面如果只提供开关，应查看导出的最终配置确认实际值。

IPv6、缓存与浏览器独立 DNS

ipv6: false 通常表示内置 DNS 不返回 AAAA 结果，但不等同于操作系统彻底关闭 IPv6。系统仍可能通过其他解析器得到 IPv6 地址，应用也可能直接连接已缓存的地址。如果网络没有稳定 IPv6 出口，可先在 Clash DNS 中关闭返回，再分别检查系统网卡和浏览器设置；如果网络具备正常 IPv6，则应同时准备 IPv6 路由规则，避免所有 IPv6 连接落入未设计的兜底路径。

浏览器可能启用独立的安全 DNS，绕过系统指向的 Clash DNS。排查时可暂时关闭浏览器独立解析，使用系统命令查询指定监听端口，并清理系统与浏览器缓存。配置改动后仍看到旧地址，不一定是新配置没有生效，可能只是缓存尚未过期。重启内核只能清理内核部分状态，操作系统、浏览器和应用内部缓存仍需分别处理。

TUN 接管、Fake-IP 映射与平台边界

TUN 与系统代理解决不同范围的问题

系统代理依赖应用主动读取操作系统代理设置，通常覆盖浏览器和遵循系统配置的桌面程序。TUN 创建虚拟网络接口，通过系统路由把更多 TCP、UDP 和不读取代理设置的应用流量交给内核。因此，游戏、命令行工具、商店程序或固定直连应用在系统代理下没有进入 Clash，并不一定是规则问题；它们可能根本没有经过代理入口。TUN 扩大接管范围，但同时引入路由、权限、DNS 劫持和局域网访问等额外变量。

启用 TUN 前应先确认普通系统代理模式可用。若节点、策略和 DNS 基线尚未验证，直接开启 TUN 会把入口问题与出站问题叠加。推荐顺序是：关闭 TUN 验证节点，启用 TUN 但暂不调整复杂路由，确认常规网页和命令行连接进入内核，再逐步处理局域网、IPv6、应用排除和严格路由。

tun:
  enable: true
  stack: mixed
  device: Clash
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53
  mtu: 1500

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack、auto-route 与 strict-route

stack 决定 TUN 数据包由哪种网络栈处理。常见值包括系统栈、用户态栈或混合模式。系统栈通常兼容性较直接，用户态栈便于内核完整处理连接，混合模式则尝试在 TCP 与 UDP 场景之间取得平衡。不同操作系统、客户端打包方式和应用协议的结果可能不同，没有适用于所有设备的固定最佳值。出现 UDP、局域网发现或特定应用异常时，切换 stack 是有效对照实验，但每次只改这一项。

auto-route 负责写入系统路由，使目标流量进入虚拟接口；auto-detect-interface 用于识别真实出口网卡，避免数据再次回到 TUN 形成环路；strict-route 会更严格地约束绕行路径，减少部分系统查询或流量绕过接管，但也可能影响多网卡、虚拟机、企业网络和局域网服务。设备同时连接有线、无线、VPN 或容器网桥时，自动检测可能选错出口，应查看路由表确认默认路由。

DNS 劫持与 Fake-IP 地址段

dns-hijack 将常见 53 端口查询交给内置 DNS，确保应用的普通 DNS 请求进入既定解析链路。它不能自动接管应用内置的加密 DNS，也不能修复已被其他安全软件拦截的请求。若系统中同时运行其他 VPN、过滤软件或虚拟网卡工具，多个组件可能争夺 DNS 与默认路由。此时应一次只保留一个接管组件，确认 Clash 单独工作后再恢复其他软件。

Fake-IP 默认使用专用保留网段建立域名映射。该网段必须被 TUN 路由接管，也不能与企业网络、实验环境或其他虚拟网络的实际地址规划冲突。若另一个组件把相同网段当作真实内部网络，应用连接会被送往错误接口。修改 Fake-IP 范围后需要清理 DNS 缓存和内核映射，旧地址不会自动代表新映射关系。

MTU 与连接能建立但传输停滞

MTU 过大时，某些路径上的分片或路径 MTU 探测可能受阻，表现为握手成功、少量数据可传输，但较大页面、上传或特定协议长时间停滞。MTU 过小则增加包数量和处理开销。默认值能覆盖多数以太网环境；移动网络、叠加隧道和部分宽带拨号环境出现异常时，可逐步降低 MTU 做对照，不应一开始就设置极端数值。测试时要覆盖小请求、大响应、上传和 UDP，不要只看首页能否打开。

如果只有部分网站加载到一半，先排除 DNS 与规则问题，再检查 MTU。可观察日志中连接是否已成功建立，以及失败是否集中在大响应。系统命令的具体参数因平台不同而异，但原则相同：发送禁止分片且逐步调整大小的数据包，找到稳定上限，再为隧道头部保留空间。调整完成后复测真实业务，而不是只依赖单次探测。

Windows、macOS、Android、iOS 与 Linux 的差异

Windows 和 macOS 启用 TUN 通常需要管理员权限或系统网络扩展授权；权限被撤销后，界面开关可能仍显示已启用，但路由并未成功写入。Android 与 iOS 通常通过系统 VPN 接口实现接管，同一时间往往只能保持一个此类连接，电池优化、后台限制和按应用代理选项也会影响覆盖范围。Linux 需要检查 TUN 设备、路由写入权限和防火墙规则，服务器环境还要避免把远程管理连接错误送入代理造成失联。

客户端实现决定了界面能否配置应用排除、路由绕过和自动恢复。选择客户端时应以平台能力为准，下载入口可在下载页查看；全平台优先考虑 Clash Plus，桌面端也可按需求比较 Clash Verge Rev、FlClash 与 Clash Nyanpasu。停止维护的 Clash for Windows 和 ClashX Meta 适合兼容旧环境时参考，不应依赖它们获得新增内核能力。

局域网、虚拟机和容器访问

TUN 开启后，私有网段通常应在规则前部直连，并根据实际网络保留路由。只写 GEOIP,LAN,DIRECT 不一定足够，因为流量在进入规则引擎前可能已被系统路由送往错误接口。需要同时检查系统路由、TUN 排除网段和 Clash 规则。局域网存在多个私有网段时，应明确列出实际网段，不要假设所有设备都在同一个子网。

虚拟机、容器与 WSL 类环境可能拥有独立虚拟交换机和 DNS。宿主机启用 TUN 后，子系统流量可能经过宿主机，也可能走单独 NAT。先在子系统中查看默认网关与 DNS，再判断是否需要将 Clash 监听地址开放给局域网。若启用 allow-lan，应配合防火墙限制可信网段，避免将代理端口暴露到不受控网络。排查 TUN 时，始终保留一个不经过该路由的管理通道，以便配置错误后恢复。

域名嗅探的作用、配置与误判控制

嗅探用于补回域名信息

部分连接进入内核时只携带目标 IP，没有可用于域名规则匹配的主机名。域名嗅探会从 HTTP Host、TLS ClientHello 中的服务器名称或可识别的 QUIC 握手信息提取域名，再将其用于规则判断。它不是 DNS 查询，也不会解密 HTTPS 内容；嗅探只读取连接建立阶段本来就可见的元数据。对于 TUN、透明代理和已被应用提前解析的连接，嗅探可以提高域名规则的命中率。

嗅探并非越强越好。连接中没有域名、协议经过特殊封装、应用使用加密客户端问候，或目标为纯 IP 服务时，内核无法可靠恢复名称。错误覆盖目标地址还可能让原本正常的连接走向不匹配的域名。配置应限制协议和端口，并为已知不兼容服务设置跳过规则。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.com"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.example.com"

parse-pure-ip 允许对目标为纯 IP 的连接尝试协议解析；force-dns-mapping 与 DNS 映射协同，帮助恢复此前由内核处理过的域名；override-destination 表示在成功取得域名后，用嗅探结果参与或替换后续目标判断。字段细节会随内核实现变化，导入前应查看客户端最终生成的配置，避免界面开关与手写段落同时存在且互相覆盖。

HTTP、TLS 与 QUIC 的可见范围

明文 HTTP 通常可从 Host 请求头取得域名，但它不一定只运行在 80 端口。将端口范围扩展到常见代理或开发端口有助于识别内部服务，不过范围越宽，内核尝试解析非 HTTP 流量的机会也越多。TLS 嗅探主要读取握手中的服务器名称；如果应用直接使用 IP、服务器名称被隐藏或握手不是标准 TLS，就不会得到有效域名。QUIC 基于 UDP，排查时还要确认 TUN 与节点链路是否支持相应 UDP 流量。

端口列表应来自实际业务。把全部端口都加入每种协议看似覆盖更广，实际上会增加误判和处理成本。常规网页优先覆盖 80、443 与少数明确使用的替代端口。数据库、远程桌面、游戏和语音协议若没有域名规则需求，不应强制按 HTTP 或 TLS 解析。日志中持续出现嗅探失败并不一定影响连接，但说明当前端口范围可能过宽。

force-domain 与 skip-domain

force-domain 用于指定需要优先尝试嗅探的域名模式，适合 DNS 映射不完整但必须按域名分流的服务。skip-domain 用于排除已知不兼容、域名结果不稳定或不应覆盖目标的连接。域名模式的语法应按目标内核要求书写，常见的 +.example.com 表示包含根域及其子域。排除项需要有实际故障依据，不要从陌生模板复制大量与本机应用无关的名称。

若某应用启用嗅探后失败，先比较关闭嗅探时是否恢复，再查看连接日志中提取的域名。若日志域名与应用实际目标不符，将该域名或相关进程加入跳过范围；若根本没有提取到名称，则应回到 DNS、规则和 IP 分流检查，继续增加强制域名不会产生真实信息。嗅探是补充手段，不能替代正确的 DNS 接管。

嗅探与规则顺序的协同

嗅探成功只表示规则引擎获得了域名，并不保证命中预期策略。更早的 IP 规则、进程规则或宽泛规则集仍可能先匹配。排查时应查看日志报告的目标域名、目标地址、命中规则与策略组，而不是只看“sniff success”。如果期望域名规则优先，应将具体域名规则放在可能截获连接的通用 IP 规则之前。

进程规则在不同平台的可用性差异较大。桌面端可能识别进程名或路径，移动端受系统限制往往无法提供同等信息。不要用进程规则替代全部域名规则；更稳定的方式是以域名规则为主，进程规则只处理专用客户端或无法稳定识别域名的流量。进程名也可能随更新改变，应通过日志获取真实名称。

逐步启用而不是一次覆盖全部协议

建议先只启用 TLS 443 端口，在常用网页和应用中观察命中变化；确认无异常后，再加入 HTTP 与 QUIC。每增加一类协议，分别测试直连、代理、局域网和长连接。若启用 QUIC 后只有部分应用异常，可临时关闭 QUIC 嗅探而保留 UDP 转发，区分问题发生在协议识别还是传输链路。

域名嗅探最有价值的场景是透明接管后丢失域名，而不是用于“猜测”所有目标。配置越明确，排错越容易。长期维护时，应记录每个强制或跳过条目的原因，并定期删除已经无法复现的兼容项。若一个服务必须依赖大量嗅探例外才能工作，应重新检查 DNS 模式、Fake-IP 过滤和应用自身的解析方式，根因通常不在嗅探列表本身。

本地覆写与多订阅合并

先确认客户端的合并层级

多订阅合并通常由客户端完成，而不是 Clash 配置格式中的单一通用字段。客户端可能提供基础配置、全局覆写、订阅专属覆写、JavaScript 脚本或可视化合并器。不同入口的执行顺序会影响最终结果：后执行的同名标量通常覆盖前值，映射可以递归合并，数组则可能整体替换、追加或按名称去重。不能把某个客户端的合并行为直接假设为所有客户端都相同。

开始前先导出客户端最终交给内核的配置，并做一个小实验：在订阅中保留两个策略组，在覆写中加入一个组，观察最终数组是追加还是替换。确认行为后再迁移完整规则。Clash Plus 适合作为全平台优先选择，桌面端的 Clash Verge Rev、FlClash 与 Clash Nyanpasu 也提供不同形式的订阅管理能力；具体入口应以客户端当前界面为准。客户端之间迁移时，先迁移标准 YAML，再重建客户端专属合并逻辑。

标量、映射和数组的处理差异

mixed-port、mode、log-level 属于标量，后层配置通常直接替换；dns、tun 属于映射，可能按子字段合并；proxies、proxy-groups、rules 属于数组，最容易出现意外。若合并器把数组整体替换，一段只有三条本地规则的覆写可能删除订阅原有全部规则。若合并器执行追加，本地兜底规则又可能被放到订阅的 MATCH 后面，实际永远无法命中。

因此规则数组需要明确“前置、后置或替换”语义。局域网直连、业务精确规则通常前置，最终 MATCH 保持唯一并位于末尾。策略组数组应按 name 去重；同名但类型不同的组不能简单拼接。节点数组同样需要处理重名，否则界面可能只显示其中一个，规则引用也无法判断实际目标。

# 本地基础覆写：只放长期稳定的标量与映射
mode: rule
log-level: info
ipv6: true

profile:
  store-selected: true
  store-fake-ip: true

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

tun:
  auto-route: true
  auto-detect-interface: true

上面的片段不包含节点、策略组和规则数组，适合由支持递归映射合并的客户端叠加到订阅上。若客户端采用整段替换，仍需在合并预览中确认 dns 其他子字段是否被保留。最稳妥的做法不是猜测，而是查看最终 YAML。任何合并工具只要无法展示结果，就不适合直接用于生产配置。

多订阅节点的命名与来源隔离

两个订阅可能包含相同节点名称。直接合并后，策略选择、健康检查和持久化状态都可能指向错误节点。建议在合并阶段按来源增加稳定前缀，例如“主源 / 节点名”和“备用 / 节点名”，并同步更新策略组引用。前缀不宜包含会随订阅标题变化的到期日期或流量信息，否则每次更新都会被视为新节点，已保存的选择也会失效。

更清晰的方式是保留多个 proxy-providers，让策略组通过 use 引用来源，而不是把全部节点展开到一个巨大数组。这样可以分别设置更新周期、健康检查和筛选规则，也便于临时停用某个来源。提供器路径必须唯一，远程地址失效时应保留最近可用缓存，并在界面中明确显示更新失败，不能将旧缓存误认为刚刚更新成功。

proxy-providers:
  primary:
    type: http
    url: https://sub.example.com/primary.yaml
    path: ./providers/primary.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  backup:
    type: http
    url: https://sub.example.com/backup.yaml
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 主订阅
    type: select
    use:
      - primary
  - name: 备用订阅
    type: fallback
    use:
      - backup
    url: https://www.gstatic.com/generate_204
    interval: 600

敏感字段与配置分发

订阅地址、外部控制密钥和节点认证信息都不适合复制到公开仓库、截图或在线格式化工具。多人维护时，可将不含敏感内容的规则与覆写单独保存，把订阅和认证信息留在客户端本地。需要在设备间同步时，应使用受控的私有存储，并限制同步范围。示例配置只能展示字段结构，不应复制真实订阅地址。

外部规则与本地覆写最好分开管理：规则集负责“哪些目标属于某类”，本地配置负责“该类目标走哪个策略”。这样更换订阅或客户端时，规则资产仍可复用。若把节点、规则、DNS 和设备专属路径全部写进单个大文件，任何一项更新都会增加冲突概率。

更新后的自动检查清单

每次订阅更新后，先确认提供器状态与节点数量是否合理，再检查顶层策略组是否仍有成员、选中状态是否指向存在的节点、规则引用的策略名称是否完整。随后验证 DNS 配置未被订阅覆盖，TUN 与外部控制接口仍保持本地期望值。若客户端支持配置预处理脚本，脚本发生异常时应停止应用新配置，而不是输出一个部分合并的文件。

多订阅问题经常表现为“更新后没有节点”或“策略组为空”。这不一定是订阅内容为空，也可能是筛选正则排除了所有节点、同名去重逻辑错误、提供器文件解析失败，或合并器替换了完整数组。应按原始响应、单份订阅解析、合并前结构、最终配置和内核载入五个阶段逐项检查。具体恢复步骤可参考订阅失效与配置解析失败。

外部控制接口、面板接入与安全边界

控制接口与代理端口不是同一服务

external-controller 提供运行状态、策略切换、连接管理、日志和配置重载等控制能力。它不是 HTTP 或 SOCKS 代理端口，应用不能通过它转发普通网络请求。常见控制面板通过该接口读取策略组并发送选择操作；客户端自身也可能调用同一接口实现图形界面。控制接口具有修改运行状态的能力，应只向可信网络开放。

监听在 127.0.0.1 时，只有本机程序可以访问，适合桌面客户端与本地面板。监听在 0.0.0.0 时会绑定所有可用接口，局域网设备可能访问，必须同时设置强密钥与防火墙来源限制。将监听地址改为全部接口并不等于完成远程管理；还需要确认系统防火墙、路由、反向代理和浏览器来源限制。没有远程访问需求时，应保持本地监听。

external-controller: 127.0.0.1:9090
secret: "change-this-secret"

# 面板文件由客户端或本地部署提供时再启用
external-ui: ./dashboard

profile:
  store-selected: true
  store-fake-ip: true

示例密钥只用于说明字段，部署时应在本地生成不可预测的独立值。不要把控制密钥与订阅地址、系统登录密码或其他服务凭据复用。修改密钥后，面板中的连接配置也要同步更新。若面板持续返回未授权，先检查请求是否携带正确认证信息，再确认客户端是否在启动时用另一份配置覆盖了 secret。

外部面板的连接流程

控制面板通常需要控制接口地址和认证密钥。面板从接口读取策略组、代理节点、当前连接与日志，再按用户操作发送切换或关闭请求。若面板页面能打开但没有数据，应把“静态页面加载”和“API 连接”分开检查：前者取决于面板文件或 Web 服务，后者取决于控制接口地址、认证、浏览器同源限制和网络可达性。

面板部署在本机而接口也只监听本机时，配置最简单。面板位于其他设备时，浏览器访问的 127.0.0.1 指向的是浏览器所在设备，而不是运行 Clash 的主机，这是常见地址误判。此时应使用 Clash 主机在可信局域网中的地址，并通过防火墙限制来源。跨公网暴露控制接口风险较高，应使用受控的安全访问层，不应直接开放端口。

常用状态检查与只读观察

排障时先使用只读信息确认控制面是否连接到正确内核：查看当前配置模式、策略组列表、内核日志和活动连接。多个客户端或内核同时运行时，端口可能被占用，面板也可能连到旧实例。应通过进程、监听端口和日志启动时间确认目标。切换策略后观察新连接采用的出口，已有连接不会自动全部迁移，必要时需关闭相关连接后重新建立。

连接列表适合判断应用是否进入内核、目标域名是否被恢复、命中了哪条规则以及实际策略链。若应用完全不出现在连接列表，优先检查系统代理、TUN、应用绕过设置和防火墙；若出现但策略错误，检查规则顺序与策略组；若策略正确但连接失败，再检查节点与目标网络。这个分层顺序比反复切换节点更容易定位。

配置重载与运行时状态

通过接口重载配置时，应先完成语法验证。错误配置可能被拒绝，也可能造成部分功能重启。策略选择、Fake-IP 映射和规则集缓存是否保留，取决于配置和内核状态。profile.store-selected 用于保存策略选择，profile.store-fake-ip 用于保存映射状态；更换 Fake-IP 地址段、清理缓存或移动配置目录时，应预期这些状态被重建。

重载后要确认监听端口、控制地址、DNS 和 TUN 是否仍正常。修改控制接口自身地址时，当前面板连接会断开，需要使用新地址重新连接。修改代理端口后，系统代理仍可能指向旧端口；修改 TUN 设备名或路由设置后，旧路由也可能需要客户端清理。完整重启虽然耗时更长，但在涉及监听器、虚拟接口和路由时通常比连续热重载更容易得到确定状态。

日志级别与故障定位

silent、error、warning、info 与 debug 提供不同详细程度。日常使用保留 info 较容易发现规则集更新、监听失败和连接错误。需要定位 DNS、嗅探或规则命中时临时使用 debug，复现一次问题后立即保存必要片段并恢复常规级别。日志可能包含目标域名、局域网地址和节点名称，分享前应删除敏感信息。

阅读日志时按时间线定位一条具体连接：先找入站类型和来源，再看目标域名或地址、命中规则、策略链、实际节点与最终错误。只截取最后一行“timeout”通常不足以判断原因。超时可能发生在 DNS、节点握手、代理到目标、UDP 转发或应用等待响应的任一阶段。结合疑难解答中的分类问题，可以先确定错误属于入口、解析、规则还是出站。

安全开放的最小原则

控制接口只绑定需要的地址，代理端口只开放给需要的设备，allow-lan 与控制接口开放应分别判断。允许局域网设备使用代理，并不意味着它们也需要切换策略或查看连接。系统防火墙应按来源地址限制控制端口，面板和接口之间使用独立密钥。设备离开可信网络或连接公共网络时，应确认监听策略不会继续暴露服务。

外部面板文件应来自已确认的客户端组件或受控部署，更新面板与更新内核分开进行。面板显示异常不代表代理核心停止工作，核心连接正常也不代表控制接口安全。维护时分别记录内核配置、面板版本来源、监听地址和访问边界，不要把所有问题归为“面板无法连接”。

形成可重复的变更流程

稳定的高级配置应遵循固定流程：导出当前可用配置，修改单一功能域，完成 YAML 与引用检查，在测试配置中启动，验证直连、代理、DNS、TUN 和控制接口，再替换正式配置。订阅更新后重复关键检查，并保留回滚副本。首次配置连接流程可回到使用文档，客户端安装包与平台选择在下载页查看。

最终配置不需要包含所有可用字段。策略组只保留有明确决策意义的层级，规则集只保留可说明来源和用途的集合，DNS 与 TUN 只开启当前网络确实需要的能力，嗅探例外必须能够解释，控制接口则遵循最小开放范围。配置越能清楚描述数据从入口到出口的路径，发生问题时越容易通过日志定位，而不是依赖反复重置或替换整份模板。