Clash 配置文件参考大全

一、YAML 结构总览

Clash 配置文件通常以 config.yaml 为入口。它不是一串彼此独立的开关，而是一棵有层级的映射结构：顶层字段决定监听端口、运行模式和网络能力；proxies 定义可用代理；proxy-groups 把代理组织成可选择、自动测试或故障转移的策略；rules 再把每类请求指向某个策略组。理解这条引用链，比记住单个字段更重要。一个规则指向不存在的策略组、一个策略组引用未定义的节点，都会使配置加载失败或产生非预期结果。

缩进、序列与映射

YAML 使用空格表达层级，建议统一使用两个空格缩进，不要混入制表符。冒号左侧是键，右侧是值；以短横线开头的是序列项。dns 后面的缩进字段属于 DNS 映射，而 rules 下的每一行短横线都是一条规则。字符串通常可以不加引号，但包含冒号、井号、逗号或容易被识别成布尔值的内容时，使用引号更稳妥。注释以井号开头，仅供阅读，不会参与运行。

# 顶层映射
mixed-port: 7890
mode: rule
log-level: info

# 嵌套映射
dns:
  enable: true
  listen: 0.0.0.0:1053

# 对象序列
proxies:
  - name: "示例节点"
    type: socks5
    server: 127.0.0.1
    port: 1080

# 字符串序列
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,节点选择

上例展示的是语法关系，不代表必须使用本地 SOCKS 节点。实际订阅通常会提供完整的 proxies 或 proxy-providers。手工编辑时，应保留节点名称的精确拼写，因为策略组通过名称引用节点。名称中的空格是有效字符，前后空格却容易造成肉眼难以发现的差异；因此节点名和策略组名建议加双引号，并避免在末尾留下空格。

最小闭环与加载顺序

一个用于规则模式的完整配置至少需要监听入口、可用出口、策略组和兜底规则。解析器先读取 YAML，再校验字段类型与引用关系，最后创建监听端口、DNS 模块和代理组。文件能通过 YAML 解析，不等于运行逻辑正确：例如 mode: rule 已启用，但规则末尾缺少 MATCH，未命中的流量就可能没有清晰的兜底去向；又如只定义节点而没有把节点放进策略组，规则也无法通过统一策略名称进行切换。

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "本地测试"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "本地测试"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,节点选择

检查结构时可沿着“规则目标 → 策略组 → 节点或其他策略组”的方向逐级查找。每一级名称都必须存在，且不能形成无意义的循环引用。编辑器如果支持 YAML 语法检查，可以提前发现缩进和重复键；客户端日志则更适合发现字段不受支持、端口占用、代理集合下载失败等运行期问题。遇到具体报错还可对照疑难解答中的配置加载分类。

二、端口、模式与通用字段

通用字段决定客户端怎样接收系统流量，以及未进入代理协议细节之前的基础行为。图形客户端往往会在界面中管理这些值，因此手工修改前先确认客户端是否使用覆写机制；否则文件中的设置可能在启动时被界面选项覆盖。最常见的入口是 mixed-port，它在同一个端口上接收 HTTP 与 SOCKS5 请求，适合浏览器、命令行工具和系统代理统一配置。

规则、全局与直连模式

rule 模式按 rules 从上到下匹配，适合长期使用；global 模式把流量统一交给全局策略组，常用于临时测试某个出口；direct 模式让流量直接连接，可用于确认问题是否由代理链路引起。模式只是总开关，不会删除原有规则。切回规则模式后，规则仍按原顺序生效。三种模式的场景对照可继续阅读规则、全局、直连三种代理模式怎么选。

局域网监听与控制接口

开启 allow-lan 后，其他设备能否接入还取决于监听地址、防火墙和所在网络。仅把字段改成 true 并不足以保证连接成功。若只希望本机使用，应维持关闭状态；需要给同一可信局域网中的设备提供代理时，再明确设置监听地址并检查系统防火墙。控制接口 external-controller 用于图形界面或外部面板管理内核，它与代理端口用途不同，不应把控制端口填写进系统代理。

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

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"

