Clash 从零到精通完整手册

核心概念：先理解请求如何经过 Clash

客户端、内核与配置文件的关系

Clash 不是单一界面的名称，而是一套由内核、图形客户端和配置文件共同组成的工作结构。内核负责监听本机端口、解析配置、匹配规则、建立代理连接和处理 DNS；图形客户端负责安装、更新、配置管理、系统代理开关和日志展示；配置文件则描述监听端口、代理节点、策略组、规则与 DNS 行为。mihomo 常被称为 Clash Meta 内核，它延续了 Clash 配置体系，并扩展了协议、规则与系统接管能力。理解三者的边界后，排错会更直接：界面打不开属于客户端层，配置载入失败先检查 YAML，某个网站走错线路则检查规则与策略组。

一次常见的浏览器请求会先进入系统代理或 TUN 虚拟网卡，再送到内核。内核读取请求的域名、目标地址、端口和网络类型，按照配置中 rules 的先后顺序寻找第一条匹配项。匹配项不会直接等同于某个服务器，它通常指向一个策略组。策略组再根据当前选择、自动测试或回退逻辑，决定使用具体代理、直连或拒绝。这个过程可以概括为“流量入口 → 规则匹配 → 策略组 → 出站连接”。任何一层设置不一致，都可能产生“客户端显示已连接，但访问结果不符合预期”的现象。

监听端口与系统代理

Clash 常见入口包括 HTTP、SOCKS 和 mixed-port。HTTP 代理适合支持系统代理或手动代理的软件；SOCKS 能承载更通用的 TCP 请求；mixed-port 在同一端口同时接受 HTTP 与 SOCKS，便于减少端口数量。系统代理开关只是把操作系统的代理地址指向本机监听端口，它不会改变配置文件里的规则，也不能覆盖完全忽略系统代理的应用。遇到“浏览器可用而某个程序不可用”时，应先确认该程序是否读取系统代理；若不读取，再考虑程序内单独设置代理或启用 TUN。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

上面的最小片段表示内核在本机监听混合端口，默认不向局域网其他设备开放，使用规则模式并记录常规级别日志。端口数值可以调整，但调整后必须同步修改系统代理或应用代理中的端口。若启动日志出现监听失败，通常是端口已经被另一个进程占用，可参考Clash 端口被占用的定位步骤查询进程，再决定关闭冲突程序或修改端口。

节点、策略组与规则不是同一层

节点是一个具体出站连接定义，通常包含服务器、端口、协议和认证信息；策略组是对多个节点或其他策略的组织方式；规则负责把请求送到策略组。日常切换线路时应优先操作策略组，而不是反复编辑规则。比如可以建立名为“代理选择”的手动组，再建立“自动选择”的测速组，把二者放入更上层的“默认出口”。视频、下载、工作服务等规则只引用稳定的组名。这样更换订阅或节点时，规则层不需要同步重写。

选择客户端：按平台、内核与管理方式取舍

首选完整图形客户端

大多数用户应从图形客户端开始。本站各平台首推 Clash Plus，它提供常用的平台安装入口、配置管理和连接控制，适合作为首次使用与日常维护的主客户端。Windows、macOS、Android 和 iOS 用户可以先在下载页切换到对应平台，阅读系统要求后再安装。选择客户端时不要只看界面外观，应检查四项基础能力：是否适配当前操作系统与处理器架构，是否使用兼容当前配置的内核，是否提供 Profile 更新与切换，是否能按需要管理系统代理或 TUN。

Windows 与 Linux 还可以选择 Clash Verge Rev 或 FlClash；Windows 可选择 Clash Nyanpasu；Android 可选择 Clash Meta for Android、FlClash 或 Surfboard；macOS 还可见归档状态的 ClashX Meta；Clash for Windows 同样属于停止维护的归档客户端。归档状态不等于旧配置立即失效，但它不适合作为新部署的长期基础。若现有环境仍依赖旧客户端，迁移时应先导出配置与覆盖设置，再在新客户端中逐项恢复，避免同时改变客户端、内核、DNS 和 TUN，导致问题来源无法区分。

区分处理器架构

