Clash 进阶配置手册

01 · 配置生效链路与修改基线

客户端、内核与运行配置

客户端界面负责导入订阅、保存选项、启动后台服务；内核负责解析规则、建立连接和转发流量。界面上出现某个开关，不意味着订阅文件中必定存在同名字段；反过来，在文件里写入字段，也可能被客户端生成运行配置的过程覆盖。排查时应先在客户端的内核信息或日志中确认实际使用的内核，再找到最终交给内核读取的配置，而不是只查看订阅编辑器。

本站按平台整理客户端入口，选型时优先查看 Clash Plus，再根据系统与具体功能核对其他客户端。Clash Verge Rev、Clash Meta for Android、FlClash 等客户端的配置入口和合并方式并不相同。需要重新选择安装入口时，可前往客户端下载页。本页不把某一款客户端的界面路径当成所有平台的固定操作，字段支持情况应结合实际运行内核判断。

建立能恢复的最小改动流程

修改前分别保存订阅来源、本地覆写内容和当前可用的运行配置，记录系统代理与 TUN 的原始状态。订阅地址可能携带访问凭据，不应放进公开仓库、截图或求助帖子。推荐一次只修改一个配置层：先确认文件能加载，再确认规则命中，最后才调整接管方式。把 DNS、路由、规则集同时更换后，即使连接失败，也很难知道是哪一处改变了流量路径。

下面是用于理解基础字段的片段，不是带有代理节点的完整订阅。这里使用规则模式和混合端口，未命中规则的连接直接出站。将它与已有配置合并时，应编辑现有的同名顶层字段，不要在同一文件末尾重复添加第二个 rules。YAML 重复键的处理会因解析过程而异，不能依赖后出现的内容一定覆盖前面的内容。

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

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

缩进统一使用空格，列表项的短横线与所属字段保持层级一致。含有冒号、井号或容易被识别为特殊类型的字符串，宜用引号包围。最常见的格式问题并非字段复杂，而是复制片段时丢失缩进，或者把完整配置嵌进了某个子字段。编辑器显示正常不代表内核能解析，保存后仍需查看加载结果。

语法检查与行为检查分开进行

如果手头有独立 Mihomo 可执行文件，可以先运行下方测试命令。命令中的文件应位于当前目录；规则集、数据库等依赖若使用相对路径，还需保证测试所用的工作目录与实际运行环境一致。通过语法测试只表示配置可以解析，不代表节点可用、DNS 能连通或系统路由已经建立。

mihomo -t -f ./config.yaml

行为检查应沿着一条新建连接逐层进行：应用是否进入内核、目标域名是否被识别、哪条规则命中、最终选择哪个出站。已有浏览器长连接可能继续沿用旧策略，测试时应新开请求，必要时关闭该应用后重新连接。不要因为切换策略组后一个旧标签页仍能访问，就认定新规则已经生效。

如果连最小配置也不能启动，先检查端口占用、文件权限和路径，再研究规则语法。出现地址已被占用的提示时，可参照7890 冲突定位与 mixed-port 修改步骤。修改端口后要同步应用手动代理设置，避免内核已在新端口监听，而浏览器还在连接旧端口。

02 · 策略组类型与分层实战

先区分规则目标与实际出站

规则回答“这条连接交给谁处理”，策略组回答“当前从哪些候选出站中选一个”。规则可以指向具体节点，也可以指向策略组。日常配置更适合让规则引用稳定的组名，把节点增删留在组内处理；这样订阅更新导致节点改名时，不必逐条修改业务规则。组名属于引用标识，空格、大小写和文字都应完全一致。

select 是手动选择组，适合放在用户能直接操作的入口层；url-test 依据探测结果选择候选；fallback 在候选可用的前提下优先沿用列表中靠前的出站；load-balance 按所选分配策略让不同连接使用候选出站。几类策略解决的问题不同，不应只凭名称判断“自动”一定比“手动”适合所有业务。

入口组与自动组分开

