Clash 进阶配置手册

策略组类型与实战

策略组是规则与实际出站之间的中间层。规则不必逐条写具体节点名称，而是指向稳定的组名；组内再决定手动选择、自动选择或故障切换。这样更新订阅时，即使节点名称发生变化，只要组名和提供器引用保持一致，分流规则就不需要跟着重写。开始设计前先区分三种对象：节点负责连接远端，提供器负责收集节点，策略组负责选择出口。它们的名称可以自定，但引用必须逐字一致，包括空格与大小写。

先确定手动选择还是自动切换

select 适合需要固定出口的服务，用户在代理页选择组内成员，内核按选择结果出站。url-test 定期向测试地址发起探测，在可用成员之间选择响应较快的出口；tolerance 用于减少小幅差异引发的频繁切换，不是节点质量评分。fallback 按成员顺序寻找可用出口，适合主线路与备用线路的关系。load-balance 在连接之间分配出口，不会把单个连接的带宽叠加，也不保证不同请求始终使用相同出口。

登录、支付或需要会话稳定的业务，优先放进手动选择组，而不是追求每次探测都更快。自动组切换后，已经建立的连接通常不会立即迁移；新连接才会使用新的选择结果。因此浏览器里同一页面的不同资源可能短暂来自不同出口。排查这类情况时，先固定一个节点、关闭旧连接并重新打开页面，再判断服务自身是否限制出口变化。不要把网页一次加载失败直接归因于规则语法。

用两层结构分开日常选择与自动候选

下面的片段假设已有名为 primary 的 proxy-providers 提供器，具体导入方式见覆写章节。自动组读取提供器的成员，上层手动组允许在自动结果和直连之间选择。测试 URL 是连通性探测目标，不是订阅地址；访问是否成功会受到出口、DNS 和目标服务策略共同影响。interval 的单位是秒，设置得过短会增加探测请求，尤其不适合后台受限的移动设备。

# 配置片段：依赖已有的 primary 节点提供器
proxy-groups:
  - name: 自动候选
    type: url-test
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: 日常出口
    type: select
    proxies:
      - 自动候选
      - DIRECT

rules:
  - MATCH,日常出口

组间引用可以嵌套，但不能形成环。比如日常出口包含自动候选，自动候选又引用日常出口，就没有可以最终落地的出口。检查时从规则目标开始逐层追踪，直到真实节点或 DIRECT。若客户端显示组为空，先看提供器有没有加载成功，再检查过滤条件是否排除了全部节点；不要用增加更多嵌套层来掩盖成员缺失。某些客户端会记住上次选择，但名称变化后可能恢复默认成员，更新订阅后应重新核对重要业务组。

把测试结果与真实访问分开验证

代理页的探测结果只说明某个出口访问指定测试目标的表现。真实应用可能使用不同域名、不同端口或 UDP，不能据此推断所有业务都可用。验证策略组应同时检查连接页里的命中规则、最终出站和目标主机；若自动组正常而视频或游戏异常，固定成员后再测试协议支持与服务区域要求。更多界面操作可查代理选择教程。需要长期固定出口的组，保留一条明确的手动选择路径，比增加多级自动算法更容易维护。

规则集订阅化管理

将规则写进 rule-providers，可以把规则内容与分流决策分开维护。提供器下载或读取一份域名、地址或经典规则列表，rules 再通过 RULE-SET 指定命中后的出口。规则集本身不决定代理还是直连；同一份列表可以在不同配置里绑定不同策略组。维护重点有三项：文件格式能否被正确解析、更新是否可靠、规则在总列表中的位置是否符合优先级。订阅化减少重复编辑，但不会自动解决规则冲突。

behavior 与 format 必须对应文件内容

