Clash 配置进阶手册

配置层级与 Clash 端口设置

修改前先找到真正生效的配置。订阅下载文件、客户端保存的配置、合并后的运行配置，往往不是同一份文件。订阅负责提供代理和基础策略，客户端偏好可能接管端口、模式、DNS 或 TUN，本地覆写再补充规则。看到编辑器里的字段不等于内核已经采用它，应同时查看运行配置、设置界面和启动日志，确认最终值。没有运行配置入口时，至少记录客户端是否开启了相关托管选项。

YAML 缩进与字段归属

YAML 使用空格表达层级，同一层字段必须对齐，列表项目以短横线开头。不要混用制表符，也不要在同一层重复写两个 dns 或 rules；重复键可能被拒绝，也可能只保留后面的值。带特殊字符的名称适合加引号，尤其是包含冒号与空格的文本。修改时保持原文件结构，只改目标字段；把整个订阅压缩成一行，会让缩进错误和错误覆盖难以定位。

把文件备份到本地，再执行一次配置检查。使用命令行内核时，可运行下列命令；./config.yaml 表示当前目录的配置文件，实际文件不在这里就调整路径。检查通过只表示语法和基本引用能够加载，不表示服务器可达、系统权限足够或 DNS 路径正确。客户端若带配置验证按钮，先验证再应用，避免把原本可用的会话一起中断。

mihomo -t -f ./config.yaml

混合端口与监听地址

mixed-port 让 HTTP 代理与 SOCKS 代理共用一个监听端口。它是本机应用连接内核的入口，不是远端节点的服务器端口，也不是控制面板端口。下面的设置仅监听回环地址，适合单机使用。浏览器通常交给系统代理接入，命令行工具则可能需要单独设置代理环境变量。是否自动设置系统代理，由客户端负责，不是写出 mixed-port 就会自动完成。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

端口报错时，先判断是另一个代理程序还是残留内核占用了入口。不要直接结束名称不明的系统进程。退出重复客户端，确认进程消失后重新启动；需要改端口时，连同系统代理、浏览器插件和终端环境变量一起修改。只改 YAML 而保留旧系统代理，表现常是内核正常运行、浏览器却连接被拒绝。具体命令可查阅端口占用排查文章。

建立可回退的修改流程

每次只调整一类行为，例如先改监听端口，再改 DNS，最后才开 TUN。应用后新建连接做验证，不能依赖已经建立的浏览器长连接。记录修改前后的字段、出现问题的应用和日志时间，回退时才能知道要恢复哪一层。若需要向他人求助，分享最小配置片段即可，删除订阅地址、认证字段和个人网络信息，保留字段结构与错误上下文。

最终判断配置是否生效，要看新连接是否到达内核、命中了什么规则、选择了哪个出口。开关亮起、文件保存成功、配置检查通过，分别只证明不同阶段完成。把这几层分开观察，才能避免把端口问题误判成订阅问题，或为了一个界面显示错误重写整份配置。

策略组类型与实际分流

规则决定流量交给谁，策略组决定从哪些出口里选。先为业务建立稳定的组名，再让节点在组内变化，订阅更新时就不必反复改规则。组名需要与规则目标完全一致，包括大小写、空格和标点。可以让一个组引用另一个组，但不能循环引用；例如手动选择组包含自动组是常见结构，自动组再反过来包含手动组，就会形成无法正常解析的依赖。

手动选择与自动选择

select 适合需要固定出口的场景，由用户在客户端选择成员。url-test 定期比较候选出口的测试延迟，适合希望自动调整的场景；fallback 按列表顺序选择可用成员，适合明确主备关系；load-balance 将不同连接分配到成员，并不把单次下载的带宽直接叠加。先选符合业务要求的行为，再考虑测量频率，不能因为自动组看起来方便就把所有应用都塞进去。