安装包名称中的 x64、AMD64、ARM64、Apple Silicon 等标识对应不同处理器架构。多数传统 Windows 电脑使用 x64；Windows on ARM 设备需要确认客户端是否提供 ARM64 构建。较新的 Mac 常使用 Apple Silicon，对应 ARM 构建；较早的 Intel Mac 使用 x64 构建。Android 设备通常优先使用 arm64 包，只有在架构不明确或安装失败时再考虑通用包。Linux 不仅要区分 AMD64 与 ARM，还要区分 deb、rpm 和压缩内核文件：桌面发行版适合使用对应包管理格式，服务器与路由器环境则更常直接运行 mihomo 内核。

图形客户端与独立内核的边界

独立 mihomo 内核适合需要精确控制启动参数、配置目录、服务权限和日志输出的环境。它不会自动提供桌面图形界面，也不会替用户修改系统代理。服务器部署时通常通过命令行指定配置目录，再交给系统服务管理器保持运行。桌面用户若只是希望导入订阅并连接，不必从内核压缩包开始；图形客户端已经封装了内核生命周期、Profile 切换和系统设置，更容易定位问题。

还要注意，同一台设备不应让多个客户端同时接管相同端口或同时建立 TUN。迁移时先退出旧客户端，确认后台内核已经停止，再启动新客户端。若新客户端提示端口占用，不要连续改成多个随机端口，应先查明残留进程。若系统代理仍指向旧端口，应先关闭旧代理状态，再由新客户端重新写入。保持“一套活动内核、一份当前配置、一个明确入口”可以显著减少交叉影响。

平台安装：完成权限、入口与首次启动检查

Windows 与 macOS 安装

Windows 安装前先退出正在运行的同类客户端，避免旧内核继续占用监听端口。完成安装并首次启动后，先不要立即打开所有开关。进入设置页确认内核状态、配置目录与 mixed-port，再导入配置。启用系统代理时，客户端会把系统代理地址指向本机回环地址与监听端口。如果浏览器仍沿用旧设置，可先关闭系统代理，再重新启用；若仅商店应用或 UWP 应用无法连接，需要检查应用是否允许访问本机回环，而不是直接修改全局规则。

macOS 安装时需要根据处理器选择 Apple Silicon 或 Intel 构建。第一次打开若被系统安全策略拦截，应在系统设置中核对应用来源与提示内容。启用系统代理通常需要授权修改网络设置，启用 TUN 或网络扩展还会出现额外授权。授权完成后应回到客户端确认开关状态，而不是只以系统弹窗消失为准。若旧客户端曾安装辅助服务，迁移前应从旧客户端正常关闭服务，避免两个辅助组件同时尝试修改网络配置。

Android 与 iOS 安装

Android 客户端通常通过系统 VPN 接口接管流量。首次启动连接时，系统会显示 VPN 授权，确认后状态栏出现相应连接标识。若连接在切换应用后很快停止，应检查系统的电池优化、后台活动和省电限制。部分厂商系统会在锁屏后回收后台服务，需要把客户端加入允许后台运行的列表。分应用代理、绕过局域网和 IPv6 行为由客户端与配置共同决定，初次测试应先保持简单设置，确认普通网页访问正常后再增加分应用规则。

iOS 使用 Clash Plus 时，通过 App Store 安装并在首次连接时授权添加 VPN 配置。系统同一时间只能保持一套活动 VPN 配置，若已有其他网络工具连接，应先断开再测试。切换无线网络和蜂窝网络后，观察客户端是否仍保持连接，并用实际访问结果确认规则生效。移动系统会隐藏部分底层日志，因此排错时应记录问题发生在无线网络、蜂窝网络还是两者都出现，并确认是否只影响某个应用。

Linux 桌面与内核部署

Linux 桌面安装 deb 或 rpm 包后，仍需确认桌面环境是否读取系统代理设置。不同桌面环境对 HTTP、HTTPS 与 SOCKS 的配置入口不同，客户端的“系统代理”按钮未必覆盖所有会话。可先在浏览器内测试，再使用明确支持代理环境变量的命令验证。独立内核部署时，应为配置创建固定目录，并以前台方式完成第一次启动，让语法错误直接显示在终端中。确认配置可载入后，再交给服务管理器。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

-d 指定工作目录，内核会从该目录读取配置及相关数据文件。实际可执行文件名和放置路径应以下载包为准。若准备长期运行，应建立权限受限的专用用户，明确配置文件和日志目录的所有者，不要为了绕过权限问题直接扩大整个目录的访问范围。服务启动失败时先在前台运行同一命令，比只查看服务状态更容易看到 YAML 行号、端口冲突或资源文件缺失。

