mihomo 进阶配置

策略组类型与实战

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

规则决定一条连接交给哪个目标，策略组再决定这个目标最终使用哪个出口。规则中的名称必须精确对应代理、策略组或内置策略，大小写与空格也属于名称的一部分。建议先确定稳定的业务组名，再让订阅更新只影响组内成员。这样即使代理条目发生变化，规则仍然可以指向同一业务组，不必同步重写所有规则。

select 适合人工确定出口。它不会因为某个成员暂时不可用，就自动切换到另一个成员。客户端面板中的选择通常可以持久化，但是否保留还取决于配置名称与客户端实现。排查时不要只看组名，应展开到实际代理，确认当前选中的成员，并观察新连接使用的完整策略链；已经建立的长连接通常不会立即迁移。

按目标选择自动策略

url-test 根据探测结果选择成员，适用于可以接受出口变化的流量。探测测量的是访问指定地址的结果，不代表所有网站或全部协议的体验。一个成员对测试地址表现较好，也可能对特定业务受限。tolerance 可以减少小幅差异引起的频繁切换，但它不是固定出口的保证；需要保持会话身份的业务，应使用单独的手动组。

fallback 更强调成员顺序：在健康检查判断可用的成员里，优先使用排在前面的出口。它适合主用与备用有明确先后关系的场景，而不是追求每次选择最低探测耗时。load-balance 则把连接分配给多个成员，不会把一条下载连接合成为多个出口的总带宽。登录、支付或有来源地址约束的服务，不宜直接套用轮换策略。

用两层结构隔离日常选择与自动探测

实用结构是外层手动组、内层自动组。外层提供自动选择、固定代理和直连等入口，内层只容纳需要被测试的代理成员。不要把外层组重新放回内层，否则会形成循环引用。层数也不宜过多：从规则目标向下展开，两三步能够找到实际出口，通常比难以追踪的多层嵌套更容易维护。

下面示例只引用内置的 DIRECT，可以用于理解组间引用，不代表已经具备远程代理出口。实际使用时，在自动组的成员列表中加入现有配置里真实存在的代理名称，再按需要保留或移除直连入口。测试地址使用 HTTPS，探测间隔以秒计；是否能访问测试地址本身，也会影响健康检查结果。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

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

如果代理来自 proxy-providers，策略组可以通过 use 引用提供者，避免复制一长串成员名称。先确认提供者能够成功加载，再检查组是否包含预期成员。过滤表达式应从宽到严逐步添加；表达式写得过窄时，订阅本身虽然成功更新，策略组仍可能没有可用成员。此时继续调整探测参数并不能解决成员为空的问题。

验证策略组时，先在面板中查看组类型、候选成员与当前选择，再发起一条新的业务连接。日志中出现探测成功，只能说明健康检查链路成立，不能代替业务验证。若切组后页面没有变化，可以关闭该应用的旧连接或重新打开应用再测试，不必立即重启所有网络服务。模式选择的基础区别见代理模式说明。

规则集订阅化管理

规则负责顺序，规则集负责内容

rules 是执行顺序，rule-providers 是可复用的匹配内容。把大量域名移到规则集后，主配置仍需通过 RULE-SET 引用它，并指定命中后的策略。规则集不会因为被声明就自动参与分流。内核通常从上到下检查规则，首个命中项生效，因此本地例外、业务规则与最终兜底之间的顺序，比文件拆成多少份更重要。

建议先建立少量语义明确的集合，例如开发服务、局域网地址与需要特殊出口的业务。不要为了分类完整，把同一批域名在多个集合里重复维护。重叠无法完全避免时，应在主规则中明确谁优先，并记录原因。新增一条例外应能回答三个问题：匹配什么、交给哪个策略、为什么放在当前位置；回答不清楚时，后续更新很难判断能否删除。

让 behavior 与文件内容保持一致

behavior: domain 用于域名条目，ipcidr 用于地址网段，classical 则容纳带规则类型的经典规则内容。三者不是可随意互换的标签。域名集合中放入整条 DOMAIN-SUFFIX 语法，或经典集合中只写裸域名，都可能导致加载失败或匹配结果偏离预期。先查看文件格式，再选择行为类型，而不是根据文件名猜测。

format 同样需要与实际数据对应。YAML 规则集通常使用 payload 数组；文本格式按行读取；二进制规则集有自己的生成要求，不能只修改扩展名得到。相同的域名来源若提供多种格式，应选内核明确支持的一种，并让路径扩展名反映真实内容。加载日志中的解析错误，比浏览器能否打开下载地址更能说明问题。

