mihomo 进阶配置手册

Clash 配置进阶：策略、DNS 与流量接管

面向已经完成安装和订阅导入的使用者，集中说明策略组、规则集、DNS、TUN、Fake-IP、域名嗅探、本地覆写、多订阅合并与外部控制。页面中的 YAML 片段以 mihomo 配置语义为准，修改前应保留一份可正常启动的配置。

策略组与规则 DNS 与 TUN 覆写与控制接口

01 / 策略组织

策略组类型与实际组合

策略组位于规则和具体代理之间。规则只负责判断一条连接属于哪一类流量，真正决定使用哪个代理、是否自动测试、失败后如何切换的是策略组。配置长期可维护的关键，不是把所有节点塞进一个组，而是先按用途建立稳定的抽象层。例如规则只引用“国外网站”“流媒体”“即时通信”和“漏网流量”，节点名称即使随订阅变化，规则层也不需要同步重写。

select、url-test、fallback 与 load-balance

select 是手动选择组，适合需要明确控制出口的场景。它不会自行判断节点质量，当前成员不可用时也不会自动换到其他成员，因此通常将若干自动策略组放进 select，而不是只放原始节点。url-test 会按指定地址周期测试成员，并选择测试结果较优的一项。测试反映的是到测试地址的连接表现，不等同于所有目标网站的实际速度；间隔过短还会产生额外连接，移动网络下尤其没有必要频繁执行。

fallback 按成员顺序选择首个可用项，重点是稳定的主备关系，而不是挑选最低测试时间。固定线路为主、备用线路兜底时，这一类型比 url-test 更容易预测。load-balance 将不同连接分配给多个成员，适用于并发请求较多且服务端允许出口变化的场景。登录、支付、风控严格的网站可能把短时间内变化的出口视为异常，因此不应把负载均衡设为所有流量的默认策略。

类型 选择方式 适合用途 主要边界
select 人工指定成员 总入口、地区选择、临时切换 成员失效后通常需要人工处理
url-test 定期测试后自动选择 同用途节点的自动优选 测试结果不代表全部业务体验
fallback 按顺序选择可用成员 固定主线路与备用线路 排序本身就是策略的一部分
load-balance 在多个成员间分配连接 并发下载、连接分散 不适合要求出口稳定的会话

建立稳定的两层策略结构

常见结构是第一层按地区或线路特征自动选择，第二层按业务用途手动选择。下面的“自动选择”从订阅提供器中筛选节点，“国外网站”则允许在自动选择、故障转移和直连之间切换。这样做的好处是规则只需要引用“国外网站”，日常调整集中在策略组，不会把规则文件改成与某一家订阅强耦合的状态。

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

  - name: 故障转移
    type: fallback
    use:
      - provider-main
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 国外网站
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

use 引用的是代理提供器，proxies 引用的是明确列出的代理或其他策略组。筛选订阅节点时可使用 filter，但正则表达式应围绕稳定关键词编写，不要依赖订阅名称里容易变化的装饰字符。节点名称无法稳定区分用途时，宁可保留人工选择，也不要写一个会误收节点的宽泛表达式。

调整策略组后应先检查引用关系：规则目标必须存在，策略组成员也必须存在，组之间不能形成循环引用。若客户端导入后提示配置解析失败，可暂时移除新增组，再逐段恢复。策略组本身没有命中流量时不会改变连接路径，因此排查时还要结合日志确认最终规则是否确实指向该组。

02 / 规则管理

规则集订阅化与匹配顺序

Clash 规则采用自上而下、命中即停止的处理方式。顺序比规则数量更重要：精确域名通常放在较宽泛的域名后缀之前会失去意义，局域网和需要直连的服务若排在大范围代理规则之后，也可能被提前接管。最后一条通常使用 MATCH 承接未被前面规则覆盖的连接，保证每条流量都有明确去向。

内联规则与规则提供器

少量、与个人环境紧密相关的规则适合写在主配置的 rules 中，例如家庭存储设备、开发环境域名和某个必须固定直连的网站。规模较大且需要持续更新的公共规则适合交给 rule-providers。规则提供器将规则内容和主配置分离，可设置下载地址、本地缓存路径、格式与更新时间。更新失败时，内核通常继续使用已经缓存的规则文件，因此缓存路径必须可写，多个提供器也不能指向同一个文件。

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

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

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - RULE-SET,private-direct,DIRECT
  - RULE-SET,service-proxy,国外网站
  - GEOIP,CN,DIRECT
  - MATCH,国外网站