下面是一个可用于理解引用关系的最小片段。成员只有内置 DIRECT，因此它不会产生代理出口；导入真实订阅后，才能把订阅中已经存在的代理或其他组加入成员列表。这样写的目的，是让结构本身能够解释清楚，而不是用虚构服务器制造可连接的假象。实际使用时保留稳定的组名，把具体成员交给订阅或本地配置维护。

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出口选择
  - MATCH,DIRECT

测速参数不等于体验指标

自动测试通常需要 url、interval 等参数，tolerance 可用于减少小幅延迟变化造成的频繁切换。测试地址应是候选出口都能稳定访问的轻量资源。示例域名只能演示字段位置，不能直接充当可靠的测速服务；正式设置要按自身网络选择可访问的地址。测试太密会增加请求与移动设备耗电，测试太稀则会让故障状态更新迟缓，两者需要按使用环境平衡。

测试成功表示出口能够完成特定请求，不代表所有目标站点都能访问。某个出口可能握手很快，但晚高峰带宽有限；也可能适合网页，却不适合对抖动敏感的语音通话。比较自动组时，要用同一个目标、相近的时间和新建连接进行验证。延迟的含义与测量边界可继续阅读节点延迟测试与实际网速的区别，不要只按毫秒数决定长期出口。

业务组与节点来源分离

长期配置可以分成两层：底层组负责汇集节点、自动测试或主备切换，上层组负责网页、工作服务等业务选择。规则只引用上层组，节点名称变化只影响底层。使用 proxy-providers 时，组可以通过 use 引用已定义的来源；来源名称不是节点名称，必须在完整配置里先声明。客户端若会自动生成组，先确认是否保留自定义组，避免更新时把同名结构覆盖掉。

需要稳定登录状态的服务，优先使用手动组或明确主备组。频繁换出口可能触发额外验证，也会改变基于来源地址的访问判断。切换组成员后，已经建立的连接通常仍沿用原路径，新连接才采用新选择；必要时在连接列表关闭相关会话，而不是误以为切换没有保存。启用负载均衡前尤其要确认服务是否允许不同请求来自不同出口。

配置完成后，用一条明确域名规则验证业务组，再检查兜底规则。全局模式可能绕过原来的规则分流，直连模式也不会按预期使用业务组；因此排查组行为时先确认当前处于规则模式。只在客户端列表看到一个组，并不能证明任何流量已经引用了它，连接详情里的规则与链路才是最终依据。

规则集订阅化管理

规则集解决的是规则来源与更新问题，不负责提供代理节点。rule-providers 声明规则数据，rules 决定何时引用以及引用后的目标策略。两者分工不能混淆：只下载了规则文件而没有写 RULE-SET，不会自动参与匹配；写了引用但来源没有加载，配置可能直接失败。先把小规模本地规则跑通，再引入远程维护的集合，能更快分辨格式问题和网络问题。

行为类型与文件格式

behavior 描述集合里装的是什么规则。domain 适合域名集合，ipcidr 适合网段集合，classical 则保存带规则类型的条目，例如 DOMAIN-SUFFIX,example.com。规则目标通常由外层 RULE-SET 指定，不要再把策略组名写进 classical 集合条目。format 描述文件编码形态，YAML、纯文本与二进制格式不能只靠改扩展名互换，行为类型也要符合该格式支持的范围。

下例使用本地 YAML 文件，适合先验证结构。相对路径通常以内核工作目录解析，GUI 客户端可能有自己的配置目录或文件访问限制，不能默认它就是编辑器当前目录。先在对应目录建立 rules 文件夹，保存规则文件，再把 provider 声明合并到完整配置。业务规则放在兜底规则之前，示例以直连作为目标，不依赖外部代理组。

rule-providers:
  local-domains:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

上面的规则文件内容如下。它只包含匹配条件，不包含代理服务器、组定义或全局 DNS 设置。若使用 domain 类型，要按该类型的域名集合语法组织内容，不能把同一份 classical 文件仅改一个字段就当成另一种类型。遇到加载报错，应先对照 provider 的行为与格式，再查看文件内容，最后才检查规则本身是否符合预期。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.net

从本地文件迁移到远程来源

