Clash 使用手册：
从安装到规则与 TUN

一、核心概念与连接路径

先分清客户端、内核和服务

Clash 生态里，客户端负责把操作入口整理成界面，内核负责解析配置、处理连接与执行规则，远端服务则提供实际出口。三者不是同一件事。安装客户端不会自动生成可用节点；订阅也不是客户端账号。遇到问题时，先判断故障属于界面、内核配置还是远端服务，能避免把所有异常都归结为软件安装失败。

许多客户端使用 mihomo 内核，但具体支持仍取决于随软件提供的内核构建、系统权限与客户端实现。界面能导入某份文件，不代表文件里的每个字段都已生效。反过来，内核支持某项功能，界面也可能尚未提供对应开关。本文涉及的 YAML 示例以 mihomo 常见语法为基础，应用前需要确认当前客户端的配置入口。

把一次访问拆成四个环节

浏览器访问网站时，通常先解析域名，再建立连接，然后完成加密握手，最后交换应用数据。代理可能介入其中多个环节：系统代理告诉应用把请求交给本地端口，规则决定连接走哪个策略，远端节点再连接目标站点。任何一环失败都可能表现为网页打不开，因此只看浏览器最后一行错误，往往不足以定位原因。

本地监听地址常见为回环地址，意思是只接受本机连接；端口则是应用进入内核的入口。它与远端节点的服务器地址、服务端口完全不同。修改本地端口后，浏览器或终端里手工填写的代理地址也要同步修改。远端节点参数通常由订阅提供，不应因为本地端口冲突就随意更改，否则会把两个独立问题混在一起。

策略组是连接去向的选择器，不是节点本身。手动选择组允许指定成员，自动测试组会按配置的测试条件选择成员，故障转移组则重视可用性顺序。规则可以指向策略组，也可以指向直接连接等内置动作。看到某个策略组名称，不应只凭名字判断它的行为，要展开查看组类型、成员及当前选择。

认识接管、分流与解析的边界

系统代理、TUN 和规则模式解决不同问题。系统代理与 TUN 主要决定流量怎样进入内核；规则模式决定进入以后怎样分流；DNS 设置决定域名如何解析以及相关信息怎样用于匹配。这些设置可以组合，并不互相替代。开启 TUN 后仍可使用规则模式，关闭系统代理也不意味着所有流量必然停止进入内核。

配置中的 DNS 与设备当前网络提供的 DNS 也可能同时存在。应用自行使用加密 DNS、浏览器内置解析以及局域网域名，都会让路径更复杂。暂时不必立刻调整解析方案，但要记住：访问结果异常时，域名解析是独立检查项。用地址直接测试与用域名测试得到不同结果，通常就是继续调查解析路径的线索。

第一次验证时，选一个普通网页作为目标，同时观察客户端连接记录。记录里应能找到目标域名或地址、使用的策略以及连接状态。若没有记录，先检查接管入口；若有记录但出站失败，再看节点、解析和远端错误。这个先找边界、再缩小范围的方法，后面每一章都会用到，也比反复重装更容易保留有效证据。

二、按平台与任务选择客户端

先选操作入口，再比较功能

日常图形界面使用，先考虑 Clash Plus，再按具体系统与功能需求比较其他客户端。选型重点不是开关数量，而是订阅更新、策略选择、连接记录和权限提示是否容易理解。安装前到下载中心查看当前平台入口，确认系统架构与安装形式，避免先下载多个程序，再在相似界面之间来回迁移配置。

桌面平台上，Clash Verge Rev、FlClash 和 Clash Nyanpasu 可以作为不同界面与工作流的比较对象。不要预设它们的设置可以逐项照搬：订阅增强、服务模式、内核更新和日志入口可能不同。若需要长期维护一台设备，清楚知道配置保存在哪里、如何恢复，比只比较首次启动的界面更有价值。

架构和系统集成比名称更重要

处理器架构应以系统信息为准，不要只看电脑品牌。Apple Silicon 与 Intel 的 macOS 安装包需要区分；Windows 设备也可能采用不同架构。Android 的通用包和特定架构包覆盖范围不同。下载页提供哪些入口，就在这些入口里选择，不应根据文件名规律猜测一个不存在的安装包地址。

