配置文件与生效顺序
区分订阅文件、生成配置和运行状态
Clash 客户端通常同时管理三种内容：远程下载的订阅文件、经过客户端加工的最终配置，以及内核已经加载的运行状态。编辑订阅副本后界面没有变化，未必是参数无效，也可能是客户端仍在使用另一份生成文件。开始修改前，先确认当前启用的配置名称、内核类型以及客户端提供的最终配置预览位置，再记录现有的模式、端口和策略组选择。
订阅可以包含节点、策略组、规则和 DNS，也可以只提供节点列表。客户端还可能根据系统代理、TUN 开关和覆写设置补入字段，因此磁盘上的原始 YAML 不等于最终生效结果。建议把远程内容视为输入，把本地覆写视为变换，把运行配置视为检查对象。出现差异时沿这条路径逐层比较，不要同时修改三个位置，否则下次订阅更新后很难说明哪一层保留了改动。
用最小配置确认基础行为
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 手动选择
type: select
proxies:
- DIRECT
rules:
- MATCH,手动选择这份最小示例仅用于理解结构：混合端口同时接受 HTTP 与 SOCKS 代理请求，规则模式按规则表处理连接，末尾兜底规则交给手动选择组。示例没有加入代理节点，组内只有直连，因此不会自动获得代理出口。实际使用时，应保留自己的有效节点或代理集合，并把它们接入策略组。不要为了套用示例而删除订阅中的认证字段、传输层配置或服务端要求的参数。
YAML 使用空格缩进，不使用制表符。同一级列表项应保持对齐；含有特殊符号的名称和密码适合使用引号。顶层的 dns、rules、proxy-groups 不应在同一个文档里重复定义，重复键可能被解析器拒绝，也可能被后一个值替换。复制代码后先查看缩进，再检查名称引用；能被 YAML 解析，并不代表策略组引用和规则语义一定正确。
先检查语法，再进行受控重载
直接使用内核的用户可以执行 mihomo -t -f config.yaml 检查配置；如果客户端没有把内核加入命令搜索路径，应使用它实际提供的可执行文件路径。测试时还要使用与运行环境一致的工作目录，因为规则集缓存和其他相对路径会依赖目录位置。语法检查主要发现结构和引用问题，无法代替真实联网测试，也不能证明远程规则集一定下载成功。
修改前保存一份已知可用的完整配置，并记录客户端覆写设置。每次只改变一个主题，检查通过后再重载；涉及监听地址、虚拟网卡和路由的字段，按客户端提示重新启动内核。不要把重载成功当作所有旧连接已经迁移：连接可能继续保留原出口，验证时应主动重新建立目标连接，同时查看日志中的配置加载结果，而不是只观察开关外观。
如果内核无法启动，先恢复上一份配置，再区分解析错误、端口占用和权限不足。端口错误可参考混合端口占用排查；结构问题可对照YAML 配置分段解析。恢复基础连接后再继续进阶设置，比在失效配置上连续叠加补丁更容易定位原因。
策略组类型与分流实战
规则决定目标，策略组决定出口
规则列表负责把连接交给某个策略，策略组则负责从候选项中选择实际出口。候选项可以是节点、其他策略组，也可以是内置的 DIRECT 或 REJECT。这两个层次应分开设计：先按业务用途定义手动选择、自动选择、工作服务等组，再让规则引用这些稳定名称。节点增删留在底层处理，可以减少订阅更新时反复改写整份规则的工作量。
select 由用户在界面中选择候选项，适合作为总入口，也适合需要固定出口的服务。它不会因为当前节点不可用就自动选择另一个候选项，除非用户选中的本身就是自动组。需要维持登录位置或长时间会话时，手动固定往往比频繁切换更容易理解。组名不仅是界面标签，也是规则中的引用标识；修改名称后必须同步修改引用它的规则和上层策略组。
自动选择、故障切换与负载分配
| 类型 | 选择方式 | 配置重点 |
|---|---|---|
select | 用户手动选择 | 入口清晰，适合固定出口 |
url-test | 依据探测结果选择 | 统一探测地址，设置切换容差 |
fallback | 优先使用顺序靠前的可用候选 | 按偏好排列候选项 |
load-balance | 按策略分配不同连接 | 关注出口一致性与会话要求 |
url-test 适合从同类节点中自动选择，但探测地址只代表到该目标的连通表现，并不等同于所有网站的使用体验。fallback 更强调候选顺序：排在前面的项目满足可用条件时优先使用，适合有明确主备关系的场景。两者都依赖探测，目标站自身不可达、证书异常或被网络限制时，可能把原本可用的候选误判为失败，排错时要单独验证探测目标。
load-balance 分配的是不同连接，不会把单条连接拆成多条来叠加带宽。按轮询分配时，同一业务的多个连接可能使用不同出口；使用一致性哈希也不能保证所有相关域名落在同一节点。支付、登录和对来源地址敏感的服务，宜单独放入固定出口组。连接中途改变策略通常也不会迁移已建立的传输，需要重新连接才能观察新选择。
proxy-groups:
- name: 自动选择
type: url-test
use:
- 主要节点
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 代理入口
type: select
proxies:
- 自动选择
- DIRECT
rules:
- DOMAIN-SUFFIX,github.com,代理入口
- MATCH,代理入口示例假设已经存在名为“主要节点”的代理集合；use 引用的是集合名称，不是订阅链接。探测地址可以换成自己确认可达且响应稳定的目标。间隔以秒计，容差用于减少细小差异引发的来回切换，不应把它理解为对实际业务响应的保证。若节点数量较多，应控制探测频率，先用默认或保守间隔观察，再根据设备资源和网络条件调整。
检查空组、循环引用与业务命中
策略组筛选后没有候选项，常见原因是集合尚未加载、名称拼写不同，或正则筛选没有匹配到节点。先暂时移除筛选条件并查看实际候选，再恢复过滤表达式。组之间可以分层引用，但不能形成循环；例如总入口包含自动组，而自动组又回到总入口，会让出口解析无法结束。保持“业务组 → 选择组 → 节点或集合”的单向结构，更便于检查。
验证时先固定一个已知可用的候选，访问目标服务，确认规则确实交给预期组，再测试自动选择。否则连接失败可能来自规则、解析或节点本身，自动组只是在表面上被怀疑。需要按平台比较界面和内核能力时，可查看客户端对比；具体组类型是否能在界面直接编辑，应以所用客户端的配置入口为准。
规则集订阅化管理
把匹配数据与处理策略分开维护
当域名和网段列表逐渐增长，把每一项都写在主配置里会增加阅读和更新成本。rule-providers 将匹配数据独立成规则集，主配置只保留集合来源和调用顺序。规则集负责说明哪些目标属于一个类别，RULE-SET 规则负责指定这个类别应交给哪个策略。这样可以更新目标清单而不改变策略组，也可以调整出口而不重写整份域名数据。
规则按从上到下的顺序匹配，通常由第一条匹配成功的规则决定去向。针对个别域名的例外应放在宽泛规则之前，MATCH 放在末尾兜底。规则集的调用位置和它内部的数据同样重要：一份正确的拒绝列表放在兜底之后不会生效；把宽泛直连条件放在业务代理规则之前，也可能提前截走连接。调整规则时应先说明优先关系，再修改文件。
选择正确的行为与数据格式
rule-providers:
内部域名:
type: file
behavior: domain
format: yaml
path: ./rules/internal.yaml
rules:
- DOMAIN-SUFFIX,github.com,代理入口
- RULE-SET,内部域名,DIRECT
- GEOIP,CN,DIRECT
- MATCH,代理入口以上主配置引用本地文件，且假设“代理入口”策略已经存在。对应的 rules/internal.yaml 可以写成下面的形式。这里使用专门保留给示例的域名，不依赖真实服务；+.example.com 表示根域名及其子域名。实际部署时替换成需要管理的目标，并把文件放到内核允许访问的位置。客户端若使用受限配置目录，应优先采用其导入或规则集管理入口。
payload:
- '+.example.com'
- '+.example.org'behavior: domain 用于域名数据，ipcidr 用于 IP 网段，classical 则可以容纳不同类型的规则表达式。三者的数据写法不能混用：域名集合里不应直接塞入完整的 DOMAIN-SUFFIX 规则行。传统规则格式的集合通常只写匹配条件，由调用它的 RULE-SET 指定策略，不要照搬主规则列表，把目标策略再附加到每个集合条目末尾。
格式字段也要与内容一致。YAML 形式通常使用 payload 列表，文本形式按对应规范逐行存放数据，二进制规则格式则需要匹配相应行为和生成工具。下载成功只说明拿到了响应内容，不说明内容能被正确解析。错误页面、登录页或重定向后的 HTML 都可能保存到缓存，因此更新失败时应查看解析日志，并检查文件首部和实际响应，而不是只看网络请求是否完成。
远程更新、缓存与启动依赖
改为远程规则集时，设置 type: http、可信的实际下载地址、缓存路径和更新间隔。不同集合使用不同缓存文件，避免更新时互相覆盖。首次启动如果访问规则源需要代理，而代理连接又依赖尚未下载的规则，便形成启动依赖；可以为规则下载明确指定可用出口，或先准备本地缓存。不要通过无限重试掩盖依赖环，先确保基础代理在精简规则下能够工作。
对于只希望根据已有目标地址匹配的 IP 规则，可以按需要使用 no-resolve，避免为了测试这条规则额外解析域名。代价是只有域名信息、尚无真实 IP 的连接可能跳过它。这不是通用加速开关，而是改变匹配时机的语义选择。域名规则、DNS 策略和 IP 规则应该一起检查，尤其在 Fake-IP 模式下，不要把合成地址当成服务端真实地址来设计网段分流。
回归测试至少覆盖一个应代理目标、一个应直连目标和一个被明确拒绝的测试目标。查看连接详情中的规则类型、集合名称和最终策略，而不是仅凭网页能否打开判断。规则命中正确但业务仍异常时，再检查策略组出口、DNS 返回和旧连接缓存；不要立即增加更多重复规则，否则下一次排查会被越来越长的例外列表拖慢。
DNS 配置优化与解析路径
先画清解析请求经过哪些环节
DNS 配置需要同时考虑三个问题：应用把查询交给谁、内核如何选择上游、上游域名自身又由谁解析。系统 DNS、浏览器安全 DNS、应用内置解析器和 mihomo DNS 可以同时存在，因此修改一个上游不一定改变所有应用的行为。开始优化前，先确认当前连接是否经过内核，以及日志是否出现对应查询。请求未进入内核时，反复调整内核缓存和上游顺序通常不会解决问题。
nameserver 定义常规解析上游，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:
- https://dns.alidns.com/dns-query
nameserver-policy:
'+.example.com':
- 223.5.5.5
fake-ip-filter:
- '*.lan'
- '*.local'示例让 DNS 仅监听本机，并为示例域名指定独立上游。监听端口不会自动改变系统 DNS，也不会自动接管其他设备的查询；只有系统设置、客户端网络接管或应用代理路径把请求送进来时，这个监听才参与工作。上游可达性取决于当前网络，应先确认基础链工作，再添加按域名区分的策略。局域网内部域名应使用知道内部记录的解析器，而不是默认交给公共上游。
nameserver-policy 根据域名选择解析上游，改变的是解析路径，不是连接出口。一个域名由指定 DNS 返回地址后，连接仍然需要经过规则匹配决定走代理还是直连。反过来，域名命中了代理规则，也不代表它的 DNS 一定通过同一个代理出口。将解析策略与路由策略写成两张清单分别核对，能避免把“指定 DNS”和“指定代理节点”当成同一个设置。
代理节点解析与备用解析的边界
节点服务器若使用域名，它的解析属于建立代理前的准备工作。需要独立处理时，可使用 proxy-server-nameserver 为代理服务器域名配置上游，避免节点域名解析依赖节点自己。采用按规则选择 DNS 出口的能力时，也应一起检查这一项。多层代理、远程集合下载和加密上游混用时，最重要的是不存在循环依赖，而不是让所有请求都套用相同路径。
fallback 与 fallback-filter 需要成套理解：后者参与判断哪些结果适合使用备用解析，不能简单看成“主 DNS 失败就一定切换”的顺序队列。添加过宽的过滤条件会使大量域名采用备用结果，也可能增加查询开销。没有明确需求时，先使用容易验证的单一路径；只有能够说明哪些域名、哪些地址结果需要特殊处理时，再逐项增加过滤条件。
加密 DNS 可以保护查询传输过程，但不能替代正确的出口选择，也不能保证远端结果适合本地访问。IPv6 同样需要完整链路支持：系统能够获得 IPv6 地址，不代表代理节点、路由和目标服务都具备可用路径。如果只在部分网站出现等待，检查 AAAA 返回与实际 IPv6 连通性，再决定是否调整内核 DNS 的 IPv6 设置，不要直接把所有故障归因于解析器质量。
验证查询进入点与缓存影响
测试时分别查询系统默认 DNS 和指定监听端口，比较它们是否走同一条链。支持指定端口的工具可使用 dig @127.0.0.1 -p 1053 example.com；工具需要另行具备，客户端不会必然附带。Fake-IP 下出现合成地址可以是预期结果，不应仅凭它与公共解析器返回不同就判断配置错误。更可靠的证据是查询日志、映射关系和随后建立的连接是否一致。
修改完成后重新建立应用连接，必要时清理应用自己的 DNS 缓存，并确认浏览器安全 DNS 是否绕开了系统解析。测试记录应注明查询入口和使用的上游，避免把两个不同路径的结果直接比较。如果只有内部域名失败，优先检查本地解析器和分域策略；如果所有域名失败，则先回到上游引导、监听端口与网络可达性这三项。
TUN、Fake-IP 与网络接管
区分系统代理与虚拟网卡接管
系统代理通常向遵循系统设置的应用提供 HTTP 或 SOCKS 代理入口，并不保证所有连接都会经过内核。TUN 则通过虚拟网卡及路由规则接收流量，适合不能直接配置代理的应用。两者不是互斥的概念，但同时开启时需要知道每类连接从哪里进入。看到 TUN 开关已开启，只能说明客户端尝试启用相关功能，仍需验证网卡、路由、DNS 和权限是否共同生效。
桌面系统通常需要管理员权限、服务模式或辅助组件来管理虚拟网卡与路由，具体入口由客户端提供。Android 的网络接管常通过 VpnService 实现，是否能后台持续运行还受到系统省电策略影响。不要把桌面 YAML 的全部路由字段原样套入移动端界面，也不要在已有企业 VPN 或其他网络接管工具运行时直接叠加配置；先了解它们各自控制的路由范围。
从保守的 TUN 设置开始
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示例展示接管与 DNS 的关联，实际使用时应合并到已有的 tun 和 dns 段。auto-route 用于自动配置路由，auto-detect-interface 用于识别出口网卡，栈类型需要结合平台支持和内核日志选择。若客户端已经管理这些字段，应通过客户端入口调整，避免本地覆写与界面开关互相覆盖。不能仅因为示例采用某个栈，就认定它在所有设备上最合适。
dns-hijack 的目的在于把匹配的传统 DNS 请求交给内核解析器，示例并不意味着所有 DNS 都能被接管。应用使用 HTTPS 或其他加密通道查询时，流量不再表现为普通的目标端口 DNS 请求，需要结合路由和应用设置判断。内部解析器、路由器域名及特殊网络可能还需要例外。先观察查询入口，再决定劫持范围，不要用扩大接管范围代替定位。
Fake-IP 依靠映射，不是真实服务地址
Fake-IP 为域名分配合成地址，内核保存域名与地址之间的映射，随后把应用连接关联回原始域名。它可以减少部分场景下提前解析真实地址的需要，也便于域名规则工作。合成地址不是远端服务器地址，不适合拿来配置远端防火墙白名单，也不应被其他未经过同一内核的设备直接使用。若应用缓存了映射，但连接没有回到相应内核，便可能出现无法访问。
fake-ip-filter 用于让特定域名不分配 Fake-IP，适合局域网发现、内部服务或确实不兼容的业务。过滤后返回真实解析结果，连接仍需由路由和规则处理，并不自动等于直连。应从具体异常域名开始加入例外，同时保证这些域名能被正确解析。把整个常用域名范围都放入过滤表，会改变模式的工作方式，也使域名关联更依赖其他信息来源。
内网网段、容器网络和企业 VPN 可能与合成地址范围或自动路由发生冲突。发现某段地址不可达时，先检查系统路由表和现有网卡，不要立即更换所有 DNS。自定义地址池前应确认不会覆盖现有网络，再按客户端能力配置路由排除。排除某个网段意味着那部分流量可能不再进入内核，随后也就无法依靠内核规则继续分流，这个边界需要事先明确。
按网卡、路由、解析、连接的顺序排错
TUN 开启后完全断网，先关闭 TUN 恢复原网络，再确认内核权限和虚拟网卡是否创建成功。随后检查默认出口识别是否错误，尤其是多网卡、热点共享和 VPN 并存的设备。基础路由正确后再测试 DNS；域名能够解析但连接失败，则查看命中规则和节点协议支持。每一层都用一个可复现请求验证，不要连续切换多个栈和 DNS 后才开始看日志。
如果仅 Android 后台断连，继续检查系统授权和省电策略，可参考Android VpnService 与后台保活说明。如果只影响局域网设备，则单独检查共享代理端口、防火墙和监听地址，而不是把电脑自身 TUN 的工作状态当成其他设备已经接入代理的证据。
域名嗅探与规则识别
嗅探补充域名信息，不替代 DNS
连接进入内核时，不一定携带可用域名。例如应用直接连接 IP，或 DNS 查询发生在内核之外，规则引擎可能只能看到目标地址。域名嗅探尝试从连接初始数据中提取主机信息，补充规则匹配所需的域名线索。它不负责给应用提供通用名称解析，也不保证每种连接都能识别。排错时应先确认域名信息究竟缺失在哪里，再判断是否需要启用嗅探。
常见信息来源包括 HTTP 请求中的主机字段，以及 TLS 握手中可见的服务器名称。QUIC 的识别还依赖协议支持和数据是否能被解析。加密客户端问候、非标准握手、没有域名的协议和已经建立的连接，都可能限制识别效果。因此嗅探成功率不能当作配置是否正确的唯一标准，未识别的连接仍然需要合理的 IP 规则和兜底策略，不能依赖嗅探补齐所有信息。
先限定协议和端口，再考虑覆盖目标
sniffer:
enable: true
sniff:
HTTP:
ports:
- 80
- 8080-8880
override-destination: false
TLS:
ports:
- 443
override-destination: false
skip-domain:
- '+.example.com'示例仅对常见 HTTP 与 TLS 端口启用识别，并保持目的地址覆盖关闭；跳过项使用示例域名，实际应替换为确有兼容性需要的目标。端口列表是识别范围，不是放行防火墙端口，也不是把这些连接自动指定给代理。规则列表仍然决定去向。先在有限范围内确认效果，比直接对大量端口启用识别更容易判断是哪类协议改变了行为。
override-destination 涉及是否使用嗅探到的域名覆盖连接目的地，和“获得一个域名供匹配”不是同一层含义。原本按 IP 连接的服务，覆盖后可能触发重新解析，最终访问不同地址；对于固定地址服务、特殊 CDN 调度或内网网关，这种变化可能产生兼容性问题。应先保持保守设置，确认具体业务确实需要覆盖，再按协议或域名范围逐步调整。
处理误识别与业务例外
有些服务会复用连接、使用与访问入口不同的握手名称，或者通过中间网关承载业务。嗅探得到的名称未必就是用户最初输入的域名，规则可能因此进入另一个分类。若启用后某个服务才出现异常，先记录嗅探前后的域名、目的地址和策略，再为具体目标添加跳过项。不要立即关闭所有域名规则，也不要把整个服务生态全部强制直连，这会扩大变更范围。
force-domain、纯 IP 连接识别等能力属于进一步的控制项，是否需要取决于实际入口和内核支持。强制范围不宜从全域名开始；一个合理的需求应能够具体描述为“某应用对某域名缺少映射，需要补充识别”。若无法指出受影响的连接，先从 DNS 进入点和 Fake-IP 映射检查。许多看似需要强制嗅探的问题，本质上是 DNS 与连接没有经过同一条链。
嗅探也会参与连接初期处理。对时序敏感的应用，协议等待和识别失败可能改变建立连接的表现，因此测试要覆盖业务实际使用的传输协议。仅在浏览器中打开主页，不能证明应用内语音、视频或其他长连接都正常。日志只应在定位阶段临时提高详细程度，完成后恢复常规等级，避免长时间收集不必要的域名和连接信息。
把识别结果放回完整分流链验证
验证时选择一个可以重复操作的目标，先关闭嗅探建立基线，再开启嗅探重新连接，比较规则命中是否按预期变化。若目的地没有域名信息，但 IP 规则已经正确处理，则不必为了让界面显示域名而增加复杂设置。若识别到域名后仍然命中兜底规则，应继续检查规则顺序、拼写和规则集内容；识别成功并不会自动创建针对该域名的分流规则。
涉及固定 IP、证书异常或代理网关的服务，应同时检查应用层错误，而不是仅查看代理连接是否建立。内核通常不会因为嗅探而解密业务正文，也不能修复服务端证书或账号权限问题。把“获得域名线索”“选择策略”“连接目的地”和“应用请求成功”作为四个独立结果记录，能避免把后续业务失败误判成嗅探失败。
对于需要保留原目的地址的内部系统，优先采用明确域名规则、内部 DNS 和有限的嗅探跳过列表。复杂业务不能依赖一条全局开关获得统一结果。若决定停用嗅探，也应重新验证原来依靠它识别的连接是否落入适当兜底，而不是只删除配置后结束检查。基本术语可在名词解释中对照查阅。
本地覆写与多订阅合并
明确远程输入和本地维护的边界
订阅更新通常会重新下载远程内容，直接修改下载副本容易在下次更新时丢失。持久设置应放在客户端提供的覆写、合并或脚本入口，但这些入口不是 mihomo 统一规定的界面功能。Clash Plus、Clash Verge Rev、FlClash 等客户端的处理时机和字段合并方式可能不同，操作前需要检查最终配置，而不能因为入口名称相似，就假定它们采用同一套覆盖规则。
适合本地维护的内容包括监听范围、DNS 偏好、内部域名规则和固定的策略组结构；适合远程更新的内容包括节点参数及外部规则数据。把这两部分拆开后，本地设置才不会跟着每次节点更新反复变化。对于远程配置已经包含完整规则的情况，要先决定保留其框架还是使用自己的框架，再设置覆写，避免两份结构互相嵌套且无法说明哪一份拥有最终控制权。
以代理集合组织多个节点来源
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:
- 订阅甲
- 订阅乙
- DIRECT示例使用本地代理集合，两个文件都应包含有效的 proxies 列表。它表达的是先分别验证来源，再通过上层入口选择来源的结构。完整 Clash 配置、只有节点的 YAML、Base64 列表和协议分享链接不是可互换的文件类型；把任意订阅地址填入集合，并不代表内核一定能识别。先确认返回格式，必要时使用可信的本地处理流程，详见订阅格式区别。
使用远程代理集合时，需要配置实际订阅地址、缓存路径与更新间隔，并考虑启动时下载走哪条路径。订阅地址通常包含账户凭据，应只保存在本地私有配置中，不要贴到公开转换页面或问题截图。教学和共享样例应移除真实地址、认证信息及可恢复账户的参数。即使不公开节点密码，完整订阅链接本身也可能具有访问权限，不能把它当作普通公开网页链接。
列表合并不是简单的文本拼接
字典字段可以按键覆盖，列表却存在替换、前置追加、后置追加等不同语义。把本地规则追加到远程 MATCH 后面，通常不会达到例外优先的目标；把 DNS 列表直接替换，又可能丢失原配置的内部解析器。覆写前应先说明期望操作，再检查客户端是否支持。若客户端只支持整段替换，就需要维护完整的目标段，而不是提交一小段后假设其他条目会自动保留。
多个来源可能包含同名节点和同名策略组。界面显示重复名称会影响识别，规则和组引用也可能出现歧义。优先在来源层建立清晰的名称区分，并在客户端确实支持的地方使用名称修饰；不要只修改界面显示名称，却留下旧引用。正则筛选同样需要在合并后检查，因为新增前缀、来源变化或名称语言改变，都可能让原本有效的表达式得到空结果。
健康检查也应分清层次。代理集合可以维护节点检查，自动策略组也可能发起探测，重复设置会增加请求。不是每个手动选择组都需要再加一轮自动测试。先明确希望知道的是“集合内节点是否可连接”，还是“自动组应选哪个候选”，再设置相应检查。多订阅同时启用时，来源各自可用不等于共享的上层组也正确，必须继续验证最终候选和规则引用。
建立可重复的更新与回退流程
一次合并完成后，依次检查 YAML 解析、集合加载、策略候选、规则顺序和 DNS 结果，并保存最终配置预览。随后主动执行一次订阅更新，再重复相同检查，确认本地设置确实保留。只有经过更新验证的覆写，才可以视为持久配置；仅在当前会话生效的界面选择，可能还依赖客户端是否保存运行状态，需要单独确认重启后的行为。
如果计划从旧客户端迁移，先导出本地覆写和必要的策略选择记录，再导入新客户端逐段验证。不要假设界面配置数据库可以跨客户端直接使用。可在下载页选择当前平台的客户端；一般先完成单订阅连接，再增加第二个来源，最后恢复复杂规则，这样每一次变化都有明确的验证范围。
外部控制面板与接口安全
控制端口和代理端口用途不同
混合端口用于转发应用连接，外部控制端口则用于读取状态和执行管理操作。面板通过控制接口查看策略组、连接和日志，也可能切换模式或重载配置。它不是另一个可供浏览器填写的代理端口。两个监听不能占用同一地址上的同一端口；遇到启动冲突时，应分别检查代理监听、DNS 监听和控制监听，不能只修改系统代理填写的数字。
控制接口的权限高于普通状态页面，因为能够访问接口的程序可能改变流量处理方式。桌面端通常只需绑定本机回环地址，远程管理则应先考虑经过认证的隧道或受控网络。把控制地址改为所有网卡监听，只会扩大访问范围，不会自动建立访问控制，也不会因为面板界面没有显示给其他人就变得安全。实际边界由监听地址、防火墙和认证共同决定。
本机监听与认证设置
external-controller: 127.0.0.1:9090
secret: "your-controller-password"示例密码是教学假值，实际部署时应在本地替换为独立的高强度值，不要沿用节点认证信息或其他账户密码。客户端可能自行管理控制地址与认证字段，如果手动覆盖后面板断开，先检查界面保存的连接参数是否仍匹配，而不是直接清空认证。修改监听或认证后，现有面板连接也需要同步更新；多个面板保存不同旧值时，容易表现为间歇性连接失败。
本地面板若由客户端内置提供，优先使用客户端支持的打开方式。直接运行内核时，可以通过 external-ui 指向事先准备好的本地静态面板目录，但目录本身必须包含有效页面资源，写入路径不会自动生成面板。相对目录要结合内核工作目录判断，移动配置位置后也应检查资源路径。不要为了让页面加载而随意放宽整个配置目录的文件权限。
区分网络不可达、认证失败与浏览器限制
面板连接失败时，先确认内核正在运行且控制地址确实监听，再检查面板填写的协议、主机、端口和认证值。本机可达而其他设备不可达，通常需要检查绑定范围和防火墙；能够连接但返回未授权，则重点检查认证。面板能打开但状态为空，也可能是页面资源正常、接口连接失败，不能根据页面外观判断控制通道已经建立。
浏览器还可能受跨域策略和混合内容限制。一个通过 HTTPS 打开的面板请求明文 HTTP 控制接口，可能在请求到达内核前就被浏览器阻止。需要查看浏览器网络面板中的具体原因，再决定使用同源部署、客户端内置入口或经过保护的转发方式。不要把所有浏览器错误都当成内核不支持，也不要为了消除报错把允许来源和网络监听范围全部扩大。
确实需要跨域访问时，应按内核与面板支持的方式限定允许来源，并保留认证。通过反向代理提供远程入口，还要确认 WebSocket 等连接能正确转发，否则普通请求可能正常，实时日志却持续断开。保护入口时同时考虑传输加密和访问范围，不能只在面板前加一个登录页，却把底层控制端口直接暴露给不可信网络。不了解部署边界时，保留本机监听更合适。
用连接详情形成排错闭环
控制面板最有价值的信息是连接入口、目标域名或地址、命中的规则和最终策略链。排查一个失败请求时，先重新建立连接，在列表中找到对应项，再核对是否进入预期业务组。如果完全没有记录，优先检查应用是否经过代理或 TUN；有记录但规则不对，回到规则顺序；规则正确却无法建立传输，再检查节点、DNS 和协议支持。这个顺序能把问题限制在可观察的层次。
切换策略只影响后续选择，旧连接可能继续沿用原出口。为了验证可以只结束相关测试连接，然后重新发起请求，不必一次中断全部业务。临时开启详细日志时，应记录复现时间和目标，完成后恢复常规等级。截图和导出日志前，移除订阅地址、认证字段、内部域名和不必要的目标信息；诊断需要的是与故障相关的证据，而不是整份私人网络记录。
最终维护流程可以固定为：保存可用配置、单项修改、检查语法、受控重载、验证命中、执行订阅更新、再次验证并记录回退点。每次故障都沿入口、解析、匹配、出口四层检查，不用同时重装客户端和替换订阅。常见安装及使用问题可继续查阅帮助中心；需要重新确认导入和连接主线时，回到快速上手教程。