Clash 进阶配置手册

CHAPTER 01

策略组类型与实战

策略组位于规则与代理节点之间。规则的最后一个参数通常不是具体节点，而是策略组名称；策略组再决定请求走哪个节点、自动测试组还是直连出口。排查“规则明明命中但出口不对”时，先看日志中的规则名称，再打开对应策略组确认当前选项。修改规则不会自动改变手动选择组的状态，切换节点也不会改写规则，因此这两个动作必须分开验证。

select、url-test、fallback 与 load-balance 的边界

select 是手动选择组，适合“代理选择”“流媒体”“下载”等需要人为固定出口的场景。它可以包含具体节点，也可以包含其他策略组。把自动测速组放进手动组后，平时选择自动组，需要固定地区时再改选某个地区组，层级清楚且便于回退。不要把几十个节点直接平铺到每一条业务策略里，否则节点名称变化后，多处引用会一起失效。

url-test 会定期访问测试地址，并在候选节点中选择测试结果较优的一个。它测到的是指定地址的连接表现，不代表所有网站和大文件传输都相同。interval 控制测试间隔，设得过短会增加后台请求；tolerance 用于抑制小幅波动导致的频繁切换。当前节点仍可用且与最优结果差距没有超过容差时，继续使用当前节点通常更稳定。

fallback 更重视可用性顺序。候选列表靠前的节点恢复后，策略组会倾向回到靠前项，适合主备出口明确的场景。load-balance 则把连接分配给多个节点，适合能够容忍出口变化的并发请求。需要登录状态、地区一致性或风控敏感的网站，不适合随意使用负载均衡，因为同一业务的不同连接可能出现不同出口。

proxy-groups:
  - name: 代理选择
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

  - name: 自动选择
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 故障转移
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    lazy: true

用过滤条件控制候选节点

订阅节点很多时，应在自动组或地区组内使用过滤条件，而不是人工复制节点名称。支持相关字段的内核可以通过 include-all 纳入节点，再用 filter 匹配名称，用 exclude-filter 排除倍率、测试或不希望参与的项目。过滤表达式按节点名称工作，订阅提供方改名后可能导致候选为空，所以每次更新订阅后都要打开策略组确认至少存在一个可用成员。

策略组可以引用其他组，但不要形成循环。例如“代理选择”包含“自动选择”是正常结构；如果“自动选择”又把“代理选择”作为候选，内核无法得到确定出口。组名也必须与规则末尾完全一致，空格、大小写和全角字符都算差异。遇到配置加载失败，先搜索同名组是否重复，再检查规则引用的组是否真实存在。

CHAPTER 02

规则集订阅化管理

规则数量增加后，把所有条目堆进主配置会造成三个问题：订阅更新时本地修改容易被覆盖，规则来源无法单独更新，排错时也难以判断是哪一组规则命中。rule-providers 把规则内容拆成独立集合，主配置只保留来源、存储路径、更新间隔和引用顺序。这样可以分别维护广告、局域网、直连区域和代理服务规则，但最终匹配顺序仍由主配置中的 rules 决定。

behavior 决定规则文件的内容形态

domain 类型用于纯域名集合，规则文件的 payload 通常写域名、后缀或通配表达式；ipcidr 用于 IP 网段；classical 可以容纳带类型的完整规则，例如 DOMAIN-SUFFIX、PROCESS-NAME 和 IP-CIDR。选择错误时，文件即使下载成功也可能无法解析。先查看规则源内容，再决定 behavior，不要根据文件名猜测。

type: http 表示远程更新，url 是来源地址，path 是本地缓存位置，interval 是刷新周期。不同 provider 必须使用不同路径，否则后下载的文件会覆盖前一个。远程更新失败时，内核通常继续使用已有缓存；首次启动没有缓存且远程地址不可达时，对应规则集无法加载，因此关键局域网规则可以保留少量内联条目作为启动保障。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domain.yaml
    url: https://example.com/rules/private-domain.yaml
    interval: 86400

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.com/rules/service-proxy.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-proxy,代理选择
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

示例地址用于说明字段结构，部署时应换成实际维护的规则源。规则文件使用 YAML 时，domain provider 可以写成：

payload:
  - localhost
  - "*.lan"
  - "+.example.internal"

排序比规则数量更重要

