Clash Meta 进阶配置手册

01

策略组类型与实战

策略组是配置中的决策层。代理节点解决“怎样建立连接”，策略组则解决“这一类流量应该交给谁”。一份容易维护的配置通常不会让规则直接指向具体节点，而是先建立“日常选择”“自动测速”“故障转移”“下载分流”等稳定名称，再由规则引用这些名称。这样更换订阅或节点名称后，规则层不需要跟着重写。策略组名称可以使用中文，但名称必须在 proxy-groups、rules 和其他组的 proxies 中完全一致，空格、大小写和符号都不能省略。

select、url-test、fallback 与 load-balance

select 是手动选择组，适合需要明确指定出口的场景。它本身不判断节点质量，只保存当前选择。把自动组、故障转移组和少量常用节点放进一个 select 组，可在稳定性与人工控制之间切换。url-test 会按设定间隔访问测试地址，在可用节点中选择测得延迟较低的一项；它适合网页浏览、接口请求等重视响应速度的短连接。测速结果只表示从当前设备到测试目标的表现，不等于所有网站和流媒体都具有同样速度。

fallback 按列表顺序检查可用性，优先使用靠前节点，当前节点不可用时才切到下一项。它适合固定主线路、备用线路的结构，也适合登录状态或出口地区不宜频繁变化的业务。load-balance 会把不同连接分配给多个节点，可用于并发下载或多目标访问，但同一个网站的多个连接若从不同出口发出，可能触发登录验证。因此负载均衡不应直接替代日常默认组，应当由单独规则精确引用。

一套可维护的分层结构

下面的结构把节点来源交给代理提供者，把自动选择和故障转移做成底层组，再由“默认代理”统一暴露给规则。include-all: true 会把可用代理提供者中的节点纳入组内；如果客户端或现有配置不采用代理提供者，也可以改为显式列出 proxies。interval 是健康检查或测速间隔，单位为秒；tolerance 表示新结果比当前节点好到什么程度才切换，设置适当容差可以避免两个延迟接近的节点频繁来回跳动。

proxy-groups:
  - name: 默认代理
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

  - name: 自动选择
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 故障转移
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300

测试地址应返回体积很小、状态稳定的响应。若目标在当前网络中被重定向、被缓存或无法访问，组内节点可能全部显示失败。此时先在日志中确认是 DNS 解析失败、连接超时还是 TLS 错误，再考虑替换测试地址。不要为了得到更小的数字而把测速间隔设得很短；频繁测试会增加连接数和电量消耗，也可能使移动网络不断唤醒。

按用途拆组，而不是按节点堆组

长期配置更适合按用途命名，例如“流媒体”“开发服务”“大文件下载”，而不是把所有地区和所有节点都铺成几十个入口。用途组可以引用地区组，地区组再引用自动测速组，形成清晰的两到三层关系。层级过深会让排错困难，也可能形成循环引用；若 A 组包含 B、B 又包含 A，配置检查会失败。修改后应先使用客户端的配置检查功能或 mihomo 的测试启动方式确认语法，再观察日志中规则最终命中的策略组。关于三种自动组的判断差异和搭配案例，可继续阅读策略组类型选择指南。

02

规则集订阅化管理

规则决定请求进入直连、代理、拒绝或某个用途策略组。把几千条域名和 IP 直接写在主配置中虽然能运行，但更新、审阅和定位都会变得困难。rule-providers 将规则内容拆成独立文件，由主配置声明来源、行为类型、保存路径和刷新间隔，实际规则只需使用 RULE-SET 引用。这样可以单独更新媒体规则、内网规则或开发服务规则，也能在规则源暂时不可用时继续使用本地缓存。

behavior 与 format 必须匹配内容