示例中的域名使用保留测试域，不代表可直接获取的真实规则地址；实际使用时应替换成自己信任并能维护的规则源。behavior: domain 只承载域名类规则，文件可以保持紧凑。classical 可容纳 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME 等经典规则语法，兼容范围更广，但解析和匹配结构也更复杂。选择行为类型时应与远端文件的内容一致，不能只改主配置中的字段而忽略规则文件格式。

从窄规则排到宽规则

一套可解释的顺序通常是：本地例外规则、局域网直连、明确需要代理的服务、明确需要直连的服务、地区数据库规则，最后是 MATCH。如果某个域名需要覆盖公共规则，应把自定义规则放在相应公共规则之前。IP 规则可增加 no-resolve，避免匹配过程为了获取目标 IP 主动触发 DNS 解析，但只有在连接本身已经提供 IP 或前序流程能够得到 IP 时才有意义。

rules:
  - DOMAIN,api.example.invalid,DIRECT
  - DOMAIN-SUFFIX,example.invalid,国外网站
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,国外网站

上例先对单个主机执行直连，再让同一后缀下的其他域名走代理。这体现了“更具体的规则在前”的原则。实际配置中还要留意 DOMAIN-KEYWORD，它容易误匹配包含相同片段但用途无关的域名。可以用后缀规则表达时，优先使用 DOMAIN-SUFFIX；必须精确控制单个主机时使用 DOMAIN。

规则更新与回滚

规则集更新不应与客户端升级混为一件事。客户端、内核、订阅节点和规则集分别有自己的变化周期。每次只改变一个层面，观察日志中规则提供器是否成功加载，再验证几个代表性域名。如果更新后大量网站路径异常，先恢复旧规则缓存或暂时禁用新提供器，而不是同时修改 DNS、TUN 和策略组。将个人规则保存在单独文件中，可以避免订阅刷新覆盖本地修改。

日志里出现规则提供器下载失败时，先确认 URL 是否可访问、文件格式是否匹配、缓存目录是否具备写入权限。若只有启动阶段失败而之后手动更新成功，可能是设备刚联网时网络尚未就绪。此时可延长自动更新间隔，并保留有效缓存。与规则相关的基础术语可在概念速查中对照；不要仅凭规则名称判断效果，最终依据始终是连接日志显示的命中规则与策略组。

03 / 名称解析

DNS 配置优化与解析链路

DNS 配置决定域名如何转换为地址，也影响规则能否拿到足够的信息。问题常被误判为节点不可用：节点连接正常，但域名解析失败、返回结果不合适或查询走错网络，同样会表现为网页打不开。排查时应把“DNS 查询由谁处理”“查询发往哪里”“得到的结果如何进入规则匹配”拆成三个步骤，而不是反复切换节点。

基础监听与上游分工

enable 控制 mihomo DNS 模块是否启用，listen 决定监听地址。仅供本机使用时应优先监听回环地址；Android 客户端通常由应用管理监听和 VPN 接管，不需要为局域网设备开放端口。default-nameserver 主要用于解析加密 DNS 上游自身的域名，因此通常填写可直接访问的 IP 地址解析器。nameserver 承担主要查询，proxy-server-nameserver 可专门解析代理服务器域名，避免代理节点域名的解析又依赖尚未建立的代理链路。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

上游地址应根据当前网络可达性选择，数量并非越多越好。并行查询多个解析器可能得到不同结果，也会增加定位难度。先使用一组稳定上游建立基线，再按需要配置分流。若代理服务器本身使用域名，必须确保其域名能在代理启动前解析；否则会形成“建立代理需要 DNS，而 DNS 又需要代理”的环路。

redir-host 与 fake-ip 的区别

redir-host 返回真实解析地址，连接过程更接近系统原有行为，兼容性直观，但内核在后续阶段可能只能看到 IP，域名规则是否生效取决于流量入口和映射信息。fake-ip 为域名分配保留网段中的临时地址，应用连接该地址后，内核根据映射恢复原始域名再执行规则。它通常能让域名规则在 TUN 场景下保持一致，也减少真实 DNS 结果提前暴露给应用的机会。

