Mihomo 配置参考 / 按主题查阅

Clash 进阶配置手册

策略组、规则集与 DNS；从流量接管到本地覆写。

首次使用客户端，先按快速上手教程完成安装、订阅导入与连接验证。本页用于连接成功之后的系统查阅：理解配置字段怎样协作，逐项调整规则，并为每次修改保留可回退的结果。无需从头启用全部功能，按实际问题选择章节。

需要重新选客户端时，可到下载中心查看首推的 Clash Plus 与各平台安装入口。本手册的界面操作以 Clash Verge Rev 为对象，YAML 说明以 Mihomo 配置语义为准；其他客户端是否提供相同编辑入口，应以实际界面和内核能力为准。

策略组类型与实战

策略组决定流量匹配规则之后交给哪个出口，不负责判断这条流量属于哪个网站。配置中的 proxies 定义实际节点，proxy-groups 把节点或其他策略组组织成可选择的出口，rules 再引用这些出口名称。三层名称必须准确对应；把节点名称改成相近写法，不能让已有规则自动找到新的对象。

调整之前，先在配置页确认当前启用的订阅，再打开代理页核对已经存在的策略组。服务商可能已经建立自动选择、地区分类和应用分流等多层结构。直接追加同名策略组会造成冲突，直接覆盖整个列表又可能让原有规则失去目标。先记录名称和引用关系，比先复制一整份配置更容易发现问题。

手动选择、测速选择与故障切换

select 用于手动确定出口，适合需要保持地区或固定登录环境的应用。客户端记住的选择还可能受持久化设置影响，不能只看 YAML 中列表的第一个成员。排错时应在代理页展开策略组，确认实际选中项；如果组内又引用另一个组，还需要继续展开，直到找到真正使用的节点。

url-test 根据探测结果选择出口，适合多个用途相近的节点。探测地址是否稳定、节点能否访问该地址、测速间隔是否过短，都会影响结果。一次探测较快只代表该次请求的表现，并不等于所有网站都更快；下载、视频与办公服务的路径可能不同，不宜把探测结果当作吞吐量排名。

fallback 按列表顺序优先使用可用成员，适合明确指定主备出口。load-balance 则按所选策略分配连接，不是把一个下载连接拆到多个节点叠加带宽。涉及账号地区、支付验证或源地址限制时，频繁更换出口可能带来额外验证，通常应先使用手动组或主备组确认行为。

类型主要依据适用边界
select用户明确选择需要固定出口、便于复现问题
url-test健康探测结果候选节点用途接近、允许自动调整
fallback成员顺序与可用性具有明确主备关系
load-balance连接分配策略业务允许使用多个出口

先建立能解释清楚的出口层

下面片段只演示策略组如何被规则引用，不包含代理服务器。两个内置出站可直接识别，因此无需虚构节点信息。把它并入现有配置时，应合并列表，而不是再写第二个同名顶层字段。示例默认直连；需要代理出口时，应将已导入订阅中的真实节点或已有策略组加入成员列表，再在客户端选择它。

proxy-groups:
  - name: 手动出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.org,手动出口
  - MATCH,DIRECT

实际使用自动组时，可设置 url、interval 和 tolerance。其中间隔按秒计，容差用于减少微小差异造成的反复切换。间隔越短并不必然越好，特别是在移动网络或按流量计费的环境下，多个组同时探测会产生额外请求。先保留适中的探测频率，再根据日志确认是否确有调整需要。

组与组之间可以引用，但必须避免环路。例如“办公出口”引用“自动出口”是清晰的单向结构；若后者又把前者列为成员，内核便无法建立有效依赖。多订阅合并后更容易出现这种问题，因为不同订阅常使用相同组名。建议在本地维护的组名前加稳定用途标识，避免依赖会随订阅更新变化的展示名称。

验证策略组时，先保持规则模式，访问一个能够明确匹配的域名，然后在连接页查看命中规则、策略链和实际出口。如果连接页没有记录，先排查流量是否进入内核；如果记录存在但走错组，再检查规则顺序。不要同时改模式、节点和 DNS，否则一次成功或失败都难以归因。