Linux 还要区分发行版的软件包管理方式。适合 Debian 系发行版的软件包不能直接当成 RPM 系发行版安装包使用。图形客户端面向桌面会话，纯命令行内核则需要自己处理配置目录、服务启动与日志读取。服务器没有图形界面时，不必为了使用代理额外部署整套桌面，直接采用内核与服务管理器通常更清楚。

移动端普遍通过系统 VPN 接口接管流量，常见限制是同一时间只能由一个相关服务占用该入口。另一个安全工具、工作配置或网络加速应用可能造成冲突。桌面也可能存在虚拟网卡和路由竞争。因此，如果需求包含企业 VPN 或特殊局域网，选型时应优先考虑能否明确控制接管范围，而不是默认所有网络工具可以同时运行。

订阅兼容与维护状态要单独确认

同样写着订阅导入，实际可能接受不同格式。完整 Clash YAML、单独节点列表和其他客户端的配置不是同一种输入。尤其在选择 Surfboard 时，应先确认提供方支持相应格式，不要把配置后缀当成兼容性保证。转换配置可能遗漏规则、策略组或协议参数，转换成功也仍需要检查实际连接路径。

Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择。已有环境确实依赖它们时，可以作为迁移参考，但新设备应优先评估仍在维护的方案。旧程序能够启动，不代表它能理解新订阅中的协议和字段。出现未知字段、节点被跳过或内核报错时，先检查能力差异，不要直接把订阅判定为失效。

iOS 使用 Clash Plus 时，从下载中心进入商店，并可查看官网 clashplus.io 的产品说明。跨平台使用同名客户端，也不要假设桌面和移动端权限完全一致。完成选型后，记下客户端名称、系统架构、配置来源和主要用途；这些信息会成为后续排错时最实用的环境说明。

三、安装、权限与基础环境检查

第一次启动先保持最小改动

安装前，先退出正在运行的同类代理工具，记录系统当前的代理设置与 VPN 状态。两套程序同时修改系统代理时，后启动的一方可能覆盖前一方，退出顺序又会影响恢复结果。已有工作配置的设备应先备份，不要把卸载旧程序当作迁移的第一步。新程序能导入并稳定运行后，再处理旧环境更容易回退。

打开客户端后，先确认主界面、设置页和日志页能正常显示，暂时不要启用开机自启、TUN 或复杂覆写。此时没有订阅、没有节点是正常状态，不应被当作安装异常。若程序启动即退出，优先检查系统兼容性、架构匹配、安装目录访问权限以及安全软件的拦截记录，而不是不断重复下载同一个文件。

把权限请求对应到实际用途

桌面客户端可能为系统服务、虚拟网卡或网络扩展请求额外授权。只有理解用途后再允许，不需要把整套图形程序长期提升权限运行当作通用解决办法。系统代理通常与当前用户会话有关；TUN 则可能涉及服务组件与路由调整。遇到权限不足，先查客户端针对该功能的安装说明，区分缺少服务与服务未启动。

macOS 应按系统提示完成网络相关授权，并在系统设置中确认对应项目的状态。Android 与 iOS 首次启动接管时会出现 VPN 授权提示，拒绝后界面仍可能正常打开，但流量不会按预期进入内核。若设备由单位管理，相关权限可能被策略限制，这种情况需要遵循管理要求，而不是通过反复安装绕开限制。

安装完成后，找到配置目录和日志入口，了解客户端是否使用便携目录、用户数据目录或独立服务目录。界面上的配置文件与真正交给内核运行的文件未必是同一个。为了减少后续误会，可先记录目录位置，不必立即手动编辑其中内容。直接改生成文件，常会在下一次保存或启动时被客户端重新覆盖。

本地端口与监听范围

本地端口是应用连接内核的入口。某个端口被其他程序占用时，日志通常会出现绑定失败或地址已使用等信息。此时可以关闭占用程序，或在客户端支持的位置调整监听端口，并同步修改手工填写的代理地址。不要为了绕过本地冲突去修改订阅中的远端服务端口，那会改变完全不同的一段连接。

# 仅用于理解本机入口，不是完整可联网配置
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

