Clash 策略组、规则集与网络栈配置

策略组类型与可维护的分流结构

策略组不是节点的简单文件夹，而是规则与实际出口之间的稳定接口。规则只需要指向“代理”“流媒体”“下载”这类长期不变的策略名，节点增删、订阅更换和地区调整则留在策略组内部完成。这样做的直接收益是减少配置联动：替换订阅时不必重写规则，切换某项业务的出口时也不必逐条查找域名。规划策略组时应先画出流量层级，再决定组类型，而不是把订阅里的所有节点一次性塞进同一个选择组。

四种常用组类型怎么选

select 是人工选择组，适合总入口、指定地区和需要稳定出口的业务。它不会自行改变当前选项，因此行为最容易预测。url-test 会按照测试地址和间隔检测可用性，并从候选项中选择响应较快的节点，适合日常网页浏览。fallback 按列表顺序使用首个可用节点，更重视优先级和连续性，适合希望主线路失效后再切备用线路的场景。load-balance 会把不同连接分配到多个节点，适合并行请求较多的任务，但同一网站的不同连接可能出现出口变化，对登录状态、风控严格的网站并不友好。

延迟测试值只表示测试目标在当时网络条件下的响应，不等于下载速度，也不能代替实际可用性判断。测试地址应选择稳定、体积很小且能快速返回的 HTTPS 资源。interval 过短会持续产生探测请求，过长则可能在节点失效后较久才更新。家庭网络通常从数分钟级间隔开始更合适；移动网络还要考虑后台限制和网络切换，不能仅靠测试组完成恢复。

先做地区组，再做业务组

更稳妥的结构通常分三层。底层是节点或代理提供者；中间层是“香港自动”“日本备用”“美国手选”等地区组；顶层是“代理”“流媒体”“开发服务”等业务组。业务组引用地区组，规则只引用业务组。不要让每个业务组直接包含几十个原始节点，否则订阅改名、节点下线和重复节点都会让每个组一起变得难以维护。

proxy-groups:
  - name: 香港自动
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 日本备用
    type: fallback
    use:
      - provider-main
    filter: "(?i)日|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 代理
    type: select
    proxies:
      - 香港自动
      - 日本备用
      - DIRECT

  - name: 开发服务
    type: select
    proxies:
      - 代理
      - 香港自动
      - 日本备用
      - DIRECT

use 引用的是 proxy-providers 名称，proxies 引用的是具体节点、内置策略或其他策略组。两者不能随意互换。过滤表达式应尽量兼容供应方的命名差异，例如同时覆盖中文地区名、英文缩写和完整英文名；但表达式也不能过宽，“US”可能误中其他单词，最好结合名称分隔符和订阅实际格式测试。

策略组之间还要避免循环引用。例如“代理”包含“自动选择”，而“自动选择”又把“代理”作为候选项，内核无法得到最终出口。修改后若出现组为空、策略无法选择或配置载入失败，应先检查名称是否完全一致，再检查引用方向。中文标点、前后空格和大小写差异都可能造成看似相同、实际不同的名称。

最后保留一个明确的总入口组，让临时排障更简单。发现某个网站异常时，先把总入口手动切换到另一地区或 DIRECT，再判断问题属于节点、规则还是目标站点。如果切换总入口后立即恢复，优先检查当前节点和地区组；如果始终直连，则检查规则顺序和模式；如果所有策略都无法访问，再进入 DNS、TUN 和系统网络栈排查。策略组设计得清楚，后续每一章都会更容易验证。

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

把数千条域名或 IP 规则直接写进主配置，会让文件难以阅读，也会让更新变成整份配置的替换。rule-providers 的作用是把规则内容拆成可独立下载、缓存和更新的集合，主配置只保留提供者定义和少量 RULE-SET 引用。规则集更新时不需要改动策略组，配置结构也更容易进行版本管理。适合订阅化的内容包括广告域名、局域网地址、特定服务域名和地区 IP 段；只针对一两个域名的个性规则则继续放在主配置顶部更直观。