behavior: domain 表示域名规则集合，ipcidr 表示地址网段集合，classical 表示包含规则类型的经典规则集合。format 描述文件编码形式，常见为 YAML 或纯文本；选择 YAML 时通常需要 payload 层。不能因为文件名以 .yaml 结尾就认定内容符合要求，更不能把包含节点和策略组的完整订阅放到规则提供器里。加载报错时打开实际文件检查首行、缩进和条目内容，而不是只改扩展名。

先用本地规则集建立可验证的最小案例。下面两段分别属于主配置和独立规则文件；路径相对内核配置目录解析，图形客户端实际目录应从配置管理或运行日志确认。规则集只列出需要直连的文档域名，总规则仍保留局域网绕行和最后兜底。示例中的日常出口沿用上一章策略组，缺少该组时必须先补齐，不能将这段代码单独当作完整订阅导入。

# 主配置片段
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,local-domains,DIRECT
  - MATCH,日常出口

# 独立文件：rules/local-domains.yaml
payload:
  - '+.example.com'
  - '+.example.org'

远程更新需要保留可回退的本地路径

远程提供器使用 type: http，并配置 url、path 和 interval。地址应来自能够确认内容格式的规则源，缓存路径不能与另一份提供器共用，否则下载结果可能相互覆盖。第一次启动时如果下载规则集需要代理，而建立代理又依赖尚未加载的规则，就可能出现启动依赖问题。应让关键引导域名有明确可达的路径，并保留一份本地基础规则。更新失败时，是否继续使用缓存应从日志和文件状态确认，不能只看客户端更新按钮的提示。

订阅间隔不是内容质量保证。频繁拉取一份来源不明、分类边界不清的列表，可能让登录接口和静态资源分别走不同出口。引入新规则集前，先写下希望覆盖的业务范围，再检查代表性域名是否包含在集合中。对于体积较大的经典规则集，留意加载时间和设备资源；路由器环境还要考虑存储写入与可用空间。远程内容更新后，连接页的新连接才适合用来验证，不要拿一直存活的旧连接判断新规则是否生效。

顺序决定冲突时的结果

规则按顺序匹配，命中后通常不再继续向下寻找。具体域名例外应放在大范围集合之前，兜底 MATCH 放在最后。地址规则带 no-resolve 时，不会为了该条规则主动把域名解析成地址；如果当前连接只有域名，可能无法靠这条地址规则命中。域名规则、地理数据规则和地址规则需要按业务目的组合，不是数量越多越完整。涉及大陆站点直连的细节，可继续阅读分流规则实战。

DNS 配置优化

DNS 配置不只是填写解析服务器地址。一次连接可能包含代理节点域名解析、业务域名解析和 DNS 上游自身的引导解析，它们的出口并不必然相同。先明确应用把查询交给谁，再确认内核如何访问上游，最后检查返回地址是否适合后续路由。浏览器安全 DNS、系统加密解析和应用自带解析都可能绕过客户端的 DNS 入口。只改 nameserver，无法证明所有应用的查询都经过了内核。

区分引导解析、节点解析与业务解析

default-nameserver 主要用于解析 DNS 上游的域名，应使用能够直接引导的地址形式；nameserver 是一般业务查询的上游；proxy-server-nameserver 可单独处理代理节点的域名，避免节点连接依赖尚未建立的代理路径。nameserver-policy 则对指定域名分配特定解析器，适合内部域名、特定网络服务或明确的解析边界。这些字段解决的是不同阶段，不应简单复制同一串地址到所有位置。

下面是可合并的 DNS 片段，使用 Fake-IP 作为业务连接的域名映射方式。所列解析地址是示例选择，不保证在所有网络环境可达；采用前应先测试当前网络的连通性。监听地址绑定回环，只接受本机请求。若路由器需要服务局域网设备，应另行设计监听、防火墙和访问范围，不能直接把桌面示例改成所有接口监听后就认为部署完成。

# 配置片段：不包含代理与规则定义
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
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

按解析目的调整，而不是叠加服务器

