Clash 进阶配置
策略组、DNS 与 TUN

策略与出口

策略组类型与实战

策略组是规则与代理节点之间的中间层。规则回答连接应交给哪个出口，策略组决定该出口当前使用哪个节点。把规则直接绑定单个节点，节点改名后就要修改多条规则；改为绑定稳定的组名，订阅内容可以更新，规则仍然有效。设计时先列出业务出口，例如手动代理、自动选择与默认兜底，再决定组内候选，不要先堆叠大量地区分组。

按选择机制区分组类型

select 保存手动选择，适合需要明确控制出口的业务。url-test 周期性探测候选，依据探测结果选择节点；它测到的是指定地址的可达性与响应情况，不代表所有网站都更快。fallback 按配置顺序寻找可用候选，适合主备关系。load-balance 按策略分配不同连接，不能把单条下载连接的速度叠加成多个节点带宽。

嵌套组能减少重复配置，但每增加一层都会增加排查成本。一个业务组指向手动组，手动组又指向自动组时，面板中看到的第一层名称不一定是最终节点。排错应继续展开选择链，确认最终出站。对登录敏感、会话较长的业务，优先保持稳定出口；自动切换可能使新连接使用另一地址，旧连接则继续留在原节点，形成短时并存。

用节点提供器隔离订阅变化

下面片段假定本地节点提供器文件已经存在，内容含顶层 proxies 列表。文件路径相对于内核工作目录，而非浏览器下载目录。自动组通过 use 引用提供器，外层代理组只引用自动组与内置直连出口。实际使用时，把已有订阅的节点导出到该文件，或由客户端支持的订阅管理功能生成对应提供器，不能把普通网页存成 YAML 后直接引用。

proxy-providers:
  本地节点:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - 本地节点
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: 代理
    type: select
    proxies:
      - 自动选择
      - DIRECT

interval 的单位是秒，tolerance 表示切换容差，避免候选响应差距很小时频繁变化。lazy 可减少未被使用时的探测。不要把间隔压得很短来制造“实时最优”的感觉，频繁探测会增加请求和移动设备耗电。若所有候选都探测失败，先验证测试地址能否经这些节点访问，再检查节点本身，不能仅据面板结果认定全部订阅失效。

过滤、命名与验证顺序

使用 filter 筛选提供器节点时，它通常按正则表达式匹配名称，不会自动理解地理位置。订阅改名、符号变动或大小写差异都可能让筛选结果变空。先在面板查看提供器是否已有节点，再验证过滤表达式，最后检查策略组是否出现候选。组名需要与规则中的目标逐字一致，特别注意全角空格、相似标点与手工复制产生的不可见字符。

验证时先选择一个明确可用的节点，再用规则模式访问目标站点。在连接详情中核对命中规则、策略组和最终节点，而不是只看客户端总开关。若手动选择正常、自动组异常，问题多在探测地址、过滤条件或自动选择机制；若所有组都失败，再回到订阅与网络链路。订阅拉取和解析问题可继续阅读订阅更新失败自查，避免把导入问题误当成分流问题。

规则与维护

规则集订阅化管理

规则集把域名、网段或完整规则从主配置拆出，主文件只保留引用关系与匹配顺序。它解决的是维护规模，不会改变首条命中即决定出口的基本原则。一个规则集即使包含大量条目，如果前面已有更宽泛的规则命中，也不会得到执行。规划时先写局域网与明确例外，再放业务规则集、地理规则和最终兜底，避免用大量重复规则弥补顺序错误。

先确定内容语义，再选择格式

behavior 说明规则集内容的语义。domain 用于域名集合，ipcidr 用于地址段集合，classical 可以容纳带规则类型的条目。它与文件扩展名不是同一回事：一个叫 YAML 的文件，也可能是节点订阅或完整配置。导入前打开源内容，检查顶层结构及每条记录，不能仅凭下载地址后缀判断兼容性。

格式与语义必须配套。YAML 规则集通常使用顶层 payload 数组；文本格式按行读取条目；MRS 是编译后的规则格式，支持范围与内核实现有关。若文件是 DOMAIN-SUFFIX,example.org 这种完整规则条目，应使用合适的 classical 语义，而非把它塞进纯域名列表。更换来源时应同时核对 behavior 与 format，不要只换 URL。

本地验证后再接入远程更新

