Configuration reference

Clash 进阶配置手册

策略组、规则集、DNS 与网络接管的配置边界。

本页面向已经完成订阅导入、能够建立基本连接的用户。首次安装与连接验证请先阅读使用指南；这里按主题解释配置之间的引用关系、验证方法和回滚顺序，适合作为修改配置时的查阅手册。

策略组类型与出口组织

策略组位于规则与节点之间。规则负责判断连接属于哪类流量，策略组负责决定这类流量最终使用哪个出口。把节点名称直接写进大量规则，会让节点改名和订阅更新牵动整份配置。先建立稳定的业务策略名称，再在组内调整节点，能够把日常切换与规则维护分开，也便于从连接记录追踪决策过程。

手动选择与自动选择的分工

select 适合需要人工确认的出口，例如工作服务、特定地区内容或临时排错。组内成员既可以是节点，也可以是其他策略组。外层保留一个手动选择组，内层放自动测速组，是比较容易理解的组织方式。用户只需决定使用自动选择还是直连，不必为每条域名规则重新指定节点。

url-test 通过指定测试地址评估成员，适合从一组用途相近的节点中自动选择。测试结果只代表节点到该测试目标的连通情况，不代表所有业务的体验。测试地址应长期稳定、允许探测，并与实际使用场景接近；把偶发失败的目标作为唯一依据，容易引起不必要的切换。

fallback 更接近按候选顺序寻找可用出口，适合主线路优先、备用线路接替的场景。load-balance 则按策略分配连接，不是把一条连接叠加成多条线路。对登录状态、来源地址或地区一致性敏感的服务，应先使用固定出口，确认服务允许出口变化后再考虑分担连接。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

上例只用于验证组名与规则引用关系，当前 PROXY 内只有 DIRECT，所以仍然直连。实际使用时，在客户端中加入已有节点或其他策略组；名称必须与当前配置完全一致。不要因为组名叫代理，就认定其内部一定经过远端出口，应展开成员确认最终选择。

自动测速参数与节点提供器

使用节点提供器时，策略组通过 use 引用 proxy-providers 的键名，而不是文件名。提供器中的健康检查与策略组的自动选择目的不同：前者维护节点可用状态，后者参与组内决策。两处都设置密集探测会重复消耗请求，通常先采用较宽的间隔，再根据真实故障恢复需求调整。

interval 表示探测间隔，单位为秒；tolerance 用于减少小幅差异导致的频繁切换。它不是最低速度保证，也不是连接超时设置。自动选择主要影响新建连接，已经建立的下载、通话或长连接不一定随当前选择立即迁移。需要验证变化时，应结束测试连接后重新建立请求。

类型主要决策适用边界
select手动指定成员出口固定、排错对照
url-test根据探测结果选择用途相近的候选节点
fallback按顺序选择可用成员主备线路
load-balance按策略分配连接允许出口变化的业务

引用检查与切换验证

组之间可以嵌套，但不能形成循环。例如业务组引用自动组，自动组又引用业务组，就无法形成确定的出口链。修改时先列出组名，再逐一检查成员。一个节点同时出现在多个组中没有问题，真正需要防止的是组名重复、引用不存在的名称，以及通过多层嵌套间接回到自身。

验证时在连接记录中同时查看命中规则、策略链和最终节点。若规则正确但出口不符，先检查外层组保存的选择，再看内层自动组状态；若组内为空，检查提供器是否加载成功以及筛选表达式是否排除了全部节点。不要一开始就修改 DNS，这会让出口问题和解析问题混在一起。

订阅更新可能移除节点，但稳定的业务组名称仍应保留。重要服务可以单独建立策略组，避免跟随通用组自动变化。将经过验证的组织方式记录下来，比持续增加嵌套层数更容易维护；涉及多个订阅的节点接入方式，见本地覆写与多订阅合并。

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

规则集把经常更新的域名或网段从主配置中拆出，由 rule-providers 负责加载，再用 RULE-SET 接入规则链。主配置因此只保留分类与出口关系。规则集不是节点订阅，也不会自动建立策略组；即使文件加载成功，缺少对应的引用规则时，它也不会参与任何连接判断。

先确定行为类型与文件格式

behavior 描述规则内容的语义。domain 存放域名集合，ipcidr 存放地址段，classical 存放带类型的规则条目。format 则描述文件如何编码，两者不能互相替代。下载得到文本文件，并不意味着应该选择某一种行为，必须打开内容检查实际条目。

