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

策略组类型与实战

先把节点、策略组和规则分开理解。节点描述实际的代理连接方式，策略组决定从哪些出口中选择，规则则把连接交给某个策略组处理。把节点直接写入大量规则，短期容易理解，长期却难维护：节点改名后要逐条修改。更稳妥的做法是让规则指向用途稳定的组，再在组内替换节点。配置里的名称引用区分具体字符，空格、大小写和中文标点变化都可能造成引用失效。

选择组、测速组与故障转移

select 是手动选择组，适合作为总出口或业务出口；组内可以放节点，也可以放其他策略组。url-test 定期通过指定地址测试可用性与响应时间，再按测试结果选择出口，适合节点条件相近的场景。fallback 更关注候选顺序：前面的出口可用时优先使用，失效后才转向后面的出口。它不是按照延迟重新排列节点，因此适合明确的主备线路，而不是替代测速组。

load-balance 会按配置的分配策略把不同连接交给不同出口，并不把单个下载连接的速度叠加。对于需要登录状态、固定出口或地区一致性的服务，频繁改变出口可能触发额外验证。先用手动组确认服务表现，再考虑是否采用负载均衡。节点测速也只代表探测地址的结果，不能据此断定视频、代码仓库或游戏连接一定更快；应把实际业务访问作为第二次验证。

建立可观察的两层结构

下面的结构把人工决策和自动探测分开。「订阅节点」必须是现有 proxy-providers 中已经定义的提供器，且至少包含一个可用节点。先把「手动选择」交给自动组，访问出现异常时再从面板切换到具体出口。不要把同一段示例重复追加到文件末尾；已有 proxy-groups 时，应在其列表中加入条目，保留同一个顶层键。

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - 订阅节点
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 手动选择
    type: select
    proxies:
      - 自动选择
      - DIRECT
    use:
      - 订阅节点

interval 的单位是秒，表示探测间隔；tolerance 的单位是毫秒，用于减少小幅波动引起的切换。lazy 允许在组未被使用时减少不必要的探测，但具体探测还会受到提供器健康检查设置影响。不要同时把组探测与订阅健康检查都设得很密集，尤其在移动网络上，持续探测会增加唤醒和流量开销。应先观察故障是否真的需要更短间隔处理。

检查引用、环路与会话稳定性

策略组嵌套应保持单向，例如业务组指向总出口，总出口再指向自动组，自动组最后指向节点。不要让两个组互相引用，也不要让组通过多层关系回到自己。维护时可以从报错组沿引用逐层向下检查：名称是否存在、提供器是否加载、筛选表达式是否把全部节点排除。一个空组往往是上游节点被过滤，而不是规则本身写错，反复修改规则无法解决这个问题。

切换策略通常影响后续建立的连接，已有长连接不一定立即迁移。验证时先关闭测试应用中的旧连接，再重新发起请求；必要时只清理对应连接，不必直接重启整台设备。登录类服务建议固定在一个业务组，避免测速结果波动导致出口来回变化。若需要理解规则与全局切换的区别，可结合三种代理模式说明判断，不能把切换全局当作策略组配置正确的证据。

规则集订阅化管理

规则集把经常更新的域名或网段列表从主配置中分离出来。主配置保留判断顺序与出口名称，规则文件负责维护匹配对象。这样更新业务域名时不用反复改动全部策略组，也更容易追踪一次更新带来的差异。需要注意，规则提供器与节点提供器是两种对象：前者只提供匹配条件，不会生成可连接的代理节点；下载成功也不代表这些规则已经被主规则列表引用。

选择 behavior 与文件格式

behavior: domain 面向域名列表，适合把同一类站点集中管理；ipcidr 面向地址段；classical 则可包含域名后缀、关键词、地址段等传统规则条件。选择时先看源文件实际内容，而不是文件扩展名。文件中的条目结构、提供器的 format 和 behavior 必须对应。把带规则类型前缀的内容当作纯域名列表读取，可能报解析错误，也可能得到并不符合预期的匹配。

先用本地规则文件验证结构，再接入远程更新，排错会更清楚。下面的 ./rules/work.yaml 相对于内核工作目录，不一定是图形客户端安装目录。若客户端运行在沙盒或服务模式中，应通过它提供的配置目录入口确认路径，并检查内核是否允许读取。主规则里的「手动选择」沿用上一章的组名；如果实际配置采用其他名称，这里也要同步调整。