Fake-IP 不是远端服务器地址，不能把它当作解析错误。看到 198.18.0.0/16 范围的结果，通常说明增强模式正在工作。真正需要关注的是连接是否被内核接管，以及对应映射是否仍然存在。部分局域网发现、设备投屏、网络连通性检测和依赖特殊 DNS 返回值的应用不适合 Fake-IP，可通过过滤列表让这些域名返回真实结果。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"
    - "connectivitycheck.gstatic.com"

过滤项应基于实际日志逐步增加。把过多后缀放进过滤列表，会削弱 Fake-IP 对域名识别的作用；过滤过少则可能让局域网服务发现失败。修改后需要清理旧 DNS 缓存或重启内核，避免旧映射影响判断。

按域名选择解析器

nameserver-policy 可让特定域名或规则集使用指定解析器。例如内部域名交给家庭路由器，公共域名交给加密 DNS。策略应保持单向可解释：内部解析器只服务内部域名，不作为所有查询的随机候选。移动设备在 Wi-Fi 与蜂窝网络间切换时，局域网解析器可能突然不可达，因此依赖局域网地址的策略应考虑网络变化后的失败表现。

dns:
  nameserver-policy:
    "router.local": 192.168.1.1
    "+.home.arpa": 192.168.1.1
    "+.example.invalid":
      - https://1.1.1.1/dns-query

DNS 故障的验证顺序应固定：先确认域名是否产生查询日志，再确认上游是否返回结果，然后确认规则命中，最后检查连接是否通过预期策略组建立。若 IP 地址可访问而域名不可访问，问题更可能位于解析层；若域名已经解析且日志显示建立连接失败，则应转向节点、路由或 TUN 检查，而不是继续更换 DNS。

04 / 流量接管

TUN、Fake-IP 与 Android VPN 接口

TUN 模式通过虚拟网络接口接收系统流量，使不读取系统代理设置的应用也能进入 mihomo。Android 客户端使用系统 VPN 权限建立这一接口，因此状态栏出现 VPN 标识属于正常现象。TUN 解决的是流量入口问题，Fake-IP 解决的是域名映射和识别问题；两者经常组合使用，但并不是同一个功能。

自动路由与严格路由

auto-route 让内核自动配置路由，把目标流量引向 TUN 接口。strict-route 进一步约束未按预期进入接口的路径，减少流量从其他路由绕过，但也可能放大与热点共享、局域网访问、企业 VPN 或特殊系统路由的冲突。首次启用时应先使用自动路由，确认基础访问正常，再根据泄漏控制和应用兼容需求评估严格路由。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack 决定 TUN 网络栈实现。mixed 通常用于兼顾兼容性与性能；不同系统、不同客户端封装的可选值可能存在差异，应以客户端当前可接受的配置为准。切换网络栈属于诊断手段，不应在没有故障证据时频繁修改。auto-detect-interface 用于识别实际出站接口，设备在 Wi-Fi 与移动网络之间变化时较为实用。

DNS 劫持的范围

dns-hijack 将发往常见 DNS 端口的查询交给 mihomo DNS 模块处理，使应用不容易绕过统一解析策略。它不一定能接管应用内置的加密 DNS，因为后者表现为普通 HTTPS 或 TLS 连接。若浏览器自行启用安全 DNS，相关域名解析可能不会出现在 mihomo 的普通 DNS 日志中。需要统一行为时，应在应用设置中关闭独立解析功能，或明确接受两套解析路径并分别诊断。

劫持范围也不应无限扩大。局域网设备发现、运营商认证页面或企业网络内部域名可能依赖本地 DNS。遇到连接 Wi-Fi 后认证页不弹出、打印机名称无法解析等问题，可先暂停 TUN 验证，再决定使用直连规则、真实 IP 过滤或局域网 DNS 策略，而不是直接删除全部 DNS 配置。

Android 上的应用分流

Android 的 VPN 接口同一时间通常只能由一个应用占用。系统中的其他 VPN、工作资料管理工具、基于 VPN 的防火墙或过滤工具可能与 Clash Plus、Clash Meta for Android、FlClash、Surfboard 产生冲突。界面显示已启动但系统没有建立 VPN 接口时，应检查是否有其他应用仍持有权限，以及系统是否撤销了后台运行许可。