log-level 常见取值包括 silent、error、warning、info 和 debug。日常使用保留 info 即可；定位连接建立、DNS 查询或规则命中问题时，可以临时切换为 debug，完成后再恢复，避免日志快速增长。ipv6 是否开启应依据本地网络、DNS 返回和代理节点的支持情况决定。如果网络没有稳定的 IPv6 路径，却让 DNS 返回 IPv6 地址，应用可能先尝试不可达地址，表现为首连缓慢。

图形客户端中的“系统代理”通常只是把操作系统代理地址指向 Clash 的监听端口；“TUN 模式”则通过虚拟网络设备接管更广范围的流量，两者不是同一个字段。只需要浏览器和支持系统代理的软件时，系统代理通常已足够。游戏、命令行程序或不读取系统代理的应用需要纳入分流时，再评估 TUN。配置 TUN 还涉及权限、路由和 DNS 劫持，不能仅凭一个开关判断是否成功。

三、DNS 配置与解析链路

DNS 配置决定域名先由谁解析、返回什么形式的地址，以及规则引擎能否在合适的阶段获得域名信息。很多“网页偶尔打不开”“规则看似正确却走错策略”的问题，并非代理节点本身故障，而是 DNS 请求绕过客户端、解析结果污染缓存，或 fake-ip 与特定局域网设备不兼容。排查时要把应用发起查询、Clash 接收查询、上游解析器返回结果和连接建立四个阶段分开观察。

基础字段与上游服务器

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

default-nameserver 主要用于解析 DoH、DoT 等上游服务器自身的域名，因此通常填写可直接访问的 IP 地址，避免形成“解析 DNS 服务器域名时又需要先访问该 DNS 服务器”的循环。nameserver 是主要解析来源，既可以使用普通 UDP 地址，也可以使用支持的加密 DNS 地址。fallback 是否参与以及怎样筛选结果，取决于内核能力与后续过滤字段。不要简单堆叠大量上游；来源越多，越难判断某次答案来自哪里，也可能增加结果不一致。

fake-ip 与 redir-host

fake-ip 模式不会立即把真实地址直接交给应用，而是从保留地址段分配一个映射地址。应用连接这个地址时，内核据此恢复原始域名，再进行规则匹配和真实解析。它通常能保留更多域名信息，规则命中更稳定。代价是部分依赖真实局域网地址、局域网发现或特殊 DNS 行为的软件需要加入过滤列表。redir-host 更接近传统解析流程，兼容思路直观，但在某些连接阶段可能只剩 IP 信息。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "localhost.ptlogin2.qq.com"

过滤项的目标不是越多越好。只有确认某类域名必须获得真实地址时才添加，并记录添加原因。遇到局域网打印机、投屏或路由器管理域名异常，可先在日志中确认查询域名，再加入精确后缀进行验证。一次性复制很长的过滤清单会掩盖真正的兼容点，也会让本可由域名规则处理的请求提前走向不同解析路径。

按域名指定解析器

支持 nameserver-policy 的内核可依据域名集合选择上游。它适合把局域网域名交给路由器，把特定区域域名交给相应解析器，或让规则集合与 DNS 策略保持一致。键的匹配写法与内核版本能力有关，迁移配置时应先用少量域名测试，不要直接假设所有旧语法都能原样工作。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

判断 DNS 是否生效，不能只看网页最终能否打开。应检查客户端日志中是否出现该域名查询、命中了哪个 DNS 策略、连接阶段使用域名还是 IP，以及系统是否仍向其他网卡 DNS 直接发送请求。启用 TUN 时，还要确认 DNS 劫持配置和系统权限。修改后先清理操作系统与浏览器缓存，再用新的域名或无痕窗口测试，避免旧答案干扰结论。

四、代理节点字段