一个便于维护的结构是：规则指向“网络出口”，入口组再提供自动组、手动候选或直连选项。下面片段只引用内置的 DIRECT，因此可以演示组之间的引用关系，但不会产生代理出口。实际使用时，需要先通过合法取得的订阅或本地节点定义加入真实候选，再把这些候选名称填入自动组，不要把示例误当成节点来源。

proxy-groups:
  - name: 网络出口
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    proxies:
      - DIRECT
    url: https://example.com/
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,example.com,网络出口
  - MATCH,DIRECT

这里的 interval 表示周期探测间隔，tolerance 用于减少很小的探测差异引起的频繁切换。测试地址应当是能通过候选出站访问、响应行为明确的端点；示例保留域名仅用于理解字段，生产配置应选择适合自己网络环境的探测目标。测试结果衡量的是到该目标的路径，不能代替下载速度、视频可用性或账号业务的稳定性判断。

登录会话、支付页面或对出口地址敏感的业务，通常应固定到手动选择的组，避免在多条新连接之间切换出口。即使使用一致性分配策略，也不能承诺所有相关域名必定落到同一地址：页面可能依赖多个服务，候选集合也可能发生变化。需要稳定出口时，应以实际连接记录核对，而不是只看组的名称。

排除循环引用与候选缺失

策略组可以引用其他组，但不能形成环。比如入口组引用自动组，自动组又引用入口组，会让选择过程失去明确终点。较稳妥的方法是保持单向层级：业务规则到入口组，入口组到功能组，功能组到真实节点或内置出站。订阅提供者引用则要核对 use 中的名称是否存在，以及提供者是否已经成功加载。

如果组能显示但没有可选节点，先查看筛选表达式是否把候选全部排除，再检查订阅加载记录；不要直接把过滤条件改成一个更复杂的表达式。节点重名也可能使显示与引用产生歧义，合并订阅时应提前制定唯一命名规则。自动组全部失败时，先选择一个已知候选单独测试，区分是节点连通性问题，还是探测目标本身不可达。

更改组选择后，只观察新连接。部分客户端会保存上一次选择并在重启后恢复，这与 YAML 中列表的排列不是同一件事。如果界面选择与预期不同，应同时检查客户端持久化设置和当前运行状态；需要比较客户端操作入口时，可查阅客户端对比页，而不是通过反复改组名绕过状态保存机制。

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

把规则内容与分流目标拆开

当域名与网段条目越来越多，把全部内容堆在主配置中会让更新和审核变得困难。rule-providers 用来定义规则内容的来源，RULE-SET 则在主规则列表中引用它，并指定命中后的策略。规则集负责“有哪些目标”，主配置负责“这些目标走哪里”，两者分离后，同一份业务域名列表可以在不同设备上指向不同的策略组。

提供者的 behavior 必须与内容相符：domain 面向域名集合，ipcidr 面向 IP 网段，classical 允许包含传统规则类型的条目。下载地址能打开，并不说明文件格式就正确；把带 payload 的 YAML 当作纯文本列表读取，或把完整规则行交给域名解析器，都可能导致加载失败或结果不符。

先用本地文件跑通引用关系

下面采用本地文件，便于在不依赖远程下载的情况下验证规则集。先在内核工作目录下创建 rules 目录，再保存 local-domains.yaml。该文件只包含规则内容，不写代理策略。示例域名用于测试匹配，实际业务应换成自己明确需要管理的域名，并保留修改记录。

# rules/local-domains.yaml
payload:
  - '+.example.com'

主配置中定义文件来源，并在普通规则里引用。相对路径按内核工作目录解释，不一定相对于客户端当前打开的编辑器文件。使用桌面客户端时，应先查明它为内核分配的配置目录，避免文件放在下载目录而运行时去另一个目录查找。

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

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