示例中的混合端口可接受常见 HTTP 与 SOCKS 代理请求，但实际端口应以客户端显示的运行值为准。关闭局域网访问有助于把初始排错范围限制在本机。若以后需要供其他设备使用，还要同时考虑监听地址、防火墙和访问控制，不能只打开局域网开关就假定已经建立了合适的共享环境。

基础检查的终点不是已经能访问某个网站，而是程序能启动、内核没有持续报错、监听入口清楚、退出可以恢复网络。之后再导入订阅，问题边界会更明确。Linux 用户若准备采用命令行部署，可继续阅读桌面客户端与 systemd 两条部署路线，不要把桌面自启与系统服务混作同一种配置。

四、订阅导入、更新与配置持久化

先确认导入的是什么

订阅通常是由服务提供方维护的配置地址，客户端通过它取得节点、策略组和规则等内容。地址可能带有个人访问标识，应按敏感信息保存。不要放进公开截图、工单正文或共享文档。导入前先确认提供方要求的客户端类型与格式；能在浏览器里打开一个地址，并不能证明返回内容适合当前内核。

在客户端找到订阅、配置或配置文件入口，新增远程配置，粘贴地址并保存。更新结束后，还需要把它设为当前使用配置，再检查策略组和节点是否出现。有些客户端的下载与启用是两个动作，只完成下载，内核可能仍运行旧配置。若界面支持为配置命名，使用能分辨来源与用途的名称即可，不要把完整地址写进名称。

第一次导入后，检查更新日志和内核运行日志，而不只是看成功提示。下载成功只说明取得了响应，解析成功说明结构能被读取，内核加载成功才表示配置已进入运行阶段。若某些节点协议不受支持，可能只有部分成员显示出来。这个时候应比较节点数量变化与警告信息，避免把缺少成员误认为提供方主动删除。

更新失败按请求、内容、加载三层排查

请求失败时，先核对地址是否复制完整，尤其注意结尾参数和多余空格。接着观察错误属于解析失败、连接超时、访问被拒绝还是重定向异常。网络可用但订阅不可达，可能与更新请求采用的网络路径有关。不同客户端是否让更新走现有代理并不一致，应在对应设置里确认，而不是假设更新一定跟随当前策略组。

取得内容后仍失败，检查返回的是 YAML、其他格式，还是网页错误提示。账户状态页面、登录页和人机验证页面都不能作为代理配置加载。若服务端临时返回异常，不要把错误页面保存后继续手工修改。保留原有可用配置，等待来源恢复，通常比清空本地数据更稳妥，也能避免丢掉仍可使用的节点与规则。

加载阶段报错时，先看错误指向的字段或行号。YAML 使用缩进表达层级，制表符、漏写冒号和列表层级错误都可能导致解析失败。能够解析的 YAML 也可能存在语义问题，例如规则引用了不存在的策略组。需要区分文本格式错误与内核校验错误，前者查结构，后者查字段支持和名称引用。

把远程内容和个人修改分开

直接编辑订阅生成的文件，下一次更新时往往会丢失修改。长期设置应放进客户端提供的覆写、合并、补丁或本地扩展入口；具体名称与合并顺序以当前客户端为准。先用一个很小的改动验证持久化，例如调整日志级别，再主动更新订阅并重启内核，确认运行配置确实保留了变化。

数组的合并尤其需要小心。某些覆写机制会替换整个规则列表，而不是只追加一条；策略组也可能被同名项覆盖。应用前应查看预览或导出的最终配置，确认原有节点、策略组和兜底规则仍在。不要同时在界面开关、本地文件和远程补丁三个位置维护同一字段，否则实际生效值会很难解释。

更新后立即变慢，不必先更换整套客户端。可以比较更新前后当前节点、策略组选择与规则命中是否变化。节点名称被调整时，原来的手动选择可能失效，客户端会回到其他成员。轻量操作流程见入门指南的订阅步骤；本章的重点是把更新做成可观察、可恢复的维护动作，而不是只设置一个定时任务。

五、代理模式与连接验证

规则、全局与直连各自改变什么

日常使用从规则模式开始。进入内核的连接会按规则列表寻找去向，既能保留需要直接连接的服务，也能把特定请求交给代理。全局模式通常把进入内核的普通连接交给全局策略，适合短时对照测试；直连模式则用于检查脱离代理出口后的情况。模式名称只描述内核内的选择，不保证所有应用已经被接管。