建议先从本地文件开始验证。以下主配置引用两个本地规则集，业务域名 对应域名列表，本地网段 对应地址段列表。它们都必须在磁盘上真实存在。代理组 代理 需事先定义；no-resolve 用于避免地址类规则为匹配域名而额外发起解析，不代表所有情况下都跳过 DNS，也不会阻止后续规则按需要解析。

rule-providers:
  业务域名:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml
  本地网段:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,本地网段,DIRECT,no-resolve
  - RULE-SET,业务域名,代理
  - MATCH,代理

例如 business.yaml 可写为下面的结构。这里使用保留示例域名，只用于演示语法，不承担实际业务分流。把它替换为确有需要的域名后，先检查内核能否加载，再观察目标请求。域名规则不包含 URL 路径，不能写成带协议、端口与网页路径的完整地址；需要区分同域不同路径时，单纯域名分流无法表达这个条件。

payload:
  - "+.example.org"
  - "example.net"

切换为 HTTP 提供器时，补充可信来源的 url、本地缓存 path 与更新间隔 interval。缓存路径应各不相同，避免多个来源覆盖同一文件。更新间隔按规则变化频率设置，不必与节点测速间隔一致。下载失败后能否继续使用已有缓存，要看缓存是否有效及内核状态；部署到新设备前，应单独确认首次下载路径可达。

更新结果与匹配结果分开检查

提供器显示更新成功，只证明文件完成获取与解析，不证明目标请求一定命中。排错先检查规则集条目，再检查它在主规则链的位置，最后检查连接实际携带的是域名还是目标地址。浏览器缓存、已有长连接和应用内置解析都可能让测试结果与预期不同。改规则后关闭目标应用连接并重新请求，比反复重启整个客户端更容易保留可比较的日志。

维护多个来源时，应写清每个规则集的职责，保留少量可解释的本地例外。不要同时订阅几套覆盖相同业务的大集合，再靠顺序猜测谁生效。移除一个来源前，检查所有 RULE-SET 引用；合并来源时关注授权、更新稳定性与内容差异。规则命中不符合预期时，可先在目标域名前加一条临时精确规则验证出口，验证结束后删除，避免临时修复长期遮蔽原有逻辑。

解析路径

DNS 配置优化

DNS 配置至少涉及三个问题：谁接收应用查询、谁解析目标域名、代理服务器自身的域名如何得到地址。把这些路径全部交给同一个上游，看似简单，却可能造成依赖环。例如解析代理服务器必须先连接代理，而建立代理又需要先解析服务器名称。优化前先画出这三条路径，确认引导解析能够独立完成，再考虑加密上游、按域名分配解析器和缓存行为。

区分引导解析与业务解析

default-nameserver 主要承担解析 DNS 上游自身域名等引导用途，通常使用明确的 IP 地址。nameserver 是常规业务解析上游；nameserver-policy 为特定域名或规则指定解析路径；proxy-server-nameserver 则用于代理节点服务器域名。具体字段是否被客户端保留，要以生成后的运行配置为准，不能只看订阅编辑器里写了什么。

下面是用于理解字段分工的基础片段，采用明确的上游地址，避免在示例中引入额外的域名引导依赖。监听端口设为本机非标准端口，不等于系统已把 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:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

示例中的局域网解析器应改成当前网络真实可用的路由器或内网 DNS；如果没有内网域名需求，应删除对应策略。把公共解析器用于企业内部域名，往往只会得到不存在的结果。反过来，把全部公共域名交给只能解析内部记录的服务器，也会造成普遍失败。判断解析器是否适合某个域名，需要观察返回地址与连接路径，而不是仅凭查询是否返回记录。

fallback 不等于任意失败后的万能补救

fallback 配合 fallback-filter 决定某些情况下采用哪一组解析结果，它不是网络出口的主备策略组。过滤条件可涉及地理信息、地址范围或域名；条件过宽会让大量查询落到备用上游，条件过窄则可能继续采用不合适的结果。如果尚未理解选择条件，先用清晰的 nameserver-policy 划分必要域名，再考虑是否确有引入 fallback 的需求。

使用 respect-rules 让 DNS 上游连接遵循路由规则时，必须先处理代理服务器域名的独立解析，否则容易形成解析与代理互相等待的环。加密 DNS 只改变查询传输方式，不自动保证查询走代理，也不保证返回地址适合当前出口。若目标域名解析成功却连接超时，应检查结果是否对应正确网络，再检查策略和路由，不能继续无差别叠加上游地址。

按查询、返回与连接分层排错