behavior 决定规则集如何解释

domain 用于域名集合，条目可以是完整域名、域名后缀或关键词形式，具体写法取决于载荷格式。ipcidr 用于 IPv4、IPv6 网段，匹配时需要目标 IP。classical 能容纳带类型前缀和参数的经典规则，例如 DOMAIN-SUFFIX、IP-CIDR 与 PROCESS-NAME。如果来源文件本身写的是经典规则，却把 behavior 设为 domain，下载可能成功，但条目不会按预期工作。建立规则集前先查看文件内容，不要只凭文件名判断。

format 常用 yaml、text 或内核支持的二进制格式。YAML 载荷通常包含 payload 顶层键，文本格式则多为每行一条。path 是本地缓存位置，每个提供者必须使用不同路径，避免后下载的文件覆盖前一个。interval 控制更新间隔；规则本身变化不频繁时没有必要几分钟拉取一次。远程请求失败时，已有缓存通常仍可继续使用，因此不要把短暂的更新失败误判为所有规则已经失效。

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

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-ip.yaml
    url: https://example.com/rules/private-ip.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,代理
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理

示例中的地址用于展示结构，实际配置应换成自己确认可访问、内容格式匹配的规则来源。若规则文件需要鉴权，不要把长期凭据放在会公开同步的主配置里。更合适的做法是使用本地生成流程、受控反向代理或客户端支持的安全存储方式，并确保导出的诊断信息不会携带访问参数。

规则从上到下，首条命中即停止

Clash 的规则顺序比规则数量更重要。精确域名和个人覆写应放在前面，业务规则集居中，广泛的地域规则靠后，最后用 MATCH 承接其余流量。若先写 GEOIP,CN,DIRECT，后面某个服务规则集想把对应 IP 交给代理，已经命中的连接不会继续向下检查。类似地，把 MATCH 放到中间会使后续规则全部失去作用。

no-resolve 适合不希望规则匹配阶段主动解析域名的 IP 规则。在目标本来就是 IP 时，它仍然能够匹配；目标是域名时，则不会为了判断网段而额外查询地址。这个参数能减少不必要的 DNS 行为，但若配置依赖某个 IP 规则决定出口，就要确认目标地址在进入规则系统前是否已经可用。不要机械地给所有 IP 规则都添加该参数。

规则集未命中时，先确认三件事：提供者状态是否成功、文件格式与 behavior 是否一致、目标请求是否带有可匹配的域名。浏览器使用加密 DNS、应用直接连接 IP，或者 TUN 没有接管该进程时，看到的匹配对象可能与预期不同。此时应结合连接列表查看实际目标、命中规则和策略，而不是反复调整规则顺序碰运气。

长期维护时，可以为每个规则集记录来源、用途、行为类型和对应策略组。新增规则先以单条形式放在主配置顶部观察几天，确认没有误伤后再并入自建规则集。删除规则也先检查连接日志，避免把“当前没有访问”误当成“永远不需要”。想进一步理解主配置各段的排列关系，可阅读Clash 配置文件 YAML 各段字段逐段解析。

DNS 配置优化与泄漏排查

DNS 配置要解决三个不同问题：域名由谁解析、查询本身从哪个网络出口发出、解析结果如何交给规则系统。只修改一个公共 DNS 地址通常不能同时解决这三件事。系统 DNS、Clash 内置 DNS、浏览器安全 DNS和应用自带解析还可能并存，因此排查时先确认实际请求路径，再讨论服务器选择。一个可控的方案通常让被接管的应用统一进入 Clash DNS，由规则和代理策略决定后续连接。

nameserver、proxy-server-nameserver 与 direct-nameserver