客户端若支持按应用包含或排除，可以只接管指定应用，也可以让少数局域网工具绕过。包含模式便于测试：先选一个浏览器确认路径，再逐步加入其他应用。排除模式适合大部分应用都需要接管、只有银行应用或局域网控制应用例外的情况。两种模式同时叠加容易产生理解偏差，应只选择一种清晰规则，并记录哪些应用由系统直接联网。

现象 优先检查 验证动作
启动后所有应用断网 默认策略、DNS、TUN 路由 先切换到直连策略，再关闭 DNS 劫持对照
浏览器可用，部分应用不可用 应用分流、QUIC、证书或网络栈 查看该应用连接是否进入日志
局域网设备无法访问 私有网段规则、严格路由 确认私有网段在宽泛代理规则之前直连
切换 Wi-Fi 后失去连接 实际出站接口与系统省电限制 重建 VPN 接口并检查接口自动识别

若需要先理解 TUN 的基础工作机制，可阅读安卓 Clash TUN 模式原理与开启方法。本章更侧重参数之间的关系。最终判断不以开关是否显示开启为准，而以系统 VPN 接口、DNS 日志、连接日志和规则命中是否形成完整链路为准。

05 / 域名恢复

域名嗅探的用途、覆盖与边界

某些连接进入内核时只携带目标 IP，规则系统无法直接知道原始域名。域名嗅探会读取连接早期可见的协议元数据，例如 TLS 握手中的服务器名称或 HTTP 请求中的主机字段，从而恢复域名并重新参与规则匹配。它不是读取网页正文，也不能从所有加密连接中取得域名；协议是否提供可见元数据、连接是否在握手阶段被接管，都会影响结果。

TLS、HTTP 与 QUIC 嗅探

TLS 嗅探常用于读取 ClientHello 中的 SNI，HTTP 嗅探读取 Host，QUIC 嗅探则处理基于 UDP 的相关握手。启用协议越多，覆盖面越广，但误判与兼容问题也会增加。初始配置可以只启用实际需要的端口范围，并保留跳过列表。若某个应用连接后立即重试、视频启动失败或日志中域名与实际服务不符，应对该域名或目标网段禁用嗅探，而不是关闭全部规则系统。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "+.lan"
    - "+.local"

parse-pure-ip 允许对纯 IP 目标尝试恢复域名。force-dns-mapping 会结合 DNS 映射信息辅助识别，尤其适用于 Fake-IP 和内核 DNS 已经掌握域名映射的情况。override-destination 决定嗅探到域名后是否覆盖原始目标用于后续连接。覆盖能提高部分域名规则的一致性，但对于依赖固定 IP、特殊证书行为或私有协议的服务可能造成差异，因此更适合在确认需求后启用。

嗅探与 Fake-IP 的配合

Fake-IP 场景下，内核通常已经能通过虚拟地址映射取得原始域名，嗅探更多用于补充绕过内核 DNS、直接连接真实 IP 的流量。redir-host 或部分透明代理场景中，嗅探对恢复域名更重要。两种机制同时启用时，应理解域名来源：日志中的域名可能来自 DNS 映射，也可能来自协议握手。若两者不一致，覆盖策略会决定最终用于规则匹配和连接的名称。

配置域名规则后仍命中 IP 规则，不一定说明嗅探失效。连接可能没有可嗅探字段，可能使用加密客户端问候扩展，可能在嗅探完成前已按 IP 规则处理，也可能目标应用直接使用自定义协议。排查时选择普通 HTTPS 网站作为基线，确认日志能显示 SNI，再测试有问题的应用。不要用一个不支持嗅探的协议去否定整个功能。

跳过列表与风险控制

skip-domain 适合局域网域名、设备发现服务、已知嗅探后异常的业务域名。部分配置还支持按目标地址或源地址跳过，可用于内部网络。跳过规则应尽量具体，避免使用过宽后缀。若把整个常见顶级域加入跳过列表，等同于让大量公网连接失去域名恢复能力。

