Clash 电脑版
从零到精通手册

Clash 不是单一的“开关”，而是一套运行在本机的流量处理链。应用程序先把连接交给本地监听端口或虚拟网卡，Clash 内核读取目标域名、目标 IP、网络协议和进程等信息，再按配置文件里的规则自上而下匹配，最后把连接交给 DIRECT、某个代理组或 REJECT。理解这条路径，比记住客户端界面上的按钮更重要。系统代理开启但某个程序仍然直连、节点可以测试却无法访问网页、规则模式与全局模式表现不同，根源通常都能落回这条链上的某一段。

客户端、内核与配置文件

桌面客户端负责界面、配置管理、系统代理开关、日志展示和更新等操作；Mihomo 等兼容内核负责实际监听端口、解析规则和转发连接；YAML 配置文件则描述端口、DNS、代理节点、代理组和规则。三者需要分开理解。更换客户端不一定改变配置语法，同一份配置能否使用，主要取决于内核支持的字段与客户端导入方式。客户端能正常启动，也不代表订阅内容、DNS 或系统代理已经配置正确。

常见本地端口包括 HTTP 代理端口、SOCKS5 端口和同时接受两种协议的 mixed-port。桌面客户端通常会自动管理这些值。以 mixed-port: 7890 为例，浏览器或终端把代理地址设为 127.0.0.1:7890，连接才会进入内核。external-controller 是控制接口，供客户端界面读取连接、切换代理组或加载配置，不应与代理端口混为一谈。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true
external-controller: 127.0.0.1:9090

系统代理与 TUN 的边界

系统代理是操作系统向应用公布的一组 HTTP 或 SOCKS 代理设置。浏览器和大部分桌面软件会读取它，但终端命令、游戏、部分商店应用、虚拟机和自行实现网络栈的程序可能忽略它。TUN 模式则创建虚拟网络接口，在更低一层接管 IP 流量，覆盖范围通常更广。两者不是速度档位，也不是必须同时开启的功能。日常浏览优先使用系统代理，遇到明确不读取系统代理的应用，再评估 TUN 是否必要。

域名、DNS 与规则匹配

用户输入域名后，DNS 先把名称转换成 IP；规则引擎可能在解析前按域名匹配，也可能在得到 IP 后继续执行 GEOIP 或 IP-CIDR 规则。如果 DNS 请求走了错误的网络路径，可能出现网页打不开、规则命中与预期不一致或本地网络域名失效。所谓“节点正常但网站打不开”，经常不是代理节点本身的问题，而是域名解析、IPv6、浏览器安全 DNS或规则顺序中的一个环节。

日志和连接页是观察这条处理链的两个入口。日志说明配置是否加载、端口是否占用、DNS 是否报错；连接页说明哪些应用产生了会话、目标是什么、命中了哪条规则、最终走了哪个策略。第一次使用客户端时，可配合客户端界面速览认识代理页、配置页、连接页和日志页的分工。建立这些概念后，后续的安装、订阅和规则操作就不再是机械点击。

桌面端可选客户端包括 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash for Windows 和 ClashX Meta；移动端还包括 Clash Meta for Android 与 Surfboard。本站下载清单把 Clash Plus 作为全平台首推选项，原因在于平台覆盖完整，适合希望在 Windows、macOS、Android 与 iOS 之间保持接近操作路径的用户。偏好社区桌面客户端时，可以比较 Clash Verge Rev、FlClash 与 Nyanpasu。Clash for Windows 和 ClashX Meta 已停止维护，只适合处理旧环境或既有配置，不宜作为新安装的默认选择。

Windows：架构、安装目录与回环限制

多数 Windows 电脑使用 x64 安装包。ARM 设备需要选择客户端明确提供的 ARM 架构包，不能只根据系统界面相似就混用。安装完成后先正常启动客户端，确认托盘图标、配置页和日志页能够打开，再导入订阅。若系统提示来自网络的应用需要确认，核对下载入口和文件名后按系统流程处理，不要通过关闭整套安全功能来绕过一次提示。

开启系统代理后，传统桌面浏览器通常可以直接使用；部分 UWP 应用受 Windows 回环隔离影响，无法访问本机代理端口。此时应使用客户端提供的 UWP 回环工具，将确实需要代理的应用加入豁免列表，然后重新启动目标应用。回环设置解决的是“应用不能连接本机代理”问题，不会修复失效订阅、错误节点或 DNS 配置。完整的平台操作与高频问题可参阅Windows 安装 Clash 全流程。

