配置进阶 预计阅读 12 分钟

Clash 配置文件结构解析：从端口、DNS 到规则段逐项说明

按 YAML 层级拆解常用字段，说明代理节点、策略组和规则之间的引用关系。

先理解 Clash 配置的处理链路

Clash、Clash Meta（现常称 Mihomo）及其图形客户端通常使用 YAML 文件描述运行参数。配置内容看起来由许多相互独立的字段组成，实际运行时却是一条连续链路：应用流量先进入本地监听端口或 TUN 网卡，域名请求交给 DNS 模块处理，连接随后按 rules 从上到下匹配，命中的规则把连接交给策略组，策略组再选择具体代理节点、直连出口或拒绝动作。

因此，阅读配置时不应只看某个节点能否连接。一个完整配置至少要回答五个问题：流量从哪里进入、域名怎样解析、有哪些可用出口、出口怎样组成策略组、连接最终由哪条规则分配。任何一环的名称引用错误，都可能表现为配置载入失败、策略组为空、域名无法解析或流量走错出口。

YAML 对缩进敏感。通常使用两个空格表示一个层级，不能用制表符代替空格。同一层级的键需要保持对齐，列表项以连字符开头。布尔值建议使用 true 和 false，包含冒号、井号、星号或特殊符号的名称则应使用引号包裹，避免被解析器当作 YAML 语法。

基础字段与本地监听端口

配置文件顶层通常先放置端口、局域网访问、运行模式和日志等级。这些字段决定 Clash 如何接受本机或局域网设备的连接，但不会直接决定连接使用哪个代理节点。

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

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

port、socks-port 与 mixed-port

port 提供 HTTP 代理监听端口，socks-port 提供 SOCKS5 代理监听端口，mixed-port 则允许同一个端口同时接受 HTTP 与 SOCKS5 请求。桌面客户端常使用混合端口简化系统代理设置。若同时声明多个端口，应检查端口号是否被其他程序占用，并确认系统代理实际指向了哪一个端口。

redir-port 和 tproxy-port 主要用于透明代理场景，依赖操作系统网络栈、路由规则和权限配置，并非所有平台都以相同方式支持。普通桌面用户如果通过系统代理或客户端的 TUN 开关接管流量，通常不需要手工增加这两个字段。

局域网访问与控制接口

allow-lan 控制其他设备能否通过本机监听端口使用代理。启用后还要检查 bind-address、操作系统防火墙以及设备之间的网络连通性。只在本机使用时可保持关闭。若需要为同一局域网内的手机或平板提供代理，应限制可信网络范围，并避免把监听端口暴露到公网。

external-controller 是控制接口地址，图形界面或外部面板可通过它读取连接、流量和策略组状态。监听在 127.0.0.1 时仅供本机访问；若改为局域网地址，应同时设置强度足够的 secret，并配置网络访问边界。控制接口端口与代理端口用途不同，不能把系统代理指向控制接口。

运行模式与日志

mode: rule 表示按照规则分流，是日常配置最常用的模式。global 模式把连接统一交给全局策略，direct 模式则让连接直接访问。图形客户端中的“规则、全局、直连”切换通常会改变当前运行模式，但不一定改写原始 YAML 文件。

log-level 可设为 silent、error、warning、info 或 debug 等等级，具体支持值以所用内核版本为准。排查规则命中和 DNS 请求时可临时提高日志详细度，问题确认后再恢复常规等级，避免大量日志影响阅读。

DNS 段：解析路径与 Fake IP

dns 段决定 Clash 是否接管域名解析、向哪些上游服务器查询，以及返回真实地址还是 Fake IP。DNS 配置与代理规则紧密相关：规则可能需要域名本身完成匹配，代理节点的服务器地址也可能需要先解析，错误的上游设置会让节点在建立代理连接之前就失败。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

enable、listen 与上游服务器

enable: true 启用内核 DNS 模块。listen 指定 DNS 服务监听地址，是否需要填写取决于客户端如何接管查询；部分图形客户端会生成或覆写这一项。监听到非本机地址前，应先理解局域网 DNS 暴露带来的访问范围变化。

default-nameserver 主要用于解析 DoH、DoT 等加密 DNS 服务器自身的域名，也可能参与代理节点域名的初始解析，因此这里通常填写可直接访问的 IP 地址型 DNS。nameserver 是常规查询的主要上游，可使用普通 DNS 地址或内核支持的加密 DNS 格式。不同 Mihomo 版本对扩展参数和协议写法的支持可能有差异，迁移配置时应检查内核文档和启动日志。