nameserver 是常规域名查询的主要上游。使用 HTTPS 或 TLS 形式可以降低本地网络对明文查询的干扰，但连接加密不代表查询一定经过代理，具体出口仍取决于内核能力、规则和引导解析。proxy-server-nameserver 主要用于解析代理服务器自身的域名，避免出现“要连接代理先解析域名，而解析又必须经过尚未建立的代理”的循环。direct-nameserver 用于明确走直连的查询，适合局域网设备名或本地网络服务，但需要客户端和内核支持相应字段。

default-nameserver 常用于解析加密 DNS 服务器地址本身，通常填可直接访问的 IP 形式解析器。它不是所有查询的最终上游，也不应堆放大量地址。若加密 DNS URL 使用域名，而默认解析器无法访问，表现往往是客户端启动后所有域名都卡住，但直接访问 IP 可能仍然正常。

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
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

listen 监听在所有接口时，局域网其他设备可能访问该端口。若只供本机使用，优先绑定回环地址；若确实需要作为局域网 DNS，则同时检查系统防火墙、访问控制和路由器设置。端口被占用时，内核可能启动失败或 DNS 模块无法监听。Windows 上可以用系统网络工具查找占用进程，macOS 与 Linux 可使用 lsof 或 ss 检查。

# Windows PowerShell
Get-NetUDPEndpoint -LocalPort 1053

# macOS
lsof -nP -iUDP:1053

# Linux
ss -lunp | grep 1053

Fake-IP 与 redir-host 的取舍

fake-ip 会先返回保留地址段中的映射地址，连接抵达内核后再恢复原始域名。这样规则系统更容易保留域名信息，域名规则匹配更稳定，也减少“解析得到某个 IP 后只能按 IP 判断”的情况。代价是部分局域网发现、时间同步、游戏联机、打印机或依赖真实解析结果的程序可能不兼容，需要加入 fake-ip-filter。过滤项应根据实际失败的域名逐步增加，不要直接复制一个极长列表，否则大量域名绕过 Fake-IP 后会削弱统一分流效果。

redir-host 返回真实解析结果，兼容性通常更直观，但域名与连接之间的关联更依赖 DNS 映射缓存。面对 CDN、多地址轮换和应用自带解析时，规则判断可能不如 Fake-IP 稳定。选择时不要只看某个测试网站的结果：常用应用、局域网服务、休眠恢复和网络切换都应纳入验证。

DNS 泄漏要按请求路径确认

所谓泄漏通常指应由受控上游或代理路径处理的查询，仍被系统、路由器、运营网络或浏览器独立发送。在线检测只能看到检测页面触发的一部分查询，不能证明所有应用都采用同一路径。更可靠的做法是先关闭浏览器自带安全 DNS或将其配置为与系统方案一致，再观察 Clash 日志、系统 DNS 设置和本地端口流量。本站的Clash DNS 泄漏检测方法与防泄漏配置步骤给出了在线检测与本地观察的组合流程。

出现“能打开 IP，打不开域名”时，从 DNS 模块启动状态、监听端口和上游可达性开始；出现“部分域名解析很慢”时，检查多个上游是否有一个长期超时，以及 IPv6 查询是否被网络丢弃；出现“规则应该代理却直连”时，确认应用是否绕过系统解析、连接列表里是否保留域名，以及目标规则是否位于宽泛直连规则之前。

如果系统在启停 TUN 后留下错误 DNS，可以先完全退出客户端，恢复网卡为自动获取 DNS，再重新启动。不要同时运行多个会修改系统代理、虚拟网卡或 DNS 的网络工具。它们各自单独工作正常，也可能因为后启动者覆盖前者而造成间歇故障。

TUN 模式、Fake-IP 与系统网络栈

系统代理只影响主动读取代理设置的应用。命令行程序、游戏、商店组件、部分桌面客户端和直接建立套接字的程序可能完全忽略它。TUN 模式通过虚拟网卡接管更广泛的 IP 流量，再交给 Clash 规则判断，适合需要统一处理非代理感知应用的场景。它并不是“更强的系统代理开关”，而是一套涉及路由、DNS、虚拟接口和权限的网络路径，因此启用前应先确保普通系统代理模式已经工作正常。