下面使用本地经典规则集，便于在没有远程更新因素的情况下验证结构。将第二段保存为主配置目录下的 rules/work.yaml，先确认目录可读，再加载第一段。这里的 PROXY 需要提前在策略组中定义；规则集只存匹配条件，不在每条内容后重复附加出口。

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

rules:
  - RULE-SET,work,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

经典规则集保留 DOMAIN-SUFFIX 等类型前缀；域名集合有自己的条目语义，不能把上面的文件仅改一个 behavior 就继续使用。若使用二进制规则格式，还要确认当前内核支持相应格式。报错时优先核对文件内容与声明是否一致，而不是不断更改缓存路径。

远程更新与缓存的职责

改为远程规则提供器时，需要使用 type: http，填写真实的规则地址，并设置更新间隔和独立缓存路径。更新间隔的单位同样是秒。远程地址必须返回所声明格式的规则内容，返回网页、登录页或错误提示都不算成功更新；连接成功状态也不能代替内容解析成功。

缓存让客户端在暂时无法获取远程文件时有机会继续使用既有内容，但是否能够启动还取决于缓存是否存在以及内核加载结果。首次使用时应在日志中确认下载与解析都已完成。多个提供器不要共用同一缓存文件，否则某次更新可能覆盖另一份规则，出现分类名称正确但内容错误的隐蔽问题。

远程规则来源也属于配置的信任边界。规则维护者可以改变域名分类，从而改变连接出口。引入前应了解规则用途、更新方式和覆盖范围，先在本地测试再接入主要配置。对必须稳定的少量业务，可以用主配置中的精确规则固定行为，不必完全依赖大范围的远程列表。

按优先级排列规则链

常规规则按顺序匹配，先命中的规则决定出口。因此本地例外通常放在通用规则集前，范围较大的网段判断靠后，MATCH 放在末尾兜底。把兜底项放到前面，会让后面的规则失去机会；把宽泛的拒绝规则放在业务例外前，也会直接遮住后者，调整策略组无法修复这种顺序错误。

涉及 IP 的判断可能需要解析域名。某些 IP 规则支持 no-resolve，用于避免为该规则额外触发解析，但这不是让连接完全跳过 DNS。是否添加取决于规则用途：希望依赖已知目标地址时可以考虑，期望通过域名解析后判断所属网段时则要谨慎，避免改变原先预期的命中范围。

排查误分流时，先记录目标域名与实际命中的规则，再缩小到对应提供器。临时加入一条精确域名规则放在最前方，能够帮助判断问题来自规则顺序还是出口本身。测试结束后应删除临时项，保留有用途说明的正式例外，避免配置逐渐积累相互遮挡的规则。

规则较多时，可按工作服务、媒体服务和本地网络分别组织，而不是按来源随意堆叠。每次只更新一类并观察连接记录，能够明确变化来源。关于字段之间的引用基础，可继续阅读config.yaml 顶层字段拆解；连接失败的通用检查见FAQ。

DNS 配置优化与解析路径

DNS 的目标不只是得到一个地址，还要让域名、地址与后续出口保持一致。相同域名通过不同解析服务可能得到不同结果，代理出口所在网络也可能影响目标可达性。优化前先确认应用的请求是否进入客户端 DNS，再确定解析请求从哪个出口发出，最后才比较解析服务，而不是只替换服务器列表。

区分监听、上游与引导解析

listen 定义客户端 DNS 服务监听的位置，nameserver 定义一般域名查询使用的上游，两者不是同一层。监听在回环地址只供本机访问；写入配置也不代表操作系统已经改用这个地址。还需要系统 DNS 设置、TUN 的 DNS 接管或客户端相应功能，把请求真正送到该监听端口。

default-nameserver 主要用于解析 DNS 上游自身的域名，因此应选用能够直接访问的明确地址。当加密上游用域名表示时，必须先解决这个引导环节。若引导解析又依赖尚未建立的代理，配置就可能出现启动循环，表现为节点域名与解析服务域名同时无法解析。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

这段示例展示字段位置，所列公共解析地址需要根据当前网络的可达性选择。它没有将系统端口自动转发到 1053，也没有承诺所有应用会使用该服务。部署后应先直接查询这个端口，确认监听工作，再验证系统和应用的解析路径，避免把系统没有接入的问题误判成上游故障。

节点域名与业务域名分开处理

业务域名最终可以通过代理访问，但代理节点自身的域名通常需要在代理可用之前解析。支持相应字段的内核可用 proxy-server-nameserver 单独设置节点域名解析服务。更改前确认上游可直接访问；如果节点地址本身无法解析，策略组探测失败并不能说明远端服务不可用。