# 主配置中的片段
rule-providers:
  工作站点:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,工作站点,手动选择
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手动选择

# rules/work.yaml 文件内容
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,gitlab.com

先明确顺序，再安排更新

规则一般从上往下匹配，命中后结束本轮选择。精确例外应放在宽泛规则之前，兜底 MATCH 放在末尾；否则后面的业务规则根本没有机会执行。同一域名同时出现在两个规则集中时，不会自动选择更具体的那个，而是由引用顺序决定。调整规则前先在连接详情中记录当前命中的规则、组与出口，再移动一条规则进行对照，不要一次调换整段列表后只看网页是否能打开。

切换为远程提供器时，将类型改为 http，再设置来源 url、本地缓存 path 和更新间隔 interval。来源必须是你已经确认内容与维护方式的规则地址；本页不把任意网络列表默认视为可信规则。不同提供器不要共用同一个缓存路径，否则更新结果可能相互覆盖。间隔应按源文件变化频率设置，以小时或天为单位通常比反复拉取更合适，手动排错时再主动更新一次。

远程下载还存在启动依赖：如果获取规则文件需要代理，而代理选择又依赖这个规则集，就可能在首次启动时形成循环。可以给下载过程明确指定一个已经可用的出口，或预先保存规则缓存，再观察冷启动是否仍能完成。不要用「配置已经加载」代替提供器状态检查；主配置加载成功时，远程规则可能仍在请求中，也可能继续使用旧缓存，因此还需查看提供器的更新时间和错误信息。

处理地址规则与规则回退

no-resolve 适用于不希望为匹配地址条件而主动触发域名解析的场景，不是让所有流量跳过 DNS。若连接已经带有目标地址，地址规则仍可能命中；若仅知道域名且没有地址，带此选项的规则就可能被略过。把它加在大范围规则上之前，要明确后面由谁接住连接。内网、私有地址和自建服务应有明确的直连安排，不能只依赖最后一条代理兜底。

规则更新后出现局部故障时，先暂停更新并恢复上一份规则文件，再比较具体增删内容。重点查看域名是否被新增到更靠前的类别、网段是否扩大、兜底出口是否变化。若文件能加载但始终不命中，再检查连接是否保留域名、嗅探是否可用，以及应用是否绕过了内核入口。关于规则模式下的常见现象，可查常见问题；应保留能复现问题的最小规则，而不是把整份配置全部重写。

DNS 配置优化

DNS 排错先画出解析路径：应用把查询交给谁，查询是否进入内核，内核向哪个上游请求，上游请求又通过哪个出口发送。浏览器打开网页成功，只能说明某条访问路径可用，不能证明系统 DNS、应用加密 DNS和内核 DNS 全部一致。尤其在启用 TUN 后，原先由路由器完成的查询可能改由客户端处理；如果同时保留多套强制解析工具，观察到的结果会更难解释。

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

listen 是内核接收 DNS 查询的位置，不是上游服务器地址。绑定回环地址适合本机使用，绑定局域网地址则需要额外考虑防火墙和访问范围。nameserver 定义常规查询的上游；default-nameserver 用于解析 DNS 上游自身的域名，解决先知道解析服务地址才能请求它的问题。选择数字地址作为引导，可以减少这层循环，但仍应确认当前网络能够到达该服务器。

下面是便于检查的起点：监听本机非特权端口，使用加密上游，并为一个明确的域名后缀单独指定解析器。它不会自动修改系统 DNS，也不会单凭这个片段接管所有应用。合入之后，要由客户端的 DNS 接管设置或下一章的 TUN 配置把查询送进来。若客户端已经管理监听端口，不应再盲目设置相同端口，以免造成地址占用或生成两套相互冲突的配置。

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
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

按域名指定解析器，而不是堆叠上游

nameserver-policy 适合处理企业内网、自建域名或明确依赖特定解析路径的服务。企业域名应指向能够回答内部记录的解析器；把内部查询发送给公共解析服务，通常只会得到不存在或错误地址。示例中的 example.org 用于展示后缀匹配语法，不代表需要特别分流的真实业务。实际使用应先确认目标域名与解析器的对应关系，再替换为自己拥有或获准访问的域名。