核心字段与栈选择

enable 控制 TUN；auto-route 让内核安装必要路由；auto-detect-interface 用于识别当前默认出站接口，减少有线、无线和热点切换后的手工修改；dns-hijack 把指定端口的 DNS 请求交给内置 DNS。stack 决定网络栈实现，常见值包括 system、gvisor 和支持混合处理的栈。不同内核及平台支持范围存在差异，应以当前客户端实际提供的选项为准。

system 通常利用系统网络能力，性能与兼容性较自然，但行为会受到操作系统差异影响。gvisor 使用用户态网络栈，隔离更明确，在部分环境能绕开系统栈限制，但也可能对特殊协议或高并发连接产生不同表现。切换栈属于排障手段，不应在没有故障证据时频繁改动。每次只改一个变量，并在同一网络条件下验证。

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

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

strict-route 能减少流量绕过预期路由的机会，但在虚拟机、容器、公司 VPN 和复杂局域网环境中也可能影响原有路由。启用后如果局域网设备、远程桌面或开发容器突然不可达，应对照启用前后的路由表，确认私有网段是否仍通过正确接口。需要访问局域网时，可以用规则将私有地址设为直连，但规则只能决定进入内核后的出口，不能修复一条已经被错误系统路由截走的连接。

Fake-IP 地址不是实际目的地址

启用 Fake-IP 后，抓包或系统连接列表中看到 198.18.0.0/16 一类地址是正常现象。应用先连接这个映射地址，内核根据映射表还原域名，再执行规则和真实解析。不要把该地址段加入普通直连路由，也不要将它解释成远端服务器地址。如果连接到 Fake-IP 后没有被 TUN 接管，系统会尝试把保留地址当作真实目标，表现为立即失败或长时间等待。

因此，Fake-IP 和 TUN 的关键是闭环：DNS 查询由 Clash 返回映射地址，应用连接映射地址，路由再把这条连接送回 Clash。任一环节由另一款工具接管，都可能破坏映射。典型冲突包括浏览器绕过系统的独立 DNS、另一个虚拟网卡抢占默认路由、公司安全软件过滤保留网段，以及休眠恢复后旧虚拟接口仍保留较高路由优先级。

按平台理解权限与冲突

Windows 上出现启用后完全断网，先关闭 TUN，确认基础代理恢复，再检查虚拟网卡是否成功创建和默认接口是否识别正确。macOS 上应确认客户端获得网络扩展权限，并关闭其他同时运行的 VPN。Linux 服务器上还要检查内核是否提供 TUN 设备、运行用户是否具有创建接口和修改路由的能力。Android 依赖系统 VpnService，一次通常只能保留一个活动 VPN；相关授权和后台限制可参考Android 版 VpnService 授权与省电白名单设置要点。

排查 TUN 最有效的方式是分层测试：先关闭 TUN，仅用系统代理验证节点；再启用 TUN 但保持简单规则；然后测试域名、直接 IP、局域网地址和不读取系统代理的应用；最后才加入复杂 DNS、嗅探与规则集。若一开始同时启用所有高级选项，任何一处失败都会呈现为“网络不可用”，很难判断实际故障点。

域名嗅探的用途、配置与边界

规则分流最理想的输入是域名，因为域名通常比不断变化的 CDN 地址更容易表达业务归属。但部分应用会先自行解析，再直接连接 IP；有些透明接管场景也只能在连接建立初期看到目标地址。域名嗅探会从 TLS 握手中的 SNI、HTTP 请求头或其他可识别信息中恢复目标域名，使域名规则重新获得匹配机会。它补充的是连接元数据，不是替代 DNS 的万能功能。

TLS 与 HTTP 嗅探分别看什么

