Clash 进阶配置手册

策略组类型与实战

策略组位于规则和节点之间：规则决定把连接交给哪个组，组再决定使用哪个出口。把业务规则直接指向一个节点虽然简单，但节点改名后所有引用都要修改。更稳妥的结构是让规则指向长期固定的业务组，再由业务组引用手动选择或自动选择组。分组应服务于实际需求，不必为每个网站建立一套重复层级。

四种类型分别解决什么问题

select 是手动选择组，适合需要固定出口或临时排查的场景；url-test 根据探测结果自动选择出口，适合允许路径变化的普通访问。fallback 按配置顺序选择可用项，重点是主备关系，不是总挑最快者；load-balance 将不同连接分配给多个出口，不会把单条下载连接直接叠加成多倍带宽。

探测地址应是稳定、响应轻量且所有候选节点都能访问的端点。若地址本身被限制，组里全部节点可能同时显示异常，实际业务却未必故障。相反，探测只建立了到一个站点的连接，也不能证明流媒体授权、工作系统登录或其他地区限制已经满足。排查时应把健康检查与业务验证分开记录。

保持业务入口固定

下面展示一个自动组套在手动组内的片段。include-all 用于纳入配置中已有的代理候选项，前提是完整配置确实载入了可用节点。它不是节点来源，也不会凭空生成代理。代码中的探测地址是常见的连通性检测端点；如当前网络无法访问，应更换为已确认可达的轻量端点。

proxy-groups:
  - name: 自动选择
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 网络出口
    type: select
    proxies:
      - 自动选择
      - DIRECT

interval 以秒计，控制探测周期；tolerance 是切换容差，以毫秒计，用来减少接近结果之间的频繁切换。周期越短不一定越好，会增加后台请求，也更容易追随短时波动。笔记本或移动网络环境可以先使用较保守的周期，再结合日志判断，而不是把测速频率当作连接质量的保证。

如果使用代理集合，可以通过 use 引用已经定义的 proxy-providers 名称，避免把节点名称逐个写进组里。集合名称和节点名称不是同一层概念：前者管理来源，后者表示具体出口。对集合应用筛选表达式时，要考虑上游改名以及筛选结果为空的情况；修改后检查候选列表，不能只确认配置加载成功。

切换的边界与恢复方法

自动组切换通常影响新建连接，已经建立的长连接不一定立即迁移。网页刷新仍使用旧出口时，可以先结束该应用的现有连接再重试；不要直接认为策略组失效。视频播放、终端会话和工作系统对出口变化的容忍度不同，需要稳定来源地址的服务更适合手动固定组，而不是在多个地区之间自动轮换。

组与组之间可以引用，但不能形成环路。例如“网络出口”引用“办公”，而“办公”又指回“网络出口”，就失去了明确的最终出口。设计时沿引用链向下检查，末端必须落到实际节点或 DIRECT 等内置策略。组名也不要与节点重名，否则界面展示与规则目标都会变得难以辨认。

验证顺序是先在代理页确认候选非空，再手动固定一个已知可用节点，最后启用自动选择。若固定节点可用而自动组失败，重点看探测端点、筛选条件和引用层级；若固定节点也失败，先回到节点认证和底层网络，不要继续叠加策略组。界面入口不熟悉时，可查阅代理页、配置页与日志页说明。

DNS 配置与解析路径

DNS 配置需要同时回答三个问题：谁接收应用查询、谁向上游解析、解析请求通过哪条网络路径发送。只把上游地址改成加密 DNS，并不等于所有应用查询都进入了内核。浏览器安全 DNS、系统缓存、应用内置解析器以及局域网网关，都可能形成旁路。讨论 Clash DNS 泄漏前，应先画清当前设备的实际查询链路。

区分监听、引导与业务解析

listen 定义内核 DNS 服务的监听地址；nameserver 是常规查询使用的上游；default-nameserver 用于解析上游 DNS 服务器自身的域名等引导需求，并不是所有失败查询都会自动转交的万能备用项。带域名的 HTTPS 解析器必须先解析自己的主机名，因此需要避免“先访问解析器才能知道解析器地址”的循环。

下面展示一个便于本机诊断的 DNS 片段，使用独立的回环端口。它不会自动把操作系统 DNS 改为这个地址，也不会接管应用流量。先用命令显式查询该监听端口，再结合 TUN 或系统配置验证接管过程，可以把“解析服务本身失败”和“应用没有进入解析服务”分开处理。

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
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5

示例地址只说明配置结构，实际选择要结合运营网络、地区与访问策略。nameserver-policy 对特定域名指定解析器，适合需要内网解析或明确区域结果的域名；不要把整个业务域名随意交给公共解析器，否则内部地址可能无法返回。匹配范围应尽量小，先确认单个域名，再扩展到其子域。

让解析请求与出口策略相互配合