增加很多上游不等于解析更可靠。不同上游可能返回不同地区的内容分发地址，也可能采用不同缓存，多个结果混用会让访问表现波动。若使用 fallback，应同时理解筛选条件和回退触发方式，不要把它简单理解为主解析器超时后的备用列表。建议从一条可观察路径开始，记录解析耗时、返回地址与业务访问结果，确认问题属于解析层后再引入额外的策略。

当配置要求 DNS 请求遵循路由规则时，respect-rules 可以参与控制这条路径，但还要为代理服务器域名安排清晰的解析来源，例如使用 proxy-server-nameserver。否则可能出现解析代理地址需要先连接代理，而建立代理又需要先解析地址的循环。相关功能的支持范围应以内核实际文档与运行日志为准；图形客户端的 DNS 开关可能生成额外配置，不能只看编辑器中的一段文本。

验证缓存、IPv6 与应用自带 DNS

测试应分三层进行：先直接查询内核监听端口，再通过系统默认解析测试，最后用实际应用访问。可以使用支持指定服务器和端口的工具，例如执行 dig @127.0.0.1 -p 1053 example.org。若第一层正常、第二层异常，重点查系统设置与接管路径；若前两层正常而浏览器表现不同，检查浏览器安全 DNS、应用内代理与已有缓存。修改配置后最好重新建立测试连接，避免旧连接掩盖变化。

关闭内核 DNS 的 IPv6 回答，不等于操作系统彻底停止 IPv6 通信。应用仍可能使用缓存、其他解析源或直接连接 IPv6 地址。反过来，启用 IPv6 也不能只看是否返回 AAAA 记录，还要确认本机路由、代理出口和目标服务都支持这条路径。若故障只发生在部分网络，分别测试地址族比反复切换全部 DNS 设置更有效；修改系统网络参数前，应先记录原值以便恢复。

DNS 配置调整后出现间歇性故障，先查上游是否可达、监听是否冲突和查询是否实际进入内核，再考虑清理缓存。缓存本身有正常用途，频繁清空会增加重复请求，也可能掩盖启动阶段的依赖问题。公共网络、企业网络和家庭路由器可能限制不同的解析协议，应在各自网络中分别验证。不要把一次查询成功概括为所有场景均已解决，也不要把某个上游地址当作长期固定答案。

TUN 与 Fake-IP

TUN 通过虚拟网络接口接收符合路由条件的流量，解决部分应用不遵循系统代理的问题；Fake-IP 则把域名映射为虚拟地址，帮助内核在后续连接中恢复域名信息。两者经常一起使用，但不是同一项功能。系统代理能工作，不代表 TUN 的权限和路由也正确；看到一个虚拟地址，也不代表这条连接已经发往远端代理。应分别检查入口接管、域名映射、规则匹配和最终出口。

按入口、路由、解析的顺序启用

先在现有系统代理模式下确认订阅和节点可用，再关闭其他会修改路由的工具，最后启用 TUN。桌面客户端可能需要安装服务、管理员权限或系统网络扩展；移动端通常由系统 VPN 接口提供接管能力。不同平台的入口不同，不应直接照搬桌面权限操作。首次配置可以选择下载页首推的 Clash Plus，按系统说明完成授权，再确认当前客户端确实采用支持这些字段的内核。

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
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route 让内核参与建立所需路由，auto-detect-interface 帮助识别外部接口，避免把代理自己的连接再次送回 TUN。stack 决定网络栈实现，具体可选项与适用情况需结合系统支持判断，不能把某一种当作所有设备的固定最优值。示例使用 mixed 作为检查起点；若启动日志提示不支持，应依据客户端文档选择，而不是继续同时调整 DNS 和规则。

理解虚拟地址与 DNS 劫持范围

Fake-IP 返回的地址用于本地映射，不是目标网站真实的公网地址。因此以「解析结果看起来不正常」判断配置失败并不准确，应看访问是否完成、连接详情能否还原域名。遇到依赖真实地址的局域网发现、某些联网设备或特殊应用，可以把对应域名加入 fake-ip-filter，让其使用真实地址解析。过滤仅改变解析结果形式，不等于自动直连；如果需要直连，还应有相应路由规则。