TLS 嗅探通常读取握手阶段公开可见的服务器名称，不会解密后续内容。HTTP 嗅探可以读取明文请求中的 Host 字段。目标协议不携带域名、应用使用直接 IP、连接复用已有通道或采用隐藏服务器名称的机制时，嗅探可能得不到结果。UDP 协议的可识别范围也取决于内核实现与具体流量，不能假设所有 UDP 连接都能恢复域名。

嗅探得到的域名应与连接真实目的保持一致。若共享 IP 上承载多个站点，错误覆盖目标可能导致规则误判；某些应用也会连接与证书、SNI 不一致的专用地址。配置时可以先开启常用端口，观察连接记录，再决定是否扩大范围。不要为了追求更高的“域名显示率”而扫描所有端口。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    TLS:
      ports:
        - 443
        - 8443
    HTTP:
      ports:
        - 80
        - 8080-8880
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip 允许对纯 IP 目标尝试恢复域名，正是透明代理场景常用的能力。force-dns-mapping 会结合 DNS 映射帮助识别目标，和 Fake-IP 配合时尤其常见。override-destination 决定是否用嗅探结果覆盖原始目的地；打开后规则和连接目标可能更符合域名预期，但误嗅探的影响也更直接。建议先保持关闭，确认日志中的恢复结果稳定后，再根据实际需求决定。

何时应该加入跳过列表

跳过列表用于明确不适合嗅探或覆盖的目标。局域网设备、智能家居、推送服务、特殊认证程序和部分游戏可能依赖固定地址或非标准握手。若某个应用在关闭嗅探时正常，开启后稳定失败，并且连接日志显示恢复出了无关域名，可以把对应域名或进程相关目标加入跳过范围。不过应先确认问题确实来自嗅探，而不是 TUN、MTU、UDP 或节点本身。

列表条目需要遵守当前内核支持的域名匹配语法。完整域名适合单个服务，域名后缀适合一组子域名。范围越大的后缀越要谨慎，例如跳过整个顶级域会让大量连接失去嗅探能力。名称看起来像应用名的条目，是否有效取决于内核对特殊标记的解释，迁移到另一客户端时要重新核对。

嗅探与规则、DNS 的协作顺序

连接进入内核后，可能先从 Fake-IP 映射得到域名，也可能通过嗅探补回域名，然后才按规则选择策略。若 DNS 映射已经可靠，嗅探更多是补充；若应用完全绕过 Clash DNS，嗅探可能成为域名规则生效的关键。看到同一应用有时按域名规则、有时落到 IP 或最终规则，往往表示不同连接采用了不同解析和传输路径。

验证时准备三个层次的规则：一条精确域名规则、一条对应 IP 或地域规则、最后一条 MATCH。访问目标后查看命中的层次。如果精确域名规则始终不触发，但连接记录能看到正确域名，检查规则顺序和拼写；如果记录中只有 IP，检查 DNS 映射与嗅探；如果连接根本不出现，检查应用是否被系统代理或 TUN 接管。这样的对照比仅看网页能否打开更有诊断价值。

不同图形客户端可能把这些字段拆成“域名嗅探”“覆盖目标”“纯 IP 解析”等开关，也可能只开放一部分能力。Clash Plus、Clash Verge Rev、FlClash 等客户端的界面位置并不完全一致，但最终仍应以导出的实际配置和内核日志为准。迁移客户端时先保留最小嗅探配置，确认字段被当前内核识别，再逐项恢复高级选项。

本地覆写与多订阅合并

远程订阅解决节点分发问题，本地覆写解决个人策略长期保留问题。把 DNS、规则、策略组和实验参数直接写回订阅文件，下一次更新很可能全部被覆盖；完全禁止更新又会错过节点变更。更合理的结构是把远程订阅视为输入，把本地覆写视为可重复应用的变换，最终由客户端或转换流程生成运行配置。这样既能更新节点，也能保留自己的规则和网络栈设置。

区分替换、追加和前置