切换为 HTTP 来源时，需要设置真实可访问的 url、缓存 path 与更新 interval，并确认服务器返回的是规则正文，不是网页预览或登录页。缓存路径应保持唯一，不要让两个不同提供者写入同一个文件。文件格式可使用内核支持的 YAML、文本或编译格式，但内容和声明必须成对匹配，不能只修改扩展名。

规则顺序决定实际结果

规则通常按从上到下的顺序匹配，先命中的规则结束本次选择。特定域名例外应放在宽泛分类之前，最后用 MATCH 承接剩余流量。把规则集加在 MATCH 后面不会产生预期效果；同样，一个过宽的域名后缀规则放在前面，也可能让后面的细分类规则永远没有机会命中。

IP 类规则可能触发域名解析。某些规则末尾可使用 no-resolve，表示在目标仍是域名时，不为这条 IP 规则额外发起解析；它不是“禁止整个连接使用 DNS”。如果希望域名规则优先处理，就应将其放在需要解析的网段规则之前。为了减少不必要的查询而随处加上该参数，可能使原本依赖解析结果的规则失效。

远程规则集更新失败时，先确认内核是否仍持有可用缓存，再查下载路径和访问条件。首次启动与日常更新的条件不同：日常可以依赖旧缓存启动，首次启动却可能没有任何可用内容。若下载规则本身需要代理，而代理选择又依赖尚未下载的规则，就会形成启动依赖环，应让基础启动路径保持简单。

对频繁更新的规则来源，应保留变更前的内容快照，更新后检查关键业务域名是否被新增分类覆盖。GeoIP、GeoSite 与普通规则提供者并不是完全相同的存储机制，相关数据库的模式、路径和更新条件可继续查阅GeoIP 与 GeoSite 数据库更新说明。不要为了统一命名，把不同机制的文件互相替换。

04 · DNS 解析路径与配置优化

分清应用查询、内核解析与节点解析

DNS 问题往往不是“有没有填解析服务器”，而是查询究竟由谁发出。浏览器可能启用自己的加密 DNS，操作系统可能缓存旧结果，内核还需要解析代理服务器域名。系统代理只影响遵循代理设置的应用请求，并不自动保证所有 DNS 查询都交给内核。开始调整之前，应先确定应用使用的是系统解析、内核 DNS，还是独立的解析路径。

nameserver 是常规解析上游；default-nameserver 用于解析 DNS 上游自身的域名等基础启动需求；proxy-server-nameserver 则可单独指定代理服务器域名的解析来源。分开设置的目的，是避免还未建立代理连接，就必须先经过该代理才能解析节点地址。仅把所有上游都改成 HTTPS，并不能自动消除这种依赖关系。

先配置可理解的基础解析

下面片段让内核在回环地址的非标准端口提供 DNS 服务，并使用 Fake-IP。它不会自行改变操作系统的 DNS 设置；只有实际把查询送到这个监听端口，才能观察到效果。桌面客户端的 TUN 劫持、系统 DNS 设置或手动测试可以形成不同入口，验证时要明确当前走的是哪一条。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  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
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

这里的上游地址只是配置示例，不构成对所有网络环境的可达性承诺。选用上游时，应考虑本地访问条件、查询隐私要求与结果是否符合业务需求。ipv6: false 控制此处 DNS 的 AAAA 响应行为，不等同于关闭系统全部 IPv6 网络。若网络本身具备可用 IPv6，禁用它也可能改变原有连接路径，应以明确的问题为依据进行调整。

按域名指定解析策略

企业内部域名、家庭设备名称或特定业务域名，可能只能由指定解析器正确回答。此时可考虑 nameserver-policy，让这些域名使用专用上游。内部域名不要盲目发往公共解析器，既可能得不到结果，也会暴露本来只在内网使用的命名信息。配置时应先确认域名范围，避免一个过宽的后缀把大量公共查询一并送入内网服务器。

如果使用 respect-rules 让 DNS 上游连接遵循分流规则，需要同时考虑代理服务器域名如何解析。该选项改变的是内核访问 DNS 上游的路径，不是让每个 DNS 响应自动获得正确分类。先建立独立、可达的节点解析通道，再观察上游连接命中哪条规则，可以避免一边解析节点、一边等待节点连接的循环。