内网域名通常需要交给本地网关或组织提供的解析器，公共解析器未必知道这些记录。确认实际内网域名后，可以通过 nameserver-policy 将其定向到内网 DNS，同时为这些域名设置适当的 Fake-IP 例外。这里存在两个独立决定：是否返回映射地址，以及由哪个上游提供真实结果。把域名加入过滤列表，只改变增强模式的处理方式，并不会自动让查询转向正确的内网解析器。

fallback 与 fallback-filter 用于筛选、比较不同上游结果，不等同于简单的主备服务器顺序。若没有明确的筛选目标，先维护少量可解释的上游比堆叠很多地址更容易排错。respect-rules 可让 DNS 上游连接遵循路由规则，但启用前必须考虑节点解析的独立路径，并配置合适的 proxy-server-nameserver。否则可能出现“解析上游要先连代理，连接代理又要先解析”的循环依赖。

分别验证解析结果与查询出口

可以对本地监听执行 nslookup example.com 127.0.0.1，但这个命令默认查询标准 DNS 端口，不能直接测试上面使用的 1053 端口。支持指定端口的工具可执行 dig @127.0.0.1 -p 1053 example.com。收到映射地址只说明该次查询进入了 Fake-IP 处理，不说明所有查询都走相同路径。继续检查浏览器解析设置、TUN 的 DNS 劫持和日志中的上游连接，才能判断应用实际行为。

修改 DNS 后，旧缓存可能来自系统、浏览器和内核多个层级。先新建连接，再按需要清理缓存；重启客户端不一定清掉浏览器缓存。若网页域名解析成功而连接失败，检查映射是否仍有效、目标策略组是否可用，以及 IPv6 是否形成另一条访问路径。检测方法与字段组合见DNS 泄漏检测与配置说明。诊断时应描述具体应用和查询路径，不要仅用单个检测站的结果替代全部分析。

TUN 与 Fake-IP

系统代理主要影响遵循系统代理设置的应用，TUN 则通过虚拟网卡和路由处理 IP 流量。两者的接管范围不同，不能把系统代理开关开启等同于所有应用已经被接管。Fake-IP 是 DNS 的域名映射机制，也不是 TUN 的另一个名称。两者常一起使用，是因为映射可以让接收到 IP 数据包的内核找回原始域名，从而继续使用域名分流；但 TUN 可以搭配其他 DNS 模式，Fake-IP 也可以在合适的非 TUN 场景中使用。

开启前先确认权限与现有网络环境

在桌面客户端中，先进入设置检查服务模式或相关系统授权，再开启 TUN。Windows 通常需要能够管理虚拟网卡和路由的服务权限，macOS 需要系统授权，Linux 需要相应网络管理权限；具体操作由客户端封装决定。Android 与 iOS 一般通过系统 VPN 能力接管流量，同一设备上的其他 VPN 可能无法同时运行。公司网络、安全软件和既有隧道也可能改变路由，应先记录原有状态，不要在无法识别影响范围时强行增加路由。

下面的代码是网络接管片段。auto-route 让内核建立需要的路由，auto-detect-interface 帮助识别出口接口；多网卡、桥接或已有 VPN 场景仍需实际验证。dns-hijack 用于捕获匹配的 DNS 流量，并非自动识别全部加密 DNS。应用通过 HTTPS 访问自带解析器时，通常不会因为这里写了 53 端口就变成内核的普通 DNS 查询。

# 配置片段：同时依赖已启用的 dns 配置
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

理解 stack 与映射地址的边界

stack 决定 TUN 数据包进入哪种协议栈路径。system、gvisor 和 mixed 的支持情况与行为取决于内核和平台，不应只凭某个选项名称就判断性能更高。优先保留客户端默认值，只有遇到可重复的兼容问题时才单独切换比较。测试要使用同一应用、同一出口与同一网络，观察 TCP、UDP 和局域网连接是否改变；同时修改栈、DNS 与规则，会使结果难以归因。