一个常见误解是切到全局模式后，整台设备的所有通信就都经过代理。若某个应用不读取系统代理，它的连接可能根本没有进入内核，切换模式当然也不会改变结果。因此排错顺序应当是先看连接记录有没有请求，再看命中的策略，最后才判断出口是否可用。不要把接管范围与分流方式当成同一个开关。

建立一条最短的验证链

先保持 TUN 关闭，启用系统代理，选定一个节点并访问测试网页。同时打开连接面板，按目标域名筛选，查看策略与出口。浏览器页面能加载只是第一层证据，连接记录能说明请求确实进入内核，日志则能进一步解释失败阶段。若只用出口地址查询页验证，也要确认该查询请求本身经过了预期路径。

命令行工具可能不读取桌面系统代理，可以显式指定本地入口进行对照。下面命令假设客户端混合端口确实为七八九零；实际运行时，应改成界面显示的端口。测试目标是公开示例站点，不代表所有目标都具有相同可达性。能完成一次请求，说明这条路径基本成立，不等于所有协议、应用与网站都已正常。

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

第二条命令把目标主机名交给 SOCKS 代理处理，有助于与本机先解析域名的路径作比较。若两种方式表现不同，要结合客户端 DNS、节点协议与日志继续判断，不能只凭结果就断言存在某一种泄漏。测试时保存命令、时间、模式与节点，后续重复同样条件才有可比性。

延迟测试不是下载性能承诺

客户端显示的测试数值通常反映某种指定请求的往返表现，具体含义取决于测试地址和实现。数值较低不保证文件下载更快，也不保证视频、游戏或特定网站更稳定。测试失败可能是测试目标不可达，而节点对其他目标仍然可用。选节点应结合真实用途、连接成功率和一段时间的稳定性，不只按列表排序。

浏览器正常而另一个应用失败时，先检查该应用是否支持系统代理、是否配置了独立代理、是否只对部分流量使用代理。登录流程还可能调用系统组件或其他进程，导致主窗口与登录窗口路径不同。不要立即切换全局并长期保留；先找到失败连接，才能决定是调整应用设置、增加规则，还是需要扩大接管范围。

切换节点或模式后，已经建立的长连接可能继续使用旧路径。验证新设置时，可重新打开目标页面，必要时关闭对应连接再发起请求，但不应随意清空与测试无关的全部会话。某些应用还缓存解析结果和连接池，需要退出后重新启动。把旧连接当成新设置的结果，会造成明明修改成功却看似没有变化的错觉。

完成本阶段后，应能复现一条成功连接，并说明它使用的模式、入口与出口。更细的首次连接检查可阅读挑节点、测试与确认流量去向。只有这条最短链路稳定，继续修改规则和 TUN 才能明确判断新增设置带来的变化。

六、规则顺序、策略组与分流维护

从第一条匹配到最后的兜底

规则列表通常自上而下匹配，先满足条件的规则决定连接去向。因此，规则内容与排列顺序同样重要。一个范围很大的域名后缀规则放在前面，可能让后面的精确域名规则永远没有机会执行。新增规则前先找到现有命中位置，不要只在文件末尾追加；末尾已经存在兜底动作时，追加内容尤其容易看起来保存成功却始终不生效。

域名规则适合表达网站或服务边界，地址段规则适合处理明确的网络范围，进程规则则依赖平台、权限与识别能力。一个应用可能访问多个域名，也可能通过辅助进程发起连接，所以把某个主域名写进规则，不代表应用全部请求都被覆盖。维护时应观察实际连接，而不是凭应用名称猜测它会访问哪些服务器。

# 配置片段：并入已有配置，不是完整订阅
# 国内外等地域标签不参与本示例判断
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

示例使用内置直连动作，便于展示顺序，不适合作为所有人的实际分流方案。精确域名规则只匹配指定名称，后缀规则覆盖相应域及其子域；地址段规则的附加选项可以避免为了这条地址匹配主动触发解析。最后的兜底负责处理前面没有匹配的连接。实际要走代理时，目标名称必须对应当前配置中存在的策略组。

先看组类型，再调整成员