behavior 描述规则集保存的内容形态。domain 面向域名条目，适合完整域名、域名后缀和关键字类集合；ipcidr 面向 IPv4、IPv6 网段；classical 保存带类型前缀的完整规则，例如 DOMAIN-SUFFIX,example.org 或 IP-CIDR,192.0.2.0/24。三者不能仅靠改字段名称互相转换，远端文件的实际结构必须与声明一致。format 常见值为 yaml、text 或 mrs，使用何种格式取决于规则源提供的文件，不能把普通文本链接声明成二进制规则格式。

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

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

rules:
  - RULE-SET,private-domains,DIRECT
  - RULE-SET,private-networks,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,默认代理

示例域名用于说明结构，实际使用时应替换为可信规则源提供的完整文件地址。path 是内核工作目录下的缓存位置，不同客户端对工作目录的选择不同；手动运行 mihomo 时应确保进程对该目录有写入权限。规则文件首次下载失败且本地没有缓存时，对应提供者不能参与匹配。若以前下载成功，内核通常可以继续读取缓存，但不会得到远端新增内容。

规则从上到下匹配

rules 的顺序具有决定性：请求命中第一条适用规则后就停止继续匹配。因此范围小、意图明确的规则应放在前面，宽泛规则放在后面，MATCH 只能作为最后兜底。例如公司内部域名需要直连，就应置于通用代理域名集合之前；局域网网段也应在宽泛 IP 规则之前处理。若把大范围代理集合放在最前面，后面的直连例外即使语法正确也永远不会触发。

no-resolve 用于 IP 类规则，表示匹配阶段不要为了获得目标 IP 而主动发起额外 DNS 解析。它能减少无意义查询，也可以避免在域名尚未解析时改变匹配路径。但并非每条规则都应机械添加；域名规则本身依赖域名，进程只提供 IP 且没有嗅探结果时，也需要后续 IP 规则承担判断。分析规则问题时，应同时查看日志里的目标主机、规则类型和最终策略，而不是只看策略组名称。

更新失败与回滚处理

规则集更新失败通常来自四类原因：远端地址失效、DNS 无法解析、下载过程必须经过代理但当前策略未就绪、缓存目录不可写。先查看日志中的 HTTP 状态或网络错误，再用浏览器或命令行从同一设备访问规则地址。若只有内核无法访问，应检查规则提供者是否需要通过代理下载，以及启动早期 DNS 是否能够解析规则源域名。目录权限问题则会出现创建文件、重命名临时文件或写入失败的提示。

远端规则并不意味着每次启动都必须在线获取。适合生产环境的做法是保留最近一次可工作的缓存，更新前检查文件格式，并控制变更范围。一次同时替换所有规则源、DNS 配置和策略组，出错后很难判断是哪一层造成。更稳妥的顺序是先新增提供者但不引用，确认下载成功；再添加一条 RULE-SET 并观察命中；最后删除旧规则。需要回退时恢复主配置引用即可，缓存文件可以留待核对。

规则数量不是配置质量

更多规则并不自动带来更准确的分流。重复集合会增加加载时间，也可能出现同一域名在不同集合中给出冲突结论。应先按需求确定少量用途组，再选择覆盖这些用途的规则集。遇到“某网站走错组”，先在日志中找到实际命中的第一条规则，再调整顺序或增加精确例外；直接更换整套规则往往会引入新的未知变化。GeoIP 或规则提供者更新异常的进一步检查，可以到常见问题查看对应故障分支。

03

DNS 配置优化

DNS 层负责把域名转换为地址，也直接影响规则能否看到正确目标。常见的“节点可用但网页打不开”“同一域名偶尔直连、偶尔代理”“日志只显示 IP 无法判断域名”等问题，往往不是节点速度，而是 DNS 请求走向、缓存结果和流量接管方式没有对齐。配置 DNS 时需要先回答三个问题：查询由谁接管、发往哪些解析器、解析器自身的域名又怎样解析。三层关系清楚后，再决定是否启用 Fake-IP。

nameserver、default-nameserver 与代理专用解析