需要让 DNS 连接遵循路由规则时，可研究 respect-rules，同时正确设置 proxy-server-nameserver 以解析节点服务器的主机名。否则解析节点地址需要代理、建立代理又需要节点地址，容易形成启动循环。这里没有适用于所有订阅的统一开关组合，关键是保证至少有一条不依赖尚未建立代理的引导路径。

direct-nameserver 可以用于直连出口相关的解析需求；若与域名策略同时使用，还要明确其是否遵循 nameserver-policy。不要在没有观察结果的情况下同时填入多组 nameserver、fallback 和策略映射。复杂配置会使同一域名可能发起多路查询，也让返回结果的来源更难追踪。

传统 fallback 与 fallback-filter 是解析结果选择机制，不能简单理解为“第一个 DNS 超时才请求第二个”。过滤条件、地理判断与候选响应都会影响最终答案。若现有环境已经通过明确域名策略满足需求，可以先保持配置简单；确有污染或返回异常问题时，再根据可复现样本设计过滤条件。

分别验证返回结果与请求去向

安装了 dig 的环境可以使用下列命令查询本地监听器。使用 Windows 系统自带工具时，注意部分工具对非默认端口的支持方式不同，不能把查询系统 DNS 的结果误认为查询了本地内核。记录查询时间、返回类型和日志中上游选择，再对照应用连接，才有完整证据。

dig @127.0.0.1 -p 1053 example.com A

Fake-IP 模式下返回虚拟地址是预期行为，不应仅凭它与公共 DNS 结果不同就判断解析错误。对于 IPv6，也要区分内核总开关、DNS 是否返回 AAAA、系统 IPv6 路由以及节点传输能力。示例关闭 DNS 的 IPv6 返回只为减少初次诊断变量，不是建议所有网络永久关闭 IPv6。

所谓泄漏测试通常只能观察某次网页请求涉及的解析来源，不能覆盖所有应用与协议。浏览器启用了独立安全 DNS 时，应单独检查其配置；企业设备还可能有组织管理策略。不要为通过某个测试页面而反复更改系统设置。先确定保护边界与查询接管范围，再用日志、路由和应用行为交叉验证。

域名嗅探与识别边界

域名嗅探用于在连接已进入内核后，从部分协议的初始数据中提取目标主机信息。常见来源包括 HTTP 的 Host 与 TLS 握手中的服务器名称。它可以帮助只有目标 IP 的连接使用域名规则，却不是 DNS 的替代品，也不能保证识别所有加密流量。把它理解为补充线索，比理解成完整的应用识别功能更准确。

先有流量，再谈识别

嗅探只处理内核已经接收到的连接。某应用绕过系统代理、没有进入 TUN 时，打开嗅探不会让流量自动进入。反过来，连接已有可靠域名信息时，额外嗅探未必带来收益。排查顺序应当是先确认连接出现在客户端连接页，再查看域名字段、命中规则和最终出口，而不是先扩大嗅探端口范围。

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

示例把嗅探限定在常见协议端口，且不覆盖原始目的地址，用于先观察识别是否可靠。端口只是协议可能出现的位置，不是内容保证；四百四十三端口也可能承载其他协议。将所有端口都加入嗅探，会增加不必要处理，并让非标准服务的兼容问题更难定位，应根据实际业务逐步扩展。

识别域名与改写目标不是同一件事

override-destination 决定是否使用嗅探结果覆盖连接目标。对依赖指定 IP 的服务，改写后可能访问到另一台服务器；对使用 CDN 的网站，重新解析也可能改变地址选择。若只是想改善分流判断，先保留目的地址，通过连接记录验证规则行为，再决定是否确有覆盖需求，不必把该选项视作必开项。

启用 parse-pure-ip 可以让某些只有 IP 目标的流量参与嗅探，但识别结果取决于协议是否携带可读取域名。直接访问 IP 的 HTTP 请求未必包含期待的域名，TLS 也可能没有对应服务器名称。应用自己的加密协议更不一定符合 HTTP、TLS 或 QUIC 的解析方式，失败时不能仅凭“访问的是 HTTPS”来推断必然可识别。

需要强制嗅探或跳过嗅探时，可使用 force-domain、skip-domain 等配置表达具体范围。例外应对应可复现的服务，不宜将不明来源的域名清单整段复制进配置。尤其在存在共享 IP、反向代理或内网网关时，一个识别名称不一定代表连接最初的业务意图，需要同时结合原始目标判断。

加密协议与隐私方面的限制

部分 TLS 部署使用加密客户端问候等机制，可能使传统服务器名称提取失效。QUIC 基于 UDP，协议处理与 TCP 不同，还受节点 UDP 能力、路由和网络策略影响。出现浏览器可访问、客户端却没有识别域名的情况，未必是配置错误；只要规则依据其他可靠信息正确工作，就不必追求每条连接都有域名标签。