macOS：芯片架构与网络权限

在“关于本机”中确认处理器属于 Apple Silicon 还是 Intel，再选择对应安装包。架构不匹配时，应用可能无法启动，或需要额外兼容层。第一次开启系统代理、服务模式或 TUN 时，macOS 可能要求输入管理员凭据并批准网络扩展。授权只需按系统对话框完成，不要把客户端直接移出应用程序目录后继续运行，否则登录启动项和辅助服务路径可能失效。

Linux：包格式与桌面会话

Debian、Ubuntu 及其衍生发行版通常使用 DEB；Fedora、RHEL 系发行版通常使用 RPM。安装后如果菜单入口未立即出现，可结束并重新进入桌面会话，或从终端启动一次以读取明确错误。Linux 桌面环境对系统代理的实现并不完全一致，浏览器可能读取 GNOME 或 KDE 代理设置，终端工具则通常依赖环境变量。需要全局接管时再配置 TUN，并先确认系统具备创建虚拟网卡和修改路由的权限。

# Debian / Ubuntu 安装本地 DEB 包
sudo apt install ./client-package.deb

# 查看常见端口是否已被占用
ss -lntp | grep -E '7890|9090'

如果仍在比较客户端，可查看Clash Plus、Verge Rev 与 FlClash 横向对比。选型时优先考虑当前系统支持、TUN 实现、配置兼容性和更新状态，而不是界面元素数量。确认选择后从下载中心进入对应平台，避免在不同来源之间混用安装包与配置说明。

Clash 配置通常以 YAML 文件存在。完整配置不仅包含代理节点，还可能包含代理组、规则、DNS、TUN 和监听端口。订阅链接则是配置的远程来源，客户端按链接下载内容并保存为本地配置。导入完成后真正被内核读取的是本地副本；更新订阅会重新拉取远程内容，因此直接修改订阅生成的配置，可能在下一次更新时被覆盖。

先辨认手上的内容

可在浏览器地址栏中导入的订阅 URL、以大量编码字符组成的通用订阅、以及包含 proxies:、proxy-groups:、rules: 的 YAML 文件，不是同一种交付形式。客户端提示格式错误时，先确认链接返回的内容，而不是连续点击导入。服务端返回登录页面、过期提示或通用 Base64 节点列表时，客户端可能将其保存下来，却无法作为完整 Clash 配置加载。

有效 YAML 对缩进敏感，使用空格而不是制表符。同一级字段保持相同缩进，列表项用连字符开始，包含冒号、井号或特殊字符的名称应放进引号。浏览器复制时还要避免全角标点和智能引号。关于 YAML、Base64 与格式转换的区别，可继续阅读Clash 订阅格式与互转方法。

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

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "自动选择"
      - DIRECT

  - name: "自动选择"
    type: url-test
    proxies:
      - "示例节点 A"
      - "示例节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

导入、激活与更新是三件事

导入只是把订阅或文件加入客户端配置列表；激活表示选择其中一份配置交给内核运行；更新则重新获取远端内容。操作时先在配置页粘贴订阅地址并确认下载完成，再选中该配置，然后到代理页选择代理组策略，最后开启系统代理。若配置列表里已有多份文件，应明确当前激活项，避免修改 A 配置却实际运行 B 配置。

订阅更新失败时按 HTTP 请求链排查。首先确认链接未过期且能在当前网络访问；其次检查系统时间，时间偏差可能导致 TLS 连接失败；再次查看客户端日志中的状态码或解析错误。返回 401、403 通常与授权或链接状态有关，返回 HTML 往往说明地址指向网页而非配置内容，解析错误则重点检查 YAML 结构和客户端内核兼容性。不要把完整订阅链接公开粘贴到论坛或截图中，因为链接本身可能携带访问凭据。

覆盖风险与本地扩展

需要增加自定义规则时，优先使用客户端提供的覆写、合并配置、脚本扩展或规则集功能。这样可以把服务方维护的节点部分与本地规则分离。若客户端不支持合并机制，可以复制订阅配置为本地文件，在副本中修改，同时保留原始订阅用于更新和对照。更新后再把节点与代理组变化合并到本地副本，比直接编辑自动更新文件更容易恢复。