首次启动后的四项确认

安装完成后按固定顺序确认：第一，客户端显示内核已启动；第二，当前 Profile 已选中且没有解析错误；第三，系统代理或 VPN/TUN 只有一种预期入口处于活动状态；第四，策略组中存在可选择的出站。接着访问一个普通站点并查看连接记录，确认请求进入内核、命中规则且产生出站。不要只用客户端首页的状态文字判断成功，因为系统代理可能尚未写入、应用可能绕过代理，或者 DNS 仍由其他网络组件处理。

订阅与配置：建立可更新、可回退的 Profile

Profile 是完整配置入口

Profile 可以来自本地 YAML 文件，也可以来自远程订阅地址。它不只是节点列表，还可能包含策略组、规则、DNS 和覆盖设置。导入远程地址后，客户端通常会把内容保存为本地副本，并记录更新来源。后续点击更新时，远程内容可能覆盖同一 Profile 中的手工修改，因此长期自定义不应直接散落在自动更新文件里。更稳妥的方式是保留原始订阅作为基础，再使用客户端提供的覆写、脚本或单独维护的本地配置增加规则。

管理多个 Profile 时，应给每份配置使用能表达用途的名称，例如“日常规则”“移动网络测试”“本地最小配置”，不要只保留一串导入时间。切换 Profile 后，内核需要重新载入配置，策略组的选择可能恢复为该配置自己的状态。切换完成后检查当前文件名、模式和主要策略组，避免界面显示已切换但实际仍使用上一份配置。关于多配置的更新关系和切换逻辑，可继续阅读Clash Profile 导入与多配置管理。

YAML 的结构与缩进

Clash 配置使用 YAML。缩进表示层级，通常使用空格，不应混入制表符。列表项以连字符开始，键名后的冒号需要与值保持正确结构。名称中含有冒号、井号、逗号或其他特殊字符时，使用引号更稳妥。配置载入失败时应先看日志给出的行号，再检查该行及其上方的层级，因为实际错误常来自前一个列表项缩进不完整。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: "代理选择"
    type: select
    proxies:
      - "自动选择"
      - DIRECT

  - name: "自动选择"
    type: url-test
    proxies:
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,代理选择

这个片段展示了层级关系，但“自动选择”组只有 DIRECT，因此仅用于说明语法。实际节点通常由订阅或代理提供器写入。MATCH 是最后兜底规则，应放在规则列表末尾；它前面的规则会优先处理局域网和其他明确目标。策略组名称必须与规则中引用的名称完全一致，包括空格和大小写。修改名称后若忘记同步规则，配置可能载入失败，或者请求被送往不存在的策略。

远程更新与本地覆写

订阅更新失败时，先区分“地址无法访问”“服务器返回错误”“内容不是有效 YAML”和“客户端写入失败”。可以查看更新日志中的网络状态与解析结果。不要连续点击更新，因为重复请求不会修复地址、权限或格式问题。若旧副本仍可使用，先保留当前活动配置，再单独排查更新来源。更新成功后若节点变化但规则未变化，属于配置提供方式的差异；若策略组名称也变化，则本地规则引用可能需要同步调整。

覆写设置适合放置本机端口、局域网访问、DNS 偏好和少量固定规则，但应记录覆写应用在导入前还是导入后。后应用的同名字段通常会覆盖前者，列表字段则可能是替换、前置或追加，具体由客户端实现决定。修改前导出可工作的配置，修改后只做一类变化并立即重载。若同时更改端口、DNS、规则和 TUN，出现故障时很难确定是哪一项造成。

代理模式：理解 Rule、Global 与 Direct 的作用范围

Rule 模式作为日常默认

Rule 模式会逐条读取规则，并把请求交给匹配到的策略组。它适合长期使用，因为局域网、常用直连目标、代理目标和拒绝目标可以分别处理。规则匹配采用从上到下、首次命中即停止的方式，所以排序比规则数量更重要。更具体的规则应放在更宽泛的规则之前，例如完整域名放在域名后缀之前，私有网络地址放在通用 IP 规则之前，最终使用 MATCH 处理未命中的流量。