fallback 与 fallback-filter 也不是一个简单的“主服务器坏了再换备用”的开关。启用后，结果筛选会受域名、地址范围等条件影响。若没有明确的筛选目标，优先保持单一、可靠的解析路径；只有确认某类域名的解析存在特定问题时，再引入回退机制。上游越多并不必然越稳定，反而会扩大排错范围。

dig @127.0.0.1 -p 1053 example.com A

测试应同时记录查询耗时、返回地址类型与内核日志。Fake-IP 模式下得到保留地址段中的地址可能是正常结果，不能仅凭它不是公网地址就认定解析失败。修改解析模式后，应用缓存和系统缓存可能仍保留旧结果；应新建请求，并按操作系统提供的方法刷新缓存，而不是不断追加新的 DNS 上游。

如果域名能解析而网页打不开，继续检查连接使用的规则和出站；如果只有浏览器行为不同，核对浏览器独立 DNS 与代理扩展。相关症状可以沿着已连接但无法访问网页的排查清单逐层确认。DNS 优化的目标是路径清楚且结果可验证，不是让配置字段尽可能多。

05 · TUN 接管与 Fake-IP 映射

两种机制各自处理什么

TUN 创建虚拟网络接口，让操作系统把符合路由条件的 IP 流量交给内核处理；Fake-IP 则在 DNS 阶段返回一个受控的虚拟地址，并在内核中保存这个地址与原始域名的映射。前者回答“流量如何进入内核”，后者帮助回答“这条流量原本访问哪个域名”。它们经常一起使用，但并非同一功能，也不是开启一个就必然替代另一个。

系统代理依赖应用遵循代理配置，对未遵循代理设置的程序可能不起作用；TUN 通过路由接管更广的流量，但也会涉及权限、虚拟网卡、系统 DNS 和其他 VPN。不要把接管范围扩大理解成所有协议都会自动获得远端支持，出站节点的协议能力仍然限制最终可用性。尤其是 UDP，需要从应用、内核到远端整条路径都具备相应支持。

按客户端权限流程启用

桌面端先使用客户端提供的服务安装或授权流程，再开启 TUN。Windows 常涉及后台服务或管理员权限，macOS 需要结合客户端实现完成系统授权，Linux 则取决于服务权限、网络管理与路由设置。Android 通常通过系统 VPN 服务授权，字段是否直接暴露由客户端决定。iOS 的网络接管受应用与系统扩展机制管理，不宜照搬桌面端的原始网卡配置。

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

该片段依赖前一章已启用的内核 DNS，并假设客户端允许相应 TUN 配置。auto-route 尝试添加所需路由，auto-detect-interface 尝试识别出口接口；多网卡、容器、远程桌面或企业网络下，自动识别未必符合实际拓扑。stack 的选择需要结合平台支持和应用表现，不应把某个栈作为所有设备的固定答案。

dns-hijack 的示例面向传统 DNS 端口，不能因此推断浏览器的 DoH 或其他加密 DNS 已被解密或替代。部分应用直接连接固定 IP，或者使用自己的解析服务，仍需要从连接记录判断。若应用完全没有出现在内核连接列表，应先调查路由与接管入口，而不是反复修改域名规则。

Fake-IP 过滤只处理必要例外

一些依赖真实地址返回值的应用，可能不适合收到 Fake-IP，例如某些局域网发现、设备连接或特定认证流程。可以在 fake-ip-filter 中为明确的域名添加例外，让这些查询返回真实解析结果。添加前先确认现有 fake-ip-filter-mode 的语义；不同过滤模式下，同一份列表的含义可能相反，不能只把别人分享的长列表复制进去。

过宽的过滤会减少内核通过映射恢复域名的机会，进而改变规则匹配条件。实际排查宜从单个出问题的域名开始：确认查询到达内核、确认返回地址类型，再观察连接是否依赖真实地址。设备发现还可能依赖广播或组播，单纯添加域名过滤并不能解决所有局域网访问问题。