# 合并到主配置；rules 的位置需要结合现有规则调整
rule-providers:
  development:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/development.yaml

rules:
  - RULE-SET,development,PROXY
  - MATCH,DIRECT

# 保存为内核配置工作目录下的 rules/development.yaml
payload:
  - '+.github.com'
  - '+.githubusercontent.com'

从本地验证过渡到远程更新

上例假设已有名为 PROXY 的策略。相对路径通常以内核工作目录为基准，不一定是编辑器当前打开文件的目录。先用本地文件确认行为类型与匹配关系，再切换远程订阅，可以把格式问题和网络问题分开。测试时选择规则集内的一个域名建立新连接，在连接详情中确认命中了对应的规则集，而不是恰好落到相同出口的兜底规则。

远程来源使用 type: http，并设置来源地址、缓存路径和更新间隔。地址应由维护者实际提供，不能把网页展示页当作原始规则文件。更新频率应与来源变化速度匹配；对几天才变化的列表频繁拉取，通常只会增加请求与排错噪声。涉及账户信息的地址应只保存在本地配置，不放进公开截图、共享仓库或故障反馈正文。

规则更新失败时，先分清下载失败、内容解析失败与引用错误。下载失败要检查来源可达性和用于下载的出站路径；解析失败应检查响应是否变成网页、错误提示或另一种格式；引用错误则检查提供者名称与 RULE-SET 名称是否一致。已有缓存可能让流量暂时继续工作，但不能据此认定更新正常，应同时查看更新时间与加载日志。

域名规则尽量放在需要解析目标地址的地理或网段规则之前。对明确不希望触发额外解析的地址规则，可以按语法使用 no-resolve，但它不是所有规则的通用后缀。已经持有真实地址的连接仍能参加地址匹配；只有域名且没有真实解析结果的连接，则可能跳过相关判断。调整这类参数前，应确认希望省去的是哪一次解析。

维护时保留一份经过验证的本地例外集合，把订阅内容视为外部输入，而不是覆盖全部个人规则的唯一来源。更新后先测试几条具有代表性的连接，再逐步扩大使用范围。发现错误分流时，记录命中规则与目标策略，再决定修改集合还是调整顺序。直接把 MATCH 改成另一出口，可能掩盖问题，却会同时改变大量原本正常的连接。

DNS 配置优化

按解析对象拆开链路

DNS 优化首先是区分谁在查询、查询什么、请求从哪里发出。应用可能使用系统解析器，也可能自行发起加密 DNS；内核还需要解析代理服务器的域名。三种请求即使都访问同一个上游，也不代表经过相同的处理路径。排查时先画出应用到内核、内核到上游、内核到代理服务器的关系，再修改字段，能够避免把引导解析与业务解析混在一起。

default-nameserver 主要用于解析 DNS 上游自身的域名，为加密解析建立起点。nameserver 是常规查询使用的上游，proxy-server-nameserver 可以为代理服务器域名指定解析器。后者尤其适合处理代理尚未建立时的启动依赖。如果解析代理域名的请求也必须经过该代理，就可能形成循环，表现为配置已加载却始终无法建立出站连接。

先建立可解释的最小 DNS 配置

下面片段展示一个本机监听、使用 Fake-IP 的基本结构。普通 UDP 上游和 HTTPS 上游的网络路径不同，前者也不提供传输加密；这里用于展示引导层与业务层的分工，并非适合所有网络的固定答案。先确认所选解析器在当前网络可访问，再考虑加密方式、策略路由与备用机制。上游地址越多，并不意味着结果越稳定。

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:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

把 DNS 监听在 127.0.0.1:1053，只表示内核提供了本地解析服务，不表示系统会自动使用它。普通系统 DNS 设置通常不能填写任意端口，需要客户端的 DNS 接管、TUN 劫持或其他明确的转发路径。若系统仍访问原有解析器，修改 nameserver 后看不到变化并不意外。应先确认查询确实进入内核，再比较上游结果。

按域名选择解析器，谨慎叠加备用逻辑

nameserver-policy 用于按域名等条件指定解析器，适合企业内部域名、家庭设备域名或有明确解析需求的业务。内部域名应交给能够返回内部地址的解析器，而不是发送到公共服务。域名策略解决的是使用哪个解析器，不等同于最终连接使用哪个出口。查询得到正确地址之后，连接仍然要经过规则与策略组，两个阶段都应分别验证。