规则模式下的“代理选择”不是模式开关，而是策略组当前出站。用户可以在策略组中选择具体节点、自动测试组或 DIRECT。若某个网站走错线路，应查看连接记录中的命中规则和策略名，而不是先切到全局模式。全局模式可以用于快速判断节点本身是否可用，但它会绕过原有分流逻辑，不能证明规则配置正确。

Global 模式用于隔离规则问题

Global 模式通常把进入内核的流量统一送到全局策略组。它适合短时间诊断：如果 Rule 模式访问失败，而 Global 模式通过同一节点可以访问，问题更可能位于规则、DNS 解析结果或策略组引用；如果两种模式都失败，则应继续检查节点、目标网络、监听入口和系统权限。完成诊断后应切回 Rule，避免局域网、软件更新和本地服务也被不必要地送往代理。

全局模式不会让原本没有进入内核的流量自动进入。某个应用若忽略系统代理，即使客户端切到 Global，也可能仍然直连。此时连接记录中通常看不到该应用请求。应检查应用自身代理设置，或在确认需求后启用 TUN。这个判断非常关键：模式决定“进入内核后的处理方式”，系统代理与 TUN 决定“请求是否进入内核”，两者不能互相替代。

Direct 模式与真正的退出

Direct 模式通常让进入内核的请求直接连接目标。它适合对照测试，但不等同于完全退出客户端。系统代理仍可能指向 Clash，DNS 仍可能由内核处理，应用连接记录也可能继续出现。若需要恢复操作系统原始网络路径，应先关闭系统代理或 TUN，再停止内核；如果客户端提供“恢复系统代理”操作，应通过客户端正常执行，避免系统保留失效的本机代理地址。

延迟数值只用于相对参考

策略组中的延迟测试通常向固定地址发起连接，用于判断节点是否可达和比较特定测试路径。它不等于访问所有网站的真实耗时，也不能完整体现带宽、丢包、连接复用、DNS、拥塞和目标服务器状态。自动测试组应选择稳定、响应体较小的测试地址，并设置合理间隔。间隔过短会增加额外连接，间隔过长则无法及时发现线路变化。具体原理可参考Clash 延迟测试数值解析。

规则分流：从匹配顺序到自定义策略

常见规则类型

DOMAIN 匹配完整域名，适合精确指定单个主机；DOMAIN-SUFFIX 匹配某个域名及其子域，适合覆盖一组同源服务；DOMAIN-KEYWORD 按域名中的关键词匹配，范围较宽，应谨慎放置；IP-CIDR 与 IP-CIDR6 匹配地址段；GEOIP 按地址数据库归类；PROCESS-NAME 在支持进程识别的平台按程序名匹配；RULE-SET 引用外部规则集合。最后的 MATCH 接收所有此前未命中的请求。

域名规则通常在 DNS 得出目标地址前就能判断，IP 类规则则依赖解析结果或实际目标地址。某些连接直接访问 IP，没有域名信息，只能由 IP 规则或兜底规则处理。启用 no-resolve 可以阻止某些 IP 规则为了匹配而触发额外解析，但是否适用取决于规则类型和配置目标。编写规则时不要只追求覆盖数量，应先定义策略组职责，再让规则引用稳定的职责名称。

rules:
  - DOMAIN,updates.example.test,DIRECT
  - DOMAIN-SUFFIX,example.test,代理选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,代理选择

示例使用保留测试域名说明语法。第一条完整域名规则优先于后面的后缀规则，因此更新主机直连，其他同后缀主机交给“代理选择”。私有地址段保持直连，最终由 MATCH 兜底。实际配置中还应根据本地网络加入必要的地址段，并确认局域网服务不会被送往远程出站。

规则顺序决定最终结果

Clash 不会在全部规则中寻找“最精确的一条”，而是使用第一条匹配规则。因此，一条宽泛的 DOMAIN-SUFFIX 若放在前面，会让后面的完整域名例外永远没有机会命中；MATCH 若被提前放置，后续所有规则都会失效。调整规则时应先在连接记录中找到目标域名、目标地址和当前命中项，再把例外规则放到产生冲突的宽规则之前。

规则集同样遵循当前位置的顺序。引用多个规则集时，应明确每个集合的范围和更新来源。不要同时加载大量职责重叠的集合，否则同一域名可能被前一个集合提前截获，后续规则难以理解。可把规则按“本地与私有网络、明确直连、明确代理、特定服务、地址规则、最终兜底”分段维护，并在每次变更后选择几个代表目标验证连接记录。