dns-hijack 中的 any:53 针对进入 TUN 且符合条件的传统 DNS 请求，不能据此声称接管了所有 DNS。应用自带的 HTTPS 加密解析通常使用其他端口，不能靠这条设置直接识别。若应用绕过内核解析，内核可能只看到目标地址，此时域名规则是否能命中还取决于嗅探等条件。先确定查询协议和实际入口，再决定修改应用设置，避免用更宽泛的路由规则掩盖解析路径差异。

处理内网访问与残留路由

启用后先测试公网访问，再测试路由器管理页、打印机和公司内网。若只有内网受影响，检查直连规则和路由排除范围，不要立刻换节点。企业 VPN 可能下发专用网段和 DNS，TUN 自动路由与其同时运行时需要明确谁负责哪些地址。排除网段应精确到实际需要的范围；一口气排除过大的地址段，会让本来需要代理的连接也绕开内核，表面恢复局部服务却引入新的分流错误。

如果所有连接都失败，先停用 TUN 并恢复系统代理测试。系统代理恢复后可用，说明节点未必有问题，应重点看 TUN 初始化日志、默认出口识别和路由安装。正常退出客户端通常会清理自身创建的状态；异常退出后若网络仍不恢复，按客户端的修复入口检查服务和路由，再按需重启网络。不要在不了解系统路由表的情况下批量删除条目，尤其不能删除企业网络下发的路由。

Fake-IP 的映射和应用的 DNS 缓存有生命周期。内核重启后，应用若继续使用旧虚拟地址，可能出现短暂连接失败；应先让应用重新解析，再判断是否需要清理相关缓存。持续运行与移动端后台策略也会影响表现，详见手机后台耗电与保活取舍。验证完成后记录正常状态下的接口、路由与 DNS 设置，下一次切换网络时便能比较差异，而不是从头猜测。

域名嗅探

域名规则需要内核知道连接对应的域名。通过普通代理入口发起的请求经常直接携带域名，但从 TUN 进入的连接可能只有目标地址；应用自带解析、缓存或直接使用地址时，这种情况更常见。域名嗅探尝试从连接初始的协议信息中补充域名，例如 HTTP 的主机字段、TLS 握手中的服务器名称。它是对信息缺口的补充，不是代替 DNS，也不是解密所有应用内容。

先确认缺少域名，再开启嗅探

排查时先查看连接详情：若目标栏已经显示域名，且规则能够命中，就没有必要为了「配置完整」再打开更多强制选项。若只显示地址，先检查 DNS 是否进入内核、Fake-IP 映射是否仍存在，然后再考虑嗅探。启用嗅探可能改变命中规则的依据，原先按地址分流的连接会获得域名条件；因此上线前应挑选几个明确的服务做对照，记录开关前后的规则和出口变化。

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

sniff 指定尝试识别的协议及端口，不是给防火墙开放端口。只列出实际需要的范围，更容易理解哪些连接会被处理。force-dns-mapping 用于扩展特定 DNS 映射场景中的嗅探机会，并不会主动把所有 DNS 请求送进内核；parse-pure-ip 则涉及直接以地址为目标的流量。示例先保留后者关闭，避免把原本明确的地址连接也纳入更宽泛的域名推断。

区分匹配域名与改写目标

override-destination 关系到是否将嗅探得到的域名用于替换连接目标。保留关闭时，可以先观察嗅探是否补充了路由判断信息，而不同时改变目标连接方式。某些服务的握手名称与实际目标并不适合互换，尤其在自建入口、共享地址或特殊转发场景中。遇到开启后证书错误、连接被重置或特定应用失败，应把目标改写作为单独变量检查，不要直接归因于节点不可用。

如果某个域名不适合嗅探，可以在 skip-domain 中列出明确的例外；但例外应基于实际故障证据，而不是从网上复制很长的通用名单。建立例外前，先重复测试几次并记录连接所见的域名、实际地址和匹配规则。若关闭嗅探才能恢复，还应继续比较是协议识别本身、目标改写还是规则顺序导致问题。只有找到这一层关系，后续更新时才不会再次依靠扩大排除范围来维持运行。

理解加密协议带来的边界

TLS 嗅探依赖握手中可见的信息，遇到加密客户端问候等机制时，不能保证获得真实业务域名。QUIC 的识别也受协议、实现和数据包可见性影响，配置了协议名称不等于每条连接都能识别。对无法恢复域名的流量，应准备合理的地址规则或兜底策略，而不是无限扩大端口范围。若服务自身提供应用级代理设置，直接让它通过携带域名的代理入口连接，有时比继续增加嗅探更清晰。