与其他 VPN 并用时，应明确谁负责默认路由、谁负责 DNS，以及是否存在重复接管。两套虚拟网卡同时声明相似路由，可能出现请求绕行、回环或只有部分目标可达。关闭其中一套接管后重测，是区分冲突来源的有效步骤；不要在未知拓扑上直接增加更严格的路由选项。

回退时先关闭 TUN，再确认系统代理和 DNS 是否恢复到预期状态；切换 Fake-IP 与真实解析模式后，也应刷新相关缓存并重新建立连接。若客户端界面已经退出但网络仍异常，要检查后台服务是否还在运行、系统是否遗留手动代理设置。通用问题可继续查阅帮助中心，并记录故障发生前最后一次改变的网络层。

06 · 域名嗅探与识别边界

嗅探补充连接上下文

当连接进入内核时只携带目标 IP，域名规则可能缺少可匹配的信息。域名嗅探尝试从协议握手中提取主机名称，例如 HTTP 请求中的主机信息或 TLS 握手中的服务器名称，再供后续处理使用。它不能解密任意 HTTPS 正文，也不是把所有 IP 自动还原成唯一域名的工具。同一个地址承载多个网站时，单靠地址本身本就无法确定业务名称。

嗅探与 Fake-IP 都能帮助保留域名上下文，但来源不同：Fake-IP 依赖由内核处理的 DNS 映射，嗅探依赖连接早期可观察的协议内容。应用如果绕过内核 DNS，嗅探可能补足一部分信息；如果握手没有暴露可用域名，或者协议不在支持范围内，就不能指望它凭空生成域名。

先限定协议与端口范围

以下片段展示 HTTP 与 TLS 的基础嗅探配置，同时保留原始连接目标。先使用较窄的端口范围观察效果，再按实际应用扩展，比一开始覆盖所有端口更容易定位问题。示例中的端口范围是配置条件，不代表这些端口上的所有流量必定使用对应协议。

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

parse-pure-ip 允许尝试处理以 IP 为目标的连接，force-dns-mapping 与 DNS 映射场景有关；是否确实需要这些行为，应结合原始连接信息判断。override-destination 决定是否允许用识别结果改写连接目标，而不只是补充域名信息。使用前应区分“希望规则识别域名”和“希望改变最终拨号目标”这两个需求。

保留原始地址更便于比较开关前后的行为。对于依赖特定地址、私有解析或专线入口的业务，改写目的地可能引入额外解析，并让请求偏离原本的服务器。需要启用目标改写时，应先在单一应用、单一域名上验证，再考虑扩大范围，不宜把它作为所有连接失败的通用修复项。

跳过范围与无法识别的情况

对不适合嗅探的业务，可以按内核支持的域名或地址排除字段建立例外。例外应来自可复现的兼容性问题，而不是复制一份不明来源的跳过清单。记录排除前后的目标地址、识别域名与命中规则，才能知道问题发生在识别过程，还是后续策略选择。

QUIC 与普通 TLS 的传输方式不同，只有启用并获得内核支持的对应解析能力，才可能提取相关信息。即使支持，也不意味着加密握手中的所有信息都可见。启用 ECH 等机制的连接可能不再暴露可用的目标名称；私有协议、直接使用 IP 的应用或没有主机信息的连接，也可能无法通过嗅探得到适合域名规则的结果。

不要为了让日志显示域名而随意阻断某种协议。阻断 UDP 可能迫使部分应用改用其他传输，也可能直接破坏业务。若确实需要做兼容性测试，应清楚说明测试条件，并在完成后恢复原设置。正常配置应围绕应用需求设计，而不是围绕连接列表是否整齐来设计。

用连接记录做前后对照