排错先确认应用查询是否进入内核，再看内核是否向预期上游发起请求，最后对照目标连接使用的地址。可用系统提供的 DNS 查询工具指定本地监听地址和端口；工具不支持自定义端口时，不要把查询到系统解析器的结果误记为内核结果。测试内网域名、公共域名和代理节点域名各一例，通常比只反复刷新一个网页更容易定位断点。

修改 DNS 后，系统、浏览器与内核可能各自保留缓存。先关闭目标应用的既有连接，必要时按客户端能力清理 DNS 缓存，再发起新请求。出现 IPv6 地址但网络没有可用 IPv6 路径时，要区分 DNS 返回记录与真实路由能力；只切换一个 DNS 开关未必能覆盖全部应用。是否启用 IPv6 应同时检查系统路由、内核配置和节点支持，不要仅凭某个网站能打开就判断完整可用。

DNS 处理与规则分流之间存在先后依赖，但两者不是同一个设置。域名规则可以在保留域名信息时直接匹配，地址规则可能触发解析；no-resolve 又会限制这一步。记录一次请求的域名、返回地址、命中规则及出口，才能说明配置如何生效。更细的字段组合与 DNS 劫持边界，见DNS 参数与劫持配置说明。

流量接管

TUN 与 Fake-IP

系统代理依赖应用遵循操作系统代理设置，TUN 则通过虚拟网络接口接收被路由到内核的流量。两者解决的是流量如何进入客户端，不决定流量必须走代理。启用 TUN 后，规则模式仍然可以把局域网与指定业务直连；全局代理也不等于所有系统流量都已被接管。判断接管是否完整，应从目标应用的连接记录和路由表入手，而不是只看一个开关。

先满足权限和路由前提

桌面客户端通常需要服务组件、管理员权限或相应系统授权才能创建接口与路由。移动平台则由系统 VPN 接口提供接管能力，配置入口和桌面端不完全一致。首次启用前，记录原来的系统代理与 DNS 设置，暂停其他可能接管路由的 VPN，再操作客户端提供的 TUN 开关。不要同时手工运行另一个内核实例，否则端口、虚拟网卡和默认路由可能互相竞争。

以下是常见的 Mihomo 局部配置。auto-route 用于自动配置相关路由，auto-detect-interface 用于识别出站接口，dns-hijack 把匹配的传统 DNS 请求交给内核处理。该片段必须与启用的 DNS 模块配合使用。若客户端通过图形设置管理这些字段，应优先使用其设置入口，再检查最终配置，避免订阅字段与界面状态互相覆盖。

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

stack 选择协议栈实现，不存在适用于所有系统的固定最优项。遇到兼容问题时，每次只更换这一项并复测同一业务，记录连接是否建立、是否能持续传输、UDP 是否正常。不要同时修改协议栈、MTU、DNS 与节点，否则即使问题消失，也无法判断哪个参数起作用。自动识别接口异常时，先查看系统当前实际出站接口，尤其是有线与无线切换之后。

Fake-IP 保留域名映射，不是真实服务地址

Fake-IP 模式向应用返回保留地址池中的虚拟地址，内核记录它与域名的映射，后续连接进入内核后再据此匹配规则和发起出站。应用看到的虚拟地址不应直接拿到另一台未参与映射的设备上使用。它也不能证明远端服务真实位于该网段。排错时应同时查看映射域名和最终出站信息，不能只用系统工具显示的目标地址判断分流是否准确。

部分局域网发现、设备管理或依赖真实解析地址的业务可能需要排除 Fake-IP，可按明确域名设置 fake-ip-filter。排除后这些域名会走真实地址解析，后续规则能否保留域名信息又受应用行为与嗅探影响。不要为解决单个设备问题把所有域名都排除；先确认具体请求域名，再测试最小范围。地址池若与现有 VPN 或实验网络冲突，应按内核支持范围调整并重新建立映射。

用可逆的流程验证接管

验证时先保持已知可用的规则与节点，只开启 TUN。选择原先不遵循系统代理的目标应用，建立新连接并检查是否出现在连接列表。若能看到连接却访问失败，接管环节通常已经完成，下一步应检查规则、DNS 与出站；若完全没有记录，则检查应用是否绕过当前网络路径、接口路由是否建立，以及另一套网络工具是否抢先接管。