配置加载失败时，日志中的行号通常指向解析器发现问题的位置，但真正的缩进错误可能出现在它前面几行。可从报错行向上检查同级字段、引号闭合和列表缩进。配置能够加载但代理组为空，则检查 proxy-groups 引用的节点名是否与 proxies 完全一致。节点存在却不能选择，可能是组类型、provider 引用或订阅转换结果不完整。把“下载失败、解析失败、运行失败”分开记录，排查会更直接。

Clash 客户端常见的 Rule、Global 与 Direct 模式控制的是内核如何决定最终策略。它们不会改变应用是否把流量交给 Clash，也不会自动修复不可用节点。系统代理关闭时，即使切到 Global，未进入本地代理端口的浏览器连接仍然不会经过内核；TUN 已接管流量时，切换模式才会对被接管的连接生效。因此，模式选择必须放在完整流量路径里理解。

Rule：按规则逐条决定

Rule 是日常使用的默认选择。内核从规则列表顶部开始匹配，命中后停止继续向下检查。常见结果是本地网络和明确的直连域名走 DIRECT，需要代理的域名进入代理组，广告或不希望连接的目标进入 REJECT，剩余流量由最后的 MATCH 兜底。规则模式的价值在于同时保持访问范围、网络路径和本地服务兼容性，而不是让全部流量统一走同一出口。

Global：把选择集中到全局组

Global 模式通常把所有已进入内核的连接交给全局代理组。它适合临时判断“问题是否来自规则”。例如某网站在 Rule 下失败、在 Global 下成功，说明节点和基本代理链路大概率可用，应转向检查规则命中、DNS 或代理组选择。如果两种模式都失败，则优先检查节点、端口、系统代理和域名解析。Global 不宜长期作为掩盖错误规则的办法，因为本地服务、局域网设备和不需要代理的连接也可能被送入代理。

Direct：让已接管流量直接连接

Direct 模式让进入内核的连接直接访问目标。它可用于判断客户端接管本身是否造成影响，也可在临时停用代理时保留内核运行状态。但 Direct 不等于彻底退出客户端：本地端口、TUN、DNS 模块和连接记录可能仍然工作。如果要恢复系统原始网络路径，应关闭系统代理或 TUN，再退出内核，并确认操作系统代理设置已还原。

代理组比模式更接近实际出口

模式确定“去哪里找策略”，代理组才进一步决定使用哪个节点或子组。select 组由用户手动选择；url-test 按指定测试地址周期测量并选择可用候选；fallback 按顺序使用可用节点；load-balance 根据实现和策略分配连接。测试结果只能反映到测试地址的连通情况，不等同于所有目标网站的体验，也不能代表持续带宽。

切换节点后，已经建立的 TCP、QUIC 或长连接不会必然迁移到新节点。浏览器可能复用旧连接，应用也可能保留 DNS 缓存。需要验证切换结果时，可在连接页关闭相关会话，重新打开目标应用，必要时等待旧连接释放。若规则把目标送进另一个代理组，切换当前组自然不会改变结果，所以应先查看连接页中的规则与链路，而不是只观察代理页高亮项。

模式切换应当服务于判断，而不是随机尝试。每次切换后记录目标域名、命中规则、实际策略和连接结果，能够快速区分规则问题与链路问题。日常状态建议回到 Rule，并通过自定义规则修正少量例外，这比长期使用 Global 更可控。

规则列表按从上到下的顺序执行，第一条命中规则决定连接策略。规则系统不是多个条件的综合评分，也不会自动选择“更具体”的一条。若前面已经存在宽泛的 DOMAIN-SUFFIX、GEOIP 或 IP-CIDR，写在后面的例外规则可能永远没有机会执行。设计规则时应遵循“精确例外在前、宽泛分类居中、最终兜底在后”的结构。

常用规则类型

DOMAIN 精确匹配完整域名，例如只匹配 api.example.com；DOMAIN-SUFFIX 匹配指定域名及其子域，适合按站点体系分流；DOMAIN-KEYWORD 根据域名中的字符串匹配，范围较宽，容易误伤；IP-CIDR 和 IP-CIDR6 按 IPv4、IPv6 网段匹配；GEOIP 根据 IP 地理数据库分类；PROCESS-NAME 根据进程名匹配，但可用性依赖操作系统、权限和内核支持；MATCH 处理前面未命中的剩余连接。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.org,节点选择
  - DOMAIN-KEYWORD,example,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