Clash 规则从上到下检查，首次命中后停止。精确业务规则应放在广泛区域规则之前，局域网和保留地址应放在默认代理之前，MATCH 必须放到最后。若先写 GEOIP,CN,DIRECT，再写某个依赖 IP 判断的代理规则，前一条可能提前截走请求。若先写宽泛的域名后缀，再写同一主域下的特殊子域，后者也不会执行。

规则冲突的处理方式不是继续增加例外，而是先记录请求实际命中的条目。客户端日志或外部控制面板通常会显示规则类型、规则内容和目标策略。确认命中错误后，把更具体的规则移动到更靠前位置。只有在域名无法获得、连接只剩 IP，或者应用绕过系统解析时，才考虑增加 IP 类规则；随意堆叠域名和 IP 规则会让结果难以预测。

no-resolve 适用于不希望为了匹配 IP 规则而额外触发 DNS 解析的场景。例如 GEOIP,CN,DIRECT,no-resolve 只在目标 IP 已经可用时判断。它能减少额外查询，但如果当前连接只有域名，这条规则不会主动解析后再匹配。使用前应先明确请求在规则阶段是域名还是 IP，不能把 no-resolve 当成通用性能选项。

更新失败与规则未生效要分开处理

provider 下载失败属于来源层问题：先用直连网络确认地址可访问，再检查 URL、响应格式和缓存目录权限。下载成功但未命中属于引用层问题：检查 rules 中是否存在对应 RULE-SET、策略组名称是否正确，以及更靠前的规则是否提前命中。文件解析失败则属于格式层问题：重点检查 behavior、format、YAML 缩进和 payload 层级。

规则更新后应执行一次配置重载，再用固定域名测试。不要用多个网站同时验证，因为浏览器后台请求、QUIC 和缓存会混入日志。选一个目标，清空连接记录，发起一次访问，确认域名、命中规则与最终策略三项一致。规则基础概念可以配合术语手册核对，遇到节点全部超时则应转到节点超时排查顺序，不要继续在规则集上反复修改。

CHAPTER 03

DNS 配置优化

DNS 问题常被误判成节点问题。浏览器显示连接失败时，可能是域名没有解析、解析结果被错误缓存、查询没有进入 Clash，或者规则阶段拿不到原始域名。诊断时先区分“DNS 查询由谁处理”和“解析结果如何用于连接”。系统 DNS、客户端内置 DNS、浏览器加密 DNS 与应用自带解析可以同时存在；只有确认查询路径，配置项才有意义。

先理解 nameserver、default-nameserver 与 fallback

nameserver 是主要解析上游。它可以使用普通 UDP/TCP DNS，也可以使用 DoH 或 DoT。default-nameserver 主要用于解析加密 DNS 上游自身的域名，通常应填写可直接访问的 IP 地址，避免出现“为了连接 DoH 先解析 DoH 域名，而解析又依赖 DoH”的循环。它不是所有业务查询的默认出口，也不应塞入大量地址。

fallback 与过滤设置用于在不同解析结果之间选择。此机制配置复杂，若没有明确的污染或分区解析需求，可以先只用稳定的 nameserver，确认基础解析正常后再增加 fallback。多加上游不等于更快；并行查询可能让日志更杂，也可能在不同结果之间产生缓存差异。优先保持两到三个职责明确的上游。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
    - time.*.com
    - time.*.gov

proxy-server-nameserver 用于解析代理服务器自身的域名。节点地址若写成域名，必须先得到节点 IP，之后才能建立代理连接。若这类查询错误地依赖尚未建立的代理，就会形成启动死锁：代理要先连接，连接又要先通过代理解析。把节点域名解析放到可直连访问的上游，能把业务 DNS 与节点 DNS 分开。

Fake-IP 与 redir-host 的选择

fake-ip 不立即把域名解析成真实目标 IP，而是返回保留地址池中的映射地址。应用连接该地址后，内核从映射表还原域名，再按域名规则处理。它通常能保留更完整的域名信息，并减少真实 DNS 结果过早暴露给应用。代价是部分局域网发现、设备投屏、时间同步、游戏和依赖真实 IP 校验的程序不兼容，需要通过 fake-ip-filter 排除。