nameserver-policy 可以针对特定域名选择解析服务，适合内部域名、分离解析或有明确地域要求的业务。企业内部域名应交给能够访问内部区域的解析服务，公开解析服务通常不知道这些记录。策略应保持范围明确，先验证单个后缀，再扩大覆盖，避免把普通域名意外送到仅内部可达的服务器。

respect-rules 会让 DNS 上游连接按照规则选择出口，使用时需要同时理清节点域名解析，避免 DNS 依赖代理而代理又依赖同一条 DNS 路径。它不是普遍适用的加速开关。没有明确的解析出口需求时，先保持简单配置，等基本连接稳定后再增加策略，通常更容易定位问题。

按层验证，不用网页体验代替查询

应用可能保留自己的 DNS 缓存，也可能开启加密 DNS。浏览器内置解析会绕开系统设置，而已经建立的连接甚至不会再次查询。更改配置后，应分别检查客户端查询、系统查询和应用新连接，必要时清理对应缓存。只刷新页面而没有关闭旧连接，很难证明新设置已经生效。

具备 dig 的系统可以用下列命令直接询问示例监听端口。返回 Fake-IP 地址意味着查询进入了相应映射机制，不意味着目标服务器真的使用该地址。若命令超时，先检查监听地址和端口占用；若能返回而应用仍失败，再检查系统接入、路由和规则命中，不应立即更换全部上游。

dig @127.0.0.1 -p 1053 example.com A

若普通域名正常、只有内部域名失败，应检查搜索域、内部解析服务器与 VPN 路由；若所有域名都失败但直接地址可通，重点检查 DNS 接管和上游路径。若域名得到地址但连接超时，则需要回到策略链与目标可达性，DNS 成功本身并不保证连接会按预期出口建立。

不要把增加上游数量当作通用优化。过多服务器会扩大隐私与故障边界，也可能因返回结果不同而增加排查难度。先选择少量可靠上游，记录特殊域名策略和选择理由。DNS 配置与 Fake-IP 的关系需要结合下一章理解，尤其是地址映射、缓存失效和应用保存地址的情况。

TUN 与 Fake-IP 的接管边界

TUN 是虚拟网络接口，用于接收被系统路由送入的 IP 数据包；Fake-IP 是 DNS 层的地址映射机制。两者经常配合使用，但不是同一项功能。系统代理主要服务于遵循代理设置的应用，TUN 则可以覆盖更多网络请求。是否启用应由应用接管需求决定，而不是把它视为所有连接问题的默认修复选项。

建立可回退的接管顺序

启用前先用普通代理方式确认节点、订阅和策略组可以工作，再检查客户端是否需要安装服务或取得管理权限。桌面系统通常涉及虚拟接口与路由权限，移动端通常通过系统 VPN 接口授权。界面开关打开不代表接管完成，应在日志中确认接口创建、路由安装以及 DNS 接管均未报错。

下面给出常见的基本字段。auto-route 用于自动设置路由，auto-detect-interface 用于识别出口接口，dns-hijack 配置 DNS 接管目标。具体支持和行为受系统及内核影响，建议先使用客户端提供的默认 TUN 设置，再对照最终配置核实，避免同时在界面和覆写中写出相反值。

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

stack 选择网络栈实现，不能简单按名称判断性能。不同系统对相关实现的支持、协议处理和资源开销存在差异。若遇到特定应用异常，应先保持其他参数不变，仅切换客户端实际支持的网络栈做对照，并记录系统环境，不要同时调整路由、DNS 和 MTU。

理解 Fake-IP 的域名映射

Fake-IP 模式向应用返回一个映射地址，客户端在后续连接中根据该地址恢复域名并执行分流。示例中的地址段用于这一机制，不是目标网站的真实地址。它能减少单纯依赖目标 IP 判断域名的困难，但前提是 DNS 查询与后续连接进入同一套映射环境，映射链断开就可能导致连接失败。

应用长期缓存地址、休眠后恢复连接，或者切换客户端实例，都可能让旧映射失效。此时先重新解析并建立新连接，必要时清理应用和系统缓存。不要把旧的 Fake-IP 地址写入 hosts 或业务配置，也不要将其分享给其他设备作为服务器地址；地址离开对应映射表后没有预期的域名含义。