策略组设计比堆叠规则更重要

常见策略组类型包括 select、url-test、fallback 和 load-balance。select 由用户手动选择；url-test 周期比较候选出站；fallback 按顺序选择可用项；load-balance 在多个出站间分配连接。自动测试不是适用于所有任务的统一答案：需要固定出口的登录会话更适合手动组，需要连续性的下载任务也不应频繁切换。可以先建立“手动选择”和“自动选择”，再按工作、媒体、下载等用途建立上层组。

策略组可以引用其他策略组，形成分层结构，但层级过深会增加排错成本。建议让业务规则只引用少量稳定的顶层组，底层节点变化由订阅和自动组处理。删除策略组前先全文搜索其名称，确认没有规则、代理提供器或其他策略组继续引用。自定义规则的完整修改方法可结合配置实际情况查阅站内使用文档，迁移到 mihomo 时则可阅读mihomo 内核特性与配置差异。

DNS 与 TUN：处理系统接管和域名解析

为什么系统代理之外还需要 TUN

系统代理只影响主动读取代理设置的应用。游戏、部分命令行工具、独立更新器和使用特殊网络栈的程序可能直接建立连接。TUN 会创建虚拟网络接口，把符合路由条件的 IP 流量送入内核，因此覆盖范围更广。它也带来额外变量：管理员权限、路由表、DNS 劫持、虚拟网卡、其他 VPN 和安全软件都可能影响结果。初次启用 TUN 前，应先让普通系统代理在 Rule 模式下稳定工作，再把 TUN 作为单独阶段测试。

启用 TUN 后，如果网页全部无法访问，先检查内核日志中虚拟接口是否创建成功，再检查默认路由与 DNS。若只有局域网设备不可达，应检查私有地址是否绕过 TUN、路由是否保留本地网段，以及规则中是否将局域网地址设为 DIRECT。若关闭 TUN 后网络没有恢复，应退出客户端并检查系统是否仍保留虚拟接口或失效代理设置。不要在故障状态下反复切换多个 VPN 工具，它们可能持续改写同一套路由。

DNS 模式与请求路径

DNS 决定域名如何转换为地址，也会影响域名规则能否正确关联到连接。若系统 DNS 在 Clash 之外完成，域名请求可能绕过既定上游；若应用自行使用加密 DNS，内核可能只能看到目标地址。Clash 的 DNS 配置可指定监听、启用状态、IPv6 行为、增强模式、默认解析器和上游服务器。上游选择应兼顾可达性与用途，不应简单堆叠大量地址。配置越复杂，越需要记录每一组解析器负责什么阶段。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - "https://dns.alidns.com/dns-query"

fake-ip 模式会为域名返回保留地址段中的映射地址，让内核在后续连接中保留域名关系，便于规则匹配。某些局域网服务、设备发现、登录验证或对解析结果有特殊要求的域名可能不适合 fake-ip，需要加入过滤列表。过滤项不应无限增加；每次增加前先确认故障确实由 fake-ip 映射引起，并记录目标域名。若改用 redir-host，解析与连接行为会不同，切换后应清理系统和应用 DNS 缓存再比较。

TUN 配置的关键字段

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - "any:53"
    - "tcp://any:53"
  auto-route: true
  auto-detect-interface: true
  strict-route: false

stack 决定 TUN 使用的网络栈实现，mixed 常用于兼顾不同流量；dns-hijack 把常规 53 端口的 DNS 请求交给内核；auto-route 自动写入必要路由；auto-detect-interface 尝试识别当前出口网卡。严格路由能减少部分流量绕行，但也可能与虚拟机、容器、局域网共享和其他 VPN 冲突。调整这些字段时应逐项测试，不要直接复制一份包含大量平台特定参数的配置。

在 Windows 上，TUN 通常需要提升权限或辅助服务；macOS 需要网络扩展或相应授权；Linux 需要访问 TUN 设备和修改路由的能力；移动端通常通过系统 VPN 接口实现。相同 YAML 在不同平台上不一定具有完全相同的权限条件。出现问题时应把“配置语法正确”和“操作系统允许执行”分开检查。

检测解析是否按预期运行