no-resolve 用于告诉内核在执行 IP 类规则时不要为了匹配而额外解析域名。它适合已经拿到目标 IP 的连接，也能避免某些规则触发不必要的 DNS 查询；但如果规则依赖域名解析后的 IP 才能命中，加入该参数可能改变结果。参数不应机械附加，应结合规则类型和连接元数据判断。

策略字段必须引用真实存在的组

规则最后一段不是任意标签，而是代理组名、节点名或内置策略。配置中写了 节点选择，就必须在 proxy-groups 中存在同名组，字符、空格和大小写都要一致。DIRECT 表示直接连接，REJECT 表示拒绝连接。自定义名称使用中文没有问题，但在多个配置和覆写文件之间维护时，稳定的短名称更不容易发生引用错误。

把本地例外放在可维护的位置

家庭 NAS、打印机、路由器后台和公司内网通常需要直连。应先列出明确域名，再覆盖常见私有地址范围，同时保留对本地域名解析的支持。如果直接把所有未知地址交给代理，可能导致局域网访问绕路或失败。反过来，过宽的直连规则也会让本应代理的目标提前命中。新增规则时先从连接页复制实际目标，不要根据网页显示名称猜域名，因为一个页面通常会访问多个 API、静态资源和认证域名。

规则集与 provider

大型规则不适合全部写在主配置中。支持 rule-provider 的内核可以从本地文件或远程地址加载规则集，再通过 RULE-SET 引用。规则集应明确行为类型、格式、更新间隔和落地路径。远程规则更新失败时，内核可能继续使用缓存，也可能因配置方式不同而报错，因此关键规则应评估缓存策略与失败行为。

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

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,节点选择

排查规则时，先在连接页找到目标会话，记录 Host、目标 IP、命中规则和最终策略。若命中规则不符合预期，检查是否有更早的宽泛规则；若规则正确但策略错误，检查代理组当前选择；若域名规则未出现，检查应用是否直接使用 IP、DNS 是否由其他程序处理、连接是否复用了旧会话。修改后重载配置并新建连接，避免拿旧连接验证新规则。

订阅配置经常在更新时重写 rules。长期维护自定义规则，优先使用客户端的 prepend、append 或覆写机制：需要优先命中的例外放在规则列表前部，普通补充放在 MATCH 之前。每条自定义规则旁保留用途记录，并定期删除已失效条目。规则越多不代表效果越好，能够解释每条规则的来源、优先级和目标，才是可维护的分流配置。

TUN 模式通过虚拟网络接口接收 IP 流量，再把连接交给 Clash 规则引擎。它适合终端工具、游戏、部分商店应用和自行管理网络连接的软件。与系统代理相比，TUN 覆盖更广，也更容易受到路由、DNS、防火墙、虚拟机和其他 VPN 软件影响。只有在系统代理无法覆盖目标应用时才需要启用，日常浏览不必把 TUN 当作固定前置条件。

启用前的基础条件

Windows 通常需要客户端辅助服务或管理员权限来创建虚拟网卡和修改路由；macOS 需要批准网络扩展；Linux 需要 TUN 设备权限以及修改路由和防火墙规则的能力。客户端提供“服务模式”时，应先确认服务安装成功，再开启 TUN。若开关立即回落、日志提示 permission denied、operation not permitted 或无法创建 interface，问题位于权限与服务层，不应继续更换代理节点。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

stack 指定 TUN 网络栈实现，常见值包括 system、gvisor 与 mixed，具体支持范围取决于内核和系统。system 更依赖操作系统网络栈，gvisor 在用户态处理更多网络行为，mixed 尝试在兼容性与性能之间分配协议。遇到某类 UDP、游戏或局域网连接异常时，可以把网络栈作为单独变量测试，但每次更改后应完全重启内核并清理旧连接。

auto-route 让内核自动写入接管所需路由；auto-detect-interface 用于识别当前出口网卡，适合在有线、无线网络之间切换。多网卡、虚拟机、容器、拨号连接或其他 VPN 同时存在时，自动识别可能选到错误接口。表现通常是 TUN 开启后全部断网、局域网不可达，或流量在两个虚拟接口之间循环。此时先关闭其他网络接管软件，再查看系统路由表和默认出口。

DNS 劫持与 fake-ip