redir-host 返回真实解析结果，兼容路径更接近传统代理，但规则阶段可能更依赖 DNS 结果和嗅探。选择模式时不要只看“能否打开网页”。应同时验证局域网设备、系统时间、常用通信软件和需要地区判定的服务。若只有某一类域名异常，优先把该域名加入过滤列表，而不是立即把全局模式切回 redir-host。

IPv6 开关需要与本地网络一起判断

ipv6: false 会抑制 AAAA 结果，适合本地 IPv6 不完整、节点不支持 IPv6 或经常出现 IPv6 优先但连接失败的环境。若本地和出口都具备稳定 IPv6，可以启用后分别检查 A、AAAA 查询与实际出口。仅在系统里关闭 IPv6、却让 Clash 返回 AAAA，应用仍可能先尝试不可达地址；反过来，网络具备 IPv6 但 DNS 禁止 AAAA，则不会走 IPv6。

判断 DNS 泄漏不能只看一个检测网页。先确认系统 DNS 是否指向客户端监听地址，再检查浏览器是否开启独立的安全 DNS，最后观察查询日志是否进入内核。浏览器 DoH 可能绕过系统 DNS，但连接流量仍经过代理；这属于查询路径不同，不等于所有流量都直连。需要统一控制时，应在浏览器中关闭独立解析或让其上游也由规则正确处理。

按现象定位 DNS 故障

“域名打不开但直接访问 IP 可以”优先检查解析上游和监听端口；“首次打开慢，刷新后正常”检查上游连接、缓存和 IPv6 超时；“部分局域网设备找不到”检查 Fake-IP 过滤；“日志只显示 IP，域名规则不命中”检查应用是否绕过 DNS、是否启用嗅探，以及透明代理是否捕获到对应连接。修改后清理系统和浏览器 DNS 缓存，再重启目标应用，避免旧连接干扰结果。

CHAPTER 04

TUN 与 Fake-IP

系统代理只影响主动读取代理设置的应用。命令行程序、部分游戏、虚拟机和自带网络栈的软件可能完全忽略它。TUN 模式在系统中建立虚拟网络接口，通过路由把更多 TCP、UDP 流量交给内核处理，因此适合需要透明接管的场景。TUN 解决的是流量入口问题，Fake-IP 解决的是域名映射问题，两者经常配合使用，但不是同一个开关。

配置前先排除路由冲突

TUN 启动需要创建虚拟接口、写入路由并接管 DNS，通常需要系统授权。若客户端界面显示 TUN 已开启，但目标应用仍直连，先检查虚拟接口是否存在，再检查默认路由和排除路由是否生效。VPN、虚拟机、容器、游戏加速器和其他代理软件都可能同时修改路由。排查时先退出同类工具，只保留一个流量接管程序。

auto-route 让内核自动配置路由，适合桌面端常规使用；auto-detect-interface 用于识别实际出站网卡，避免代理流量再次进入 TUN 形成回环。网络从有线切到无线、从家庭网络切到热点后，旧接口信息可能失效。若切网后突然全部超时，先重启 TUN 或客户端，使接口重新探测，而不是马上更换节点。

tun:
  enable: true
  stack: mixed
  device: Mihomo
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true
  mtu: 1500

stack 决定 TUN 数据如何进入用户态网络栈。mixed 通常用于兼顾 TCP 与 UDP 的通用桌面环境；若特定系统出现兼容问题，可以在客户端支持的范围内对比其他栈，但每次只改这一项。strict-route 会更严格地约束流量路径，有助于减少绕行，但也可能影响局域网、虚拟网卡和多网卡环境。启用后应立即测试网关、局域网设备与常用服务。

DNS 劫持要与监听配置对应

dns-hijack 把经过 TUN 的常规 53 端口查询交给内置 DNS。它无法直接解密应用自行发起的 DoH，也无法保证未经过 TUN 的查询被接管。配置了劫持但 dns.enable 未开启，或监听地址冲突，可能表现为所有域名失效。此时不要先动规则，先确认 DNS 模块是否启动、端口是否被其他服务占用。

Fake-IP 地址池通常使用专门保留范围。应用看到该地址后，连接必须继续经过同一个内核，内核才能从映射表恢复域名。如果 DNS 查询由 Clash 返回 Fake-IP，但后续连接绕过了 TUN 或系统代理，应用会直接尝试访问不可路由的保留地址，结果就是“能解析但连接失败”。这类故障应检查流量入口是否一致，而不是更换 DNS 上游。