nameserver-policy 可以按域名或规则集合指定 DNS 上游，例如让特定域名使用指定解析服务。它处理的是“向哪个 DNS 查询”，并不等同于代理规则中的“连接走哪个出口”。DNS 查询路径与后续连接路径需要分别配置。

fake-ip 与 redir-host

Fake IP 模式会先向应用返回保留地址段中的临时地址，并在应用发起连接时把该地址映射回原始域名。这样可以让内核更稳定地保留域名信息，便于执行 DOMAIN、DOMAIN-SUFFIX 和 GeoSite 等域名规则。在 TUN 场景中，Fake IP 也常用于统一接管不同应用的 DNS 与连接。

某些局域网服务、游戏平台、打印设备或依赖真实 DNS 结果的应用可能不适合 Fake IP。这类域名可加入 fake-ip-filter，使其返回真实解析结果。过滤范围不宜盲目扩大，否则大量域名会绕开 Fake IP 映射，降低域名规则的可观察性。redir-host 模式返回真实 IP，兼容思路更直接，但规则匹配效果会受到 DNS 缓存、连接方式和应用行为影响。

代理节点与代理提供者

proxies 是静态节点列表，每一项描述一个可供策略组引用的代理出口。常见字段包括节点名称、协议类型、服务器地址、服务器端口及协议认证参数。不同协议需要不同字段，不能仅通过修改 type 把一种节点转换成另一种节点。

proxies:
  - name: "示例节点 A"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "example-user"
    password: "example-password"
    udp: true

name 是节点在配置内部的引用标识。策略组中的名称必须与这里完全一致，包括空格、大小写和符号。节点名称重复时，不同内核或客户端可能拒绝载入，也可能让引用结果难以判断，因此应保持唯一。

订阅通常包含大量节点，直接展开到 proxies 后不便维护。Mihomo 支持通过 proxy-providers 定义代理提供者，由提供者读取本地文件或远程内容，再把节点集合交给策略组。提供者常包含 type、url、path、更新间隔和健康检查等字段。订阅地址属于访问凭据，应避免写入公开仓库、截图或公开日志。

proxy-providers:
  provider-main:
    type: http
    url: "订阅服务提供的完整地址"
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

提供者的健康检查用于周期性测试节点连通性，不等于策略组会自动选择最低延迟节点。是否自动选择由策略组类型决定。健康检查地址也只反映到目标地址的响应情况，延迟数值可能受目标服务器、DNS、网络拥塞和节点出口位置影响。

策略组：把节点组织成可引用出口

proxy-groups 位于节点和规则之间。规则通常不直接绑定某个易变节点，而是指向稳定的策略组名称。这样在节点更新或失效时，只需在客户端切换组内选项，无须重写整套规则。

proxy-groups:
  - name: "节点选择"
    type: select
    use:
      - provider-main
    proxies:
      - DIRECT

  - name: "自动测速"
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: "默认出口"
    type: select
    proxies:
      - "节点选择"
      - "自动测速"
      - DIRECT

常用策略组类型

  • select：由用户手动选择组内节点、其他策略组或内置动作，适合主入口和需要固定出口的服务。
  • url-test：按指定测试地址周期性测量，并自动选择符合条件的低延迟节点。它关注探测结果，不代表所有业务连接都具有相同速度。
  • fallback：优先使用列表中可用的前置节点，当前节点不可用时切换到后续节点，适合强调固定优先级的场景。
  • load-balance：按内核支持的策略把连接分配到多个节点。它不会把单个 TCP 连接的带宽简单叠加，且频繁变化出口可能影响依赖会话或地址一致性的服务。

proxies 用于列出静态节点、其他策略组以及 DIRECT、REJECT 等内置动作；use 用于引用 proxy-providers。两者可以在同一个策略组内按需要组合。策略组也能引用另一个策略组，但应避免形成循环引用，例如 A 引用 B、B 又引用 A，这会导致配置校验失败。

组名同样属于严格引用。若规则写着 默认出口，配置中就必须存在完全同名的策略组、节点或内置策略。重命名策略组后，应同步搜索并修改 rules、其他策略组和覆写脚本中的引用。

规则段：顺序匹配决定最终出口

rules 是连接分流的决策表。内核通常从第一条开始向下检查，命中后停止继续匹配，并把连接交给规则末尾指定的策略。规则顺序因此比规则数量更重要：范围较窄、优先级较高的规则应放在前面，通用规则和兜底规则放在后面。