dns-hijack 把指定端口的 DNS 查询交给内核处理，避免应用绕过 Clash DNS。fake-ip 模式会为域名返回保留地址，内核再根据映射恢复原始域名并执行规则，优点是域名规则命中更稳定；但依赖真实 IP 的局域网设备、某些游戏、企业认证和特殊协议可能需要加入 fake-ip-filter。redir-host 则返回真实解析结果，兼容路径不同。切换增强模式会影响缓存和既有连接，验证前应刷新系统与浏览器 DNS 缓存。

局域网与保留地址

TUN 开启后仍需保证私有网段、链路本地地址和本地域名能够直连。家庭网络常见 IPv4 网段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，IPv6 本地地址也应按实际环境处理。仅有直连规则还不够：如果 DNS 把 NAS 名称发给了外部解析器，仍然可能得不到正确地址。内部域名应交给局域网 DNS，或在 hosts、nameserver-policy 等位置明确解析路径。

最小化排错步骤

开启 TUN 后断网，第一步关闭 TUN，确认原始网络恢复；第二步检查日志中的权限、接口和路由错误；第三步关闭其他 VPN 与虚拟网卡程序；第四步只保留 enable、stack、auto-route 和 auto-detect-interface 等必要字段测试；第五步再加入 DNS 劫持和自定义路由。若网页正常但某个游戏失败，重点比较 TCP、UDP、IPv4 与 IPv6 路径，不要直接推翻整套配置。

TUN 的验收应覆盖浏览器、终端、局域网和系统恢复四项：浏览器能够按规则访问；未设置代理环境变量的终端连接能出现在连接页；路由器或 NAS 仍可访问；关闭 TUN 后系统默认路由与 DNS 能恢复。四项同时通过，才说明接管与退出路径都完整。

稳定使用依赖少量但持续的维护：保留可用配置、按需更新订阅、观察客户端与内核更新说明、清理失效规则，并在系统网络变化后验证代理设置。遇到故障时，重装客户端通常不是第一步，因为订阅、系统代理、DNS、TUN 权限和规则错误会在重装后原样出现。更有效的方法是按应用层、接管层、内核层、策略层和远端链路逐层确认。

建立可重复的健康检查

每次更新客户端或配置后，先看内核是否启动、配置是否加载、端口是否监听，再用一个浏览器页面和一个终端请求验证。连接页应出现相应会话，规则字段应符合预期，代理组应指向实际选择。最后测试一个局域网地址，确保直连例外没有受影响。这套检查不需要频繁执行，但在配置大改、系统升级或网络环境切换后很有价值。

# macOS / Linux：临时为当前终端设置代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 完成测试后清除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# PowerShell：只影响当前窗口
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# 清除当前窗口中的设置
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

终端环境变量与系统代理相互独立。浏览器能访问而命令行不能访问，先检查终端程序是否读取系统代理，再查看 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。反过来，关闭客户端后终端仍尝试连接 127.0.0.1:7890，通常是环境变量仍然存在。浏览器与终端的分路检查可参阅系统代理不生效的两条排查路线。

常见故障与定位入口

端口占用与残留进程

日志出现 address already in use，说明另一个进程已经监听相同端口。可能是重复启动的内核、另一款代理客户端，或退出异常后残留的进程。先在系统任务管理器或端口工具中确认占用者，再正常结束对应程序。直接把端口改成其他数字虽然能让内核启动，但浏览器、终端和系统代理仍可能指向旧端口，最终形成“客户端正常、流量不通”的新问题。若确实修改端口，应同步更新所有引用位置。

更新策略与回退

客户端、内核、订阅和规则集是四条不同更新链。不要在同一时间全部更新。先保存现有配置和客户端设置，再更新其中一项并完成基本测试。内核更新后重点看配置字段兼容性；订阅更新后重点看代理组名称和规则变化；规则集更新后重点看命中结果；客户端更新后重点看系统代理、服务模式和启动项。发生异常时，明确回退哪一层比重新创建所有配置更可靠。

系统休眠、网络切换或从公司网络回到家庭网络后，旧连接、默认网卡和 DNS 缓存可能仍然存在。此时先重启内核，再重新打开目标应用；TUN 使用自动出口识别时，确认当前默认接口已经变化。若只有一个网站异常，清理该网站连接与 DNS 缓存即可，不必重置整套系统网络。维护的目标是缩小变更范围，并保留足够信息解释每次变化。