fake-ip-filter 用于让指定域名不走假地址返回，适合需要真实地址语义的部分局域网发现、内部服务或兼容性场景。过滤不是直连规则，域名拿到真实地址之后，连接仍会按规则决定出口。应针对已确认的问题逐项添加，而不是使用过宽的匹配让整个机制失去作用。

环境重点检查常见冲突来源
桌面系统服务权限、虚拟接口、默认路由其他 VPN、虚拟机网络
移动系统VPN 授权、后台运行状态同时占用 VPN 接口的应用
多网卡设备实际出口与接口识别有线、无线及隧道路由竞争

路由冲突与局域网访问

公司 VPN、容器网络、虚拟机和其他代理工具都可能改写路由。TUN 启动后若只有内部资源不可达，应先比较相关网段的路由归属，确认是否需要排除或保留原有路径。不要直接删除所有路由恢复联网，这可能中断管理连接，远程操作设备时尤其需要预留其他恢复方式。

开放“允许局域网连接”与启用 TUN 是两件事。前者通常影响代理监听是否接受其他设备访问，后者影响本机路由接管。需要为其他设备提供代理时，还要检查监听地址、防火墙和认证设置；仅在本机启用 TUN，并不会自动让整个局域网的流量经过客户端。

若接管后整体断网，按 TUN、系统 DNS、系统代理的顺序检查恢复状态，并确认客户端退出后是否清理接口和路由。先恢复基础网络，再重新测试单一接管方式。安装包和平台选择见下载页，优先选择 Clash Plus；具体功能支持仍需以所用客户端的实际设置为准。

域名嗅探与规则补充

域名嗅探尝试从连接早期的协议数据中识别主机名，补充仅有目标 IP 时缺失的信息。它与 DNS 提供的域名映射互为补充，但不能替代完整的解析与路由设计。启用前应先确认问题是否真的来自域名丢失：如果连接记录已经显示正确域名和命中规则，继续增加嗅探通常不会解决出口故障。

可以识别的信息与限制

HTTP 请求可能提供主机头，TLS 握手可能提供服务器名称，部分 QUIC 握手也能提供可用线索。这些信息是否出现，取决于协议、握手形式以及内核的支持。嗅探并不是解密 HTTPS 内容，无法因此读取完整的加密请求；名称信息受到保护或协议不支持时，客户端也不能凭空恢复域名。

一些应用直接连接固定地址，或者使用自己的解析流程，使连接没有经过客户端 DNS。在这类场景下，嗅探可能让域名规则重新获得匹配机会。但同一个地址可能承载多个服务，应用握手中的名称也未必等同于用户在界面输入的地址，因此需要根据实际连接记录确认结果，不能只凭网站是否打开作判断。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
      override-destination: false
  skip-domain:
    - "*.lan"
    - "*.local"

示例先限定 HTTP 与 TLS 的常见端口，并关闭目标覆写，适合观察识别效果。它不会自动覆盖所有自定义端口，也没有启用 QUIC 识别。若实际服务使用其他端口，应确认服务协议之后再扩展范围。端口只是筛选条件，不是协议真实性证明，在任意端口上强行尝试所有解析会增加不必要的干预。

识别域名与覆写目标分开验证

override-destination 控制是否根据识别出的域名覆写连接目标。关闭时更适合先观察域名识别与规则变化，开启后则可能改变后续解析和建立连接的方式。两种行为要分开测试：先确认识别结果可信，再评估是否确实需要改变目标，避免一次开启后无法区分是哪一步导致异常。

固定地址访问、内部反向代理和某些对目的地址有特殊要求的应用，可能不适合目标覆写。原本指定某台服务器的连接，如果根据握手域名重新解析，可能转向另一台服务器。出现登录异常或服务响应变化时，应比较原始地址、识别域名与最终连接目标，而不只是观察是否命中了预期策略组。

skip-domain 可以排除不希望参与嗅探处理的域名。先从明确的内部服务和已知兼容性例外开始，不应复制无法解释用途的大量排除列表。排除范围过大可能让原先希望解决的域名缺失继续存在；范围过小则可能让不需要干预的内部连接产生额外变化，关键仍是逐项验证。

与 DNS、应用加密解析协同排错

浏览器的加密 DNS 可能使客户端看不到常规查询，但不意味着嗅探一定能够恢复名称。若握手中的名称也被隐藏，客户端只剩 IP 与其他有限信息。此时需要明确选择：让应用使用可被客户端接管的解析路径，或接受基于地址的规则边界，而不是反复叠加无效的嗅探端口配置。