nameserver 是普通域名查询的主要解析器，可以填写传统 UDP/TCP DNS，也可以使用 DoH 等加密形式。default-nameserver 主要用于解析 DoH 服务器域名、代理服务器域名等启动阶段依赖项，适合填写可直接访问的 IP 形式解析器，避免“先解析 DNS 服务域名才能使用该 DNS 服务”的循环。proxy-server-nameserver 可专门处理代理节点服务器域名，使节点地址解析与普通业务域名分开，减少业务规则反过来影响代理连接的可能。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  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

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

示例展示字段关系，不代表所有网络都适合同一组解析器。选择 DNS 服务时应考虑当前网络的可达性、返回结果和隐私要求。若某个 DoH 服务需要通过代理才能访问，启动阶段又把它作为唯一解析入口，可能形成代理尚未建立、DNS 已经等待代理的依赖环。保留能够直接访问的基础解析路径，并让代理服务器域名单独解析，通常更稳定。

nameserver-policy 的匹配用途

nameserver-policy 可以按域名、规则集合或 geosite 分类指定解析器。例如本地域名交给距离较近的解析器，其他域名交给另一组解析器。它解决的是“查询发给谁”，不是“最终流量走哪个代理组”；连接策略仍由 rules 决定。DNS 政策与路由规则可以采用相似分类，但两者不必完全相同。若把大量互相重叠的域名集合同时写入策略，排查时会难以确定具体使用了哪个解析器，因此仍应坚持从精确到宽泛的顺序。

respect-rules: true 表示 DNS 连接本身遵循路由规则。启用后应确保 DNS 服务器域名和地址拥有可完成启动的路径，否则解析器请求可能被发送到尚未可用的策略组。修改此项后出现全部域名解析失败，应先暂时使用可直接访问的解析器验证，再检查 DNS 服务域名命中了什么规则。

IPv6、缓存与结果差异

ipv6: false 通常表示 DNS 模块不返回 AAAA 结果，适合设备或出口没有稳定 IPv6 连通性的情况。如果本地网络和代理节点都具备可用 IPv6，则可以开启，但需要同时检查 TUN、系统路由和规则对 IPv6 网段的处理。只在 DNS 中开启 IPv6，而 TUN 或出口不支持，可能表现为应用优先尝试 IPv6 后长时间等待，再回退到 IPv4。

更改 DNS 后，旧结果可能仍存在于操作系统、浏览器、客户端和内核缓存中。排查时先重启相关客户端或清理系统 DNS 缓存，再进行同一域名的重复测试。浏览器还可能启用独立的安全 DNS，它会绕开系统解析路径；如果系统工具解析正常而只有浏览器异常，应检查浏览器自身设置。反过来，浏览器正常、终端异常，则更可能是系统 DNS、环境变量或终端程序没有经过预期的流量入口。

04

TUN 与 Fake-IP

系统代理依赖应用主动读取代理设置，浏览器通常支持良好，但部分终端程序、游戏、系统服务和使用自定义网络栈的应用可能完全忽略。TUN 模式通过虚拟网卡和系统路由接管更广范围的 TCP、UDP 流量，再交给 mihomo 处理。Fake-IP 则在 DNS 阶段给域名分配保留地址，应用连接该地址时，内核根据映射还原原域名，从而让域名规则在更多场景下生效。两者经常配合，但职责不同：TUN 管接管，Fake-IP 管域名映射。

TUN 基础配置与平台权限

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

stack 决定 TUN 数据包由哪种网络栈处理，mixed 是常见的兼容选择；具体可用值和效果取决于内核能力与平台实现。auto-route 自动添加必要路由，auto-detect-interface 根据默认出口识别物理网卡，网络在有线、无线、热点或 VPN 之间切换时尤其有用。dns-hijack 将符合条件的 DNS 请求交给内核 DNS 模块，避免系统继续向原解析器发送查询。strict-route 会更严格地限制绕过路径，能减少泄漏与路由偏差，但也更容易暴露虚拟机、局域网共享或其他 VPN 的路由冲突。