fallback 不能简单理解成主解析器超时后才使用的第二地址。它与 fallback-filter 一起参与结果判断，可能产生额外查询。配置了不适合当前网络的过滤条件，反而会把可用结果替换成另一条不合适的结果。只有能够说明哪些响应需要被替换时，再加入这一层；否则先用少量可靠上游建立基线，更容易判断故障来源。

启用 respect-rules 后，DNS 上游连接可以遵循路由规则，但同时必须处理好代理服务器域名解析等启动依赖。不要把所有 DNS 请求强行导向一个尚未可用的代理组。测试时分别记录上游连接的出口和业务连接的出口：它们可以不同，也常常应该不同。涉及该字段与备用解析的更细分说明，可参考DNS 字段拆解。

加密 DNS 失败应分支排查。若报名称解析失败，先检查引导解析；若已得到地址但握手失败，检查系统时间、证书信任与连接路径；若上游连接成功但返回异常，检查域名策略与服务响应。不要通过关闭证书验证来掩盖网络或时间错误，也不要在没有证据时连续替换多个上游。每次只更改一个变量，保留可复现的查询对象。

缓存会让修改后的结果暂时不明显。系统、浏览器与内核都可能保存解析结果，应用还可能复用旧连接。验证前先停止目标应用的旧连接，按客户端提供的入口清理相关缓存，再重新查询。命令行直接询问本地监听器与浏览器打开网页，验证的是不同路径；两者结果不同，应先检查浏览器是否启用了独立解析，而不是认定内核配置没有生效。

最后检查地址族。禁用 DNS 返回 IPv6，不等于整个系统的 IPv6 通信被关闭；应用仍可能使用缓存地址或自行解析。反过来，允许返回 IPv6 也要求实际网络具备可用路径。出现部分站点等待后才打开时，分别观察 IPv4 与 IPv6 连接结果，再决定调整哪一层。DNS 配置的目标是得到适合当前路径的结果，而不是追求字段尽可能齐全。

TUN 接管与 Fake-IP 映射

Fake-IP 负责关联域名，不是远程出口

Fake-IP 模式下，内核可以向应用返回映射地址，并保存该地址与域名的关联。应用连接映射地址时，内核恢复域名，再执行路由和出站处理。映射地址不是目标服务器的公网地址，也不是代理服务器地址。看到 198.18.0.0/16 范围的结果，不应直接认定解析错误；需要结合连接是否被内核接住，以及是否恢复出预期域名来判断。

Fake-IP 与 TUN 是两个维度。前者处理解析与域名关联，后者通过虚拟网络接口接收流量；两者常一起使用，但并不互相替代。只开启 Fake-IP，不能让所有应用自动经过代理；只开启 TUN，也不保证每条连接都有域名信息。应把解析入口、虚拟接口与规则处理串起来验证，而不是把某个开关视为完整的网络接管方案。

按权限、路由与解析顺序启用 TUN

TUN 往往需要管理员权限、服务组件或系统授权。Clash Plus、Clash Verge Rev 与 FlClash 等客户端的入口和权限处理方式不同，应先按当前客户端说明安装必要组件。配置文件中的 enable: true 只是内核请求，系统拒绝创建接口或添加路由时仍然无法接管。查看日志中接口与路由的创建结果，比反复点击开关更有效。

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

此片段需要与已启用的 dns 配置配合。auto-route 请求内核设置相关路由，auto-detect-interface 帮助识别出站接口，dns-hijack 把匹配的普通 DNS 流量交给内核处理。它不会自动接管所有 HTTPS 加密解析；应用自带的加密 DNS 仍需单独分析。不同平台和网络栈的实际支持范围，应以运行日志和当前内核文档为准。

system、gvisor 与 mixed 是网络栈选择，不是质量排名。它们在协议处理、系统集成与兼容性上的取舍不同。出现特定应用异常时，可以在保留其他设置不变的前提下切换网络栈进行对照，但不要同时修改 DNS、路由与 MTU。只有一个变量变化，才能判断改善究竟来自网络栈还是另一项设置。

处理局域网、VPN 与映射例外

局域网设备通常要求直接访问真实地址，例如打印机、投屏设备和内部管理页面。fake-ip-filter 可以让匹配域名不领取映射地址，但不等于对应连接自动直连。还需要让解析器能够返回正确的内部地址，并通过规则指定合适的出口。只增加过滤而没有正确的内部 DNS，常见结果是映射地址消失了，设备仍然无法访问。