规则集订阅化管理

规则集把经常变动的匹配条件从主配置中拆出，主配置只保留引用和顺序。这样，网站域名列表更新时，不必反复修改策略组与端口设置。它与节点订阅不是同一对象：节点订阅提供出口，规则集提供匹配条件，最终走哪个出口仍由 RULE-SET 规则中指定的策略决定。

管理规则集之前，先把现有规则按用途分层。设备和局域网例外通常需要较高优先级；明确的站点分流随后处理；地理范围与兜底规则放在更后面。Mihomo 通常从上往下找到首条匹配规则就停止，下面更精确的规则不会自动覆盖上面的宽泛规则。维护顺序与维护域名内容同样重要。

先选行为类型，再选文件格式

behavior 表示规则内容的语义。domain 处理域名集合，ipcidr 处理地址网段，classical 可以包含带类型前缀的规则条件。format 则描述文件编码形式，例如 YAML、纯文本或受支持的二进制规则格式。把格式写对并不代表行为类型正确，两者都必须与来源内容一致。

以下示例使用本地文件，不依赖远程地址。先在客户端允许访问的配置目录中建立对应文件，再把提供者与规则引用合入主配置。相对路径以客户端实际传给内核的工作目录为依据，不是浏览器下载目录；如果日志提示文件不存在，应核对配置目录和运行环境，而不是重复修改域名内容。

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

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,手动出口

对应的 local-direct.yaml 内容如下。这里保留了规则条件，没有把出站策略写进每一行，因为出口由主配置引用统一指定。末尾的 no-resolve 表示这一条地址规则不主动触发域名解析，并不是关闭整个客户端的 DNS。上例的“手动出口”应沿用上一章建立的策略组或替换成现有组名。

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR,10.0.0.0/8,no-resolve

迁移到远程管理时，把提供者改成 type: http，填写实际可访问的 url、本地缓存 path 与以秒为单位的 interval。不要只根据文件后缀猜测内容：服务器返回登录页、访问限制提示或普通网页时，即使地址以 YAML 结尾，也无法按规则集解析。先确认响应正文，再检查配置字段。

更新失败与规则未命中分开处理

更新失败首先看下载路径是否成立。规则集更新请求本身也需要网络，不能把唯一可用的出口完全依赖于尚未下载成功的资源。已存在缓存时，客户端可能继续使用旧内容，因此“网络仍能访问”不能证明新规则已经加载。应在提供者状态和日志中核对更新是否完成，再检查缓存内容是否符合预期。

更新成功但没有命中时，先检查前面是否已有更宽的规则，例如同一后缀已经直连，或者一个较早的地址规则先命中。再检查连接对象究竟是域名还是 IP：以 IP 建立且没有域名映射的连接，未必能命中域名规则。最后确认是否测试了新连接，浏览器连接池可能让旧连接继续存在。

规则集体积增加时，不宜把所有来源都叠在一起。多个来源可能互相覆盖、更新周期不同，甚至对同一站点给出相反分类。更容易维护的方案是选定一套基础分类，再添加少量本地例外；给每个提供者记录用途、来源、行为类型和引用位置，删除时先移除引用，再移除提供者定义。

本地例外应尽量写成范围明确的规则。只为一个域名修正出口，就不要直接把整个顶级域名或大段地址都纳入同一策略。地址规则尤其需要确认是否会触发解析，避免为了匹配一个广泛网段而产生不必要的 DNS 查询。规则命中理由越具体，后续定位误分流时需要检查的范围越小。

远程规则属于配置供应链的一部分，应选择用途清楚、可以审阅内容的来源。更新之前保留上一份可用文件，更新之后选几个代表性域名检查策略链。需要进一步理解顶层字段与缩进，可参阅Clash 配置文件 YAML 逐段拆解；不要用增加重复字段的方式尝试修复合并问题。

DNS 配置优化

DNS 配置的目标，是让域名解析过程与连接出口保持一致，而不是简单增加服务器数量。一个请求可能涉及应用自己的解析、系统解析、内核 DNS 以及代理服务器域名解析。只有先判断查询发生在哪一层，才能解释为什么浏览器正常而命令行失败，或者切换出口后仍然连接到原来的地址。