创建虚拟网卡和修改路由通常需要管理员权限。Windows 客户端可能通过服务模式完成权限操作；macOS 会请求网络扩展或系统权限；Linux 直接运行内核时需要相应网络能力，并注意 systemd 服务的权限设置。开启后若整个设备断网，第一步不是更换节点，而是关闭 TUN 确认系统基础网络能否恢复，再查看虚拟网卡是否创建成功、默认路由是否被错误覆盖。

Fake-IP 的工作路径

在 enhanced-mode: fake-ip 下，DNS 模块为域名返回 fake-ip-range 中的地址。应用随后连接这个地址，内核从映射表取得原始域名，再根据域名规则选择策略并解析真实目标。198.18.0.0/15 属于基准测试用途的保留地址范围，常用于此类映射；不要把 Fake-IP 地址误认为远端服务器真实地址。抓包或日志中看到该网段并不表示 DNS 被劫持到陌生主机，而是映射链路正在工作。

Fake-IP 的优势是域名信息保留较完整，规则判断更直接，也减少应用提前拿到真实 IP 后绕过域名规则的情况。代价是少数应用会校验 DNS 返回、依赖局域网发现、使用特殊 UDP 协议，或者把解析结果传给不经过同一内核的进程，这些场景可能不适合映射。此时应通过 fake-ip-filter 为特定域名返回真实地址，而不是完全关闭 Fake-IP。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - geosite:private

blacklist 模式表示列表内域名不使用 Fake-IP，其余域名继续映射。过滤范围应尽量精确。直接加入过宽的通配符会让大量请求回到真实 IP 模式，削弱域名规则效果。局域网设备发现异常时，可以先针对设备使用的 .local、私有域名或厂商服务增加例外，再观察日志，不应一次性排除整个常见顶级域名。

与其他 VPN、虚拟机和局域网的冲突

TUN 与企业 VPN、游戏加速工具、虚拟机网卡、容器网络同时运行时，冲突通常发生在路由优先级、DNS 接管或相同保留网段。先记录不开 TUN 时的默认路由和 DNS，再逐个启用网络组件，能够找出是哪一步改变了出口。公司 VPN 只允许特定网段通过时，应为这些网段保留正确路由，并将内部域名交给企业 DNS；否则即使代理节点可用，内部服务仍可能因为解析和路由分离而无法连接。

局域网访问失败时，检查私有网段是否被规则设为 DIRECT，TUN 是否保留局域网路由，以及系统防火墙是否允许虚拟网卡访问。路由器或旁路网关部署还要避免客户端流量回到自身形成环路。Linux 可通过 ip route 和 ip rule 查看路由与策略规则，Windows 可使用 route print，macOS 可使用 netstat -rn；执行命令只用于观察时无需修改系统配置。

# Linux：查看路由与策略规则
ip route
ip rule

# Windows：查看 IPv4 与 IPv6 路由
route print

# macOS：查看当前路由表
netstat -rn

如果只需要浏览器和常见桌面程序走代理，系统代理的结构更简单，也更容易定位；只有确实存在不读取系统代理的应用时，再启用 TUN。两种机制的生效范围、权限和性能差异，可参阅TUN 模式与系统代理对比。

05

域名嗅探

并非所有连接在进入内核时都携带域名。应用可能先自行解析 DNS，再直接连接目标 IP；透明代理或网关部署也经常只能看到地址。域名嗅探会读取连接早期的协议特征，从 HTTP Host、TLS SNI 或 QUIC 握手信息中提取域名，再把它用于规则匹配。它不能解密业务内容，也不是对任意协议都有效；它只利用握手阶段原本可见的目标标识，补足路由判断所需的信息。