Fake-IP 返回的是映射用地址，不能拿这个地址直接当作网站真实服务器地址去做地理判断。应用后续连接必须能再次进入持有映射记录的内核，否则这个地址在普通网络中无法作为真实目的地访问。客户端退出、映射记录被清理或应用继续使用旧缓存时，可能出现“刚切换设置就无法联网”。此时先关闭应用旧连接并重新解析，再判断是否需要清理缓存，而不是把整个映射网段加入直连规则。

局域网例外与失败回退

打印机、网络存储、投屏和局域网发现涉及不同协议，只有域名过滤可能不够。先确认服务使用内网域名还是固定地址，再检查网段路由、DNS 解析和组播发现。把确实需要真实地址的域名加入 fake-ip-filter，把确定的内网网段安排为直连，并核对 TUN 路由是否仍允许访问本地接口。不要泛化排除整个业务域名类别；过大的例外会让域名规则失去预期的匹配信息。

开启后完全断网，按权限、虚拟网卡、默认路由、DNS 上游、节点连接的顺序检查。先关闭 TUN 保留系统代理，如果系统代理恢复，问题更可能集中在接管层；如果两者都失败，再检查订阅、策略组和基础网络。记录错误日志后一次只恢复一个设置，必要时回到开启前保存的配置。完整平台操作见TUN 模式开启教程，一般故障可查故障排查分类。

域名嗅探

域名嗅探用于在连接缺少域名信息时，从支持的协议特征中尝试恢复主机名。典型来源包括 HTTP 请求中的 Host、TLS 握手中可见的服务器名称，以及部分 QUIC 握手信息。它不是解密功能，不会让内核读取全部 HTTPS 内容，也不能保证每条连接都能得到域名。正确定位是补充匹配信息：当应用提交的是 IP 地址，或者 DNS 没有经过当前内核时，嗅探有机会让域名规则仍然生效。

先判断是否真的缺少域名

如果连接页已经显示正确域名，并且命中了预期规则，嗅探未必带来收益。应先找一个稳定可重复的案例，观察它是否只显示地址、走了地址规则或直接落入兜底。开启后比较同一业务的新连接，确认是否恢复了正确主机名。不要把开启嗅探当成所有分流问题的统一修复：规则顺序错误、策略组为空、出口不可达和 DNS 上游失败，都需要在各自层级处理。

以下片段启用 HTTP、TLS 与 QUIC 的识别范围。端口数组中的字符串区间属于配置语法，不是网络扫描任务。parse-pure-ip 允许对纯 IP 目标尝试嗅探；force-dns-mapping 在 DNS 映射相关场景下加强嗅探处理。采用之前应确认当前 mihomo 内核识别这些字段，若启动报告未知配置或协议不支持，应先检查客户端实际内核，而不是继续堆叠其他选项。

# 配置片段
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

匹配域名与改写目标是两件事

override-destination 控制是否使用嗅探结果替代原始目标。初次测试保留关闭状态，先观察补充域名对规则匹配的影响；只有业务确实需要按嗅探域名重新确定目标时，再评估开启。应用连接到指定地址，可能是因为内置调度、特殊解析或固定服务端要求。贸然改写目的地会改变应用原本选定的路径，即使嗅探出来的名称看上去正确，也不代表重新解析后一定兼容。

一个 IP 地址可能承载多个域名，连接日志里的地址不能单独代表业务名称。反过来，握手携带的名称也可能是网关、共享入口或中间服务，而不是用户在页面上看到的站点。验证时应同时记录原始目标、嗅探名称、命中规则和最终出站。对一条已经建立的长连接切换嗅探设置，通常不能重新构造它最初的握手信息；需要断开后重新创建连接，才有可比较的样本。

协议限制与兼容性排查