嗅探不等于解密 HTTPS 正文，不需要为普通域名识别在设备中安装自签名根证书。它读取的也不是用户登录密码或网页内容。与此同时，域名本身仍能反映访问意图，因此日志导出和面板共享应保持克制。分享故障材料时，去掉私人域名、订阅信息和节点凭据，尽量只保留足以复现规则问题的一小段。

验证时先使用一个已知域名，在嗅探关闭和开启两种状态下分别创建新连接，比较域名字段与规则命中。不要只看网页是否能打开，因为成功可能来自完全相同的兜底策略。若开启后访问异常，先关闭目的地址覆盖，再缩小端口范围；若仍有问题，暂时关闭嗅探，回到 DNS 映射与规则配置检查基础路径。

对于金融登录、企业内网和固定地址访问服务，稳定性通常比扩大识别覆盖更重要。可以保留明确的地址或域名规则，并为已知不兼容服务建立小范围例外。嗅探配置的验收标准应是“目标业务按预期分流且没有引入异常”，而不是“所有连接都显示名称”，这样才能避免为界面完整度牺牲实际可用性。

外部控制面板与安全边界

外部控制面板通过 mihomo 的控制接口读取运行状态、切换策略和查看连接。它不是代理入口，也不是订阅服务器。混合端口负责应用流量，控制端口负责管理操作，两者不能互换。面板打不开时，应分别确认静态页面能否加载、控制接口是否可达，以及鉴权是否通过，不要直接更改用于上网的混合端口。

本机管理从回环监听开始

如果使用桌面客户端内置界面，通常不需要再开放额外控制端口。确实要接入本地面板时，可以先采用回环地址，避免将管理接口暴露给局域网设备。下面的凭据仅是教学示例，实际使用前应替换成自行生成且仅保存在本机的强口令，不应把示例值用于可被其他设备访问的服务。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

external-ui 指向准备好的面板静态文件目录，相对于内核工作目录解析；它不会凭空生成面板文件。目录存在但缺少入口文件时，接口可能正常而页面仍返回错误。下载面板文件应使用可信项目来源，并按其说明部署到本地，不要把未知网页中输入的控制凭据当作普通网站登录信息处理。

绑定 127.0.0.1 只允许本机通过对应地址访问。若改为所有接口监听，意味着局域网乃至其他可达网络可能访问该端口，是否能到达还取决于防火墙和网络拓扑。与此同时，allow-lan 主要影响代理监听范围，并不是控制接口的总开关；关闭它不能代替控制端口的监听与访问限制。

把连通性、鉴权与浏览器限制分开

接口连接被拒绝时，先查内核是否运行、监听地址是否正确、端口是否被占用。能够连接但返回未授权，通常应核对面板保存的控制口令，而不是继续调整防火墙。面板能显示页面却取不到数据，还可能涉及浏览器跨源限制或页面地址与接口地址不一致；这些问题应在浏览器开发工具中查看具体请求结果。

HTTPS 页面访问 HTTP 控制接口可能受到混合内容限制。优先使用同机、同源的本地部署方式，减少跨源配置需求；若必须经过反向代理，应明确 TLS、鉴权和来源限制分别由哪一层负责。不要为了消除浏览器报错而开放任意来源，也不要把控制口令放在公开 URL 中，地址可能进入历史记录、日志或分享内容。

需要跨设备管理时，优先考虑受控的安全隧道或仅在可信管理网络内开放，并通过系统防火墙缩小可访问设备范围。直接将控制接口映射到公网会放大风险：接口不仅能查看状态，还能影响正在使用的策略和配置。仅设置一个口令，并不意味着已经处理了传输加密、暴力尝试与面板来源可信度。

完成一次配置变更的验证闭环

通过面板切换组后，确认客户端界面与新连接的实际出口同步变化；通过面板改变运行模式后，检查是否影响当前规则验证。面板状态、配置文件与运行状态并不总是永久一致，有些选择会被客户端保存，有些在重载时被覆盖。需要持久生效的参数仍应回到明确的配置维护层，而不是只在控制接口中临时修改。

日志应保持满足排错的最小范围。需要调试时临时提高详细程度，复现后恢复常用级别，避免长时间记录大量访问域名。对外分享材料前，检查节点认证、订阅链接、控制口令与个人访问记录。若管理凭据意外公开，应更换实际使用值，并清理面板中保存的旧值，而不是仅从截图中删除文字。

整份手册的最终检查顺序可以固定为：配置加载成功，节点来源可用，策略组引用闭合，规则命中正确，DNS 路径清楚，TUN 接管符合预期，嗅探没有引入兼容问题，控制接口只在需要的范围可达。每次只改一个变量并保留回退点，往往比不断堆叠参数更容易维护。无法定位时，带上脱敏日志到故障排查分类按现象逐项核对。