手动策略组适合固定选择，自动测试组适合依据配置的探测结果选择成员，故障转移组则更强调顺序与可用性。测试目标、间隔和容差会影响切换行为，不能只看到自动两个字就假设它总会选到实际业务最合适的节点。需要稳定会话的应用，还应关注切换是否导致现有连接中断或重新建立。

策略组之间可以存在引用关系，但名称必须准确，关系也应避免循环。订阅更新改变组名后，本地规则引用旧名称可能加载失败。修改前先列出规则目标、组成员与最终节点的对应关系，确认每条路径能够走到可用出口。复杂配置里最难排查的往往不是规则语法，而是多个名字相近的组之间究竟选中了谁。

用连接记录验证规则，而不是猜

新增分流应从一个明确目标开始，记录修改前的命中规则和出口，再把小范围规则放到合理位置，重新建立连接观察结果。若没有变化，依次检查当前配置是否正确、覆写是否实际合并、规则是否位于更宽泛条目之前，以及目标请求是否属于旧连接。四个位置查完，再考虑规则类型本身不适用。

地址匹配与域名匹配的结果可能受 DNS 行为影响。内核若拿不到原始域名，只能依据现有信息匹配；反过来，fake-ip 映射有助于保留域名与连接的关联，但也需要完整的接管路径。不要把所有异常归因于规则库过期。先确认连接记录中看到了域名还是地址，再决定应补域名规则、地址规则，还是修复解析路径。

规则集适合复用一批持续更新的条件，但需要明确它采用哪种行为类型、存放在哪里以及怎样被规则引用。下载成功不代表引用已经存在，文件类型也不能混用。引入外部规则集前，应了解更新来源和失败时的影响，并保留上次可用内容。不要为了追求覆盖面同时叠加大量重合规则，重复越多，命中解释反而越困难。

维护一段时间后，清理已经失去用途的例外，尤其是临时测试添加的强制直连或强制代理条目。它们可能让未来的订阅规则失去作用，却很难从界面一眼发现。稳定的规则方案不是条目越多越好，而是在出现问题时，能够迅速解释一条连接为什么走到这里，并能安全撤销最近一次修改。

七、TUN 接管与 DNS 协同

在需要扩大接管范围时启用

TUN 通过虚拟网络接口接收系统流量，适合处理不遵循系统代理的应用。但它不提供新的远端出口，也不会自动修复失效节点。启用前，应先用系统代理确认订阅和节点可用，再保存现有配置。这样启用后出现问题，才可以把调查范围集中到权限、路由、DNS 或虚拟接口，而不是从头怀疑整条链路。

桌面端通常需要相应服务权限或网络组件，移动端则主要受系统 VPN 接口管理。若已有企业 VPN、安全工具或其他虚拟网络软件，先确认它们是否也修改默认路由或 DNS。多个工具各自正常，组合后仍可能产生路径竞争。测试期间尽量只保留一个接管工具，同时记录原本必须访问的局域网资源，便于逐项检查。

# mihomo 配置片段，需与有效节点、规则及 DNS 配置合并
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

示例展示常见字段关系，不保证在每个客户端和系统上都适用。自动路由决定是否由内核设置相关路由，自动识别出口接口用于选择实际网络出口，协议栈选项则与系统兼容性有关。客户端可能通过界面生成这些字段，直接写入文件又被覆盖时，应回到它提供的正式入口修改，而不是同时维护两套相互冲突的设置。

DNS 不是附带开关

DNS 劫持通常针对经过接管路径的传统解析请求，不能据此断言所有应用内置的加密解析都会被接管。浏览器自己的安全 DNS、应用私有解析和企业内部域名，都可能采用不同路径。诊断时应分别检查普通网站、局域网名称和依赖特定解析服务的应用，避免只用一个公开域名的结果代表全部网络。

fake-ip 模式向应用返回用于映射的地址，再在后续连接中关联原始域名；这种机制有利于域名分流，但依赖映射与连接路径保持一致。redir-host 更接近返回实际解析地址的方式，却也有自身的匹配与缓存条件。两者没有脱离场景的绝对优劣。某个局域网服务异常时，应先调查域名和应用要求，不要立刻全面切换解析模式。