DNS 排错要同时观察系统侧和内核侧。先确认系统 DNS 请求是否进入 Clash，再查看内核选择了哪个上游、返回了什么类型的结果，最后查看目标连接命中了哪条规则。检测网站的单次结果可能受到浏览器安全 DNS、缓存、IPv6 和网络出口影响，不能只看一个结论。可更换浏览器、关闭浏览器独立 DNS 后复测，并比较连接日志。更完整的检查路径见Clash DNS 泄漏检测与防护配置。

日常维护：更新、备份、日志与故障隔离

建立可回退的更新流程

客户端、内核、订阅和规则集是四类不同更新对象。它们不应在同一时间全部更新。较稳妥的顺序是先备份当前可用配置，记录主要策略组选择；随后只更新订阅并验证；再按需要更新客户端或内核；最后更新外部规则集。每一步都完成启动、解析、连接和规则命中检查。这样出现兼容问题时，可以明确是哪一层发生变化，并回退到上一个可用状态。

备份内容至少包括本地 Profile、覆写规则、脚本、策略组命名和关键 DNS/TUN 设置。订阅地址本身只是更新来源，不能替代本地备份；远程内容发生变化后，重新下载未必能恢复原状态。备份文件应按用途和日期组织，并避免让客户端同时扫描多个重复副本，否则 Profile 列表会出现难以区分的配置。恢复时先在不启用系统代理和 TUN的情况下验证配置能否载入，再逐步恢复接管。

日志级别与连接记录

info 适合日常使用，能够看到启动、配置载入和主要连接信息；需要排查规则或网络细节时可临时提高日志详细程度，但长期保留大量详细日志会增加磁盘写入和阅读成本。日志排查应围绕时间点展开：记录触发问题的具体操作，随后在相同时间范围内查找 DNS、规则、策略和连接错误。只截取最后一行错误往往不够，因为根因可能出现在此前的配置重载或接口创建阶段。

连接记录适合回答三个问题：请求是否进入内核、命中了什么规则、最终使用了哪个出站。若没有记录，检查系统代理、TUN 和应用自身网络设置；若规则不符，检查域名、地址和顺序；若出站正确但连接失败，检查节点、目标服务和网络环境。对间歇性问题，应记录发生时使用的网络、Profile、模式和策略组选择，避免在复现前不断切换设置。

常见故障的分层处理

端口冲突是最常见的启动问题之一。修改端口前先确认占用者；若占用者是旧的 Clash 内核，应正常结束旧进程，而不是让两个实例使用不同端口长期共存。DNS 问题则经常表现为部分网站失败、规则命中异常或切换网络后暂时恢复。此时要区分域名解析失败、解析结果不符合预期和连接到目标地址失败，三种情况对应不同处理层。

保持配置可读与可迁移

策略组名称应稳定、清晰，规则应按职责分段，外部规则集应记录来源与用途。避免在同一配置中保留大量已经失效的节点、重复规则和未使用策略组。每次整理后先用配置检查或客户端重载确认语法，再验证几个代表目标。若准备迁移客户端，应先关闭旧客户端的系统代理和 TUN，导出配置，再在新客户端中导入并检查覆写能力；不要直接复制整个应用数据目录，因为不同客户端的数据库、缓存和界面状态未必兼容。

日常使用中可保留一份“最小可用配置”作为诊断基线，只包含监听端口、一个明确出站、简单策略组、局域网直连和 MATCH。复杂配置故障时，先用最小配置确认客户端与网络入口正常，再逐层加入 DNS、规则集和 TUN。这个方法比在数千行配置中随机删除字段更可靠，也能帮助判断问题属于基础环境还是扩展配置。

进阶路线：从稳定使用到可维护配置体系

第一阶段：固定基础入口

进阶配置的起点不是增加更多规则，而是让基础入口可预测。固定 mixed-port，明确是否允许局域网访问，选定日常使用的 Rule 模式，并保证系统代理与 TUN 不会同时被多个客户端控制。建立一份最小 Profile，记录配置目录、客户端名称和内核类型。完成后应能清楚回答：请求从哪里进入、当前配置是哪一份、默认策略组是什么、关闭客户端后如何恢复系统网络。

这一阶段还应建立测试方法。选择一个局域网地址、一个预期直连目标和一个预期代理目标，分别观察连接记录。测试时保持节点与网络不变，只调整一个参数。若基础入口仍不稳定，不要急于添加远程规则集、复杂 DNS 或进程规则，因为这些功能会增加观察维度。

第二阶段：重构策略组与规则