proxies 是静态节点列表，每个序列项至少包含名称、协议类型、服务器地址、端口以及该协议所需的认证参数。订阅生成器通常已经完成这一部分，手工维护更适合本地测试、固定出口或理解字段。节点协议不同，字段集合也不同，不能通过替换 type 就把一个节点改成另一种协议。服务器提供方给出的认证信息、传输层设置和 TLS 参数必须作为一个整体核对。

通用字段与名称引用

节点名称不仅用于展示，也是配置内部的主键。两个节点同名时，客户端可能拒绝加载，也可能使策略组引用结果难以判断。名称可以包含地区、线路用途和协议提示，但不应把频繁变化的数据写进名称，否则每次订阅更新都可能让策略组的固定引用失效。更稳妥的方法是让代理集合通过筛选器动态加入策略组。

SOCKS5 与 HTTP 示例

proxies:
  - name: "本地 SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    username: "user"
    password: "your-password"
    udp: true

  - name: "办公 HTTP 代理"
    type: http
    server: proxy.example.com
    port: 8080
    username: "user"
    password: "your-password"
    tls: false

认证字段应按服务端实际要求填写。没有用户名和密码的服务不需要保留空字段。tls 表示到 HTTP 代理服务端的连接是否使用 TLS，不等同于通过代理访问的目标网站是否为 HTTPS。若服务端地址使用域名，启动时还依赖 DNS；因此出现所有策略组都无法使用同一批域名节点时，要检查节点服务器域名的解析路径，而不是逐个修改节点。

TLS、SNI 与传输参数

使用 TLS 的协议通常还涉及服务器名称校验。配置中的 servername 或同类字段用于指定握手中的服务器名称，应与服务端证书和部署设置一致。跳过证书验证会改变安全边界，不应作为长期解决连接失败的通用方法。正确的排查顺序是确认系统时间、域名解析、服务端名称、证书链和传输参数，再判断是否属于测试环境中的特殊证书。

WebSocket、gRPC 等传输方式通常还会带路径、Host 或服务名。它们是服务端路由的一部分，漏写一个字符也可能表现为端口可连接但握手失败。订阅导入后若只有个别节点失效，应对照原始节点信息检查传输字段；若全部节点同时失效，更应优先检查本地网络、系统时间、DNS、订阅是否过期以及内核日志。

客户端选型也会影响可用字段。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等图形客户端可能使用不同内核或不同覆写界面；停止维护的 Clash for Windows 与 ClashX Meta 对新字段的支持范围也可能有限。配置来自 mihomo 环境时，不应默认旧客户端能识别全部字段。需要更换客户端可前往下载页查看对应平台选项。

五、策略组与选择逻辑

策略组是规则与具体节点之间的中间层。规则最好指向用途稳定的策略组，例如“节点选择”“流媒体”“下载直连”，而不是直接指向某个节点。这样节点更新、订阅名称变化或临时切换出口时，无需重写整套规则。策略组既可以包含节点，也可以包含其他策略组和内置目标 DIRECT、REJECT。设计时要避免循环引用，并保证最底层最终能落到真实节点或内置目标。

select：手动选择

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "自动选择"
      - "故障转移"
      - "本地 SOCKS"
      - DIRECT

select 不主动测试或切换，它保留用户当前选择。适合作为规则统一入口，也适合需要手动指定地区的场景。把自动测试组放入手动选择组，可以同时保留自动与手动控制。需要注意的是，图形客户端保存的选择状态可能独立于 YAML；重新导入、清理配置或策略组改名后，选择状态可能回到首项。因此首项应是合理的默认策略，而不是仅供临时排错的目标。

url-test：按测试结果选择

  - name: "自动选择"
    type: url-test
    proxies:
      - "本地 SOCKS"
      - "备用节点"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

url-test 定期向指定地址发起测试，并根据结果选择可用节点。测试结果反映的是节点到测试目标的连接表现，不等同于所有网站的实际速度。interval 太短会产生不必要的请求，太长则不能及时反映线路变化；tolerance 可减少数值轻微波动造成的频繁切换。lazy 启用后，未被使用的策略组可减少主动测试。测试地址应稳定、响应体小，并与主要使用场景具有一定相关性。