排错可以选一个域名固定、连接易于重建的服务。先关闭嗅探记录命中，再开启识别而不覆写目标，最后根据需要尝试覆写。每次都关闭旧连接，保持策略组选择不变，同时查看域名和最终出口。这样能够把名称识别、规则匹配和目标重建三类变化拆开，减少互相掩盖。

如果仅 UDP 服务异常，应另外核实节点是否支持所需传输、TUN 是否接管以及对应协议是否在嗅探范围内。浏览器还可能在 QUIC 失败后回退到 TCP，网页最终打开不代表两条路径都正常。不要通过全局拒绝所有 UDP 来证明规则正确，这会改变应用行为并掩盖原始问题。

嗅探配置应保持小范围、目的明确。确认 DNS 映射已经稳定后，可以只为确有需要的协议启用，并在记录中说明用途。若开启后看不到可重复的改善，恢复较简单的配置更便于维护。关于规则模式、连接日志与常见故障，可结合FAQ 对照检查，而不必让嗅探承担所有分流职责。

本地覆写与多订阅合并

订阅负责远程提供的内容，本地覆写负责设备与个人需求，两者应分开保存。直接修改下载得到的订阅文件，可能在下次更新时被覆盖；把所有设置都交给订阅，又容易让端口、DNS 或接管方式随远程内容变化。稳定的做法是明确哪些字段由远程维护，哪些字段始终由本地配置接管。

先确认客户端的合并语义

不同客户端可能提供合并配置、覆写文件、规则补丁或脚本处理，名称相近但行为并不一致。尤其是数组字段，有的实现会整体替换，有的支持追加或前置。使用前必须了解执行顺序和适用范围，不应把某个客户端的补丁语法直接当作通用 mihomo YAML，也不要同时启用两套不清楚顺序的覆写方式。

可以先用低风险字段验证，例如改变日志级别，加载后打开最终配置确认值是否变化；随后再测试规则前置和列表替换。界面里保存成功，只能说明输入被接收，不能说明最终内容按预期合并。真正需要核对的是交给内核的有效配置，以及内核是否接受并加载了这些字段。

建议把本地维护内容分成设备层和业务层。设备层保存监听端口、DNS、TUN 与控制接口，业务层保存稳定组名、规则顺序和本地例外。这样迁移设备时能够单独调整网络参数，而不必重写全部业务规则。涉及脚本的覆写还应先阅读脚本行为，因为它可能直接重建整份配置。

多订阅优先拆成节点提供器

合并两份完整订阅时，常见冲突不在节点本身，而在同名策略组、重复规则以及互不兼容的 DNS 设置。若需求只是同时使用两组节点，更清晰的方式是让每个来源提供独立节点文件，再由本地配置统一组织策略组。下面以本地文件示意结构，文件必须包含节点提供器可读取的 proxies 列表。

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - access-a
      - access-b
    proxies:
      - DIRECT

完整订阅通常还包含策略组和规则，不能仅把文件改名就认定它是规范的节点提供器。需要确认文件结构与读取方式相容，或使用客户端明确支持的转换能力。若使用远程提供器，应填写真实订阅地址、分开缓存路径，并注意订阅地址可能带有访问凭据，不应贴进公开文档或排错截图。

名称冲突与规则保序

两个来源可能使用相同节点名称，导致选择项难以区分或引用结果不明确。优先在导入或预处理阶段增加稳定的来源前缀，确认客户端支持的重命名方式后再应用。不要只按节点显示名称推断地区或用途，来源标记用于区分维护边界，实际可达性仍应通过正常连接验证。

规则合并需要保留顺序语义。个人精确例外通常前置，订阅通用分类位于中间，兜底规则只保留一个并放在末尾。单纯把两份规则数组首尾拼接，第一份中的 MATCH 会遮住第二份全部内容。若客户端默认追加规则，应特别确认是否有前置能力，不能仅看到条目存在就认为已经生效。

策略组也要检查引用闭环。合并后保留两个同名业务组，或者重命名组却没有同步规则出口，都会产生加载错误或意外选择。最小验证顺序是先加载提供器，再建立统一策略组，最后加入规则。每一步都查看日志，避免把节点读取失败与规则引用失败同时带到最终配置中。

备份、更新与回滚

备份至少包含本地覆写、主配置、规则文件与提供器的组织说明，敏感订阅地址应单独保管。只备份客户端截图不足以恢复引用关系；只备份更新后的有效配置，也可能丢失原来的覆写逻辑。每次较大修改前，保留可连接状态和对应说明，便于判断回滚需要恢复哪些层。