把节点层、选择层和业务层分开。底层由订阅提供节点，中层建立手动选择、自动选择和故障回退，上层按用途建立稳定策略，例如“默认出口”“工作服务”“下载任务”。业务规则只引用上层名称。订阅节点发生变化时，中上层结构不必重写；需要临时切换线路时，也只操作策略组，不改规则文件。

随后整理规则顺序。先处理私有网络和明确例外，再放业务规则集与域名规则，之后处理地址规则，最后使用 MATCH。每加入一个规则集，都记录覆盖范围、更新频率和目标策略。若两个集合范围高度重叠，只保留职责更明确的一份。对于经常变化的例外，可维护单独的小型本地规则区，并放在宽泛规则集之前。

第三阶段：配置提供器与规则提供器

当节点和规则需要独立更新时，可以使用代理提供器与规则提供器，把大块远程内容从主配置中拆开。主配置保留端口、DNS、策略组和引用关系，提供器负责按间隔更新外部文件。拆分后更容易维护，但也增加了下载失败、路径权限和格式兼容等检查项。提供器更新失败时，内核通常会尝试使用缓存，因此缓存目录必须可写，并应保留最近一次可用内容。

rule-providers:
  local-service:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-service.yaml
    url: "https://example.invalid/rules/local-service.yaml"
    interval: 86400

rules:
  - RULE-SET,local-service,DIRECT
  - MATCH,代理选择

示例地址是保留测试地址，用于展示结构。实际使用时，规则文件的行为类型必须与内容一致：domain 适合域名集合，ipcidr 适合地址段，classical 支持完整规则表达式。路径应位于内核可写的工作目录中。提供器名称同样属于稳定接口，修改后要同步调整所有 RULE-SET 引用。

第四阶段：按平台处理进程与局域网

进程规则依赖操作系统和内核获取进程信息的能力，不同平台支持程度可能不同。使用前先在连接记录中确认能否看到进程名，再写 PROCESS-NAME 规则。进程路径、应用商店封装和子进程都可能影响匹配，不能只依据界面显示名称猜测。移动端更适合使用客户端提供的分应用代理界面，因为系统权限与应用标识由客户端直接处理。

局域网共享需要同时考虑 allow-lan、监听地址、防火墙和访问控制。只开启 allow-lan 并不代表其他设备一定可访问，本机防火墙可能仍阻止端口；反过来，向所有接口监听也会扩大可访问范围。若只是本机使用，保持局域网访问关闭。确有共享需求时，限制在可信网络，并明确其他设备使用的本机局域网地址和端口。TUN 下还要保留私有网段直连，避免打印机、存储设备和开发服务被送往代理。

第五阶段：形成变更记录与验证清单

长期维护的配置需要简单的变更记录。每次修改写明目的、字段、验证目标和回退方式。例如“为某个完整域名增加直连例外，放在对应后缀规则之前；验证首页与下载接口；异常时删除该行并重载”。这种记录比只保存多个无说明副本更有价值。发生问题时，可以沿变更顺序定位，而不是重新阅读整份配置。

最终验证清单应覆盖：客户端启动、Profile 载入、系统代理、TUN、DNS、局域网、直连目标、代理目标、策略组切换、订阅更新和规则集更新。并非每次小改动都要执行全部项目，但涉及入口、DNS 或 TUN 的变化应完成完整检查。测试后查看日志中是否存在持续重试、解析失败或接口错误，即使表面访问正常，也应处理重复错误，避免后续网络切换时集中暴露。

继续查阅与实践顺序

完成本手册后，可以按实际需求选择下一步。需要尽快建立基础连接，回到使用文档复核最短主线；需要替换客户端，前往平台下载入口核对架构与系统要求；端口报错时查看监听端口排查；DNS 结果异常时查看DNS 检测与修正；管理多份配置时查看Profile 管理方法；迁移旧配置时查看mihomo 配置差异。

从零到稳定使用的关键不是一次写出复杂配置，而是按层推进：先让客户端和内核稳定启动，再建立可更新的 Profile；先理解 Rule、Global 与 Direct，再编写自定义规则；先让系统代理工作，再启用 TUN；先确认 DNS 请求路径，再调整增强模式；最后才引入提供器、进程规则和自动化维护。每完成一层都保留可回退状态，配置体系就能在客户端、订阅和网络环境变化时继续维护。