改成远程维护时，将来源类型调整为 http，设置真实规则地址，并保留独立缓存路径与合理更新间隔。interval 的单位是秒，不是分钟。每个 provider 使用不同路径，避免一个集合更新后覆盖另一个集合。远程来源必须是规则文件的实际内容地址，而不是网页预览地址；返回 HTML 登录页或访问提示页，即使下载请求成功，也不能被当作规则数据加载。

选择来源时看维护范围、条目类型和更新方式，而不是集合体积。覆盖面特别广的集合可能改变预期分流，尤其会影响工作网络、内网域名或特定应用的登录行为。首次引入时，把个人例外规则放在集合之前，用少量目标验证，再扩大覆盖范围。保留最近一次可用的本地配置，缓存行为则以实际内核和客户端为准，不要假设断网后一定能从空缓存启动。

规则顺序与解析副作用

规则从上到下匹配，先命中就停止。精确域名例外放前面，较宽的域名后缀与规则集放后面，MATCH 最后兜底。IP 类规则可能需要先解析域名，增加一次解析等待；适用规则上的 no-resolve 可避免为了判断该规则主动发起解析，但它不是所有规则都适用的通用开关。需要按域名决定策略时，通常优先安排域名规则，再安排必须依靠地址判断的规则。

某个目标分流异常时，先在连接详情读取实际命中的规则。如果命中了前面的广泛集合，后面的个人例外永远不会执行；如果只命中兜底，检查域名信息是否存在、规则文件是否加载、目标是否使用了另一个相关域名。日志里若显示规则下载失败，再追查来源访问与缓存目录权限。不要为了一个目标不匹配就同时换掉全部规则集，那会扩大排查范围。

长期维护建议为每个来源记录用途和预期目标策略。删掉一个 provider 前，先搜索全部 RULE-SET 引用；改组名时也要同步引用目标。用本地小集合保存个人例外，用远程集合维护通用分类，能把更新风险限制在明确边界内。复杂分流需要理解术语时，可对照概念速查，再回到连接记录验证结果。

DNS 路径与解析优化

先分清谁在解析，再选择解析服务器。应用可能使用系统 DNS、浏览器内置加密 DNS，或直接访问自己的解析服务；内核也可能为了代理服务器地址和规则判断单独发起查询。这些请求并不天然走同一条路径。只改 nameserver 而应用仍绕过内核解析，界面上字段正确也不会改变实际结果。排查应先确认目标查询有没有进入内核，再分析它选择了哪个上游。

默认解析、上游与节点域名

default-nameserver 主要用于引导解析带域名的 DNS 上游，通常选择可直接到达的 IP 地址。nameserver 是常规上游列表；proxy-server-nameserver 可用于解析代理服务器域名，防止解析代理域名时又依赖尚未建立的代理路径。不同网络可达的解析服务器不同，公共解析地址只是示例选择，使用前应验证是否允许访问以及是否能返回正确结果。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

这里的本地监听端口只提供 DNS 服务，不是 HTTP 代理入口。设置为 1053 不会自动让系统 DNS 使用它；操作系统常规 DNS 设置通常使用标准端口，需要客户端集成、转发或 TUN 劫持才能接入其他端口。先确认客户端如何接管系统查询，再考虑监听地址。不要为了让另一台设备访问而随意改成所有地址监听，DNS 服务同样需要限制访问范围。

按域名指定解析路径

nameserver-policy 适合处理内网域名、特殊服务或必须由特定解析器回答的域名。公司内网域名可能只有公司 DNS 知道，发给公共解析器会得到不存在的结果；公共服务则可能需要稳定的加密解析路径。策略匹配遵循该字段支持的域名语法，不要直接把完整 rules 条目塞进去。先为一个明确的域名后缀建立策略，验证响应后再扩大范围。

若启用 respect-rules，DNS 上游请求会按规则选择路径，配置还要准备可靠的代理服务器域名解析方式。否则可能出现循环：为了建立代理先解析服务器，为了访问解析器又要求代理已经可用。检查循环时，把代理服务器解析单独放到能够直接到达的上游，再观察 DNS 服务是否恢复。解析器列表越长并不越可靠，多条上游还会增加结果差异和排查复杂度。