域名嗅探不能替代正确的 DNS 配置。DNS 已经失败时，应用可能根本无法发起可供嗅探的连接；连接使用 IP 时，嗅探也不保证一定能恢复名称。合理顺序是先让 DNS 与 TUN 链路稳定，再启用嗅探补足纯 IP 流量。每次修改后查看日志中的目标、嗅探结果、命中规则和最终策略组，四项一致才算达到预期。

在移动网络上，UDP 与 QUIC 的路径可能和 TCP 不同。若网页可打开但视频或实时通信异常，可临时禁用 QUIC 嗅探或通过规则阻断 UDP 443 做对照，让应用回退到 TCP。该操作用于定位，不应默认长期阻断所有 UDP。确认具体服务和网络条件后，再决定保留何种协议范围。

06 / 配置编排

本地覆写与多订阅合并

订阅通常由服务提供方维护，刷新时会替换节点、策略组或规则。如果直接编辑订阅生成的主配置，本地修改很容易在下次更新后消失。覆写的目标是把“远端经常变化的部分”和“本地希望长期保留的部分”分离。节点列表可以来自订阅，DNS、TUN、个人规则和策略结构则由本地覆写稳定控制。

覆写的优先级与最小修改面

不同客户端对覆写的实现名称有所区别，可能称为覆写、混入、配置补丁或脚本处理。无论界面如何命名，都应先确认合并方向：是本地字段覆盖远端字段，还是将数组追加到远端数组。映射字段通常可以按键合并，数组字段则可能整体替换。规则和策略组都是数组，误以为“追加”而实际发生“替换”，会导致订阅原有规则全部消失。

最稳妥的方式是保持覆写范围小。只修改明确需要控制的字段，例如 DNS 增强模式、TUN 开关、外部控制监听和位于规则顶部的个人例外。策略组若由本地完全接管，就应同步检查远端规则是否引用了已经不存在的组名。名称是引用关系的一部分，中文空格、大小写和全角符号变化都可能造成目标找不到。

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

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

store-selected 用于保留策略组选择，订阅刷新或内核重启后不必每次重新选择。store-fake-ip 可保存 Fake-IP 映射，减少重启后已有连接对应关系丢失的影响。是否启用应结合客户端存储权限和问题表现；发生映射异常时，可以清理缓存后重新建立，而不是持续叠加旧状态。

多订阅通过 proxy-providers 汇入

多订阅不应简单复制粘贴成一个巨大节点数组。使用 proxy-providers 可以让每个来源独立更新、独立缓存，并在策略组中按需引用。主订阅与备用订阅采用不同文件路径，更新失败时也不会相互覆盖。健康检查可以放在提供器层，让引用该提供器的多个策略组共享检查结果。

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

  provider-backup:
    type: http
    url: https://example.invalid/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

示例地址为保留测试域，实际订阅地址属于敏感配置，不应放进公开文件、截图或共享日志。多来源节点可能重名，内核或客户端合并时可能覆盖、重命名或拒绝加载。可在提供器中使用前缀、后缀或过滤机制区分来源，例如给备用来源统一增加“备用”前缀。策略组筛选时再基于前缀和地区关键词组合，避免同名节点造成无法判断来源。

更新失败与回滚策略

订阅自动更新间隔不宜过短。节点变化通常不需要分钟级刷新，频繁请求会增加失败机会，也可能在临时网络异常时用不完整内容替换当前配置。客户端提供“配置自动更新 · 间隔 1440 分钟”一类设置时，日级更新通常足以覆盖常规变化。每次更新后应先完成语法校验，再切换正在运行的配置；支持保留旧配置的客户端，应至少保存上一份可启动版本。

若多订阅合并后无法启动，按层拆分：先只保留本地基础配置，再加入主提供器，随后加入备用提供器，最后恢复策略组和规则。解析错误通常能定位到字段或行号；逻辑错误则需要从“节点是否加载、组是否包含成员、规则目标是否存在”三步检查。不要在失败状态下继续增加转换脚本，这会把原始错误包裹在更多处理层中。

需要在桌面与 Android 间迁移时，优先迁移不含设备路径的通用字段。Windows 与 Android 对文件路径、监听权限、TUN 实现和应用分流的处理不同，不能假设同一份完整配置在所有平台上直接复用。关于停更客户端迁移，可参考迁移到 mihomo 内核客户端的配置方案。