按协议和端口限制范围

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.org"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip 允许对原始目标为 IP 的连接尝试嗅探，适合透明接管场景。force-dns-mapping 会结合 DNS 映射寻找域名信息，常与 Fake-IP 配合。不同协议可以分别限定端口，避免在明显不是 HTTP、TLS 或 QUIC 的连接上做多余判断。端口范围应根据实际应用调整；把所有端口都交给所有嗅探器并不会提高准确率，反而可能增加误判和排错成本。

override-destination 表示使用嗅探得到的目标覆盖原始目标信息。开启后域名规则更容易命中，但错误嗅探也会直接影响连接去向，因此通常只在明确协议上启用。force-domain 可要求特定域名采用嗅探结果，skip-domain 则用于已知不兼容的服务。域名匹配写法需要遵循内核支持的通配规则，修改后应在日志中确认提取到的域名与实际请求一致。

嗅探、DNS 与规则的先后关系

一次连接可能包含三类目标信息：应用提交的域名、DNS 映射保存的域名、嗅探得到的域名。若应用通过普通代理协议提交域名，通常不需要额外嗅探；若应用只连接 IP，内核才需要从映射或握手中恢复域名。规则引擎最终使用何种信息取决于接管方式和配置。排查时可观察日志中目标是否从 IP 变为域名、命中了哪条规则，以及最终连接的真实地址。

嗅探不能替代 DNS。它发生在连接已经开始之后，节点服务器域名、规则提供者地址和某些不带可识别握手的协议仍然依赖正常解析。它也不能替代规则设计：提取出域名后，仍需要相应的 DOMAIN、DOMAIN-SUFFIX 或规则集把连接送到正确策略组。若日志中已经显示正确域名但仍走错组，应回到规则顺序排查，而不是继续扩大嗅探端口。

常见误判与例外处理

某些应用会在非标准端口上使用自定义协议，数据开头可能恰好类似 HTTP 或 TLS；也有服务使用共享地址和前置域名，握手域名不等于用户界面中的业务域名。出现开启嗅探后连接失败、关闭后恢复的情况，应先记录目标 IP、端口、嗅探出的域名和命中规则。确认是单个服务后，将其加入跳过列表，通常比关闭全部嗅探更合适。

QUIC 基于 UDP，受网络、防火墙和代理节点 UDP 能力影响较大。浏览器访问同一网站时可能在 QUIC 与 TCP/TLS 之间切换，因此问题会表现为偶发。可以在日志中对比两种连接的目标和策略；若节点不支持 UDP，应调整策略或让应用回退，而不是把所有 UDP 都归因于 DNS。移动设备休眠恢复、网络从 Wi-Fi 切到蜂窝数据后，也可能保留旧连接，需要重新建立连接才能观察新配置。

用日志建立可复现样本

调整嗅探配置时，每次只改变一个字段，并固定测试同一应用、同一域名和同一网络。记录关闭与开启时的目标表示、规则命中和错误类型。若错误是 timeout，需要继续区分目标不可达、策略节点不可达还是 UDP 不可用；若错误是证书域名不匹配，则应重点检查覆盖后的目标是否正确。日志字段和常见连接错误的阅读方法，可参考Clash 运行日志定位指南。

06

本地覆写与多订阅合并

订阅通常负责提供节点、基础策略组和部分规则，但用户自己的局域网例外、DNS 偏好、TUN 设置不适合直接写回远端订阅。订阅更新时，客户端会重新生成配置，直接编辑生成文件的内容可能被覆盖。更稳妥的结构是把远端内容视为“输入”，把长期保留的本地设置放入覆写、合并脚本或独立主配置。不同客户端对“覆写”“扩展”“合并”的名称与语法不完全相同，使用前应确认客户端究竟执行替换、浅层合并还是深层合并。

区分替换、追加与深层合并