客户端中的 dns.enable 开启内核 DNS 功能，但不意味着所有应用都必然使用它。系统代理一般处理支持代理设置的应用连接，不一定接管系统 DNS；TUN 的 DNS 劫持则属于另一条路径。应用自带的加密 DNS 也可能绕过普通的五十三端口查询，因此不能仅凭开关状态认定所有解析已经统一。

把引导解析、普通解析和策略解析分开

default-nameserver 用于解析 DNS 上游服务器自身的域名，通常应提供可直接访问的 IP 形式地址。nameserver 是常规上游列表。nameserver-policy 则允许按域名为特定范围指定上游。它控制解析去向，不等同于 rules 控制业务连接去向，两者需要分别检查。

下面片段演示普通解析模式和局部域名策略。监听地址限制在回环接口，高位端口便于避免与系统服务冲突。该片段不会自动修改操作系统的 DNS 设置，也不包含 TUN；可先用查询命令直接访问监听端口，确认内核响应，再考虑接入应用。合并时应替换或整合原来的 DNS 对象，不能在文件尾部追加第二份。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

示例中的域名策略只用于说明匹配写法，不代表该域名必须使用指定上游。企业内网域名应指向实际能够解析它的内部 DNS，而不是直接照抄公共服务器。使用内部服务器时，还应确认请求经过的网络接口和路由；在公司网络之外，内网 DNS 可能根本无法访问，长期硬编码就会变成间歇性故障。

启用基于规则的 DNS 出站控制时，应额外检查 respect-rules 与 proxy-server-nameserver 的配合。代理服务器地址如果本身是域名，内核必须先解析它才能连接代理，不能又要求这个解析只能经过尚未建立的代理。为代理服务器域名保留独立、可达的解析路径，可以避免这种启动依赖环。

回退机制不是双份服务器保险

fallback 与 fallback-filter 需要成套理解。后者决定哪些结果采用回退解析，并不是简单在主服务器超时后依次尝试所有备用地址。只增加回退服务器而不检查过滤条件，可能让同一域名产生与预期不同的地址选择。优先用较小配置确认基本解析，再按具体污染或地域问题增加分流条件。

开启加密 DNS 能保护到上游之间的查询传输，但不能自动保证解析结果适合当前出口。远程上游可能给出另一地区的内容分发地址，导致访问路径绕行。遇到某个网站加载变慢时，应比较解析结果、实际连接地址和出口路径，不宜把所有性能差异都归结为节点问题，也不必为每个域名建立单独策略。

IPv6 应按整条链路判断。系统获得 IPv6 地址，不代表代理节点、TUN 路由和目标站点的 IPv6 路径都正常。关闭 DNS 的 IPv6 响应可以缩小排错范围，但不能替代系统路由检查；应用如果使用自己缓存的地址，修改后仍可能继续连接。先结束相关应用连接，再重新查询与测试，结果才具有可比性。

在提供 dig 的系统上，可用下列命令检查示例监听端口。关注响应是否返回、耗时是否异常以及地址类型是否符合当前模式。查询成功只能说明这次直接访问内核 DNS 成功，仍需从实际应用发起连接，确认它没有使用另一套解析。相关查询工具没有安装时，不必为测试修改整个系统的 DNS。

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

缓存排查应分层进行：浏览器、操作系统和内核都可能保存解析结果。修改策略后先创建新连接，必要时再清理对应层缓存，而不是每次都重启电脑。若日志连续出现解析失败，记录失败域名与使用的上游；若只是单个站点异常，优先检查域名策略和应用自身设置。报错阅读方法见日志含义与定位思路。

TUN 与 Fake-IP

TUN 通过虚拟网络接口接收流量，适合不读取系统代理设置的应用。Fake-IP 则是 DNS 的一种工作方式：内核返回用于内部映射的地址，并在后续连接中恢复域名信息。两者经常一起使用，但不是同一个功能，也不要求在所有环境下同时开启。先明确缺少的是流量接管还是域名关联，再决定改哪一层。