嗅探结果也不应被当作应用身份认证。一个连接携带的主机信息只是在当前协议上下文中的线索，不能证明请求属于哪个用户，也不能承担隔离不同租户的安全边界。共享出口、内网授权或访问控制应使用独立的网络和身份机制。对于需要严格限定目的地址的工作环境，应由管理员制定可验证的规则，不能仅依赖域名嗅探来判断是否允许连接，更不能将观察到的域名当作访问授权。

验证时建议同时保留三组样本：正常经过内核 DNS 的网页、使用独立解析的应用，以及直接以地址连接的服务。每组都看目标信息、命中规则和最终出口，而不仅是能否打开。若启用嗅探后才出现额外等待，可暂时只保留一个协议范围测试，再逐项恢复。日志级别提高到能够定位问题即可，完成排错后恢复日常级别，避免持续写入大量连接信息，也避免把含有访问记录的日志直接公开分享。

本地覆写与多订阅合并

远程订阅会定期更新，直接修改下载后的配置容易在下次刷新时丢失。本地覆写的作用，是把个人的端口、DNS、规则与策略偏好放到独立维护层，让上游继续负责节点更新。不同客户端可能称为覆写、合并、扩展配置或脚本处理，底层行为并不统一。开始前必须确认它修改的是哪一层：原始订阅、客户端保存的配置，还是交给内核的最终运行配置；这三份内容不一定相同。

先记录合并顺序与列表行为

标量字段通常容易理解，例如最后写入的 mode 覆盖前值；但列表字段可能追加、前置或整段替换，对象字段也可能浅合并或递归合并。不能因为两个客户端都叫「合并」就假定结果一致。建议先在本地副本中只改一个不影响连通性的字段，预览最终配置并确认结果，再加入 DNS 或规则。若客户端没有预览入口，可查看运行配置导出或启动日志，但分享前必须去除订阅地址和节点凭据。

尤其要检查 rules 的处理方式。若覆写把自定义规则追加在已有 MATCH 后面，这些规则可能永远不会执行；若整段替换，则可能丢掉原有内网与业务例外。策略组列表也类似：覆盖全部组会让上游规则引用的名称失效。维护时应把需要保留的稳定组名列出来，并明确自定义规则插入的位置。不要用重复的 YAML 顶层键模拟合并，不同解析器对重复键的处理并不可靠。

多订阅通过提供器分层管理

多订阅并不需要把几份完整配置直接拼在一起。更容易维护的结构是：每个来源作为独立节点提供器，总配置统一定义策略组、规则和 DNS。下面用两个本地节点文件展示组织方式；它们各自需要包含合法的 proxies 列表，不是任意完整客户端配置。文件路径相对于工作目录。若已有提供器健康检查，可根据实际需求统一调整，避免和组内探测叠加成过密的周期请求。

proxy-providers:
  线路甲:
    type: file
    path: ./providers/a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
  线路乙:
    type: file
    path: ./providers/b.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 多订阅出口
    type: select
    use:
      - 线路甲
      - 线路乙

改为远程提供器时，应使用自己有效且获准使用的订阅来源，并分别指定缓存路径与更新间隔。订阅地址常包含访问凭据，不能放进公开仓库、截图或求助帖。上游返回内容也要检查格式：适用于完整配置导入的地址，不一定能直接当作提供器文件读取。若报错提示缺少节点列表，先核对响应内容与类型，不要急着修改每个节点的协议字段；错误可能发生在最外层的数据结构。

不同来源出现相同节点名称时，面板选择和日志追踪都会变得模糊，还可能触发名称冲突。优先采用客户端或内核支持的名称前后缀机制，为来源建立稳定标识；如果使用转换脚本，应先在副本上运行并检查输出。筛选条件也要包含来源意图，不能只靠地区关键词，否则上游改名后可能让组内突然没有节点。合并完成后分别停用一个来源测试，确认另一来源能够独立承担预期的回退。

用运行配置验证，而不是只看编辑器

每次调整后执行配置检查，再重新加载并查看日志。如果设备上有可直接调用的 Mihomo 程序，可以在正确工作目录运行下方命令；命令只检查文件结构和引用等内容，不会证明远程节点或规则来源一定可达。图形客户端用户可以使用内置检查入口，不必另外启动第二个内核进程。两套进程同时运行会争用端口与路由，反而制造原本不存在的故障。