验证时先关闭嗅探，新建一次目标请求，记录目标类型、规则和出站；再开启嗅探，对相同业务发起新的连接。若域名出现但分流没有变化，可能是前面的 IP 规则已经命中，或域名规则的匹配范围本来就不包含该目标。若开启后反而失败，则优先比较目标是否被改写，以及额外的解析是否成功。

测试日志应控制保存范围。域名、请求路径、节点名称和控制接口信息都可能涉及个人或组织网络活动，求助时只保留必要字段并做脱敏。对于“节点全超时”这类更基础的故障，嗅探通常不是第一检查项，应先按照订阅、系统时间与协议兼容的排查顺序确认出站本身能够建立连接，再讨论域名识别的优化。

07 · 本地覆写与多订阅合并

把可更新内容与设备设置分开

订阅适合维护节点、组和由提供者管理的规则，本地配置则更适合保存设备端口、TUN、局域网访问限制与个人分流例外。直接在订阅正文里修改，往往会在下一次更新时丢失。使用客户端的覆写、合并或增强配置机制，可以让订阅继续更新，同时把需要长期保留的设备差异独立管理。

不同客户端对“覆写”的定义并不完全一致：有的执行对象合并，有的替换整个字段，有的提供脚本处理，有的还会在最后强制写入界面设置。尤其是 rules、proxy-groups 这类数组，不能假定一定逐项追加。配置前应查清处理顺序，并在修改后查看最终运行配置；只看覆写编辑器无法确认最终结果。

通过代理提供者组织多份来源

多订阅不一定要把完整文件直接拼接。对于格式合适的节点来源，可以使用 proxy-providers 分别维护，再让策略组通过 use 引用。下面演示文件型来源，适合先验证结构。需要先在内核工作目录准备实际节点文件；未创建文件之前，不应把此片段当作可直接启动的完整配置。

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

  work-nodes:
    type: file
    path: ./providers/work.yaml

proxy-groups:
  - name: 个人线路
    type: select
    use:
      - personal-nodes

  - name: 工作线路
    type: select
    use:
      - work-nodes

提供者文件应包含符合内核要求的 proxies 列表，而不是随意保存一份带全套规则的客户端配置。编码后的分享链接集合、完整 Clash 配置与代理提供者文件是不同形式，导入前要确认客户端或来源是否支持对应转换。不要把私人订阅交给不明在线转换服务，订阅链接与节点凭据一旦离开受控环境，访问权限也可能随之暴露。

如果来源本身支持 HTTP 提供者，可以为每份来源设置独立缓存路径和更新间隔。个人与工作来源分开，能够让策略组边界更明确，也方便单独停用一份来源进行测试。但应确认来源的授权使用范围，技术上可以合并并不意味着可以把访问权限转交给其他设备或人员。

处理命名、追加位置与优先级

合并前先建立命名约定：提供者名称唯一，策略组名称稳定，节点名称避免跨来源冲突。引用关系以名称为准，不能指望界面显示相同名称时仍能自动区分来源。需要前缀或重命名时，优先使用客户端或内核明确支持的机制，并测试筛选条件是否仍能命中改名后的节点。

本地规则通常分为前置例外和兜底选择。必须优先处理的内部域名，应放在宽泛规则之前；最终 MATCH 只能承担兜底职责。某些合并机制把本地列表追加到订阅之后，如果订阅已有 MATCH，追加规则就没有机会执行。正确做法是调整合并方式或显式重建规则顺序，而不是继续在末尾添加更多相似规则。

订阅更新也需要回归验证

更新成功后，检查三类内容：来源是否正常加载、组引用是否仍存在、前置规则是否仍位于预期位置。订阅新增字段可能被旧覆写整体替换掉；本地保存的组选择，也可能引用已经消失的节点。排查时先禁用个人覆写，确认原订阅能否运行，再逐块恢复，能够更快找出冲突。

若客户端不便展示最终配置，至少保留加载日志、节点列表和关键连接的规则记录。恢复旧快照时也要注意节点凭据可能已经失效，配置能加载不等于旧节点还能使用。日常操作以上手教程中的导入与连接流程为主，本章用于解释更新后为什么需要重新核对合并结果，而不是要求每次连接都手工编辑文件。