企业 VPN、虚拟机、容器和其他代理软件都可能安装路由。并行启用前先记录各自网段，尤其检查是否与 Fake-IP 地址段重叠。自动识别接口也可能在多网卡环境选到不合适的出口。此时应依据真实接口与路由调整，而不是复制其他设备的接口名称。对企业内部网络作修改前，还应遵守设备管理要求，避免破坏原有访问边界。

某些程序会把解析地址用于协议校验、局域网发现或地址展示，无法接受映射结果。处理这类兼容性问题应缩小范围：先确认异常域名，再添加必要过滤，并复测正常域名是否仍按预期映射。把所有域名加入过滤虽然看似简单，却会改变整套域名恢复机制，导致原来可以通过域名匹配的连接转而依赖真实地址与嗅探。

验证顺序建议为：先确认不开 TUN 时系统代理可用，再启用 TUN，检查接口与路由，然后确认 DNS 请求进入内核，最后测试不遵循系统代理的应用。出现故障时沿相反顺序回退。不要把浏览器访问成功当成全系统接管成功，因为浏览器可能仍然使用系统代理；也不要把一条映射地址的查询结果当作全部流量已进入内核的证据。

域名嗅探与规则补充

嗅探补足信息，不代替 DNS

连接进入内核时，可能只有目的地址，没有可用域名。例如应用使用自己的解析器、连接来自透明接管，或程序直接使用缓存地址。域名嗅探尝试从部分协议的初始数据中提取主机信息，使内核有机会按域名执行规则。它适合补充缺失信息，但不是对任意流量都有效的域名识别器，也不意味着能够读取加密连接的全部内容。

HTTP 可以携带主机字段，TLS 握手在条件允许时可能提供服务器名称，QUIC 则需要内核对相关握手内容进行识别。若客户端隐藏服务器名称、使用内核不支持的协议，或数据不足以完成识别，嗅探就可能得不到结果。此时应允许规则回到地址或兜底路径，而不是把嗅探失败理解为代理出口不可用。协议本身没有暴露的信息，增加端口范围也无法凭空得到。

从受控端口范围开始

下面片段开启 HTTP、TLS 与 QUIC 的常见业务端口，并关闭根据嗅探域名改写目的地址的行为。它适合先观察识别结果，再决定是否需要进一步接管目标解析。合并时检查客户端是否已经生成 sniffer 字段，避免同名顶层键重复。先只测试一两个明确的网页请求，确认日志中域名来源的变化，再扩大应用范围。

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 允许对纯地址连接尝试识别，能够帮助处理部分缺少域名关联的流量，但不能保证识别成功。force-dns-mapping 涉及在相应 DNS 映射场景下继续尝试嗅探，不能代替 DNS 监听与转发配置。不要仅凭字段名称把它理解成强制所有应用采用内核 DNS；请求是否进入解析模块，仍取决于实际网络路径。

override-destination 是需要单独评估的行为。启用后，内核可以依据嗅探到的域名改变后续目标处理，而不只是补充匹配信息。对于使用特殊解析、固定地址或依赖特定入口的应用，这可能改变原来的连接路径。先保持关闭可以减少变量；只有确认业务需要，并理解重新解析与路由影响之后，再按域名或协议范围谨慎调整。

对照域名来源，判断是否真的需要嗅探

测试时先关闭目标应用的旧连接，再建立新连接，观察连接详情中的域名、目的地址和命中规则。已有连接不会因为打开嗅探开关而重新执行完整握手。若连接本来已经通过 Fake-IP 恢复域名，开启嗅探前后规则相同是正常现象；这种情况下，额外嗅探的收益可能很小，没有必要为了字段齐全强行启用全部选项。

如果启用后特定业务异常，应先对该业务做关闭嗅探的对照，而不是更换整个 DNS 配置。可以利用内核支持的跳过域名等范围设置缩小处理对象，但例外应对应真实观察到的域名，不要从其他配置整段复制。过宽的强制范围会让更多流量等待协议识别，过宽的跳过范围则可能让本来需要域名规则的连接回到地址分流。

端口并不能唯一确定协议。某些应用在常见网页端口上运行自定义协议，也有服务在非标准端口提供 TLS。限制端口有助于控制处理范围，却不保证范围内的每条连接都可识别。对自定义服务，应先确认实际协议，再决定是否纳入；把所有端口全部加入通常只会扩大排查面，不能解决握手内容被隐藏或识别尚未支持的问题。