rules:
  - DOMAIN,example.org,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN-KEYWORD,service,默认出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,默认出口

常见规则类型

DOMAIN 精确匹配完整域名；DOMAIN-SUFFIX 匹配指定域名及其子域名；DOMAIN-KEYWORD 按域名中的关键词匹配，范围更宽，使用时要防止误命中。IP-CIDR 和 IP-CIDR6 根据目标 IP 网段匹配，适合局域网、固定服务地址和明确的网络范围。

GEOIP 根据 IP 地理数据库匹配目标地址。Mihomo 还可通过 GeoSite 或规则集合处理批量域名，具体规则类型和数据库格式取决于内核版本及配置方式。地理规则依赖本地数据库，数据库缺失、路径错误或格式不兼容时，内核会在加载阶段或运行日志中给出提示。

no-resolve 常用于 IP 类规则，表示匹配该规则时不为域名额外触发 DNS 解析。它可以减少不必要的解析，但如果当前连接只有域名、没有可用于匹配的目标 IP，这条 IP 规则就可能无法命中。是否添加应根据 DNS 模式和规则目的判断。

MATCH 是最终兜底项，应放在规则列表末尾。它负责处理此前没有命中的连接。缺少合理兜底时，不同内核版本或客户端生成逻辑可能产生难以预期的结果；在手写配置中，明确写出 MATCH 能让默认出口更清楚。

规则提供者与大规模规则集

当规则数量较多时，可以使用 rule-providers 把规则集拆分到独立文件，再通过 RULE-SET 引用。规则提供者通常声明行为类型、来源、保存路径、更新间隔和格式。引用名称必须与提供者键名一致，规则集的内容格式也要与 behavior 相符。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: "规则维护方提供的完整地址"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,默认出口

规则集更新成功不代表顺序一定合理。若在 RULE-SET 前已经放置范围更广的规则，连接可能提前命中，后面的规则集便不会生效。排查时应查看连接详情中的规则类型、命中内容和最终策略，而不是只确认规则文件已经下载。

TUN 模式与流量入口的关系

系统代理只影响遵循操作系统代理设置的程序。终端工具、游戏、虚拟机或自行实现网络栈的应用可能忽略系统代理。TUN 模式通过虚拟网络接口接管更广泛的 IP 流量，再把连接送入 Clash 的 DNS、规则和策略链路。

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

auto-route 让内核尝试自动设置路由，auto-detect-interface 用于识别默认出站接口，dns-hijack 则把指定的 DNS 流量交给内核处理。stack 的可选值及默认行为会随内核和平台变化，常见实现包括 system、gVisor 和 mixed。图形客户端一般会根据操作系统提供合适默认值，除非正在定位兼容问题，否则不必频繁切换。

TUN 启动失败时，应依次检查客户端权限、虚拟网卡状态、其他 VPN 或网络过滤软件、路由表以及 DNS 接管冲突。TUN 已启用却仍有应用直连时，还要检查路由排除项、接口选择和应用自身是否使用独立 VPN。TUN 负责把流量送入内核，最终走直连还是代理仍由规则和策略组决定。

配置载入失败与规则不生效的检查顺序

  1. 先检查 YAML 语法。确认缩进、冒号后的空格、列表连字符和引号闭合。解析器提示的行号有时只是发现错误的位置，真正问题可能出现在前几行。
  2. 再检查名称引用。核对规则末尾的策略名、策略组中的节点名、use 引用的代理提供者，以及 RULE-SET 引用的规则提供者。
  3. 确认远程资源状态。检查订阅、代理提供者和规则提供者是否更新成功，保存目录是否可写，远程内容是否符合内核要求的格式。
  4. 核对流量入口。系统代理端口必须与当前监听端口一致；使用 TUN 时确认虚拟网卡和路由已建立；局域网设备还要检查监听地址与防火墙。
  5. 观察 DNS 与规则日志。先判断域名是否成功解析，再确认连接命中了哪一条规则、进入哪个策略组、最终选择哪个节点。
  6. 缩小配置范围。复杂配置可临时保留一个可用节点、一个手动策略组和少量规则，验证基础链路后再逐段恢复 DNS 策略、规则集和自动测速。

一份便于维护的 Clash 配置，应让引用关系保持清晰：端口和 TUN 负责接收流量，DNS 负责域名解析，节点与代理提供者提供出口，策略组组织出口，规则负责选择策略。修改时沿着这条链路逐层验证，比同时更换内核、订阅、DNS 和规则集更容易定位问题。

下载Clash