07 / 控制接口

外部控制面板与接口安全范围

mihomo 的外部控制接口允许兼容面板读取策略组、切换成员、查看连接和日志。它提供的是管理能力，不是代理端口。控制接口与 mixed-port、HTTP 代理端口或 SOCKS 端口应分别规划。仅在本机使用时监听回环地址，可以减少局域网中其他设备访问控制面的机会。

监听地址与访问口令

external-controller: 127.0.0.1:9090
secret: "replace-with-a-local-password"
external-ui: ./ui
external-ui-name: dashboard

external-controller 指定监听地址和端口。127.0.0.1 只接受本机连接，适合客户端内嵌面板或同设备浏览器。若确实需要从局域网管理，可以改为局域网可达监听地址，但必须同时设置访问口令，并通过系统防火墙限制来源。控制接口能够修改运行状态和查看连接信息，不应直接暴露到公网。

external-ui 指向静态面板文件目录。面板只是控制接口的前端，加载成功不代表已经连接到内核。页面空白、策略组不显示时，要分别检查静态文件是否存在、浏览器是否能访问控制地址、口令是否一致，以及面板填写的协议与端口是否正确。若客户端自带面板入口，优先使用客户端管理的路径，减少手工配置目录差异。

从其他设备访问局域网控制面

跨设备访问需要同时满足四层条件：内核监听非回环地址，操作系统防火墙允许该端口，访问设备能到达主机局域网地址，控制口令正确。任一层不满足都会表现为面板连接失败。先在运行内核的设备上访问本机地址，再从同一局域网的另一台设备测试。不要一开始就更改代理端口、TUN 路由和控制接口，因为这些设置解决的是不同问题。

启用 allow-lan 主要影响代理端口是否接受局域网连接，不应把它当作外部控制接口的唯一开关。控制接口由自己的监听地址决定。若只想让其他设备使用代理而不允许管理内核，可以开放代理端口并继续把控制接口限制在回环地址。反过来，只开放控制接口也不会自动让局域网设备获得代理能力。

使用接口读取状态

调试时可以从本机请求控制接口确认内核是否响应。下面示例只请求版本信息和代理组列表，不包含真实口令。实际设置了口令时，需要在请求头中提供对应授权信息。命令应在运行内核的同一设备执行。

curl http://127.0.0.1:9090/version
curl http://127.0.0.1:9090/proxies

第一个请求确认控制服务是否启动，第二个请求确认策略组是否成功加载。若端口拒绝连接，优先检查监听地址、端口占用和内核启动日志；若返回未授权，说明接口存在但访问口令不匹配；若返回数据但面板不显示，则问题位于面板配置、浏览器限制或静态资源，而不是策略组本身。

日志级别与连接观察

log-level: info 适合日常排查，可看到规则命中与连接建立信息。更详细的调试级别会产生大量记录，只应在复现问题时短时开启。日志可能包含访问域名、局域网地址和策略名称，分享前应删除个人订阅地址、认证字段及不相关连接。排查完成后恢复常规级别，避免长时间记录带来存储压力。

接口状态 含义 下一步
连接被拒绝 没有监听或端口不可达 检查启动日志、监听地址与端口占用
返回未授权 控制服务可达，口令不匹配 核对面板和配置中的访问口令
接口有数据，面板空白 内核正常，前端连接或资源异常 检查面板地址、静态目录和浏览器控制台
策略组缺少成员 提供器、筛选或组引用异常 查看提供器更新状态和 filter 结果

外部面板适合观察，不应取代配置文件本身的版本管理。策略组切换属于运行状态，规则、DNS 和 TUN 参数仍应回到配置来源中修改。否则重启、订阅刷新或更换客户端后，面板里的临时操作无法还原完整意图。

08 / 故障定位

配置诊断顺序与长期维护

复杂配置出现问题时，最有效的方法是缩小变量，而不是连续切换所有开关。将链路分为配置解析、代理提供器、DNS、规则匹配、策略选择、流量接管和目标连接七层，每次确认一层是否正常。日志中的第一条错误通常比后续连锁错误更有价值；先处理配置无法加载、提供器无法读取等上游问题，再看具体网站连接。

从最小可运行配置开始