系统代理已经满足使用需求时，可以先保持 TUN 关闭。需要接管命令行工具、游戏或其他直连应用时，再启用 TUN 并核对系统权限。Clash Verge Rev 的服务模式、操作系统授权和其他网络软件都可能影响虚拟接口建立；界面开关显示开启，并不能代替检查接口、路由和连接记录。

先建立接管路径，再调整 DNS 模式

下面片段展示 TUN 自动路由与 Fake-IP 的常见组合。它依赖客户端具备创建虚拟接口和设置路由的权限，应通过客户端提供的设置入口确认权限状态。不同平台对协议栈和接口的支持存在差异，不能把其他平台上的某个值直接视为性能最优选项；出现兼容问题时先恢复原来的协议栈。

tun:
  enable: true
  stack: mixed
  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"
  nameserver:
    - https://dns.alidns.com/dns-query

auto-route 负责添加相关路由，auto-detect-interface 用于识别出站接口。它们不能保证在多网卡、虚拟机桥接、企业 VPN 同时存在时自动选对路径。切换无线网络、接入有线网络或启动另一套隧道后，如果流量突然中断，应先检查出口接口和路由变化，不要立即重建订阅。

dns-hijack 中的普通 DNS 劫持不等于拦截所有形式的域名解析。应用自带的 HTTPS DNS 请求是加密业务流量，通常不能按普通 DNS 包处理。某些系统的本地 DNS 服务也有独立转发路径。验证时应同时看查询结果和连接页域名，而不是因为写了五十三端口规则就推断全部应用已经受控。

Fake-IP 地址是映射，不是远端服务器

在 Fake-IP 模式下，看到保留范围内的地址是预期现象，不能直接把该地址当作目标站点故障。真正访问时，连接必须回到维护这份映射的内核。如果应用拿到了映射地址，却绕过内核直接连接，通常就会失败。因此，DNS 接管和流量路由需要配套，单独把系统 DNS 指向内核并不一定完整。

fake-ip-filter 用于让特定域名返回真实解析结果，常见对象包括局域网设备名称和确有兼容问题的应用域名。列表不是越大越稳：排除过多域名会减少可用的域名映射信息，也可能改变后续规则匹配路径。应先确认具体失败对象，再添加最小范围例外，避免一开始就排除整个公共域名空间。

本地域名后缀例外不能替代发现协议支持。打印机、投屏与文件共享可能还依赖组播、广播或操作系统服务，解析成功不代表设备发现一定正常。排查时分别验证设备 IP 是否可达、名称是否能解析、服务端口是否开放，再判断是否需要路由排除。不要为修复一台设备而把所有私网业务都强制代理。

环境先检查再确认
Windows服务状态与虚拟接口权限其他 VPN、系统防火墙与路由冲突
macOS客户端授权与网络接口系统代理、路由及其他网络扩展
LinuxTUN 设备与路由管理权限网络管理服务、防火墙与策略路由

与企业 VPN 共存时，应先保留企业网络的必要路由。若两套软件都试图接管默认路由，可能出现流量反复进入隧道或内部服务不可达。记录启用前后的路由表，分别测试公网、内网地址和代理服务器地址，再决定是否做接口排除或网段例外；具体字段需要按当前内核能力和系统路由设计选择。

停用 Fake-IP 或切换配置后，应用可能仍缓存旧映射地址，而新内核没有相应记录。此时应先结束应用连接并重新解析，必要时清理缓存，不要把所有失败都归因于节点掉线。开启映射持久化有助于某些重启场景保持一致，但不能修复被其他 DNS 服务接管或流量绕过内核的问题。

验证顺序建议固定为：先确认普通代理连接可用，再启用 TUN 检查原本不走代理的应用，最后切换 Fake-IP 观察域名匹配。每一步都保留可用配置。若刚启用 TUN 就整体断网，优先停用并恢复网络，再查权限与路由；反复更换节点通常不能解决虚拟接口未建立的问题。

域名嗅探