传统 DNS 劫持并不能自动拦截所有加密解析。应用自带的 DoH 或其他加密协议看起来是普通加密连接，不会仅因目标端口为非标准 DNS 端口就被交给本地解析模块。遇到域名信息缺失时，应先核对应用的安全 DNS 设置，再结合下一章的嗅探能力判断，不能把启用 dns-hijack 当作所有解析路径已统一的证据。

出现断网时先关闭 TUN，观察路由与 DNS 是否恢复，再处理冲突来源。退出客户端后仍异常，应检查残留系统代理、其他 VPN 状态与系统网络设置，不要不断叠加新路由。远程维护服务器时尤其需要回退通道，避免接管管理连接后失去访问。完整原理及系统代理对照可继续阅读TUN 流量接管说明，首次安装则仍以快速上手教程为准。

域名信息补全

域名嗅探

域名规则需要知道目标域名，但进入内核的连接有时只带目标 IP。应用可能直接连接缓存地址，也可能自行完成解析，绕过内核 DNS。嗅探尝试从受支持协议的握手或请求信息中恢复域名，再供规则匹配或目标处理使用。它补充的是连接元信息，不是把所有加密内容解密，也不能替代合理的 DNS 路径和完整规则设计。

识别范围与信息来源

HTTP 嗅探通常依靠请求中的主机信息，TLS 嗅探通常依靠握手中的服务器名称，QUIC 则需要内核对相应流量的支持。协议不在支持范围、握手信息不可见或使用隐藏名称的机制时，可能无法得到域名。面板上没有显示域名不一定是客户端故障，也可能是流量本身没有提供可用信息。遇到这种情况，应保留地址规则和明确兜底，而不是无限扩大嗅探端口。

下面的片段把常见网页端口作为起点，并保留 TLS 与 QUIC 的范围。它是能力配置，不表示每个连接都一定会得到域名。parse-pure-ip 允许尝试处理只有 IP 目标的连接，force-dns-mapping 涉及 DNS 映射场景的嗅探行为。初次启用时只增加嗅探设置，不同时重写 DNS 和规则，以便能对比启用前后的域名与匹配结果。

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
    QUIC:
      ports:
        - 443

端口范围要与实际业务一致。把所有端口交给所有协议解析，既增加不必要的处理，也可能把非目标协议带进更复杂的判断链。自建服务运行在非标准端口时，先确认它实际使用的协议，再仅为相应项补充端口。QUIC 通常基于 UDP，是否能正常代理还取决于节点协议、服务端与链路支持；不能因为开启 QUIC 嗅探，就认定 UDP 出站已经具备。

区分用于匹配与改写连接目标

override-destination 决定是否使用嗅探到的域名覆盖连接目标。用于规则判断与用于重新连接域名是两种不同效果。某些业务依赖特定 IP、内部解析结果或地址绑定，改写目标可能改变原有连接语义。示例先关闭覆盖，以较小影响观察域名恢复情况；确有需要时再针对协议或业务调整，并检查当前内核对全局值和协议级值的继承规则。

同一目标 IP 可能承载多个域名，而一个域名又可能对应多个地址。只看到 IP 发生变化，不能判断嗅探是否正确；应核对原始目标、嗅探域名、命中规则与最终出口。若应用把请求交给另一个中间代理，嗅探得到的信息也可能只反映中间连接。应在接近目标应用的流量入口分析，而不是把所有连接列表中的名称都理解为用户正在访问的完整网站。

限定范围，保留兼容性例外

如果开启后只有少数服务异常，先关闭目标覆盖复测，再考虑通过 skip-domain 排除明确不兼容的域名。只有需要强制处理特定域名时才评估 force-domain，不要把它当作常规白名单。例外项应写明业务原因，避免半年后只剩一串无法解释的域名。对于内部系统，尤其要关注私有证书、非标准握手和固定 IP 访问方式，不宜直接套用公共网站的处理习惯。

验证必须使用新连接。浏览器的连接池、HTTP/2 复用和应用长连接可能让修改后的配置暂时没有新的握手可观察。先关闭目标应用相关连接，再打开一个可重复测试的页面，查看日志是否出现预期域名。不要同时清空全部系统网络设置，否则会丢失原本用来对照的环境。若需要保存调试日志，应只保留与该问题相关的时间段，并隐藏访问域名、节点地址等个人信息。