采用加密客户端问候等机制的连接，可能隐藏原本可见的服务器名称；非标准协议、特殊握手和过早失败的连接，也可能没有足够信息。QUIC 使用 UDP，是否能成功还取决于出口对 UDP 的支持以及网络路径，不应把 QUIC 访问失败全部归因于嗅探。测试时可在应用中暂时切换到可比较的 TCP 访问路径，再看域名识别是否改变，但不要据此宣称所有应用都必须禁用 QUIC。

如果开启后只有某个服务异常，先关闭目标改写，再缩小协议与端口范围。确认是特定域名造成问题时，可使用内核支持的 skip-domain 配置排除该域名，并验证排除模式是否符合预期；不是看到一个关键词就加入覆盖过大的通配表达式。也应检查故障是否其实来自新增域名命中了更靠前的规则。嗅探成功后路由结果改变，可能说明原来依赖 IP 的规则被域名规则取代，应该调整规则设计，而不是简单认为嗅探失效。

需要理解域名、地址与规则之间的术语差异，可以查概念速查。日常维护中，嗅探应是有明确目的的补充，而不是每次联网异常都首先打开的总开关。能够解释一条连接为何命中规则，比启用更多识别选项更重要。

本地覆写与多订阅合并

远程订阅负责交付节点或完整配置，本地覆写负责保留设备自己的端口、DNS、规则例外和策略组织。直接编辑下载下来的订阅文件，常会在下一次更新时被替换。正确做法是先确认客户端支持哪一种覆写：合并 YAML、配置扩展、脚本处理或独立的本地配置。它们的合并顺序不一定相同，字段同名时也未必都采用深层合并。不能把某款客户端的操作步骤直接套到另一款客户端。

先找出最终加载文件

在配置页选择当前订阅，进入其扩展或覆写入口；菜单名称以客户端实际界面为准。保存后重新加载，再从运行配置、配置预览或内核日志检查最终结果。源文件写着 mixed-port: 7890，不代表运行端口一定是 7890，因为客户端全局设置可能再次覆盖它。应把“远程原文”“本地覆写”“最终配置”分开保存，避免仅查看编辑器内容就判断配置已生效。若客户端提供内核配置检查，先检查通过再重载。

对于多份订阅，优先把节点来源组织成多个 proxy-providers，再让策略组引用它们，而不是直接拼接两份完整 YAML。完整订阅可能同时带有 dns、rules 和同名策略组，简单连接文本会出现重复顶层键或引用冲突。下面展示本地节点提供器：两个文件各自应包含有效的 proxies 数组，不是包含全部规则与设置的完整配置。文件路径应位于内核实际可访问的配置目录中。

# 主配置片段：依赖两份本地节点文件
proxy-providers:
  primary:
    type: file
    path: ./providers/primary.yaml
  backup:
    type: file
    path: ./providers/backup.yaml

proxy-groups:
  - name: 多订阅出口
    type: select
    use:
      - primary
      - backup
    proxies:
      - DIRECT

rules:
  - MATCH,多订阅出口

数组合并最容易改变结果

标量字段通常只有一个最终值，但规则、节点和策略组是数组。覆写工具可能替换整个数组，也可能追加到末尾；两种行为对 rules 的影响完全不同。本地例外如果被追加到已有 MATCH 后面，就不会按预期命中。保存后应展开最终规则列表，确认例外确实位于兜底之前。策略组数组也要检查是否保留原有引用，不能只确认新组出现，却忽略原组已被整体替换。

多来源节点可能重名。显示相同的名称不一定意味着相同服务器，也可能让选择记录和规则引用变得含糊。使用客户端支持的重命名或提供器命名管理时，保持变换规则稳定，并记录变换作用于哪个阶段。不要频繁根据临时状态给名称添加前缀，否则更新后手动选择可能失效。过滤表达式也应先在小范围测试；意外匹配全部节点或排除全部节点，都可能让组的行为偏离设计。

订阅格式与远程提供器边界