测试订阅更新时，应检查本地例外是否仍在、规则顺序是否改变、当前选择是否指向已移除节点。出现异常先停用最新补丁并加载备份，而不是在失败配置上连续修补。Profile 的切换与订阅更新区别见多配置管理笔记；基础导入流程仍以使用指南 为主。

外部控制面板与配置验证流程

外部控制接口用于读取运行状态、切换策略组和执行部分管理操作，控制面板是它的可视化入口。面板本身不提供代理出口，也不能代替内核。连接面板失败与代理连接失败属于不同层次：客户端仍可能正常转发流量，但管理接口没有监听、认证不匹配或被浏览器的安全策略阻止。

本机监听与本地面板文件

仅在本机管理时，应把 external-controller 绑定到回环地址。external-ui 指向本地面板资源目录，目录内需要实际存在对应静态文件，写一个目录名不会自动生成面板。下面演示监听和资源路径，启用前应在本地另行设置控制接口的认证密钥，不要复制公开示例值作为长期凭据。

external-controller: 127.0.0.1:9090
external-ui: ./ui

认证字段为顶层 secret，应使用独立的随机长字符串，并与面板连接设置保持一致。该密钥用于控制接口认证，不是节点密码或订阅地址，三者不应混用。把密钥放进公开截图、分享链接或公开配置，同样会扩大管理权限的暴露范围，排错前应先移除敏感信息。

把监听地址改为所有接口，会让其他网络设备有机会访问管理接口，不应仅为方便而直接开放。确有远程管理需求时，应通过受控网络、访问限制和适当的加密通道保护连接，并检查系统防火墙。配置了认证并不意味着可以忽略网络隔离，管理接口可以修改运行行为，应按管理权限对待。

分开检查网络、认证与浏览器限制

面板无法连接时，先确认当前内核进程确实加载了控制接口配置，再核对地址和端口。浏览器看到的本机地址属于浏览器所在设备；在另一台设备打开面板时，回环地址不会指向运行内核的主机。不要为解决这个理解偏差就直接扩大监听范围，应先确定是否真的需要跨设备管理。

本机无认证检查阶段可以用下面的命令观察接口是否响应；若已经设置密钥，需要使用带相应认证的请求，不能据此要求删除认证。连接被拒绝通常指向没有监听或地址错误，认证错误通常说明接口已可达但凭据不匹配。两类现象应分别处理，重复修改代理节点不会改变结果。

curl --fail --silent --show-error http://127.0.0.1:9090/version

远程 HTTPS 页面请求本机 HTTP 接口时，可能受到混合内容、跨源或本地网络访问限制。面板空白也可能只是静态文件路径错误。优先使用客户端内置面板或可信的本地面板，逐项检查浏览器控制台信息；不要把允许任意来源访问当作通用修复，也不要为了连接面板关闭所有浏览器保护。

配置加载前后的两次检查

第一次检查发生在加载之前：确认 YAML 缩进、字段类型、引用名称与文件路径。可在具备 mihomo 命令的环境中执行测试，配置包含本地提供器时还要确保相关文件已经就位。测试能发现语法和部分引用问题，但不能证明远端节点可达、系统授权完成或所有业务规则都符合预期。

mihomo -t -f ./config.yaml

第二次检查发生在加载之后：先看启动日志，确认接口、提供器和规则集均正常，再建立一条可重复的测试连接，查看域名、命中规则、策略链和最终出口。随后分别验证需要直连和需要代理的服务。只看到面板显示运行中，不能替代这条从配置到实际连接的完整检查链。

面板中的临时切换未必会写回订阅或本地覆写。需要长期保存的选择，应确认客户端持久化机制；需要长期保存的规则，则应进入可维护的配置层。不要把运行时修改当作唯一备份，否则重启、更新或切换 Profile 后，原本在面板中调整的状态可能不再存在，造成配置似乎自行变化的误解。

一次只改变一个故障变量

建议按配置解析、文件加载、DNS、出口、规则、系统接管的顺序排查。每次只修改一层，记录观察结果，再决定下一步。若问题紧随某次更新出现，优先恢复最近可用配置确认关联，而不是同时打开嗅探、更换网络栈和重写 DNS。较少的变量通常比更多参数更有助于定位。

发生启动闪退时，先保留报错并停止反复自动重启，参照日志定位与配置回滚步骤处理。能够启动但单项功能异常时，再结合本手册对应章节查阅。完成调整后保存最终配置与用途说明，下一次订阅更新或设备迁移才能沿用相同的验证路径。