缓存、IPv6 与故障定位

修改 DNS 后，浏览器、操作系统和内核都可能保留旧缓存。验证时关闭相关旧连接，按客户端支持的方式清理缓存，再发起新查询。不要根据一次旧页面刷新判断新配置无效。用系统查询工具观察到的结果，也只能说明那个工具的解析路径；浏览器启用了独立安全 DNS 时，结果可能不同。必要时暂时统一解析路径，完成测试后恢复日常设置。

IPv6 需要同时考虑 DNS 是否返回 IPv6 地址、系统是否具备可用路由、代理节点是否支持对应目的地址，以及 TUN 是否接管相关流量。只关闭一个 DNS 字段，不能保证其他应用不再发起 IPv6 请求。遇到部分网站先等待再打开，应观察连接是否先尝试不可达地址，然后才回落到另一地址族；判断清楚后再调整，不要把所有等待都归因于节点延迟。

日志出现 DNS 超时，先查上游地址的可达性和解析循环；返回地址却连接失败，再检查规则出口与目标服务。若只有内网名称异常，优先检查域名策略和内网 DNS，而不是切换整个代理组。按查询入口、上游选择、地址响应、业务连接四步检查，通常比不断更换公共解析器更有效。更详细的日志定位方法见运行日志解读。

TUN 全局接管与 Fake-IP

TUN 是流量入口，Fake-IP 是 DNS 映射方式，两者不是同一个开关。TUN 创建虚拟网络接口并调整路由，使部分不遵循系统代理的程序也能把流量交给内核；Fake-IP 给域名返回映射地址，内核接到连接后再还原对应域名。两者配合能保留域名信息，但并不意味着所有设备和应用都适合使用。浏览器已经正常走系统代理时，应按实际需求决定是否引入 TUN。

启用条件与最小接管结构

桌面平台通常需要管理员权限、服务模式或网络配置权限，移动平台则依赖系统 VPN 接口。权限不足、服务未运行或另一个 VPN 正在占用网络接口，都会影响接管。先在客户端确认服务状态，再开启 TUN，不要只把 enable 改成 true 就期待路由完成。下例是一组常见 mihomo 字段，实际是否由 YAML 管理，需要先确认客户端有没有接管同名设置。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route 负责自动设置接管路由，auto-detect-interface 用于识别出口接口；多网卡、虚拟机和企业 VPN 环境仍可能识别到不合适的接口。dns-hijack 针对能够被捕获的普通 DNS 请求，不会自动解密应用自己的 DoH。stack 的选择涉及协议栈实现，system、gvisor 或其他受支持方式的可用性取决于平台与内核构建，不应按名称直接判断谁更快。

Fake-IP 映射与兼容例外

Fake-IP 地址不是目标服务器真实地址，不适合拿来做普通公网地址连通性判断。它依赖内核保留域名与映射地址的对应关系，因此 DNS 查询和后续连接应当进入同一个处理体系。应用缓存了旧映射，而内核映射状态已经变化时，可能出现短暂访问异常。修改地址范围或切换解析模式后，要按需清理缓存并重建连接，避免把映射失配误判成规则故障。

部分局域网服务、设备发现、游戏或必须读取真实地址的应用，需要加入 fake-ip-filter。上例只是常见本地域名后缀，不能覆盖所有内网；实际例外应按出现问题的域名补充，不要直接过滤全部域名。过滤后通常返回真实解析结果，分流能否继续按域名判断，还取决于查询路径、缓存关联和嗅探能力。它是兼容调整，不是强制直连规则。

按流量、DNS、路由分层检查

开启后先看新连接有没有进入内核。完全没有连接记录，优先检查权限、路由和应用排除列表；有连接但只能看到地址，检查 DNS 是否经过预期路径；能识别域名却走错出口，再检查规则顺序和策略组。只有部分 UDP 应用异常时，还要确认节点协议与服务端是否支持对应流量，不能用网页能打开来证明所有协议都可用。