域名嗅探用于从连接初始阶段可见的协议信息中补充域名，例如 HTTP 请求中的 Host、TLS 握手中的服务器名称。它可以改善只有目标 IP 时的域名规则匹配，但不能保证恢复所有连接的域名，也不是解密 HTTPS 内容。应用使用何种协议、是否隐藏握手名称以及流量有没有进入内核，都会影响结果。

启用之前先确认是否真的缺少域名。如果 Fake-IP 映射已经提供正确域名，嗅探未必带来额外收益；如果连接根本没有进入内核，嗅探开关也无法补救。适合排查的典型情况是：连接页能看到目标 IP 和端口，但域名为空，导致原本针对站点后缀的规则没有命中。

从有限协议与端口开始

下面片段仅在常见 Web 端口尝试 HTTP、TLS 和 QUIC 嗅探，并允许处理没有已有域名信息的连接。它不负责启动 TUN，不会替代 DNS 设置，也不会自动改变所有应用的代理行为。合并后需要重新建立连接；已经完成握手的长连接通常不会因为开启嗅探而重新提供初始协议信息。

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

parse-pure-ip 表示尝试处理原本仅有 IP 信息的连接，并不意味着任意二进制协议都可以识别。端口范围也只是尝试识别的入口，不代表这个端口上一定运行对应协议。把所有端口加入所有协议，通常只会扩大处理范围，不能解决握手内容本来就没有可读域名的问题。

override-destination 涉及是否用嗅探得到的目标信息覆盖原连接目标。它与“能否取得域名”不是同一件事。某些应用对实际连接地址有明确要求，覆盖目标后可能改变服务选择或与应用缓存不一致。示例对 HTTP 显式关闭覆盖，是为了先观察域名识别，再按兼容情况判断是否需要调整。

识别结果要和原始目标交叉核对

CDN、多域名共用地址和应用内置地址列表，都可能使 IP 与域名的对应关系不唯一。一个 IP 可以服务多个网站，不能仅根据反向解析或地址归属就确定当前业务域名。嗅探获得的协议名称比按地址猜测更具体，但仍应结合应用实际访问行为判断，尤其是存在重定向与多个后台请求的场景。

测试时先选一个能稳定复现的请求，结束相关连接后重新访问，并在连接页查看目标域名、命中规则和出站链。若域名出现但规则仍未命中，检查规则顺序与匹配类型；若规则正确而服务失败，则继续核对出口、DNS 地址与目标覆盖行为。不要把嗅探成功当作整条连接已经正常的证明。

日志级别可暂时提高到足以观察连接过程的程度，记录一次完整复现后恢复常用级别。详细日志可能包含访问域名和连接元信息，不宜长期保存后直接公开。向他人提供排错材料时，应去掉订阅地址、账号内容和控制接口凭据，只保留与故障相关的几行及必要的配置结构。

QUIC 使用 UDP，HTTP/3 流量是否能够正常工作还取决于代理节点和网络路径对 UDP 的支持。连接失败时先判断是协议传输失败还是域名识别失败。仅关闭 QUIC 嗅探不会强制应用切换到 TCP；应用是否回退取决于自身实现，不能把这个开关当作通用的协议转换功能。

部分 TLS 连接可能使用加密的握手名称机制，或者通过另一层隧道传输。此时可观察信息减少，嗅探无法凭空恢复原始域名。更稳妥的方向是让应用使用可控的 DNS 路径、保留 Fake-IP 映射，或者在明确理解范围后使用地址与进程条件补充规则，而不是无限扩大嗅探端口列表。

遇到单个应用兼容问题，可考虑按当前内核支持的字段设置 skip-domain 等例外，先排除具体域名再测试。例外条件必须与实际识别到的对象一致：日志只有 IP 时，写一个从未出现过的域名未必有效。若关闭嗅探后恢复，应逐项比较协议范围与目标覆盖，而不是删除整套规则。

企业内部应用、固定 IP 服务和设备管理页面尤其需要谨慎。它们可能发送与实际地址用途不同的主机名，或依赖网关特定映射。先保留局域网直连规则，避免嗅探结果把内部请求送入公网出口。需要理解连接、规则与日志页面各自作用，可结合客户端界面功能速览逐项核对。