MTU 与 UDP 是常见边界

网页能开但大文件、图片或部分 TLS 连接卡住时，需要考虑 MTU。虚拟接口封装会增加额外开销，底层网络又可能使用较小的有效 MTU。先观察是否只在特定网络出现，再逐步降低 TUN 的 MTU 测试，不要一次降到很小。数值过低会增加分片和处理开销，数值过高则可能遇到路径中黑洞。

游戏、语音和 QUIC 依赖 UDP。TUN 捕获到 UDP 不代表节点协议和出口一定支持。检查顺序是：日志中是否出现 UDP 连接、规则是否命中正确策略、所选节点是否支持 UDP、系统防火墙是否允许虚拟接口。浏览器页面异常时还可临时关闭 QUIC，比较 TCP 路径是否正常；这一步用于定位，不应直接当作长期解决方案。

各平台的处理重点

Windows 重点看驱动授权、系统服务和其他 VPN 虚拟网卡；macOS 重点看网络扩展授权和系统网络服务顺序；Linux 重点看 TUN 设备权限、策略路由、转发与防火墙规则。Android 和 iOS 上的 Clash 类客户端通常通过系统 VPN 接口接管流量，系统同时只允许一个主要 VPN 会话，开启其他 VPN 后当前连接可能被替换。需要选择适配客户端时，前往下载中心查看各平台列表，Clash Plus 为全平台首推项。

CHAPTER 05

域名嗅探

当应用直接连接 IP、使用缓存结果，或 DNS 查询没有经过 Clash 时，规则阶段可能只看到目标 IP。域名嗅探会从连接初始数据中提取主机名，例如 TLS 握手中的 SNI 或 HTTP 请求中的 Host，再把域名交给规则系统。它的作用是补全路由依据，不是解析所有加密内容，也不能保证每个协议都能恢复域名。

什么时候需要开启嗅探

日志长期只显示 IP，导致 DOMAIN、DOMAIN-SUFFIX 和域名规则集无法命中时，嗅探有价值。使用 Fake-IP 时，内核通常已经掌握域名，嗅探的必要性会降低，但对绕过内置 DNS 的连接仍可能有帮助。不要为了“功能更全”无条件开启全部端口，应先找出问题连接使用的协议和端口，再决定捕获范围。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud
    - "+.push.apple.com"

parse-pure-ip 允许对目标为纯 IP 的连接尝试提取域名；force-dns-mapping 会结合已有 DNS 映射；override-destination 决定是否使用嗅探得到的域名替代原始目标。覆盖目标可以让域名规则生效，但对某些使用固定 IP、证书校验或私有协议的应用可能产生副作用。建议先在协议分项中启用覆盖，不要一开始全局覆盖。

HTTP 嗅探依赖明文请求头，TLS 嗅探读取握手阶段可见的 SNI，QUIC 则受协议实现和加密握手影响。ECH 等机制可能隐藏传统 SNI，使嗅探无法得到目标域名。这不是配置错误，而是连接中没有可供提取的明文标识。此时应让 DNS 查询进入内核，或使用明确的 IP、进程和规则集策略补充。

skip-domain 用于处理兼容问题

局域网设备发现、推送服务、系统连通性检测和某些游戏可能不适合改写目标。出现“关闭嗅探就正常，开启后只有某个应用失败”时，先从日志确认嗅探得到的域名，再把具体域名加入 skip-domain。排除范围应尽量小，避免使用过宽的顶级后缀，否则大量正常连接会失去域名规则能力。

部分客户端把嗅探选项放在图形界面的覆写设置中，订阅更新时不会改变；另一些客户端直接读取配置文件。排查前确认最终生效配置，而不是只看订阅原文。客户端界面若提供“运行配置”或“当前配置”查看入口，应以该内容为准。本地覆写可能已经修改了 sniffer，手工编辑订阅文件却没有任何效果。

验证嗅探是否真正参与路由

选择一个日志中只显示 IP 的目标，清空现有连接后重新发起请求。依次记录原始目标、嗅探域名、命中规则和最终策略。看到域名不代表规则一定使用了它；还要确认命中条目已经从 IP 规则变成预期的域名规则。若域名正确但仍命中默认规则，检查规则顺序和后缀写法。若嗅探域名错误，先关闭目标覆盖，再将该域名或应用加入排除。