停用 TUN 后仍不能联网，先确认内核是否正常退出、系统路由是否恢复、DNS 设置是否还指向已停止的服务。优先通过客户端关闭服务和重置网络设置，不要把删除全部虚拟网卡作为第一步。涉及底层接管原理和不同协议栈的取舍，可继续阅读TUN 虚拟网卡接管详解，再按平台确定配置边界。

可靠的验收应覆盖普通网页、原先不走系统代理的目标程序、局域网服务和休眠后恢复。每项测试都使用新连接，并观察实际规则与出口。TUN 让入口更广，问题面也随之扩大；只接管确实需要的程序、保留合理例外，比把所有流量一概接入更容易维护。

域名嗅探与规则匹配修正

域名嗅探用于补充连接目标信息，不是读取全部加密内容。应用直接连接地址、DNS 查询没有经过内核或目标域名关联丢失时，规则可能只看到 IP。嗅探从协议握手或请求头中尝试提取主机名，例如 HTTP 的 Host、部分 TLS 的 SNI，以及可识别的 QUIC 握手信息。提取结果受协议实现和隐私机制影响，不能保证每条连接都能得到域名。

先确认缺少的是域名信息

只有连接记录长期显示地址、相关域名规则不命中时，才需要优先考虑嗅探。若记录已经有正确域名，问题更可能是规则顺序、组选择或目标访问能力。启用嗅探前，先确认 DNS 与入口配置合理，因为嗅探只补信息，不会替代 DNS 服务，也不会修复连接没有到达内核的问题。把它当成补充层，才能保留清晰的排查顺序。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

上述端口表示尝试解析相应协议的范围，不是监听端口，也不会把范围内所有流量转换成该协议。parse-pure-ip 允许对纯 IP 目标尝试嗅探，force-dns-mapping 涉及 DNS 映射场景下的嗅探行为。override-destination 控制是否使用嗅探得到的域名覆盖连接目标；先设为 false 有助于避免同时改变目标信息和目标连接方式，确认需求后再调整。

覆盖目标与仅补充识别的差别

覆盖目标可能让后续连接按新域名重新处理，在某些分流场景中有用，但也可能改变原来由应用选定的地址。一个域名在不同解析器下可能对应不同入口，应用选好的地址与内核重新解析的地址不一定相同。排查访问变化时，要同时观察嗅探域名、原始地址和最终出口，而不是只看规则从 IP 规则变成域名规则就认定修改正确。

当应用采用加密客户端问候等隐藏握手主机名的机制，或协议数据不符合嗅探器支持的格式时，内核可能拿不到有效域名。此时扩大全部端口范围也不一定有用，反而可能增加等待与误识别。目标本来就是字面 IP 的服务，也不一定有可供恢复的主机名。可以保留必要的 IP 规则或按应用需求调整入口，不要把每次嗅探失败都当成配置错误。

跳过例外与验证方法

内网设备、特殊 TLS 服务和对初始握手时序敏感的程序，可按实际域名建立嗅探跳过列表。先复现问题，再加入精确范围，避免为了一个例外跳过整类公共服务。例外列表只影响嗅探过程，不等于直连规则；需要直连的流量仍应在 rules 中明确安排目标。不同客户端可能没有开放所有嗅探字段，使用界面选项时以最终运行配置为准。

验证时先关闭嗅探，保存目标应用的新连接记录；再启用同一范围，重建连接并比较域名、规则和访问结果。若使用浏览器测试，要避免沿用已经建立的连接池。只有新连接得到预期域名且访问行为稳定，才适合继续扩大使用范围。必要时临时提高日志详细程度，但测试结束后恢复常规日志级别，减少输出量和个人访问记录的保存。

QUIC 识别还取决于 UDP 流量是否真的进入内核。系统代理通常不能让所有应用的 UDP 都经过代理，TUN 或应用自身支持才可能提供合适入口。若同一个站点的 TCP 连接可识别、UDP 连接没有记录，先查入口，不要反复改嗅探端口。对于仅在特定协议下异常的应用，记录连接协议比只记录域名更有帮助。