远程提供器使用 HTTP 时，地址必须返回内核能够解析的节点集合。通用 Base64 链接集合、单条协议链接与完整 Clash YAML 不是同一种输入，不能只把 URL 换进 proxy-providers 就期待自动转换。格式判断与转换流程见订阅格式对照。订阅链接可能包含访问凭据，分享日志、截图和配置时应移除这些部分；不要把真实链接交给无法确认处理方式的在线转换服务。

维护时保留一份已知可用的最终配置，以及对应的覆写源。每次更新先确认提供器成员数量与重要组是否有成员，再检查关键规则和 DNS 字段；如果失败，先停用最近增加的覆写，恢复原订阅运行，不要同时删除所有来源。脚本覆写尤其需要留意异常分支：输入结构变化时，脚本应明确失败或保留原结果，不能静默返回缺少节点的配置。对于只需要少量端口和规则例外的用户，简单 YAML 覆写通常比复杂脚本更容易检查。

外部控制面板

外部控制接口用于读取运行状态、切换策略组、查看连接与管理配置，控制面板是访问这个接口的网页前端。它与应用使用的代理端口属于不同服务：浏览器访问面板不等于浏览器流量已经走代理，代理端口能连接也不代表控制接口正常。配置前先明确面板运行在本机、局域网设备还是服务器，再确定接口应该监听哪些地址。对于普通桌面使用，本机回环监听通常更容易控制访问范围。

区分接口地址与静态页面目录

external-controller 指定控制接口的监听地址，external-ui 指向面板静态文件目录。目录里需要有实际的入口文件和配套资源，只创建一个空文件夹不会生成可用面板。可以把确认来源的静态面板文件放到内核工作目录，再配置相对路径；如果客户端已经集成面板，应优先使用其提供的管理入口，避免同时维护两套位置不同的前端文件。相对路径的解析基准仍以实际运行目录为准。

# 配置片段：ui 目录需已有面板静态文件
external-controller: 127.0.0.1:9090
external-ui: ./ui
secret: "your-controller-secret"

示例密钥仅用于展示字段，实际使用必须自行设置足够长、独立且不公开的值。密钥不应写进可公开访问的文章、截图或仓库，也不要为了分享面板方便而嵌入页面链接。控制接口具有修改运行状态的能力，不能按只读信息页来部署。若客户端自动管理 secret，应通过它的授权方式连接，而不是覆盖客户端生成的值后导致内置界面连接失败。

从本机验证开始，再考虑局域网

先在同一台设备上检查端口是否监听，再访问已配置的静态面板路径，并填写接口地址和密钥。若页面能打开但连接失败，说明静态资源与 API 是两条不同链路，应检查地址、认证和浏览器报错。下面的命令用于展示带认证的本机查询方式，示例密钥应与本地配置一致；测试结束后避免把包含实际密钥的命令记录分享到外部。

curl --header "Authorization: Bearer your-controller-secret" \
  http://127.0.0.1:9090/configs

将面板放在另一台设备后，127.0.0.1 指向的是浏览器所在设备，不再是运行内核的主机。应填写内核主机实际可达的地址，并明确配置监听与防火墙范围。allow-lan 控制代理服务的局域网访问行为，不能把它当作控制接口是否开放的总开关。控制接口的监听地址需要单独检查；即使代理仅供本机使用，错误的接口绑定仍可能暴露管理能力。

浏览器安全限制与远程部署

HTTPS 面板访问 HTTP 接口，可能受到混合内容限制；来自不同来源的页面也可能遇到跨来源访问限制。应根据实际部署选择同源访问或安全的反向代理方式，而不是关闭浏览器保护来绕过报错。需要调整控制接口的跨来源设置时，只允许确定的面板来源，不要把所有来源都开放当作默认方案。页面显示连接失败时，浏览器控制台通常能区分网络不可达、认证失败和安全策略拦截。