QUIC 常与 UDP 相关，部分应用也会在条件不满足时回退到 TCP。测试时如果只看网页能否打开，可能忽略协议已经发生变化。应结合连接记录确认使用了哪种传输，再比较嗅探结果与规则命中。不要为了得到整齐的日志而直接阻断全部 UDP；语音、实时通信与部分应用可能依赖它，处理方式应围绕具体业务，而不是围绕日志外观。

嗅探结果还涉及隐私与调试边界。它提取到的域名可能出现在连接记录或调试日志中，截图与反馈前应检查是否包含内部服务名称。普通故障通常只需要提供规则类型、策略链与匿名化的目标特征，不必上传完整访问历史。更广泛的日志也不会自动让问题更容易定位，清楚记录开启前后的差异，往往比堆积数据更有用。

本地覆写与多订阅合并

以最终运行配置为准

图形客户端常把订阅内容、全局设置与本地覆写合并后交给内核。编辑界面显示的是输入，运行配置才是结果。相同的 DNS 字段可能同时出现在订阅与客户端设置中，最终采用哪一份由合并顺序决定。排查前先找到客户端提供的运行配置预览或导出入口，确认内核实际收到的内容，避免在一个随后会被覆盖的文件里反复修改。

建议按职责拆分：订阅提供代理及必要的提供者信息，本地维护业务组、规则优先级、DNS 与设备相关设置。设备相关字段包括监听地址、端口、TUN 和控制器，它们不适合在不同系统之间原样同步。同步之前应区分可复用的业务意图与只属于当前设备的环境参数；文件能够成功导入，不代表路由和权限在另一设备上同样成立。

不要假设所有合并器遵循相同规则

映射、数组与标量在不同客户端中可能采用不同的合并策略。映射可能逐层合并，也可能整段替换；数组可能追加、前置或覆盖。内核本身不会替客户端统一这些行为。尤其是 rules 数组，如果本地例外被追加到原配置的 MATCH 后面，就永远不会生效。必须查看最终顺序，不能仅依据界面上显示已经保存来判断成功。

下面是可交给覆写功能处理的局部意图示例：固定本机监听与规则模式，并请求保存选择状态。它不是通用于所有客户端的覆写文件格式；应把这些字段放到当前客户端支持的 YAML 合并入口。若入口要求脚本或专用结构，应遵守该入口的规则，不要把 YAML 粘贴到脚本编辑器。profile 的效果也应通过重启后的实际状态确认。

mixed-port: 7890
allow-lan: false
mode: rule

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

YAML 同一个映射里出现重复键属于应当消除的问题。某些解析器报错，另一些可能保留后一份值，不能依赖这种差异实现覆盖。字段缩进使用空格，字符串中含有可能被解释成特殊语法的内容时应加引号。修改后先做语法测试，再加载到运行环境。能够被 YAML 解析只说明语法成立，策略引用、文件路径与规则行为仍需另外验证。

多订阅先隔离来源，再处理名称与引用

多个来源可能出现同名代理、同名策略组与同名提供者。直接拼接会导致冲突，或让规则引用到并非预期的对象。更稳妥的方式是为来源建立清晰的提供者命名空间，再由本地策略组通过 use 选择成员。确实需要重命名代理时，应同步更新所有引用；只改列表里的显示名，而不改组内引用，会留下启动错误或空成员。

多来源合并也不应复制多份完整 DNS 和规则段。先指定哪一份拥有最终决策权，再把其他来源当作代理数据输入。若某个订阅带有必须保留的专用规则，应单独审查并放到明确位置，而不是让其覆盖本地全部策略。来源越多，越需要明确删除与停用方式：停用某个提供者后，所有引用它的组是否仍能工作，应当能够预先判断。

终端环境下，可以在部署前使用内核的配置测试功能。命令中的目录必须替换为实际的配置工作目录；下面命令适用于当前目录已存放配置和依赖文件的情况。测试不会替代真实网络访问，但能提前发现字段、引用或文件加载等问题。图形客户端若内置配置检查入口，也应先检查，再执行重载，避免把尚未验证的配置直接作为启动默认项。

mihomo -t -d . -f ./config.yaml

订阅自动更新后，应抽查最终配置中的监听端口、规则前几项、最后兜底和关键组成员。这些位置最容易暴露覆盖关系变化。若更新后异常，先回退到上一份有效输入，再比较生成结果；不要立即把自动更新完全关闭后长期搁置。保留可解释的变更记录，例如新增哪个域名例外、调整哪个组的成员来源，后续排错会更有依据。