08 · 外部控制面板与维护闭环

控制接口不是代理端口

external-controller 提供内核的管理接口，可供面板读取状态、切换策略或执行管理操作。它与接收 HTTP、SOCKS 请求的混合代理端口不同，也不是 DNS 监听端口。把面板连接地址填成代理端口，不会自动获得管理功能；把控制端口当成网络代理填写，同样无法产生正确的转发路径。

控制接口能够影响网络行为，因此默认应绑定回环地址，仅允许本机访问。确需跨设备管理时，应先设计访问边界，再考虑监听地址、认证、传输保护与防火墙。不能只为了让手机打开面板，就把接口暴露到所有网卡，并依赖一个容易猜到的示例口令。控制接口泄露的影响不仅是看见状态，还可能包括修改运行选择。

本机面板与认证配置

下方片段展示回环监听与本地面板目录。your-password 是明确的教学示例，实际启用时必须替换为自行生成的高强度密钥；不要把真实值发到公开问题记录中。external-ui 指向已经准备好的静态面板文件目录，没有放入面板文件时，不会仅凭字段自动出现可用页面。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

如果客户端已经内置面板和控制设置，应优先使用其管理入口，避免本地覆写与界面设置互相竞争。手动测试管理接口时，可以在受信任的本机终端发起请求。下面命令会交互读取密钥，避免将真实值直接写在命令历史里；使用后会清除当前终端中的变量。

read -r -s -p "控制接口密钥: " MIHOMO_SECRET
printf '\n'
curl --fail --silent --show-error \
  -H "Authorization: Bearer $MIHOMO_SECRET" \
  http://127.0.0.1:9090/configs
unset MIHOMO_SECRET

该命令适用于 Bash 环境，其他终端应使用对应的安全输入方式。读取成功只能说明当前终端到控制接口的链路可用，不能直接证明浏览器面板也具备相同条件。浏览器还会受到页面来源、混合内容、跨域策略与网络地址的约束，应把接口连通性和页面访问问题分别检查。

远程访问先确认地址含义

面板页面中的 127.0.0.1 指向打开浏览器的那台设备，而不是部署内核的远程主机。通过另一台电脑访问面板时，如果仍填写回环地址，浏览器会尝试连接自己。较稳妥的远程管理方式是受控的加密隧道或经过认证与访问限制的反向代理，并继续让内核控制接口保留在本地监听。

使用反向代理时，要同时核对普通 HTTP 请求和 WebSocket 连接，连接列表或日志可能依赖持续通信。页面能打开但状态不更新，常见原因包括代理未转发升级头、认证不一致或浏览器拦截连接。跨域允许范围应限制到实际需要的页面来源，不应为了消除报错而无条件扩大。

面板静态文件也属于维护对象。更新来源应明确，升级前保存当前可用文件和配置，升级后测试登录、策略切换与日志连接。若控制接口可访问而新面板异常，应先回退面板文件，不要立即改动整个内核配置。客户端内置面板由客户端统一管理时，则应遵循其更新机制，避免手动替换造成路径冲突。

把每次改动收束成可验证记录

完成配置后，保留一份简短记录：修改了哪个字段、预期改变什么、用哪个新连接验证、失败时回退哪个文件。策略组要验证最终出站，规则集要验证命中顺序，DNS 要验证查询路径，TUN 要验证入口与路由，面板则要验证认证与访问范围。这样的记录比保存大量不明来源的配置截图更便于长期维护。

遇到异常时沿同一方向排查：先确定配置加载，再确认流量进入，之后检查解析、规则和出站。不要在面板失联时直接认定节点故障，也不要在网页打不开时马上修改控制接口。需要按症状查找解决路径，可前往帮助中心；需要更换客户端，可在下载页按平台核对入口。维护目标是每一层都有明确职责，并且每项修改都能解释、验证和恢复。