嗅探之后命中了不同规则，并不自动代表结果更正确。检查新规则是否真正符合业务目的，特别是宽泛的域名后缀规则可能覆盖原来精确的地址例外。可暂时加一条目标域名的明确规则验证，再把结果回填到长期规则设计。若关闭嗅探也能通过调整 DNS 得到稳定域名信息，应优先保留结构更简单、依赖更少的路径，避免每个问题都用新的功能开关补偿。

仍无法识别的流量应按地址、端口或可靠的进程信息处理。进程规则的可用性受平台、权限和内核能力影响，移动平台与桌面平台也不完全一致。将不确定流量交给明确兜底组，至少能解释最终出口。术语不熟悉时可查阅术语手册中的 DNS、规则与网络栈概念，再回到连接详情逐项比对，避免把“没有域名”直接归因为“代理没有工作”。

配置生成与更新

本地覆写与多订阅合并

订阅配置会随更新重新生成，直接在订阅文件里修改端口、DNS 或规则，下一次更新可能丢失。本地覆写的用途，是把长期由用户维护的设置与远程内容分开。节点交给订阅更新，个人规则、监听范围和必要的 DNS 策略保存在本地层。操作前先确认客户端提供的是字段合并、规则前置、规则后置还是脚本处理，它们不能统一理解成简单的文本追加。

先确定配置所有权和处理顺序

配置通常经过订阅下载、解析、客户端转换、覆写与内核运行几个阶段。一个字段在编辑器中存在，却没有出现在运行配置中，可能是后续处理覆盖了它，而非 YAML 语法失效。Clash Plus 与其他兼容客户端的入口名称可能不同，应根据实际界面寻找本地配置、覆写或运行配置查看功能。不要照着另一客户端的菜单路径判断当前客户端缺少某个内核能力。

对映射字段，客户端可能按键合并；对数组字段，则可能整体替换，也可能提供专门的前置或后置机制。rules、proxy-groups 与 nameserver 都涉及列表，不能假设新增一项就会自动保留远程所有条目。第一次使用覆写时，先做一个影响范围很小且易观察的改动，查看运行结果，确认合并语义后再迁移其他设置。

多订阅按来源隔离，再统一出口

多订阅合并不宜把所有节点粗暴塞进同一列表。不同来源可能出现同名节点、同名策略组或重复的提供器标识，覆盖顺序又可能随客户端实现变化。更稳妥的方式是每个来源独立成为提供器，先建立来源组，再由公共出口组引用。下面片段假定两个本地文件均为有效节点提供器文件；完整订阅需先经过客户端支持的转换，不能直接更改文件名冒充节点列表。

proxy-providers:
  来源甲:
    type: file
    path: ./providers/source-a.yaml
  来源乙:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 甲组
    type: select
    use:
      - 来源甲
  - name: 乙组
    type: select
    use:
      - 来源乙
  - name: 代理
    type: select
    proxies:
      - 甲组
      - 乙组

这种结构把规则与订阅来源解耦，但仍需处理同名节点和组名冲突。若客户端支持为来源节点增加前缀，应使用稳定、短且容易识别的前缀；如果使用脚本改名，必须同步检查所有按名称引用和过滤的表达式。删除来源前先从公共出口移除引用，再删除提供器。更新后候选为空时，先查看来源是否加载，再检查筛选条件，不要立即重建整份配置。

远程订阅不仅可能含节点，还可能携带规则、DNS 与控制接口字段。合并时应明确哪些内容允许进入运行配置，不能把两份完整配置逐段拼接后期待内核自动判断优先级。尤其是 external-controller、allow-lan 和监听地址，应由本地策略统一管理。使用订阅转换服务时，还要评估链接的保密性和转换方能接触到哪些内容，优先选择自己可控的处理路径。

每次只改变一层，并保留回退文件

建议保留原始订阅、本地覆写与最终运行配置三个可区分的文件，不要反复用同一个文件名覆盖。先对最终配置做语法检查，再加载到客户端，最后验证连接。独立使用 Mihomo 命令行时，可执行下面的配置测试；它检查语法和相关配置关系，不证明订阅服务器、规则下载或全部业务连接都已成功，运行时仍要继续观察日志。

mihomo -t -f ./config.yaml

修改覆写后发生闪退或无法启动，应先撤回最近一次本地变更，尝试恢复已知可用的配置，再判断是否需要处理客户端自身。错误提示中的行号可能指向生成后的文件，而非远程原文；排错时打开正确的运行文件，重点检查缩进、重复键、无效引用和列表被替换。启动问题的进一步处理见客户端启动崩溃排查。