不同客户端对覆写的名称不完全相同，但操作通常落在三类：替换某个顶层字段、向数组末尾追加项目、向数组开头插入项目。DNS、TUN 这类完整对象适合明确替换或深度合并；规则数组通常需要把个人精确规则前置，把兜底规则保留在最后；策略组则要根据名称去重，不能简单把两份数组拼接。

最危险的操作是直接覆盖整个 rules 或 proxy-groups，却没有把订阅原有内容重新纳入。结果可能是节点存在但没有策略组引用，或规则只剩几条个人条目。修改前应导出当前有效配置，确认覆写发生在订阅更新之前还是之后，并检查客户端的合并顺序。相同脚本在不同客户端中运行时机不同，结果也可能不同。

# 本地前置规则示例
rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,developer.example,开发服务

# 本地 DNS 覆写示例
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

YAML 合并还会遇到锚点、空值和类型变化。一个字段在来源中是数组，在覆写中却写成对象，通常无法按预期合并；写成 null 可能表示删除，也可能只是得到空字段，取决于工具实现。为了可迁移，覆写尽量使用普通映射和数组，不依赖某个图形客户端独有的脚本接口。必须使用脚本时，应同时记录输入结构、处理顺序和预期输出。

多订阅先做命名隔离

合并两个订阅时最常见的问题不是节点协议，而是重名。两边都可能包含“自动选择”“故障转移”“代理”这样的组名，节点名称也可能重复。简单拼接会让后出现的对象覆盖前一个，或者让策略组引用到错误节点。稳妥做法是给不同来源增加固定前缀，例如“主订阅 / 香港 01”和“备用订阅 / 香港 01”，再由本地策略组统一引用。

如果客户端支持 proxy-providers，可以让多个来源分别成为提供者，利用 use 和 filter 组装地区组，而不是先把所有节点展开进主文件。这种方式更新边界清晰，某个来源失败时不会直接破坏另一个来源的缓存。提供者名称、缓存路径和健康检查地址都应独立。

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

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

proxy-groups:
  - name: 全部来源
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - DIRECT

示例地址只用于说明字段关系。真实订阅地址通常携带访问凭据，不应粘贴到截图、问题帖、公开仓库或诊断文件中。分享配置前可以删除 proxy-providers 的 URL、节点服务器地址、用户名和认证字段，只保留能复现结构问题的最小片段。

建立可回退的配置流程

每次大改前保留三份内容：未经处理的订阅输入、本地覆写文件、最终生成的运行配置。出现问题时先比较最终配置是否符合预期，再判断是订阅变化、合并逻辑还是内核行为。只保存最终文件无法区分错误在哪一阶段产生，也很难在下一次订阅更新后重复构建。

调整流程建议按固定顺序进行：先更新单个订阅并确认节点可用；再应用名称过滤和提供者健康检查；然后加入策略组；接着前置个人规则；最后启用 DNS、TUN 和嗅探。每个阶段都重新载入并检查日志。这样即使最终配置失败，也能准确找到首次出现异常的阶段。

如果合并后出现“节点可见但无法选择”，通常是策略组引用对象不存在；出现“个人规则更新后消失”，通常是覆写发生在错误阶段；出现“同名节点随机变化”，通常是来源没有做命名隔离。把问题放回输入、变换、输出三层检查，比在客户端界面中反复删除和重新导入更有效。

外部控制面板与安全的远程管理

外部控制接口允许图形面板读取代理组、连接、规则、日志和提供者状态，也能执行切换策略、更新提供者和关闭连接等操作。它适合把内核运行与管理界面分离，常见于服务器、路由器和独立内核部署。该接口拥有实际控制能力，不应被当作普通状态页面直接暴露到公共网络。

监听地址、密钥与面板目录