YAML 映射和列表的合并行为不同。映射中的 dns.enable 可以按键覆盖，但 rules、proxies、proxy-groups 都是列表。很多工具在遇到列表时会整体替换，而不是自动追加；如果只写一条本地规则，却把订阅原有规则全部替换，最终可能只剩本地条目。也有客户端提供 prepend、append 等明确操作，把规则插入列表前端或末尾。开始使用前应先用一条容易识别的测试规则导出最终配置，确认它出现的位置和原内容是否保留。

本地覆写适合保存端口、日志等级、DNS、TUN、嗅探和少量规则例外；节点和频繁变化的远端规则更适合继续由订阅或 provider 管理。不要在多个层级同时修改同一个字段，例如订阅转换模板、客户端覆写和启动参数都设置 mixed-port，最终值会取决于应用顺序，排查时很难还原。

# 本地主配置示意：节点由 provider 更新，
# 规则与策略名称保持稳定。
proxy-providers:
  work-subscription:
    type: http
    url: https://subscription.example.com/work.yaml
    path: ./providers/work.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 默认代理
    type: select
    use:
      - work-subscription
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,默认代理

示例地址仅用于展示 provider 结构。实际订阅地址通常包含访问凭据，不应复制到公开日志、截图或共享配置中。use 引用的是 proxy-providers 的名称，不是节点名称。provider 更新后，引用它的策略组会获得新节点，而规则仍然指向稳定的“默认代理”，因此订阅侧节点增删不会破坏路由层。

多订阅合并的命名与去重

同时使用工作、个人或不同来源订阅时，最常见的问题是节点重名。两个提供者都包含“香港 01”时，直接平铺到同一列表可能无法辨认来源。较好的方式是让每个 provider 独立保存，并通过 filter、exclude-filter 或客户端支持的名称前缀区分。筛选表达式应从简单关键词开始，确认组内节点数量合理后再增加条件。过于复杂的正则容易把全部节点过滤掉。

多订阅不意味着把所有节点放进同一个自动测速组。可以建立“工作线路”“日常线路”两个底层组，再由顶层手动组选择。工作服务规则只指向工作组，日常流量指向默认组，避免自动测速时把业务出口切到不符合要求的来源。若不同订阅包含名称相同的策略组，应在本地主配置统一重新命名，不要依赖远端组名长期不变。

更新前检查与失败回退

更新订阅前先保留上一份可工作的最终配置，而不是只保存原始订阅。更新完成后检查四项：配置能否通过解析、关键策略组是否仍存在、组内是否有节点、规则末尾是否保留兜底。随后再进行连接测试。若更新后客户端无法启动，可以先恢复上一份最终配置，再对比节点、组名和列表缩进，不必在失效配置上连续修改。

YAML 对缩进敏感，列表项必须在正确层级。制表符、全角标点和看似相同的特殊空格都可能造成解析失败。订阅转换工具生成的配置也应视为普通配置进行检查，不能因为它是自动生成就跳过验证。涉及 provider 的路径要确认目录存在且可写；涉及多个文件时，移动主配置后也要同步检查相对路径。

客户端之间迁移配置

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客户端都可围绕 mihomo 配置工作，但界面层的覆写方式、配置目录和服务模式不同。迁移时先导入不含设备专属路径的核心 YAML，再在新客户端界面配置系统代理、TUN 权限和开机启动。不要直接复制旧客户端的整个数据目录，以免把缓存、锁文件和平台路径带入新环境。客户端选择与平台差异可在横向评测中核对。

07

外部控制面板

mihomo 提供外部控制接口，用于查看连接、切换策略、更新提供者和读取日志。桌面客户端自带的界面通常已经连接这个接口；服务器、路由器或纯命令行部署则可以配合独立 Web 控制面板使用。控制接口拥有修改运行状态的能力，应把它视为管理入口，而不是普通网页服务。安全配置的核心是限制监听范围、设置访问凭据，并由可信网络或反向代理承担远程访问。

监听地址与访问范围

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui
external-ui-name: dashboard