fallback 与 load-balance

  - name: "故障转移"
    type: fallback
    proxies:
      - "主节点"
      - "备用节点"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "连接分配"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

fallback 按列表优先级使用首个可用节点，适合明确的主备关系；它不是简单选择数值最低的节点。load-balance 把不同连接分配到多个节点，适合能够容忍多出口的任务，但账号登录、会话绑定和对来源地址敏感的网站可能不适合频繁变化出口。consistent-hashing 倾向于让相同目标保持较稳定的节点映射，仍不能把它理解为单连接带宽叠加。

策略组的分层设计

一套易维护的结构通常分为三层：底层由静态节点或代理集合提供出口；中层按地区、用途或测试方式组织；顶层提供规则稳定引用。例如“香港节点”从订阅中筛选名称，“自动选择”引用多个地区组，“节点选择”再同时包含自动选择和手动地区组。业务规则只指向“节点选择”“流媒体”等顶层组。订阅变化时，只需维护筛选和中层结构。

proxy-groups:
  - name: "香港节点"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|港|HK"

  - name: "节点选择"
    type: select
    proxies:
      - "香港节点"
      - "自动选择"
      - DIRECT

正则筛选应从宽到严逐步验证。节点名称由订阅提供方决定，过度依赖表情符号、固定空格或复杂前后缀会降低稳定性。发现策略组为空时，先查看代理集合是否更新成功，再核对筛选表达式；不要直接删除筛选后长期使用全部节点，因为这可能把测试、到期提示或特殊用途条目混入生产策略。

六、规则语法、顺序与兜底

rules 按从上到下的顺序匹配，通常命中第一条后停止继续检查。因此，规则不仅要写对类型和参数，还要放在正确位置。精确域名应位于宽泛后缀之前，特殊直连或拒绝项应位于覆盖范围更大的集合之前，最终使用 MATCH 兜底。规则目标必须是已存在的策略组、节点或内置目标。

域名规则的范围差异

DOMAIN 只匹配指定完整域名，适合接口域名或需要例外处理的单一主机。DOMAIN-SUFFIX 会覆盖根域名及其子域名，是网站分流的常用选择。DOMAIN-KEYWORD 范围更宽，关键词短时可能误伤无关域名，因此应谨慎放置。若需要让 api.example.com 直连、其余 example.com 走代理，精确规则必须写在后缀规则之前。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN-KEYWORD,stream,流媒体
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

IP 规则与 no-resolve

IP 规则用于匹配连接目标地址。某些内核在处理 IP 类规则时，可能为了判断域名最终对应的地址而触发解析；追加 no-resolve 可阻止该条规则主动解析域名，适合本地网段等明确只需处理已有 IP 的规则。它不是提高所有规则速度的通用参数，也不能加到不支持该参数的规则类型后。使用前应理解当前内核的规则解析行为。

GEOIP 依赖本地地理数据库，匹配的是目标 IP，而不是域名本身的属性。数据库是否存在、是否更新以及 DNS 返回哪个地址都会影响结果。需要更细的域名分类时，可结合规则集合或 geosite 类能力，而不是仅依赖 GEOIP。国内外分流的完整写法与验证过程，可参考Clash 国内外分流规则配置实战。

PROCESS 与端口规则

桌面环境中的部分内核支持按进程名、进程路径或目标端口匹配。进程规则依赖操作系统权限和内核获取进程信息的能力，跨平台配置不一定能保持相同行为。端口规则只描述端口，不代表应用身份；多个协议都可能使用同一端口。编写时应先确认需求是“某个应用走指定策略”，还是“所有访问某端口的连接走指定策略”，避免把二者混为一谈。

rules:
  - PROCESS-NAME,curl,DIRECT
  - DST-PORT,22,节点选择
  - DOMAIN-SUFFIX,example.net,节点选择
  - MATCH,节点选择