mihomo -t -f ./config.yaml

建立回退记录时，至少保存原始配置、本地覆写和一份去除敏感信息的变更说明。节点凭据应只留在受控位置，不随排错材料传播。订阅刷新后也应重新检查最终规则顺序、提供器状态和组内节点数量，特别是上游修改组名或默认模式的时候。首次安装阶段的设置顺序可参阅初始设置清单；配置稳定后尽量减少自动改写层数，一处需求只由一层负责，排错会明显直接。

外部控制面板

外部控制面板通过内核控制接口读取状态、切换策略、查看连接和管理提供器。它不是代理入口，也不会因为面板连接成功就自动让应用走代理。需要区分三个地址：应用使用的代理端口、DNS 监听端口，以及面板连接的控制地址。面板能打开却看不到连接时，应先确认它连接的是正在承载流量的内核，而不是残留服务、另一份配置或同机启动的第二个实例。

默认只监听本机

external-controller 定义控制接口监听地址。个人桌面使用优先绑定回环地址，让控制接口只在本机可达。external-ui 指向本地面板静态文件目录，该目录应真实存在，并与内核工作目录关系明确。下面的片段只演示本机监听与静态目录，不包含访问凭据；如果客户端已自动生成控制地址和口令，应优先沿用其管理方式，不要通过覆写随意清空现有认证配置。

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

面板认证由 secret 等相关设置参与控制，实际部署时应使用自行生成并妥善保存的高强度口令。不要把口令写进可分享的面板链接、截图或公开配置。仅绑定本机也不意味着可以忽略认证：本机其他程序和浏览器中的网络访问仍应纳入考虑。若面板来自网页，还要注意浏览器对跨源请求、混合内容以及本地网络访问的限制，页面自身能加载不代表它一定能访问控制接口。

按网络、认证、实例顺序排错

连接失败时先确认内核已运行、监听端口没有冲突，再核对面板填写的协议、地址和端口。访问被拒绝通常指向监听或防火墙问题；收到未授权响应，则重点检查认证配置；能够读取状态但策略组不对，往往是连到了其他实例。不要为了尽快连上就把地址直接改成所有接口，也不要把认证关闭当作长期方案。应在本机建立一条最小可用路径，再逐层扩大访问范围。

需要从另一台设备管理时，优先使用受控的隧道或已有管理网络，再考虑具体的监听调整。直接绑定 0.0.0.0 会让接口在多个网络上可达，实际暴露范围取决于防火墙、路由和端口转发。控制接口具有切换出口、查看连接等管理能力，不应直接暴露到公网。确实需要反向代理时，还应同时配置传输加密、访问控制与认证，并理解浏览器跨源设置，不能只增加一个转发规则就结束。

读懂连接详情，再进行干预

连接详情应按入口、目标、命中规则、策略链和实际节点依次阅读。入口帮助判断流量来自系统代理还是 TUN；目标信息帮助确认域名是否保留；规则说明为什么选择这个组；策略链则展示组如何继续选到节点。看到「手动选择」并不代表已知道最终出口，还要沿链查看。若一个网页产生多个连接，应按目标域名区分主请求和资源请求，不能只取其中一条连接概括全部页面的路由。

面板里的切换与重载操作也有不同影响。切换策略主要改变后续选择，重载配置可能更新规则与组结构，关闭连接则会中断现有会话。排错时先记录状态，再仅处理目标连接，避免把文件传输、远程终端和工作会议一起断开。规则提供器更新失败应查下载与解析日志；节点不可用应查出口；本地程序没有出现在连接列表中，则回到入口接管层检查，不要只在面板里重复测速。

日常维护可以固定为一个短循环：保存当前配置，修改一个主题，检查语法，重载后观察日志，再用明确的应用重新连接验证。跨网络测试时补查 DNS 与默认接口，多订阅更新后补查引用和缓存。局域网代理共享与控制接口开放是两件事，若要让其他设备使用代理，可参阅mixed-port 与 allow-lan 配置说明，不要误把控制端口填到手机代理设置中。仍无法定位时，带上去敏后的最小配置与复现步骤查阅故障排查问答。