完成前七章后，客户端应具备稳定的基础路径：应用流量能够进入内核，订阅可以更新，Rule 模式按预期分流，TUN 只在需要时启用，故障可以通过日志和连接页定位。进阶阶段不应继续堆叠功能，而是把配置拆成清晰、可验证、可回退的模块。判断一项配置是否成熟，不看规则数量，而看它能否在网络切换、订阅更新和客户端升级后继续工作。

第一阶段：拆分配置责任

主配置保留端口、模式、DNS、代理组与规则入口；服务方订阅负责节点和基础组；本地覆写负责固定的自定义规则；大型规则放入 rule-provider；设备相关设置单独记录。这样更新订阅时不会覆盖本地策略，更换客户端时也能快速判断哪些部分可以迁移。配置文件命名可包含用途与环境，例如 desktop-rule、laptop-tun、home-lan，而不是使用“新配置2”这类无法长期辨认的名称。

如果需要在多台设备上维护同一套策略，不要直接同步包含节点凭据的完整文件。可同步不含敏感内容的规则片段、DNS 模板和说明文档，再由每台设备分别导入订阅。这样既能统一分流逻辑，也能避免设备间互相覆盖端口、网卡和本地路径等系统差异。

第二阶段：按域名建立 DNS 策略

复杂网络中，单一 nameserver 未必适合全部域名。内核支持时，可以通过 nameserver-policy 为内部域名、特定公共域名或不同规则集指定解析器。设计前先确定问题：是内部域名只能由局域网 DNS 解析，还是某些域名需要避免错误结果，或 IPv6 路径不稳定。没有明确目标时，不应同时堆叠多组解析器、fallback 与过滤条件。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.internal.example":
      - 10.0.0.53
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.home.arpa"

内部 DNS 地址必须在对应网络中真实可达。笔记本离开家庭或公司网络后，这些地址可能超时，所以要考虑网络环境切换。若客户端支持按配置切换，可以为不同网络准备独立 DNS 覆写；若只维护一份配置，则应确保内部域名规则不会影响普通公共解析。DNS 调整后，用明确域名验证解析结果和连接页中的规则命中，不要只看网页最终是否打开。

第三阶段：使用控制接口做只读诊断

控制接口可以读取当前配置、代理组和连接状态。默认监听在本机地址更安全，也足够桌面客户端使用。通过命令行访问接口前，先确认 external-controller 的地址和端口；若配置了 secret，请按客户端方式提供认证。控制接口不应直接暴露到公共网络。下面示例读取本机控制端口，只用于确认接口是否响应。

curl http://127.0.0.1:9090/configs
curl http://127.0.0.1:9090/proxies
curl http://127.0.0.1:9090/connections

诊断时优先读取而不是修改。/configs 可确认当前模式与部分运行参数，/proxies 可查看代理组结构，/connections 可检查活动连接。不同兼容内核的接口字段可能存在差异，自动化脚本应处理字段缺失和接口不可用，而不是假设所有客户端都返回相同结构。

第四阶段：为变化建立测试清单

每次更改规则或 DNS 后，至少测试四类目标：明确应直连的局域网服务、明确应走代理的域名、由 MATCH 兜底的未知目标，以及需要特殊处理的应用。记录目标、预期策略、实际规则和最终链路。测试清单比凭感觉浏览几个网站更能发现宽泛规则提前命中、DNS 策略遗漏和代理组引用错误。

如果配置使用 TUN，还要加入退出测试：关闭 TUN 后默认路由恢复，系统 DNS 可用，浏览器不再依赖本地端口。若使用开机启动，则重启系统后检查辅助服务、内核、配置和系统代理的启动顺序。启动项显示为开启，不代表每一层都已经就绪；日志中的时间顺序能够说明配置加载是否早于网络建立，或系统代理是否指向尚未监听的端口。

后续学习可以围绕三个方向展开：需要更精细分流时，深入 rule-provider、代理组链和进程规则；需要覆盖更多应用时，研究 TUN 路由、DNS 劫持与多网卡行为；需要长期维护时，建立配置版本记录、变更说明和自动化语法检查。不要同时推进三条路线，先选当前环境中最明确的问题。

从零到精通的终点不是记住所有字段，而是能解释一条连接如何进入 Clash、为何命中某条规则、最终选择哪个策略，以及失败时应查看哪一层。需要重新走一次最短操作链，可返回入门指南；准备安装或更换客户端，可前往下载中心。把快速操作与系统查阅分开，日常维护会更稳定。