内核的上游解析、代理服务器域名解析和直接连接域名解析，可能具有不同职责。一个看似合理的加密上游地址，如果必须依赖尚未建立的代理才能访问，就可能形成启动依赖环。节点服务器本身使用域名时，还要确保解析它的路径可用。字段关系可继续查阅nameserver、fallback 与 fake-ip 配置拆解。

启用后分组检查，异常就回退

先测试浏览器，再测试原本不走系统代理的应用，最后检查打印机、网络存储、远程桌面等局域网服务。每一步都查看连接记录与路由相关日志。若局域网异常，先确认目标地址是否属于需要绕过的范围，以及解析是否仍返回正确结果。不要用关闭系统防火墙作为第一反应，它会扩大改动范围，也容易掩盖真实原因。

从无线网络切换到有线网络、热点或休眠恢复后，出口接口与默认路由可能发生变化。TUN 之前可用而切网后失效时，先检查接口识别和服务状态，再重启相应连接。某些环境需要重新建立虚拟接口，但这不等于每次都必须重装客户端。保留切网前后的日志，能够区分接口变化、节点重连和 DNS 缓存问题。

可以用出口查询与解析测试辅助观察，但单个网页不能证明整台设备的所有应用都遵循相同路径。应把结论限定在实际测试过的应用和请求类型。TUN 的合适终点是所需应用被接管、局域网仍可用、切网能恢复，而不是为了让设置看起来完整就一直打开每个高级开关。

八、日常维护、备份与故障定位

把可用状态保存成基线

连接稳定后，记录客户端名称、内核信息、当前配置、订阅来源、接管方式以及需要的本地例外。备份中应包含个人覆写和必要的策略选择，但不应公开带访问标识的地址。仅保存一张主界面截图通常不足以恢复环境，因为真正影响运行的字段可能藏在服务设置、DNS 或本地扩展配置中。

备份文件应保存在只有自己或授权人员能够访问的位置。准备迁移设备时，先导出客户端支持的配置，再检查导出内容是否包含订阅凭据与本地路径。桌面路径不一定适合移动端，某些界面偏好也无法跨系统恢复。迁移成功的标准是新设备能够重建预期连接，而不是文件导入时没有出现错误提示。

更新分开进行，留出观察窗口

客户端、内核、订阅和规则集属于不同更新层。不要在同一个时间段全部更换，否则出问题后无法判断变化来源。可以先更新订阅并验证，再更新客户端或内核，最后处理个人规则。每次都保留一个能够回退的状态，尤其是在重要工作前，不宜临时进行涉及权限、网络扩展或路由的较大调整。

更新日志中的能力变化应结合自己的实际配置阅读。某项新协议支持与当前使用无关时，不必立即迁移；某个旧字段行为改变时，则需要先在副本中验证。图形客户端更新也可能改变配置合并顺序或默认设置，因此升级后应重新查看最终运行配置，而不是只确认原来的按钮仍然显示为开启。

按故障范围划分排查入口

先问故障影响一个目标、一个应用，还是所有连接。只影响单个网站时，目标服务状态和单条规则更值得先查；所有节点同时失败时，本地入口、解析与当前网络限制更值得先查；只有某个节点异常时，则应集中查看该节点的连接错误。范围判断不是最终结论，但能明显减少没有依据的重复操作。

日志应从错误出现的时间附近开始阅读，先找到第一处相关失败，再看后续连锁报错。解析失败可能让后续连接全部超时，本地端口绑定失败也可能引出界面连接异常。不要只截取最后一行。临时提高日志详细程度后，完成排查应恢复日常级别，避免长期积累大量记录、增加存储占用并暴露不必要的访问细节。

开机自启和休眠恢复单独测试

开机启动客户端、启动内核服务和自动启用系统代理可能是三个独立选项。设置后应进行一次真实重启，检查登录前后服务状态，以及网络尚未就绪时订阅更新如何处理。不能只看启动项列表存在程序名称，就认定代理已正常工作。需要密码解锁或用户确认的环境，也可能影响自动连接的完成时间。

休眠恢复与切换网络也要纳入维护检查。若恢复后仅旧会话失败，重新建立连接可能足够；若所有请求都没有记录，则检查接管入口与服务；若记录存在但解析持续失败，再查看 DNS 和出口。按层排查可以保留仍然正常的部分，不必每次都通过重启整台设备把暂时证据清空。