127.0.0.1:9090 只接受本机连接，适合桌面客户端或控制面板与内核运行在同一设备的情况。若改为 0.0.0.0:9090，局域网其他设备也可能访问，必须同时设置防火墙和强访问凭据。示例中的凭据是教学假值，实际部署应使用独立且不可猜测的值，不要与订阅地址或其他账户共用。

external-ui 指向静态控制面板文件目录，目录中应包含面板入口文件。external-ui-name 用于区分或指定界面目录的名称，具体下载与更新方式取决于采用的控制面板和内核配置。若接口可连接但页面显示空白，应检查静态文件路径和进程工作目录；若页面能够打开但提示无法连接内核，则应检查控制接口地址、协议、浏览器同源限制和凭据。

局域网与远程访问边界

局域网管理时，可以让控制接口监听内网地址，并只允许管理设备所在网段访问。不要把控制端口直接暴露到公网。需要远程管理时，更合适的方式是先进入可信 VPN，或通过带身份验证和 TLS 的反向代理访问。反向代理还应限制允许的方法、请求体大小和来源，避免任何能访问网页的人都能操作内核。

控制面板中的策略切换会改变当前运行状态，但不一定写回原始配置。重启后选择是否保留取决于 profile.store-selected 等持久化设置和客户端实现。若希望策略选择在重启后恢复，可启用相应持久化；若服务器要求每次启动回到固定出口，则应关闭保存并在配置中明确默认顺序。

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

log-level: info
unified-delay: true
tcp-concurrent: true

store-selected 保存策略组当前选择，store-fake-ip 保存 Fake-IP 映射，有助于重启后维持部分连接行为。保存文件仍需要工作目录写权限。log-level: info 适合日常观察；排错时可临时提高详细程度，但长期保留大量详细日志会增加磁盘写入和信息暴露范围。unified-delay 用于让延迟测试采用较统一的计算方式，tcp-concurrent 会并发尝试目标地址以改善部分双栈连接建立过程，是否适合应根据设备资源和网络表现测试。

控制面板中的正确排查方式

连接列表适合回答三个问题：应用连接了哪个目标、命中了哪条规则、最后使用哪个策略。遇到网站打不开时，先按目标域名筛选连接，确认请求是否出现；没有连接记录，说明流量可能没有进入内核，应检查系统代理或 TUN。出现记录但目标只有 IP，可继续检查 DNS 和嗅探。规则与策略正确但连接超时，再检查节点和目标可达性。

策略组页面中的延迟测试只是一种健康检查，不是线路评分。某节点对测试地址响应快，但对具体服务仍可能不可用。应结合实际连接日志判断。提供者页面更新失败时，查看失败的是代理提供者还是规则提供者，并对应检查订阅地址、规则地址、DNS 和写入权限。一次点击连续触发多次更新会产生重叠请求，等待当前任务结束后再重试更容易得到清晰日志。

配置变更的安全流程

通过控制接口重新加载配置前，应先在独立位置完成语法检查。远程服务器上修改监听地址、TUN 或默认路由时，保留当前管理会话，并准备能够恢复旧配置的服务命令。systemd 部署可以先检查服务日志，再执行受控重启；不要在确认新配置可读取之前删除旧文件。若服务进入重复启动失败，应停止自动重启，直接查看第一次失败的错误行，后续错误常常只是前一问题的连锁结果。

# 查看服务状态与最近日志
systemctl status mihomo
journalctl -u mihomo -n 100 --no-pager

# 配置确认后再重启
sudo systemctl restart mihomo

系统服务名称可能由实际安装方式决定，执行前应核对本机单元名称。纯命令行部署需要更多系统管理知识；希望直接管理订阅、策略和系统代理的桌面用户，优先从Linux 客户端或其他对应平台 GUI 客户端开始。Linux 桌面与 systemd 两条部署路线可继续阅读Clash Linux 安装指南。