本地覆写与多订阅合并

订阅内容通常由远端维护，本地偏好则需要在更新之后继续保留。直接编辑远程订阅下载下来的 YAML，短期可以生效，但下次更新可能覆盖修改。本地覆写的作用是把稳定的个人设置与定期更新的远程内容分离；关键不是编辑入口叫什么，而是确认它在哪个阶段执行、对哪些字段执行以及最后生成了什么。

在 Clash Verge Rev 中，应通过配置页提供的扩展、合并或脚本入口管理本地调整，具体名称以实际界面为准。某些设置也由客户端全局设置写入内核运行配置，因此订阅文件里的值未必是最终值。先检查客户端设置，再查看运行配置和日志，比在原始文件中反复添加相同字段更有效。

对象合并与列表替换要分别验证

不同合并机制对对象和数组的处理可能不同。对象可能按键合并，而 rules、proxy-groups 这样的列表可能整体替换、前置追加或后置追加。不能因为 DNS 的一个字段保留成功，就推断规则列表也会按相同方式保留。应先用一条容易识别的本地规则测试实际行为，再扩大修改范围。

下面片段表达“保存策略组选择”的配置意图，本身不是通用合并指令。把它放进客户端认可的合并入口后，还需要确认运行配置保留了原订阅的其他必要字段。如果某个脚本会重建整个 profile 对象，执行顺序靠后的结果仍可能覆盖前面的设置，因此要核对最终输出而不是只看编辑器保存成功。

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

添加本地规则时，最需要关注插入位置。用于修正特定站点的规则应放在较早位置；如果追加到已经存在的 MATCH 后面，通常永远不会执行。保留一个明确的兜底规则就足够，不需要为每个订阅各追加一条。合并后的列表应能逐行说明用途，重复规则过多会让排错变得困难。

两个订阅不等于两份完整配置直接拼接

完整配置常同时包含端口、DNS、策略组与规则，不能将两份文件首尾连接。YAML 顶层键重复可能被解析器拒绝，也可能出现后值覆盖前值，结果取决于工具行为。若只需要组合节点，应优先考虑把订阅作为代理提供者，再由本地统一维护策略组和规则，避免多个远程来源争夺同一组基础设置。

以下示例使用两个本地代理提供者，便于先验证结构。两个文件必须由用户准备，每个文件包含合法的 proxies 列表；它们不是任意 Base64 节点字符串。此片段也不包含虚构服务器，只有提供者引用与一个保底直连成员。初次测试应先确认两个文件分别可用，再启用统一的选择组。

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 订阅汇总
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

代理提供者文件可以保留本来可用的节点定义，但应删除与提供者格式无关的整套规则和全局设置。切换到远程提供者后，再补充实际订阅地址、缓存路径和更新间隔。格式不兼容时，应使用可信的本地处理方式或服务方提供的兼容入口，具体差异见订阅导入方式与格式说明。

多来源的另一个问题是节点名称重复。即使提供者名称不同，展示到同一策略组里的节点仍可能难以区分，脚本按名称筛选时也容易匹配错误。优先采用来源前缀或当前内核支持的名称处理能力，保持命名稳定；不要把地区旗帜、临时活动名称或流量提示当作长期引用的唯一依据。

筛选表达式也要有回退方案。按地区关键词筛选时，服务方改名可能让组内突然没有节点。应检查空组是否被客户端明确报告，并保留可操作的选择路径。使用正则表达式前，先在少量节点上核对匹配结果；不要把未经验证的复杂表达式同时应用到全部策略组，再通过猜测寻找缺失成员。

脚本适合处理确定、可重复的转换，例如统一命名或插入少量规则，不适合隐藏大量无记录的配置变化。执行脚本前保留输入，执行后检查输出；错误时应能明确回退到原始订阅。若脚本来自他人，应审阅是否访问外部地址、读取本地信息或改变控制接口，不能只凭“能联网”判断它适合长期使用。

外部控制面板