最终应保留一套即使缺少嗅探信息也有合理兜底的规则结构。域名规则负责主要分类，必要的网段规则处理明确地址范围，末尾兜底承接无法识别的连接。嗅探可以提升分类准确度，但不应成为整个配置唯一的识别来源；这样在应用更新、网络变化或协议隐私能力增强后，配置仍有可解释的行为。

本地覆写与多订阅合并

个人规则放在本地覆写，订阅原文保留给更新流程。直接修改下载后的订阅，下一次刷新可能全部丢失；把订阅内容复制成永久本地文件，又会失去正常更新。可维护的做法是分清来源层、客户端偏好层和覆写层，让代理数据随订阅变化，让端口、业务组与个人例外保持稳定。具体功能名称可能是覆写、扩展、合并或脚本，不能只按界面名称判断合并语义。

对象、列表与合并顺序

对象字段可能递归合并，也可能整体替换；列表则可能追加、前置或直接覆盖。尤其是 rules，个人例外追加到 MATCH 后面就不会生效。先用一条可识别的域名例外测试前置行为，再批量加入规则。修改 dns 时也要检查原有上游和策略是否被保留，不能只看到新增字段存在就假设旧设置仍然有效。

下面的片段演示最终希望出现的规则顺序，而不是通用的客户端覆写文件语法。先把个人例外放前面，中间保留已有业务规则，末尾只留一条兜底。若客户端要求专门的 prepend 或 append 格式，应按该客户端说明操作；不能把最终运行配置的片段当成任何客户端都支持的扩展格式。运行配置才是检验合并结果的共同入口。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

多订阅合并先解决命名冲突

不同来源经常使用相同的组名和节点名，直接拼接会让引用含义变得不确定。合并前为来源确定稳定标识，并检查重名如何处理。自动加前缀后，手写成员列表和过滤表达式也要跟着更新；只改显示名称却不改引用，会导致组成员不存在。不要把临时测试名称写成长期业务目标，最好让业务规则始终引用本地定义的稳定上层组。

使用 proxy-providers 可以将不同来源分开管理，再由组的 use 引用来源。provider 的 URL 是敏感的订阅信息，应保留在个人配置中，不出现在公开截图或求助材料里。下例采用本地代理数据来源，文件需由用户提前准备有效内容；它不是完整订阅，也没有提供任何可用节点。若来源没有代理条目，需要先处理来源，不能期待组自动生成出口。

proxy-providers:
  personal-source:
    type: file
    path: ./providers/personal.yaml

proxy-groups:
  - name: 订阅出口
    type: select
    use:
      - personal-source

远程代理来源应下载内核支持的代理集合格式，完整 GUI 配置不一定能直接作为 provider 内容。订阅转换与客户端导入流程可能会负责提取代理，但能力取决于实现。遇到来源加载成功却没有成员，检查数据结构、过滤条件与重命名规则，而不是先去改 DNS。过滤表达式过宽会纳入不希望使用的成员，过窄则会让整个来源为空。

覆写脚本的边界

脚本适合做去重、统一命名和批量插入规则，但应保留清楚的输入输出边界。先判断字段是否存在，再改数组；先判断规则是否已加入，再插入，避免每次更新都增加一份重复规则。某个来源变化时，脚本应保留可诊断的错误信息，而不是返回空配置。不同客户端的脚本接口不同，没有必要为一个静态端口设置引入复杂脚本。

做完合并，用三类情况验收：个人例外是否位于通用规则之前，业务组是否包含预期来源，订阅更新后覆写是否仍然存在。再测试一次空来源或来源下载失败的情况，确认界面不会把不可用结构当成正常配置。多订阅意味着更多独立故障点，保留一个单来源可用配置，能在出错时迅速缩小范围。