进程规则可作为桌面端补充，但不同操作系统对进程识别的支持和权限不同。进程名也可能随启动器、子进程或沙箱变化，因此不宜把所有业务都绑定到进程。稳定的分流通常以域名规则为主，IP 与进程规则负责覆盖无法获得域名的少数连接。

CHAPTER 06

本地覆写与多订阅合并

远程订阅适合提供节点和基础策略，但不适合作为长期手工编辑区。客户端更新订阅时通常会重新生成配置，直接写入订阅文件的 DNS、规则和策略组可能被覆盖。本地覆写的目标，是把“上游负责更新的内容”和“本机长期保留的内容”分开。修改前先确认客户端支持的是字段覆写、脚本处理、配置片段合并，还是完整配置托管；这些机制名字相近，合并顺序却不同。

先确定最终配置的生成顺序

常见流程是：读取远程订阅，解析节点和策略组，应用本地前置脚本或片段，再写入运行配置。有些客户端把本地规则追加到订阅规则前面，有些追加到后面；有些对同名键执行覆盖，有些对数组执行连接。若不了解顺序，新增的规则可能落在 MATCH 之后，永远不会命中；同名策略组也可能被整组替换，而不是只增加一个节点。

最可靠的检查方式是比较三份内容：远程订阅原文、本地覆写内容、客户端最终运行配置。只看编辑器里的片段无法证明生效。每次修改后搜索目标字段，确认它在最终配置中只出现一次、层级正确、引用存在。特别注意 YAML 中数组和对象的差异：rules、proxies 是有顺序的列表，dns、tun 通常是键值对象，错误的合并策略会直接改变语义。

prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - PROCESS-NAME,backup-client,DIRECT

append-proxies:
  - name: 本地出口
    type: socks5
    server: 127.0.0.1
    port: 1081

override:
  ipv6: false
  log-level: info

上例表达的是常见覆写意图，不同客户端对片段文件的字段名并不统一，应以客户端实际说明为准。通用 Clash 配置中没有 prepend-rules 这一顶层字段，不能把覆写工具的语法直接复制进 config.yaml。排查配置错误时，第一步就是区分“内核原生字段”和“客户端合并器字段”。

多订阅合并要先处理命名冲突

两个订阅可能同时包含“自动选择”“代理选择”等策略组，也可能出现同名节点。直接拼接会导致重复名称、引用错位或后一份覆盖前一份。合并前应给来源加稳定前缀，例如按用途标记“办公”“备用”，再构建自己的上层策略组。上层规则只引用自建组，不直接依赖上游随时可能改名的组，这样更新某个订阅时不会牵动全部规则。

节点名称是引用键，也是过滤依据。同名节点来自不同订阅时，即使服务器不同，策略组里也难以区分。重命名应在节点进入策略组前完成，并保持地区、用途与来源信息简短明确。不要把订阅到期时间、剩余流量等动态文字混入长期过滤条件，因为上游更新这些文本后，正则表达式会产生意外匹配。

proxy-groups:
  - name: 总出口
    type: select
    proxies:
      - 主订阅自动
      - 备用订阅自动
      - DIRECT

  - name: 主订阅自动
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 备用订阅自动
    type: fallback
    use:
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

覆写范围越小，更新成本越低

长期覆写建议只保留本机确实需要的内容：局域网直连规则、DNS 选择、TUN 参数、自建策略组和少量业务例外。不要复制整份上游配置再修改，因为那会失去订阅更新带来的节点变化。若必须维护完整配置，应明确把订阅降级为节点 provider，只从中读取代理节点，所有策略与规则由本地配置负责。

合并失败时按三个层次检查。语法层看 YAML 缩进、列表符号和重复键；引用层看策略组、provider 和规则名称是否存在；运行层看客户端是否真正选用了生成后的配置。配置能够加载但节点为空，通常是 provider 或过滤问题；配置无法加载，优先查重复名称和未知字段；更新后本地设置消失，则是覆写执行顺序或保存位置错误。