外部控制接口用于查询内核状态、查看连接和调整策略选择，控制面板则是调用这个接口的前端界面。它与浏览器使用的 HTTP 代理端口不是同一个入口。混合端口处理代理业务，控制端口处理管理请求；把面板连接地址填成混合端口，通常只会得到连接错误，而不是打开客户端的代理页面。

Clash Verge Rev 已提供常用的代理、连接与日志界面，本机日常操作通常直接使用客户端即可。只有在需要独立面板、远程设备管理或自动化查询时，再配置外部控制。控制能力可能影响当前所有连接与出口选择，因此首先考虑监听范围和访问来源，而不是先把端口开放到局域网。

本机使用从回环监听开始

下面示例只监听回环地址，并引用已经放在本地的面板静态文件目录。目录应由用户准备，路径以实际内核工作目录为准。示例中的口令是明确的教学假值，实际使用前应替换成自行生成的长随机值；不要把实际口令写进公开配置、截图、分享链接或版本管理仓库。

external-controller: 127.0.0.1:9090
secret: "example-only-change-before-use"
external-ui: ./ui

控制端口与混合端口需要分别排查占用。设置保存后，如果日志提示监听失败，先查看是否已有另一个客户端或内核进程占用该端口；不要为了绕过占用直接改成所有接口监听。端口修改后还要同步面板连接设置，处理方法可参照混合端口占用定位文章，但应把查询端口换成当前控制端口。

面板需要知道接口地址和认证信息，但它本身不一定与内核运行在同一台设备。面板页面中的 127.0.0.1 指向浏览器所在设备：在手机浏览器打开面板时，它不是桌面电脑的回环地址。这个差异是远程连接失败的常见原因，不能只靠在桌面配置里打开“允许局域网连接”解决。

跨设备连接要检查边界而非只改地址

确需跨设备管理时，应使用受信任网络、明确的防火墙规则和经过认证的访问路径。把监听改成 0.0.0.0 只表示接受来自多个接口的连接，不会自动建立安全边界。设备若同时连有公网接口、虚拟网络或访客无线网络，开放范围可能比预想更大，配置前应逐一确认。

通过浏览器访问接口，还可能受到同源策略、跨域配置和混合内容限制。HTTPS 面板请求普通 HTTP 接口时，浏览器可能阻止请求，这不代表内核没有启动。应先在本机确认接口可以响应，再检查开发者工具中的具体错误；不要用允许任意来源的宽泛跨域设置掩盖地址或协议配置问题。

本地面板资源应来自可审阅、与接口兼容的项目，并按该项目说明部署。目录存在不等于资源完整，资源能打开也不等于管理接口已经认证成功。排错时把“静态页面加载”“接口可达”“认证通过”“操作成功”分成四步，每一步都获得明确结果后再进入下一步，避免把白屏与认证失败混为一谈。

自动化查询同样应遵循最小暴露原则。脚本只需要本机访问时，不必为了方便把控制接口发布到外网。认证信息应由运行环境安全提供，不要硬编码到网页脚本；浏览器可下载的任何 JavaScript 都能被访客读取，不能用代码压缩或改文件名来保存口令。排错材料中也应清理请求头与连接配置。

修改后按固定顺序验收

第一步检查运行配置是否包含预期监听地址，日志是否报告端口占用或配置解析错误。第二步从同一台设备验证接口可达与认证结果。第三步再加载面板，确认它连接的是当前正在使用的内核，而不是后台残留的另一进程。最后修改一个容易恢复的策略选择，观察客户端界面是否同步更新。

若接口可访问但面板中的代理组为空，先确认当前配置确实加载了策略组，再检查面板与接口兼容性。若能查看状态却无法切换，检查操作对应的组是否允许手动选择，以及认证和请求错误。不要用重装客户端替代这些层次检查；重新安装不会自动修复错误的目标地址或后台重复进程。

收尾时恢复常用日志级别，关闭临时开放的监听，删除不再需要的本地面板目录或自动化任务，并保留一份可用的配置备份。备份应区分公开结构与私人订阅信息，分享时只提供必要片段。未来更新客户端或内核之后，按同样顺序复测关键功能，才能判断变化来自配置、面板还是运行环境。