当客户端显示已连接而访问仍异常，先用本手册的最短验证链复测，再根据结果选择分支。若变更无法解释，恢复最后一个可用状态，并一次只重新引入一项修改。维护的目标不是记住所有错误提示，而是形成稳定的记录方式，让下一次同类故障能够更快定位，也让临时修复不会变成长期隐患。

九、从可用配置到可维护的进阶方案

先学会看最终配置

进阶的第一步不是增加更多字段，而是能解释当前运行配置从哪里生成。订阅、客户端默认值、界面开关和本地覆写可能共同参与合并。先找到预览、导出或运行配置入口，抽查监听端口、模式、DNS、策略组和规则顺序。若文件里的值与界面不同，应先弄清覆盖关系，再决定修改哪一层。

建立一个专门用于实验的配置副本，把日常使用配置留作基线。每次实验只改变一项，并写下预期结果与验证方法。例如引入规则集时，先确认文件能更新，再确认规则被引用，最后观察测试连接是否命中。这样即使实验失败，也能指出失败在哪个环节，而不是只得到一个全部不能用的结论。

按依赖关系扩展能力

可以先学习规则集，再学习节点提供器，之后研究 DNS 分流与更复杂的策略组。规则集解决条件复用，节点提供器解决节点来源管理，两者并不相同。使用前应确认内容格式、行为类型、更新位置和引用方式。一个来源能够下载，不代表其内容会自动加入现有规则或策略组，引用关系必须明确存在。

定时更新、健康检查与自动策略选择也要放进同一张依赖图里理解。节点列表更新可能改变成员，健康检查决定可用性信息，策略组再依据自己的类型选出成员。如果某一层更新失败，界面仍可能保留旧结果。排查自动选择异常时，先问成员是否最新、探测是否成功，再问选择逻辑，而不是直接缩短测试间隔。

协议能力需要同时满足内核支持、客户端配置支持和服务端参数正确。看到某个协议名称出现在文档里，不代表当前安装的内核一定能够使用它。迁移旧配置时，可阅读mihomo 与原版 Clash 核心差异，重点核对字段与协议，而不是根据软件名称推断全部配置兼容。

终端与服务环境独立管理

终端环境变量通常只影响当前会话及其子进程，不会自动给所有桌面应用配置代理。不同工具对变量的支持也有差异。需要临时测试时，优先使用命令自身的代理参数；确实需要会话级设置，再使用环境变量。不要把本地地址长期写入多个启动文件后忘记来源，否则客户端退出时，终端可能继续指向失效端口。

# POSIX shell：仅对当前会话及其子进程设置
# 端口需与客户端实际监听值一致
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

# 结束测试后清除本示例设置
unset http_proxy https_proxy

服务管理器启动的进程通常不会继承交互式终端里的全部环境。服务器部署时，应明确配置文件路径、工作目录、运行用户和日志位置，再考虑开机启动。不要把终端里能够运行当成系统服务已经正确配置。使用客户端 API 或控制面板时，也要限制监听范围并设置访问控制，避免把管理入口暴露给不需要访问的网络。

用验收清单替代配置复杂度

一套进阶方案至少应能通过这些检查：普通网页正常，需要代理的应用有连接记录，局域网服务仍可达，订阅更新不会覆盖个人规则，切换网络后能恢复，关闭程序后系统网络能回到预期状态。这些是使用结果，不依赖某一种界面。若新增功能破坏其中一项，应先解决边界问题，再继续叠加能力。

涉及旁路网关、路由器或多设备共享时，风险范围会从单机扩大到其他设备。此时还需要理解网关、转发、防火墙与回程路由，不能直接把桌面 TUN 示例照搬过去。先在独立设备或可隔离的网络里测试，并保留恢复原有网关与 DNS 的方法。超出当前知识范围时，停在稳定的单机方案并不是功能不足，而是合理控制影响面。

需要重新走一次操作主线，可返回入门指南；准备换设备或客户端，可到下载中心按平台选择；遇到具体配置问题，可在技术笔记里按主题继续阅读。系统查阅的价值不在一次读完全部字段，而在每次改动之前，都知道目标、条件、证据和退路在哪里。