规则维护应尽量按“例外、局域网、业务分类、区域分类、最终兜底”分段，并在每段上方写简短注释。每次修改少量规则后立即重载和验证，比一次加入数千行后再定位问题更可靠。拒绝规则也应明确用途：REJECT 会直接终止匹配连接，误写宽泛后缀可能导致相关登录、静态资源和接口一起失效。

七、代理集合与规则集合

代理集合 proxy-providers 用于从外部文件或订阅地址加载节点，规则集合 rule-providers 用于加载可复用规则。二者都解决“主配置不应塞入大量频繁变化内容”的问题，但数据格式和引用位置不同：代理集合由策略组通过 use 引入；规则集合由 RULE-SET 规则引用。把节点订阅误填为规则集合，或把规则文件误填为代理集合，都会解析失败。

代理集合配置

proxy-providers:
  provider-main:
    type: http
    url: "https://subscription.example.com/clash.yaml"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: "订阅节点"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|新加坡|日本|HK|SG|JP"

type: http 表示从远程地址更新，path 是下载后的本地缓存位置，interval 是更新间隔。更新成功不等于所有节点可用，因此可以单独配置健康检查。健康检查地址和间隔应控制在合理范围，订阅节点很多时，过于频繁的检查会同时建立大量连接。若订阅需要特殊请求头，部分内核允许配置相应字段，但应按照订阅服务要求填写，不要把敏感认证内容分享进公开配置。

策略组中的 use 可以引用一个或多个代理集合，并配合 filter、exclude-filter 等能力筛选节点。筛选表达式通常是正则。建议先用客户端显示的实际节点名称做小范围验证，再扩展关键词；中英文地区名、缩写和大小写可以通过组合表达式覆盖。筛选结果为空时，策略组无法提供出口，日志通常会指出对应集合或策略组问题。

规则集合配置

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

  local-network:
    type: file
    behavior: ipcidr
    format: text
    path: ./ruleset/local-network.txt

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,节点选择

behavior 描述集合内规则的行为类型，常见方向包括域名、IP 网段和经典规则。它必须与远程文件内容匹配。format 则说明文件采用 YAML、文本或内核支持的其他格式。仅修改扩展名不会改变内容格式；加载失败时要打开文件检查真实结构。远程规则集合也会缓存到 path，路径应彼此独立，避免两个集合写入同一文件。

域名行为的 YAML 规则文件可以采用负载列表结构：

payload:
  - "example.com"
  - "+.example.org"
  - "full:api.example.net"

不同内核与规则项目对前缀语义可能有差异，使用第三方集合时应以其说明为准。若需要完全可控的规则，可以自行维护少量高价值条目，并把大型公共分类作为补充。外部集合越多，更新链路越复杂；当某个远程地址不可用时，本地缓存是否存在会影响启动结果。重要配置应确保即使某个附加集合暂时更新失败，核心直连、代理与兜底逻辑仍然清晰。

更新与持久化边界

主配置、代理集合缓存和规则集合缓存应分开管理。客户端更新订阅时可能重写主配置，但不一定删除本地覆写；更换配置目录后，旧缓存也可能不再被读取。排查“订阅明明更新，节点列表却没变化”时，要确认当前激活配置、集合更新时间、实际缓存路径和策略组引用的是同一个 provider 名称。

Linux 无桌面环境常直接运行 mihomo 内核，配置目录与服务用户权限会直接影响集合缓存写入。使用 systemd 部署时，应让服务用户对配置目录拥有读取权限，并对 providers、ruleset 等缓存目录拥有必要写入权限。相关部署流程可阅读Linux 命令行部署 Clash 内核。

八、覆写、合并、验证与回退

订阅配置会随更新被重新生成，直接在订阅正文中手工修改，下一次更新后往往会丢失。图形客户端因此通常提供覆写、合并或脚本处理能力：订阅负责节点和基础配置，本地覆写负责端口、DNS、策略组补充与自定义规则。不同客户端对“合并”的定义并不完全相同，有的按键覆盖，有的对数组追加，有的允许在指定位置插入规则。迁移客户端时，应先用小配置验证合并结果。