跨设备同步时，只同步明确需要的文件，并排除日志、缓存与设备生成的临时配置。订阅地址和代理凭据属于敏感信息，不适合放入公开仓库。详细方案可参阅多设备配置同步。出现端口冲突时，除了修改本地覆写，还要同步调整系统代理和应用设置，具体定位步骤见端口占用排查。

外部控制面板与验证流程

控制端口与代理端口分开理解

external-controller 提供内核管理接口，供面板查看状态、切换策略或执行相关管理操作。它不负责代替 mixed-port 接收普通代理流量。浏览器代理设置中应填写代理监听端口，面板连接设置中才填写控制器地址。把两个端口混用，常见结果是浏览器无法访问网络，或面板显示连接失败，但内核本身仍在运行。

控制接口能够影响实际网络行为，应优先限制在本机回环地址。下面配置展示本机控制入口与本地面板目录，适用于只在本机使用的基础场景。面板文件需提前存放到内核工作目录下的 ui 目录，内核不会凭这个路径自动生成网页。若客户端已经内置控制器与面板管理，应优先使用其入口，避免手工创建重复监听。

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

回环监听限制了远程访问，但不等于完成所有安全设置。本机其他进程仍可能接触这个端口。应根据客户端支持方式为控制器设置独立的 secret，并在面板连接设置中填写同一值。不要把实际密钥写进公开文件或示例，不把包含认证信息的面板链接发给他人，也不要使用代理账户密码作为控制器密钥。修改后重新连接面板，确认旧认证不再有效。

先验证接口，再验证浏览器面板

面板打不开时，先确认内核是否运行、控制端口是否监听，再检查静态网页目录。没有启用认证的本机基础环境，可以用下面命令查看配置接口是否响应；已经启用认证时，应通过客户端的受支持入口或在本机请求中提供认证，不要为了测试而临时把控制器暴露到所有网卡。响应被拒绝与根本连不上端口，属于两个不同分支。

curl --noproxy '*' http://127.0.0.1:9090/configs

接口可访问而面板不可用时，应检查面板保存的控制器地址、认证信息与浏览器报错。使用 HTTPS 打开的网页连接本机 HTTP 接口，可能遇到混合内容或浏览器本地网络访问限制；跨来源访问还可能涉及控制器的来源策略。不要直接允许所有来源作为通用修复，而应优先使用客户端内置面板或同源本地页面，并按实际需要限制允许的来源。

远程管理时，不应仅把监听地址改为所有网卡就结束配置。需要同时设计认证、网络访问范围、加密传输与防火墙规则。能够通过受控的本机转发或管理网络完成操作时，通常不必把控制接口直接开放到公共网络。面板页面本身能打开，也不代表管理连接受到了保护；页面与接口可能走不同的地址和传输方式，必须分别确认。

用连接记录形成验证闭环

面板最有价值的用途是追踪一条新连接的处理过程：来源应用、目标域名或地址、命中规则、策略链与最终出口。验证时先选定一个明确目标，再产生一次新的请求，避免在大量并发连接里凭印象判断。看到某个组名并不代表它直接就是出口，应继续展开组内选择。若规则命中正确但连接失败，下一步应检查实际代理和解析，而不是继续修改规则顺序。

面板显示的策略选择与配置文件里的默认成员也可能不同。启用选择持久化后，重载配置可能恢复之前的选择；修改组内顺序不一定会改变当前出口。排查时记录面板实际状态，再进行手动切换。配置重载也不意味着所有旧连接已被关闭，测试结论应以新连接为准。对需要连续工作的应用，应先评估主动关闭连接是否会中断任务。

建议按固定顺序完成一次完整检查：配置语法与引用能够通过测试；混合代理端口与控制端口正常监听；常规模式下能够建立连接；DNS 查询进入预期模块；规则命中正确；策略组能展开到实际出口；需要时再启用 TUN 与嗅探。每增加一个模块就保留一次结果，这样遇到回归时能够回到最近的有效节点，而不是同时推翻所有配置。

故障记录应简洁而完整，包含操作系统、客户端名称、是否使用 TUN、异常目标类型、命中规则和关键错误信息。不要公开完整订阅、认证信息或全部访问记录。基础问题可继续查阅常见问题；如果表现为已连接却无法打开网页，可按逐项排查清单从系统代理走到 DNS 与防火墙。配置的可维护性，最终体现在能够解释一条连接为何这样处理，并能够在失败时明确回退到哪一步。