建立一份最小配置作为诊断基线，只保留一个可用代理、一个手动策略组、基础 DNS 和最终规则。确认它能启动后，再按策略组、规则提供器、TUN、Fake-IP、嗅探、覆写的顺序逐层恢复。每恢复一层就测试同一组目标：一个直连网站、一个应走代理的网站、一个局域网地址和一个问题应用。固定测试对象能避免把网站自身波动误判为配置变化。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: local-test
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 测试策略
    type: select
    proxies:
      - local-test
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,测试策略

示例中的本地 SOCKS 服务只有在设备确实运行对应端口时才可用，它用于展示最小结构，不是公共节点。实际诊断可以换成已确认可用的订阅节点。最小配置的目的，是证明客户端、内核和基础网络路径可工作；若它仍无法启动，应先检查 YAML 缩进、字段支持范围和端口冲突。

按现象选择检查层

“已连接但无法上网”先看默认策略是否选择了可用成员，再看 DNS 是否返回结果，然后检查 TUN 是否接管。完整清单可参考安卓端逐项排查清单。“只有部分网站失败”更可能与规则、IPv6、DNS 结果、UDP 或目标服务的出口限制有关。“所有节点都慢”应先排除本地 Wi-Fi、蜂窝网络和系统省电限制；“只有一个节点慢”则优先看节点和线路。速度问题可继续阅读节点、线路与本地设置三层定位法。

日志中若显示 DIRECT，而预期应走代理，检查规则顺序和域名是否成功恢复；显示正确策略组但连接失败，检查该组当前成员；没有任何连接日志，检查应用是否进入系统代理或 TUN；有 DNS 日志但没有后续连接，可能是应用缓存、解析结果不符合预期或连接被系统层阻止。每一种现象都对应不同层，不要只用“换节点”处理。

YAML 结构与常见解析错误

YAML 使用空格表达层级，不能用制表符混排。列表项的短横线应与同级条目对齐，包含冒号、井号或特殊字符的名称可使用引号。重复键可能被解析器覆盖，也可能直接报错；合并多份配置时尤其要检查是否出现两个 dns、两个 rules 或多个同名提供器。配置能解析并不表示引用关系正确，仍需检查策略组、规则集和提供器名称。

遇到错误行号时，应同时查看前几行。真正缺少缩进或引号的位置经常位于报错行之前。可以先删除最近加入的完整区块确认是否恢复，再把区块分半加入，以二分方式定位。不要只删除报错行，因为那一行可能只是解析器第一次无法继续理解的位置。

变更记录、备份与更新节奏

建议保留三份状态：最后确认可用的配置、当前测试配置、订阅或规则更新前的快照。文件名可使用日期和用途，但不要在公开位置保存订阅地址。每次变更记录“为什么改、改了哪些字段、如何验证”，比单纯保存大量副本更容易回滚。客户端升级、内核变化、订阅更新和规则集更新应分开执行，避免一次变化覆盖四个层面。

更新客户端时优先选择仍在维护且适合当前平台的包。Android 可在安装包页面的 Android 分区查看 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard；桌面端应按对应平台选择。Clash for Windows 与 ClashX Meta 已停止维护，迁移时应先导出通用配置，再处理平台特有字段，而不是继续围绕旧客户端增加补丁。

推荐的固定排查流程

  1. 确认配置已加载。查看启动日志是否存在语法错误、字段不支持或端口占用。
  2. 确认节点与提供器存在。策略组必须有成员，远端提供器应有可用缓存。
  3. 确认 DNS 有结果。区分查询未发出、上游失败和结果不合适三种情况。
  4. 确认规则命中。从日志核对域名、规则类型、目标策略组和当前成员。
  5. 确认流量入口。系统代理、TUN 和应用分流至少有一种覆盖问题应用。
  6. 确认目标连接。最后才判断节点线路、目标限制、UDP 或 IPv6 路径。

长期稳定的配置通常并不复杂。它有清晰的策略层、有限且可信的规则来源、可解释的 DNS 路径、受控的 TUN 范围和可回滚的覆写。自动化应建立在这些关系已经明确之后。配置目标不是开齐所有选项，而是让每条连接的入口、名称解析、规则命中和出口选择都能从日志中得到解释。