映射覆盖与数组处理

对于 mode、mixed-port 这类标量字段，后加载值通常覆盖前值；对于 dns 这类映射，可能逐层合并，也可能整体替换；对于 rules、proxies 和 proxy-groups 这类数组，追加、前置和替换会得到完全不同的结果。尤其是规则数组：自定义例外若追加到订阅的 MATCH 后面，将永远没有机会命中。

# 本地覆写示意，具体入口以客户端为准
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

编写覆写前，先明确目标是“替换订阅字段”还是“补充订阅字段”。端口和日志级别通常适合覆盖；自定义规则往往需要前置到规则数组；本地策略组可能需要追加，同时确保它引用的 provider 在最终配置中存在。不要仅查看覆写文件本身，应查看客户端合并后交给内核的最终配置。很多问题正是由“覆写看起来正确，但最终顺序不同”造成。

规则前置与策略组补充

假设需要让公司内部域名直连，自定义规则必须位于宽泛代理规则与 MATCH 之前。若客户端提供 prepend、append 等独立区域，应放在前置区域。新增策略组时，还要确认组名不会与订阅已有组重名；同名对象的覆盖方式取决于实现，有时会替换掉原组全部内容。稳妥做法是使用含义清楚且不易冲突的名称，并在合并后检查引用链。

# 期望的最终规则顺序
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - RULE-SET,applications,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

分阶段验证

修改复杂配置时，不要同时更换 DNS、策略组和全部规则。第一阶段只验证 YAML 能否加载；第二阶段确认监听端口和控制接口启动；第三阶段确认 DNS 查询进入内核；第四阶段检查策略组中确有可用节点；第五阶段用少量域名验证规则命中；最后再导入大型规则集合。这样每一步只增加一个变量，错误范围更小。

1. 保存基线：保留一份当前能够正常启动并连接的配置，记录当前激活配置名称。
2. 检查语法：确认缩进、冒号、引号和数组结构，重点查看编辑器标出的重复键。
3. 读取日志：先处理第一条明确错误，后续报错可能只是前一错误引发的连锁结果。
4. 核对引用：逐项检查规则目标、策略组名称、节点名称、provider 名称和本地路径。
5. 验证行为：用日志确认实际命中的规则与最终策略，而不是仅凭网页打开速度判断。

常见错误分支

出现“配置文件格式错误”时，优先检查缩进、制表符、未闭合引号和冒号后的空格；出现“找不到代理组”时，核对名称大小写、全角半角符号和尾部空格；出现“provider 更新失败”时，检查地址可达性、缓存目录权限与文件格式；出现“端口监听失败”时，查看是否被另一个客户端或旧内核进程占用；出现“规则始终不命中”时，确认当前模式、规则顺序、连接是否复用以及日志中拿到的是域名还是 IP。

如果配置能加载但所有节点都无法连接，可以临时使用 DIRECT 验证本地网络，再测试单个静态节点，最后恢复策略组。若只有某类网站异常，则从规则日志和 DNS 查询开始，而不是重装客户端。若启用 TUN 后才出现问题，应额外检查系统权限、虚拟网卡、路由表、防火墙和 DNS 劫持。Android 后台运行还受 VpnService 授权与省电策略影响，可参考Android VpnService 与省电白名单设置。

最终配置应做到三点：入口清晰，所有应用知道该连接哪个端口；引用闭合，每条规则都能沿策略组找到真实出口；更新可控，订阅变化不会覆盖本地关键逻辑。达到这三点后，再考虑细化地区组、DNS 策略和大型规则集合。配置复杂度应服务于明确需求，而不是字段数量。遇到仍无法归类的问题，可继续查看疑难解答；需要重新完成导入与连接主线时，回到Clash 设置教程逐步核对。