external-controller 定义 API 监听地址。仅本机使用时绑定回环地址最稳妥；需要局域网访问时可以绑定局域网接口或所有接口，但必须配合防火墙限制来源。secret 是控制接口凭据，应使用独立且足够长的值，不与订阅、系统账户或其他服务共用。external-ui 指向本地静态面板目录，内核只负责提供文件和 API，不会自动保证目录内容可信。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard
external-ui-name: metacubexd
external-ui-url: https://example.com/dashboard.zip

示例中的密码和面板地址仅展示语法。实际使用时应替换密码，并从自己确认的来源获取面板文件。若图形客户端已经内置控制面板，通常无需再设置远程下载地址。多个实例不能监听同一个 IP 与端口；端口冲突时，后启动的内核会报告绑定失败，面板可能继续显示旧实例的数据，让人误以为配置没有生效。

从浏览器访问本地面板时，还要区分页面地址与 API 地址。面板文件可以由某个 Web 服务提供，API 则由 Clash 内核监听。两者协议、主机或端口不同会形成跨域访问，是否允许取决于内核和浏览器策略。若面板能打开但一直提示无法连接，先在本机确认 API 端口监听，再检查面板填写的控制器地址和密钥，不要先重装内核。

局域网访问的最小开放范围

确实需要从手机或另一台电脑管理时，可以把控制器绑定到局域网地址，并在系统防火墙中只允许可信私有网段访问。不要在路由器上为控制端口配置公网端口转发，也不要使用弱密钥。公共网络中的设备可能主动扫描常见管理端口，一旦控制接口被访问，对方可以查看连接目标、改变策略或中断流量。

更安全的远程方式是先通过现有的受控私网、设备间安全隧道或系统远程管理能力进入本地网络，再访问回环或局域网接口。这样控制器仍不需要直接面对互联网。若反向代理控制接口，应启用访问认证、限制来源并正确处理 WebSocket；但多加一层代理也增加配置复杂度，家庭单机使用没有必要。

# Linux：确认控制端口只监听在回环地址
ss -lntp | grep 9090

# macOS：查看监听进程
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Windows PowerShell：查看端口状态
Get-NetTCPConnection -LocalPort 9090 -State Listen

用控制面板定位连接问题

面板最有价值的部分不是一键切换，而是把连接、规则和策略串在一起观察。排查某个网站时，先按目标域名或进程筛选连接，记录命中规则、策略链和最终节点；然后关闭该连接，让应用重新建立，避免旧连接继续沿用修改前的策略。只切换组但不重建连接，常会出现界面已经改变、实际请求仍走旧出口的错觉。

提供者页面可以确认订阅和规则集最近一次更新是否成功，但不能只凭“成功”判断内容正确。还要核对提供者条目数量是否异常、策略组过滤后是否为空，以及规则集行为类型是否匹配。日志页面适合查看解析失败、接口绑定失败、规则文件读取错误和节点握手错误；长期保持详细日志则会增加写入和隐私暴露，完成排障后应恢复常规级别。

完成配置后的整体验证

高级配置完成后，按固定用例验收比随意浏览更可靠。先验证直连网站、代理网站和局域网设备；再测试浏览器、命令行和一个不读取系统代理的应用；随后检查 DNS 查询、Fake-IP 映射和域名规则；最后进行休眠恢复、Wi-Fi 切换以及订阅更新。每项都记录预期策略与实际命中，异常时回到对应章节处理。

配置载入失败时，先检查 YAML 缩进、冒号后的空格、数组层级和重复键。配置载入成功但没有流量时，检查系统代理或 TUN 接管；有流量但策略不对时，检查域名信息、规则顺序和策略组引用；策略正确但连接失败时，再检查节点、协议和目标站点。这个顺序能避免把所有问题都归因于节点。

仍无法确定问题所属层级时，可查看疑难解答中的安装配置与故障排查分类。需要更换图形客户端或在其他系统复现配置，可到客户端下载页选择 Windows、macOS、Android、iOS 或 Linux 版本。图形界面适合日常切换和观察，最终判断仍以实际运行配置、连接记录和内核日志为准。