备份文件同样包含订阅地址、节点密码与控制凭据，不能直接附在公开问题中。分享配置前应删除敏感内容，只保留能复现问题的最小结构，并用明显的教学假值替代。迁移到另一设备时，除 YAML 外还要核对本地提供器、规则集、控制面板目录与相对路径；配置正文相同而工作目录不同，也会出现文件不存在或旧缓存被误读的问题。

运行观察与控制

外部控制面板

外部控制接口让面板读取代理组、连接、规则与日志，并执行切换策略等操作。面板是内核的控制入口，不是另一套代理出口，也不负责替内核创建 TUN 路由。界面无法连接时，浏览器本身可能仍能正常上网；反过来，面板能打开，也不代表代理链路正常。需要把页面资源是否加载、控制接口是否可达、鉴权是否通过与业务连接是否成功分别判断。

默认保持本机监听

本机使用时，将控制接口绑定到回环地址，配合独立凭据。下面的 your-password 仅为教学假值，实际部署必须替换为自行生成的长随机字符串，不与订阅或其他服务共用。external-ui 指向本地面板资源目录，目录里应有面板入口文件；该路径相对于内核工作目录。没有准备面板文件时，可以先只测试 API，再配置界面。

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

回环监听只允许本机访问。手机浏览器访问电脑的回环地址，实际连接的是手机自己，不会自动跳到电脑。若确需跨设备管理，优先使用受控的私有通道，并限制来源、身份和访问范围；不要为了方便直接把控制接口暴露到公网。代理端口的 allow-lan 与控制接口监听不是同一项设置，开启局域网代理不等于控制面板已配置正确或已受到保护。

先验证 API，再处理页面连接

可先在内核运行设备上请求控制 API。以下命令读取当前配置概况，终端中的凭据同样只是示例。返回未授权时，先核对当前运行配置中的凭据；连接被拒绝时，先检查监听地址、端口与进程状态；请求超时则还需检查路由和防火墙。不要在接口尚不可达时反复重装面板，界面文件无法修复一个没有启动的控制服务。

curl --fail \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/configs

API 正常而浏览器面板仍失败，应检查面板填写的后端地址、协议和端口。通过 HTTPS 打开的页面连接 HTTP 后端时，浏览器可能按安全策略阻止混合内容；跨来源访问又可能涉及来源限制。优先让本地面板与受控接口采用清晰一致的访问路径，确有跨来源需求时再按内核能力设置精确来源，不要把放开所有来源当作通用修复。

面板可能把后端地址和凭据保存在浏览器存储中，因此换浏览器后需要重新配置，借用设备结束后也应清理保存内容。截图中注意隐藏连接域名、订阅来源、节点地址与凭据；复制调试信息时，只保留与故障相关的字段。分享日志前检查正文而非只检查文件名，连接详情往往比主配置更容易暴露具体访问记录。

用连接详情建立验证闭环

策略页适合确认选择链，连接页适合确认命中规则与最终出口，日志页适合定位解析失败、提供器更新和路由错误。调整规则时，先记录一个测试请求的时间与目标，再对照该条连接，避免在持续刷新的列表里误认另一个进程。部分连接已在修改前建立，不会因切换策略就立即重新路由；必要时只关闭对应连接，再发起新请求，减少对其他业务的影响。

面板中的自动测速与真实业务测试应分开看。一次探测成功，只说明探测请求当时完成；节点能否访问目标服务，还受协议、端口、UDP 能力、服务侧限制与出口路径影响。遇到某站点异常，可暂时固定手动节点，停止自动切换带来的变量，再观察域名解析、命中规则和连接错误。不要用频繁测速代替具体故障记录，也不要据一次结果重新排列全部规则。

控制接口修改与配置文件修改不一定具有相同持久性。有些面板操作只改变内存状态，有些选择会被内核或客户端缓存，重新加载后是否保留取决于实际实现。长期设置应回到本地配置或客户端设置保存，并在重新加载后验证；临时诊断则应记录改动并及时恢复，防止下次排错从一个已经偏离文件内容的运行状态开始。

完成一次进阶调整后，按固定顺序验收：配置能够解析、提供器成功加载、DNS 路径可解释、目标连接进入内核、命中预期规则、最终出口符合目的。每次只变更一个主要因素，保留可用回退文件。日常安装与首次连接仍参考快速上手教程；需要更换平台或客户端时到下载页选择，配置概念可在术语手册继续查阅。