从旧客户端迁移时，先搬订阅地址和必要业务规则，再逐项恢复 DNS、TUN 与脚本。旧文件中的界面字段或扩展语法可能不被新客户端认识，不能只根据文件扩展名相同就整体替换。旧 Clash for Windows 和 ClashX Meta 属于已停止维护的归档选择，迁移思路可参考停更后配置迁移指南，平台选择则回到客户端对比。

外部控制面板与运行诊断

外部控制器提供内核管理接口，面板通过它读取状态、切换策略组和查看连接。它不是代理入口，也不是 DNS 监听。把浏览器代理指向控制器端口不会得到正常代理连接；把面板连接地址写成混合端口，也不能管理内核。先明确各端口职责，再配置面板。大多数桌面用户直接使用客户端内置面板即可，只有服务器或独立内核场景才需要额外开放管理方式。

本地监听与访问认证

常规单机配置优先监听回环地址。下例的 secret 是明确的教学假值，使用前应自行设置高强度随机值，并仅保存在个人配置中。secret 保护的是控制接口，不能拿它代替局域网代理认证。即使只在本机监听，也要考虑其他本机程序访问的风险；需要远程维护时，优先通过受控隧道进入，而不是直接公开管理端口。

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
log-level: info

客户端可能自动设置控制器地址与认证，手写字段未必会成为最终值。连接面板之前，先查看运行配置或客户端提供的管理入口信息。面板配置中的主机、端口、协议和认证必须对应同一个内核实例。电脑上同时运行多个客户端时，面板可能连到了旧实例，造成切换策略没有影响的错觉；先确认当前实例，再讨论接口是否工作。

面板文件与浏览器访问限制

external-ui 用于指定本地面板资源目录，目录中应当有完整的页面与相关静态文件。不要随意填写一个不存在的文件夹，也不要把客户端自己的安装目录当成面板目录。服务器部署时，面板资源、内核配置和缓存路径各自维护权限，升级面板后确认资源路径仍然正确。只需要内置面板的用户，通常不必自己配置这项字段。

浏览器显示连接失败，可能来自认证错误、跨域限制或混合内容拦截。HTTPS 页面访问 HTTP 控制器可能被浏览器拒绝，即使端口可达也不能正常请求。不同来源的独立面板还需要符合内核的跨域设置；不要为省事允许所有来源并暴露控制器。最容易验证的路径是客户端提供的本地入口或同源面板，先让它正常工作，再扩展远程访问方案。

用运行记录串起排查闭环

先观察连接列表：目标域名或地址、命中的规则、策略组链路与出口，是判断配置效果的关键。再按同一时间点看日志，区分 DNS 超时、拨号失败、连接被拒绝和规则不匹配。日志级别从 info 临时调到 debug 后，只复现一次目标问题，收集必要上下文就恢复。长期开详细日志会增加存储占用，也会保留更多访问元信息。

一次完整复现要记录时间、应用、目标、当前模式、入口方式和预期策略。网页打不开但连接列表完全没有记录，先查应用入口与系统代理；记录存在却域名缺失，查 DNS 和嗅探；规则正确但拨号失败，查节点与远端目标；切换后仍走旧出口，查长连接。按照这一顺序排查，才能避免在 DNS 问题上不断换节点，或在节点问题上反复改路由。

分享诊断材料时，优先截取相关连接和短时间日志，隐藏订阅地址、认证内容与个人访问记录。规则名称和组名通常可以保留，用于说明链路结构；代理服务器信息则按实际隐私要求处理。不要直接上传完整运行目录，里面可能同时包含缓存、订阅和客户端设置。最小复现材料既降低信息暴露，也能让问题更容易被准确阅读。

维护结束后回到可用基线：确认规则模式、常规日志级别、预期监听范围和备用配置都在。重新启动一次客户端，验证配置不是只在当前会话有效；再检查订阅刷新后个人规则是否保留。首次操作仍有疑问，可返回系统代理上手步骤；需要查字段含义，使用概念速查。进阶配置的目标是行为可解释、修改可验证、故障可回退，而不是增加尽可能多的开关。