建立回退点比增加更多自动处理更重要。保留一份已验证可用的基础配置，记录每个本地片段的用途，并在修改后执行重载测试。若客户端更新或迁移设备，先加载基础配置确认内核与网络正常，再逐个恢复覆写。不同平台客户端可在下载中心选择，首次迁移流程则参考使用指南。

CHAPTER 07

外部控制面板

外部控制接口用于读取连接、日志、规则和策略组状态，也可以切换策略、关闭连接或重载配置。它是排查工具，不是流量转发入口。控制面板只是调用内核提供的 API，页面本身不会替代内核，也不会自动修复配置。遇到界面显示离线时，先确认控制地址和认证，再确认内核进程是否运行。

监听地址决定暴露范围

external-controller 指定控制接口监听地址。只在本机使用时，优先绑定 127.0.0.1；绑定 0.0.0.0 会让同一网络中的其他设备有机会访问该端口，必须配合访问控制和防火墙。不要为了让浏览器页面连接成功就直接扩大监听范围。先确认面板与内核是否在同一设备，同一设备使用回环地址最简单。

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
external-ui: ./ui
external-ui-name: dashboard
external-ui-url: https://example.com/dashboard.zip

secret 是控制接口认证信息，面板连接时需要填写相同内容。修改后旧面板会立即失去访问权限，这是正常现象。认证失败通常表现为接口可达但无法读取策略或连接。不要把控制密钥写进公开页面、截图或共享配置；向他人提供诊断信息时，应删除控制地址、认证字段、订阅地址和节点凭据。

external-ui 指向本地静态面板目录，external-ui-url 可用于获取面板文件。内核 API 与面板文件是两个部分：API 正常但页面空白，可能是 UI 文件路径错误；页面能打开但没有数据，可能是控制地址、跨域设置或认证错误。分开测试才能确定故障在哪一层。

跨设备访问需要额外限制

确需从局域网另一台设备访问时，可以把监听地址改为局域网可达接口，并在系统防火墙中只允许可信网段访问该端口。路由器端口转发和公网监听会显著扩大风险，不应作为常规远程管理方式。更稳妥的做法是通过受控的私有网络或本地隧道访问回环接口，并保持认证开启。

浏览器面板通过 HTTP 或 WebSocket 连接控制接口。若面板使用 HTTPS，而控制接口是普通 HTTP，浏览器可能拦截混合内容。此时应让面板与 API 通过同一受控入口访问，而不是关闭浏览器安全限制。出现 WebSocket 反复断开时，还要检查反向代理是否正确转发升级头、系统休眠是否暂停内核，以及防火墙是否回收空闲连接。

利用面板按层检查请求

连接列表至少要看四项：目标域名或 IP、命中规则、策略链、最终节点。若域名为空，回到 DNS 与嗅探章节；若规则不对，检查规则顺序；若策略链正确但最终节点异常，检查策略组当前选择；若所有信息都正确但连接失败，再看节点握手、UDP 支持和本地网络。这个顺序能避免看到“超时”就直接更换所有配置。

规则页面通常可以确认 provider 是否加载、规则数量是否存在，但不要用数量判断质量。连接日志更重要：选择一个固定目标，关闭旧连接，再发起一次请求，观察从域名到出口的完整路径。日志级别使用 info 足够日常定位；只有需要查看握手和规则细节时临时切到 debug，完成后恢复，避免大量日志掩盖关键事件。

面板切换策略后，已有长连接不一定立即迁移到新节点。验证出口时应关闭对应旧连接，必要时重启目标应用，再发起新请求。浏览器标签页、下载任务和即时通信软件会维持连接池，只看策略组界面已经切换并不能证明当前请求使用了新出口。

保存一条可重复的综合排错路径

当配置经过多次修改后，先导出当前运行配置和最近日志。随后关闭 TUN，仅保留系统代理，确认基础节点可连接；再启用 DNS，检查固定域名解析；然后恢复规则集，确认命中；最后依次开启 Fake-IP、嗅探和 TUN。每恢复一层都使用同一个测试目标。若某一步开始失败，故障就在刚恢复的层或它与前一层的交界处。

如果只有个别节点超时，按节点超时无法连接的排查顺序检查；如果整体速度下降，参考速度慢分层排查区分节点、线路与本地设置。配置文件加载失败时则回到语法和引用关系，不要把连通性文章中的换节点步骤套到解析错误上。