不建议把控制接口直接暴露到公网。确实需要远程管理时，应使用有访问控制的私有网络或经过认证的安全入口，并限制来源、配置加密传输和保留回退通道。密钥认证只是其中一层，不能替代网络边界。远程修改规则和策略组前，确保当前管理连接不会被刚修改的规则切断；服务器环境尤其要保留本地或其他可用的维护路径，避免一次配置重载后失去控制。

外部面板适合需要细看规则与连接的用户，不是完成基础连接的必需步骤。若只是导入订阅和选择出口，先使用客户端内置界面；各区域职责可查客户端界面逐区讲解。排错时先确认内核本身运行正常，再处理面板资源、接口访问和浏览器限制，避免把前端连接错误误判为节点故障。

端口设置与配置验证

端口是应用连接内核服务的入口，不是远端代理节点的服务器端口。mixed-port 同时接受 HTTP 与 SOCKS 代理连接，port 和 socks-port 可分别提供对应服务。控制接口、DNS 监听和代理入口各有用途，不能因为都写着本机地址就相互替换。常见错误是把 9090 填进浏览器代理设置，或者把 7890 当成 DNS 端口；先明确协议，再确认地址和端口，比反复更换数字更有效。

建立字段与服务的对应关系

本机使用先保持 allow-lan: false，让应用通过回环地址连接。需要给局域网设备提供代理时，再明确绑定地址、设备访问权限和防火墙规则。共享代理不等于共享控制接口，两者应分别设计。路由器与桌面系统的本地防火墙行为也不同，不要只确认设置按钮已经打开；必须从需要使用代理的设备实际发起连接，才能验证跨设备访问链路。

# 配置片段：本机代理入口
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

每次只验证一个变化

修改前保存可用配置，并记下当前网络、策略组选择与客户端运行模式。若客户端允许导出最终运行配置，应同时保存它，因为订阅原文未必包含客户端附加的设置。改动后先做语法与引用检查，再重载；原生内核可在对应工作目录使用 mihomo -t -f config.yaml 检查配置。这个命令不会代替联网测试，也不会证明远程规则源、节点和 DNS 上游都能够连接。

确认配置加载后，检查端口是否实际监听。Windows 可用 Get-NetTCPConnection -LocalPort 7890 查看本地 TCP 监听，Linux 可用 ss -lntp，macOS 可用 lsof -nP -iTCP:7890 -sTCP:LISTEN。部分命令需要相应权限或系统工具。若端口被另一款客户端占用，应停止冲突进程或选择新端口，并同步修改系统代理与应用设置，而不是只改 YAML 后继续连接旧端口。

可以通过显式代理测试把系统代理因素暂时排除。下面的命令指定 HTTP 代理入口并请求示例域名；成功说明这次请求能通过该入口完成，不代表 TUN、所有规则或 UDP 已正常。对 SOCKS 测试使用带远端域名解析语义的形式，有助于区分本机解析与代理路径解析的影响。测试目标应换成当前要验证的合法业务地址，并避免在日志中留下私有访问参数。

curl --proxy http://127.0.0.1:7890 --head https://example.com
curl --proxy socks5h://127.0.0.1:7890 --head https://example.com

把故障定位到连接路径中的一层

入口连接被拒绝，优先检查进程、监听地址和端口；能进入内核但没有正确域名，检查 DNS、应用解析方式与嗅探；域名正确但出口错误，检查规则顺序和组选择；出口正确但连接失败，再检查节点协议、目标服务和网络路径。临时提高日志详细程度有助于观察，但排错完成后应恢复适当等级，避免长期记录过多连接信息。分享日志前移除订阅地址、认证信息和私人域名。

配置验证最好保留一组固定案例：一个应该直连的站点、一个应该代理的服务、一个局域网目标，以及实际需要的 UDP 应用。每次只改一类字段，确认新连接结果后再继续下一项。若问题仅出现在开机后，检查服务启动与配置加载顺序，参考开机自启教程；如果仅某款应用异常，查使用技巧。稳定的配置不是字段最多，而是每个字段都有明确作用，每个例外都有能够复现的验证方法。