Clash 使用与配置完整手册

第一章 · 核心概念与连接路径

客户端、内核与配置各负责什么

Clash 生态中的客户端通常包含图形界面和代理内核。界面负责导入配置、展示代理组、管理系统代理与日志；内核负责监听本地端口、匹配规则并建立连接。mihomo 是这一生态中常见的内核。界面名称相似，不代表所带内核、支持字段和权限机制完全相同，因此迁移设置前要先确认目标客户端的说明。

配置文件是内核的工作说明，常以 YAML 保存。它描述本地监听端口、可用代理、代理组、路由规则与 DNS 行为。订阅通常是远程配置的获取地址，不是客户端本身，也不是开关一开便能使用的服务。只有客户端取得有效配置、启用该配置，并且应用流量进入内核，后续规则和代理选择才有机会生效。

节点、代理组与规则的关系

节点表示一个具体出口及其连接参数；代理组是对节点或其他代理组的组织方式，例如手动选择或定期检测后自动选择。规则则决定一条连接应该交给哪个出口。遇到某个网站异常时，首先看连接记录命中了哪条规则、送到了哪个组，再检查组内实际选中的节点，比直接反复切换整个配置更容易定位原因。

可以把浏览器访问理解为一条处理链：应用读取系统代理或使用自身设置，把请求交给本地监听端口；内核根据可获得的域名、地址和规则决定出口；选中的节点再与目标建立连接。这里每一段都可能失败。浏览器显示超时，只能说明链路没有完成，不能单凭这一个提示判断订阅失效、DNS 异常或服务器不可用。

系统代理与 TUN 不属于同一层

系统代理是一项供应用读取的操作系统设置，并不会强制所有程序遵守。TUN 则借助虚拟网络接口和路由接收流量，涉及额外权限、DNS 与路由配置。第一次使用时先以系统代理验证浏览器连接；只有确认确实有应用绕过系统代理，再评估 TUN，避免在基础配置尚未可用时同时排查多层网络行为。

本地端口也需要区分。混合端口可接受 HTTP 与 SOCKS 代理请求，控制接口则用于客户端管理内核，两者不能互换。把浏览器代理地址填成控制接口地址，通常只会得到连接错误。日常使用优先让客户端自动设置系统代理，不要照抄其他设备的端口；需要手工填写时，应从当前运行设置中读取实际值。

最后区分两种“更新”：客户端更新替换程序及其内核，订阅更新拉取远程配置内容。前者不必然修复过期订阅，后者也不会升级程序。记录问题时把这两类变化分别写清，并保留故障发生前最后一次成功连接的条件，这会成为后续章节中最有价值的排查基线。

第二章 · 按系统选择客户端

先确认设备，再比较界面

选型先看操作系统、处理器架构与需要接管的应用，再看界面偏好。对于初次安装，优先从下载页的 Clash Plus开始；需要比较配置管理方式、桌面集成和内核设置入口时，再阅读客户端对比。不要为了寻找某个截图里的开关，同时安装并运行多套网络接管工具。

在 Windows 的“设置 → 系统 → 系统信息”中查看系统类型，确认设备使用哪种处理器架构；在 macOS 的“关于本机”中查看芯片或处理器名称。Apple Silicon 与 Intel 安装包不能只凭文件大小区分。下载页提供的架构才是可选范围，遇到不匹配的设备应先确认支持情况，不要把其他平台的包改名后尝试运行。

配置兼容性比外观更重要

同在一个平台，不同客户端对配置的处理也可能不同。有的在订阅之外另加覆写层，有的直接编辑本地文件，有的只接受特定格式。尤其是 Surfboard，不能因为出现在同一下载页，就假设它能直接读取任意 Clash YAML。应先核对客户端支持的配置类型，再向配置提供方取得对应内容，避免把格式错误误判成网络故障。

桌面端若需要较多配置切换，可以比较代理组展示、覆写入口、日志导出与退出时恢复代理的行为。手机端则更应关注前台连接状态、后台限制和按应用接管方式。功能越多不等于越适合当前设备；能稳定完成导入、连接、验证和退出恢复的客户端，才适合作为后续配置实验的固定环境。

iPhone 可从下载页进入 Clash Plus 的 App Store 页面，并通过官网 clashplus.io了解产品说明。获取后，先熟悉配置列表和连接入口，再授权系统添加 VPN 配置。iOS 的后台与网络权限由系统管理，桌面端关于服务安装、系统托盘和本地端口的操作不能直接照搬到手机上。

归档客户端与独立内核

Clash for Windows 与 ClashX Meta 在本站按已停止维护的归档客户端展示，适合已有环境的兼容性查阅，不作为新安装首选。旧教程中出现它们的界面，并不意味着当前仍应沿用相同安装流程。对于新设备，先选择维护中的客户端，再把教程中的概念映射到现有菜单，通常能减少权限和配置兼容问题。

独立 mihomo 内核面向需要自行管理进程、配置目录和网络规则的用户。它不是完整桌面界面的替代安装包，运行后也不会自动具备所有系统集成功能。服务器、路由器等环境还需要安排启动服务与访问控制；普通桌面用户先使用图形客户端，可以把注意力集中在配置本身，而不是进程守护和系统路由细节。

迁移客户端时，先关闭旧客户端的系统代理与 TUN，再退出程序，随后启动新客户端。只迁移自己理解的配置、规则和覆写，不复制含义不明的运行目录。完成迁移后重新检查端口、代理组选择和 DNS 行为，因为同一份订阅在不同客户端中可能叠加不同的默认设置，连接结果未必完全一致。

第三章 · 安装、权限与首次启动

安装前整理现有网络设置

开始安装前，退出已有代理客户端，并确认浏览器在原始网络下的访问情况。如果设备之前使用过手动代理，先记录地址与端口，再判断是否需要关闭。这样安装后出现异常时，能够区分是原有网络问题还是新增设置造成的变化。工作或学校管理的设备应遵循设备管理规则，不要绕过组织设置安装系统服务。

从客户端下载页选择与系统及架构匹配的文件。Windows 按安装向导完成部署后，从开始菜单启动；macOS 若获得的是磁盘映像，打开后按提示将应用移入应用程序目录，再从该目录运行。不要长期从临时解压目录或磁盘映像中启动，否则升级、辅助服务路径和开机启动项可能出现不一致。

把权限申请对应到具体功能

首次启动时先观察主界面、配置列表与日志入口，不急着允许所有权限。普通配置导入与系统级网络接管所需权限不同：TUN 或服务模式可能需要管理员确认，通知权限则主要影响状态提示。每次授权前看清系统窗口中的应用名称和操作目的；如果申请来自不认识的程序，取消后先核对安装来源与正在进行的操作。

macOS 出现无法打开或系统扩展相关提示时，先核对文件来源，再到系统设置的隐私与安全相关页面查看具体原因，按系统提供的方式处理。不要把关闭整机安全机制当作常规安装步骤。钥匙串或网络扩展授权与普通订阅导入并非同一件事，遇到重复弹窗时应检查应用是否仍在原安装位置，以及辅助组件是否安装完整。

Android 安装后，先在客户端中导入配置，再点击连接，并阅读系统弹出的 VPN 连接确认。持续运行时若频繁被系统停止，可在电池与后台管理中检查该应用的限制，但不必一开始就修改所有节电选项。部分系统只允许一个普通 VPN 服务活动，启动另一款 VPN 应用可能使当前连接断开，这不一定是客户端自身故障。

iOS 同样需要系统确认添加 VPN 配置；授权后返回客户端检查配置是否已选中，再执行连接。Linux 则先确认发行版适用的包格式，通过桌面软件安装器或发行版包管理工具安装，并观察缺少依赖的具体提示。桌面启动失败与内核配置失败应分开处理：前者先看应用启动错误，后者再进入配置与日志检查。

建立首次启动的检查顺序

没有订阅时，主界面显示未连接或空代理组通常是正常状态。此时先找到配置、代理、连接和日志四个页面，确认程序能正常保存设置。随后查看本地监听端口，记录是否启用系统代理、是否启用 TUN。首次测试只开系统代理，保留其他网络接管功能关闭，能让下一章的订阅验证保持清晰的因果关系。

Windows 可在 PowerShell 中查看某个示例端口的监听情况。下面的数字仅代表待查询端口，应按客户端实际设置调整；查到进程后先通过任务管理器识别程序，再正常退出，不要直接结束不认识的系统进程。端口没有监听也不表示网络必然可用，它只说明当前查询范围内未发现对应的监听项。

Get-NetTCPConnection -LocalPort 7890 -State Listen

最后测试一次退出恢复：关闭系统代理与 TUN，退出客户端，确认普通直连访问仍符合预期。如果退出后浏览器持续提示代理服务器不可用，检查系统是否残留指向本地的代理设置。先恢复网络入口，再重新启动客户端；安装阶段把恢复路径走通，比连接出问题后临时寻找开关更可靠。

第四章 · 订阅导入与配置生效

识别订阅链接和实际配置

订阅链接通常由配置服务提供方生成，可能包含个人访问标识，应按敏感信息保存。不要把完整链接贴进公开截图、在线转换页面或问题反馈中。本站讲解配置使用流程，不提供可长期依赖的公共订阅。搜索 Clash 免费节点时，也应先评估来源、有效期和数据风险，不把临时获得的配置当作稳定的日常基础。

取得链接后，打开客户端的“配置”“订阅”或 Profile 页面，选择新增远程配置，把地址粘贴到 URL 输入框，设置便于识别的名称，然后点击导入或下载。名称可描述用途，例如“日常配置”，不要包含访问标识。完成后应看到配置条目、更新时间或可用的代理组，而不是只看到一条仍待下载的空记录。

下载成功后还要启用

导入成功不等于已经切换运行配置。在配置列表中选中刚导入的条目，点击启用、使用或对应选择标记，再到代理页面检查组名和选项是否变化。某些客户端会自动重载内核，某些需要额外确认。若界面仍显示旧代理组，先回到配置页确认启用状态，不要急着重新安装客户端或反复添加同一个订阅。

本地 YAML 导入适合已有文件或需要离线编辑的情况。选择“从文件导入”后，确认导入的是配置文件本身，而不是压缩包、网页保存文件或截图。远程配置通常能拉取更新，本地文件则主要由用户维护；编辑磁盘原文件是否会同步到客户端，取决于它采用引用还是复制机制，应通过一次小范围修改与重新加载确认。

如果导入提示格式错误，先看错误位置与响应类型。订阅地址可能返回了登录页、访问限制说明或服务到期页面，这些内容不是 YAML，即使能在浏览器里打开也不能被内核使用。还要检查粘贴时是否混入空格、换行和中文标点；不要把订阅管理网页的地址当成实际配置地址，二者常常并不相同。

理解 YAML 的结构要求

YAML 依靠缩进表达层级，通常使用空格而不是制表符。同一层级的字段需要对齐，列表项的短横线也要保持位置一致。下例仅展示基础设置片段，不包含可用代理，不能单独当作完整订阅连接。它的用途是帮助识别顶层字段：模式、日志级别和监听设置彼此并列，不应缩进到某个代理节点内部。

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

订阅更新前应先理解客户端的保存方式。直接在远程配置中修改规则，下一次更新可能覆盖改动；需要长期保留的本地调整，应放入客户端支持的覆写或合并机制。初期先不添加复杂覆写，确认原始订阅可以正常加载和连接，再逐项加入自定义内容。每次加入后检查最终生效配置，避免只看编辑框便以为修改已生效。

自动更新间隔不宜设得过密，普通使用可按照提供方建议配置。频繁更新既不能让失效服务恢复，也可能触发访问限制。更新失败时不要立即删除最后一份可用配置，先保留当前内容，再单独测试拉取。需要进一步区分超时、空内容与格式报错时，可参照订阅解析错误自查清单逐层检查。

如果同一订阅在旧客户端可用、新客户端报错，优先比较内核支持的字段与配置格式，不要公开传播完整配置求助。先导出并遮盖节点地址、认证信息和订阅标识，只保留错误附近的结构及报错文本，通常已足够判断缩进、未知字段或格式不兼容问题。

第五章 · 代理模式与连接验证

先把入口和出口分开检查

客户端中的“规则、全局、直连”主要决定进入内核之后如何选择出口；系统代理和 TUN 决定应用流量能否进入内核。把模式切到全局，并不意味着所有应用都会自动被接管。验证时先打开客户端连接页面，再用浏览器访问一个明确的测试目标，观察是否出现新连接，有记录以后再讨论模式和节点选择。

日常通常从规则模式开始。到代理页面找到主要选择组，手动选一个已知可用的节点，再开启系统代理。测试过程中保持浏览器和测试网址不变，先观察能否建立连接，再检查连接详情中的命中规则与实际出口。节点检测成功只是说明某种探测请求完成，不能保证任意网站、协议或长连接都能正常工作。

用全局模式做有限对照

某个目标在规则模式下失败时，可以临时切换全局模式，并确认全局组实际选中了哪个节点。如果同一入口、同一节点下全局可用而规则不可用，应重点检查规则命中与目标策略组。如果两种模式都失败，就继续检查节点、解析和上游网络。完成对照后恢复规则模式，避免后续测试仍停留在临时设置上。

直连模式也不等于彻底恢复系统原状。应用可能仍通过本地代理端口进入内核，DNS 与流量观察方式也可能继续受客户端影响。若要判断完全退出后的网络，应先关闭系统代理和 TUN，再退出客户端进行独立测试。把“内核直连”和“客户端完全退出”分为两种测试条件，才能避免对故障范围作出错误判断。

逐层定位没有连接记录的情况

浏览器访问时没有新记录，先检查系统代理是否真正开启，以及代理地址是否指向当前监听端口。浏览器扩展、自定义代理配置、应用内网络设置可能覆盖系统选择；另一个客户端也可能刚刚改写了系统代理。暂时关闭不必要的代理扩展，保持一个客户端运行，然后重新建立请求，观察连接页面是否发生变化。

若记录出现但连接失败，展开详情看目标域名、目标端口、策略链和错误信息。超时、拒绝连接、解析失败各指向不同层次，不应统一处理为“换节点”。先用同一目标比较两个已配置出口，再用同一出口比较两个目标。这样每次只改变一个变量，能更清楚地区分目标服务限制、单个节点问题与本地配置问题。

命令行程序不一定读取桌面系统代理。需要独立验证本地 HTTP 代理时，可使用下面的请求，地址和端口应与实际运行设置一致。示例域名用于说明测试方式，不保证当前网络一定可达；命令得到响应只证明这次请求经过指定入口完成，不能替代对浏览器或其他应用实际连接记录的检查。

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

切换模式或节点后，已有连接可能沿用原来的出口。为了观察新设置，应重新发起请求；必要时只关闭相关连接或重开测试应用，不必直接清空全部系统网络设置。浏览器缓存、连接复用和页面离线内容也可能造成误判，测试时关注新建连接及其时间，而不是仅看一个已经打开的页面能否继续显示。

本章结束时应得到一份简短基线：使用哪个客户端、启用哪份配置、选择哪个组和节点、通过什么入口访问、哪个目标成功。保存这组条件，下一章修改规则后再重复测试。若速度问题只在特定场景出现，可继续阅读连接速度的分层排查，不要同时更换 DNS、模式和整套订阅。

第六章 · 规则分流与配置顺序

从上到下，首先命中

规则模式按从上到下的顺序匹配连接，通常在第一条匹配规则处确定策略。更具体的例外应放在较宽的规则之前，兜底规则放在末尾。添加规则后没有效果，首先检查上面是否已有更早命中的条目，再看目标名称与策略组是否正确。把同一条规则反复复制到列表末尾，无法改变已经被前面规则截走的连接。

域名规则适合按服务名称分流，地址段规则适合处理明确的 IP 网络范围。域名后缀规则用于匹配指定域及其子域，不应简单替换为关键字规则，否则可能扩大匹配范围。不同应用是否向内核提供域名，会影响域名规则的可用性；连接页面只有 IP 时，还需要结合 DNS 工作方式判断，不能直接认定规则语法有误。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

这段规则是合并示例，不包含完整代理定义。其中 DIRECT 为内置直连策略，PROXY 必须与实际配置中的代理或代理组名称完全一致；没有这个名称时应改用已有组名。最后的 MATCH 接收前面未命中的连接，不能放在其他规则前面。复制前先看自己的组名，不要仅因为示例排版完整就把它覆盖到整份配置中。

地址规则与解析边界

地址段规则中的前缀长度描述网络范围，不是端口号。示例中的私有地址段用于说明局域网直连思路，但实际家庭或办公网络未必使用同一网段，应根据网关与设备地址确认。不要随意把宽泛的公网地址段加入直连列表；过宽匹配可能让原本需要代理的目标提前命中，并把问题表现为部分网站间歇性不可用。

no-resolve 表示这条地址规则不为了匹配而主动触发域名解析，不是关闭整套 DNS。连接已经具有目标 IP 时，仍可以按地址范围判断。是否添加它取决于规则目的与解析策略：若需要基于解析后的地址进行分流，应理解额外解析的影响；若只想处理本来就是 IP 的访问，可以减少不必要的解析步骤。

远程规则集与本地覆写

规则数量增多后，可使用内核支持的规则提供器管理远程或本地规则集。规则集的内容格式必须与声明的行为类型一致，例如域名集合与完整规则集合不能混用；文件可下载并不代表一定可解析。还要检查引用名称、缓存路径和更新时间，避免远程拉取失败后误以为已经加载新规则，实际却仍使用旧缓存。

图形客户端可能把订阅规则、本地覆写和合并脚本组合成最终配置。某个编辑器中的顺序未必就是内核实际读取的顺序。修改后应打开最终配置或运行配置预览，搜索目标条目，确认位置与策略名称；再从连接页面查看实际命中。形成“编辑、预览、重载、验证”的闭环，比只看保存成功提示更可靠。

遇到应用登录与网页访问走不同出口时，应先检查真实目标。一次操作可能涉及认证、资源、接口等多个域名，不能只给地址栏里的主域添加规则。通过连接记录逐个确认必要目标，优先使用范围明确的规则；不要为修复单次失败直接把所有流量改为全局，这会隐藏规则缺口，而不是解释和修复它。

规则维护的目标是可解释，而不是条目越多越好。为自定义例外写清用途与撤销条件，过期后及时清理；当订阅本身已包含对应规则时，评估是否仍需重复覆写。完成本章后，应能从一条连接的目标、命中规则和策略链解释其出口，而不是只能凭页面是否打开来猜测分流结果。

第七章 · TUN、DNS 与路由接管

明确开启 TUN 的理由

TUN 通过虚拟网络接口接收流量，常用于不遵循系统代理的应用。它不是速度增强按钮，也不能修复无效节点或错误订阅。先确认第五章的系统代理基线可用，再判断目标应用是否确实没有进入内核；如果只是浏览器代理扩展配置错误，应先修正入口，不必直接引入虚拟网卡、系统路由与 DNS 接管。

开启前记录当前网络接口、其他 VPN 状态和客户端的关闭路径。桌面端可能需要安装辅助服务或提升权限，移动端则由系统 VPN 接口管理。优先使用客户端提供的 TUN 开关和默认适配参数，不要一边开启图形界面的接管，一边照着服务器教程手工添加系统路由，否则可能形成重复规则或难以回退的状态。

把字段看作相互配合的设置

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

这是 mihomo TUN 设置片段，需要与已有配置合并，并不代替完整 DNS 与代理定义。auto-route 控制自动路由，auto-detect-interface 用于自动识别出站接口，协议栈选项则应以当前内核支持情况为准。某些客户端会生成这些字段，应优先在界面修改，避免文件设置与界面设置互相覆盖。

dns-hijack 中的示例用于捕获匹配的常规 DNS 请求，不意味着能接管所有加密解析或应用自带的解析机制。浏览器安全 DNS、应用内加密解析、企业内部域名，都可能改变最终观察结果。先保持一套明确的解析方案，再检查域名是否进入预期 DNS 流程；不要看到 DNS 字样便同时更换所有解析服务。

理解 fake-ip 与本地解析

fake-ip 模式会为域名返回映射地址，由内核维护域名与连接的对应关系，便于后续分流。这类地址并不是目标服务器的真实公网地址，不能拿它直接判断网站位置或节点线路。少数依赖真实地址、本地发现或特定校验行为的应用可能需要例外，应按客户端和内核支持的过滤机制处理，而不是整体关闭所有分流。

局域网打印机、文件共享和公司内部域名需要特别测试。它们可能依赖本地 DNS、特定网段路由或广播发现，不能仅靠一条公网域名规则解决。开启 TUN 后先测试网关访问、局域网设备和常用内部服务，再测试外部目标。如果只有内部资源异常，应检查直连路由与解析路径，不要立即把所有代理节点视为故障源。

冲突识别与安全回退

另一个 VPN、虚拟机网络、容器网桥或安全软件也可能修改路由。出现所有应用同时断连时，先关闭 TUN，确认原始网络能否恢复，再逐个排除冲突。自动识别出站接口在多网卡环境中未必符合预期，尤其是有线与无线同时启用时；需要手工指定接口时，应使用设备当前真实名称，不照抄其他机器的示例。

若浏览器可用而某个应用仍失败，检查该应用协议、目标端口以及节点是否支持相应传输。UDP 业务能否工作，还依赖节点能力、内核配置与上游网络，TUN 本身不会自动补足缺失能力。通过连接详情判断请求是否进入、使用何种协议、在哪一步报错，才能决定继续调整接管范围还是更换测试出口。

测试结束后做一次回退演练：关闭 TUN，确认虚拟接口和自动路由的状态符合客户端预期，再恢复系统代理基线。设备从睡眠唤醒、切换无线网络或拔插网线后，也要重新观察出站接口与解析是否正常。只有这些日常场景都稳定，才把 TUN 作为长期工作方式；否则保留较简单的入口更容易维护。

第八章 · 更新、备份与故障维护

保存能够恢复的配置基线

稳定运行后，记录当前客户端、启用配置、主要代理组选择、系统代理与 TUN 状态，并保存必要的本地覆写。备份不只是复制一个订阅地址，还应包括用户自己编写的规则及其合并方式。远程订阅能够重新获取，但本地调整未必有其他副本；遇到需要重装客户端的情况，先导出这些内容，再处理程序文件。

备份中可能包含节点认证信息、订阅标识或控制接口设置，应保存在受控位置，不上传公开代码仓库或公开网盘。截图和日志也可能暴露访问目标与设备路径，分享前要遮盖相关字段。排错需要的是结构、错误和时间顺序，不需要公开完整账户信息；保留最小必要内容，通常还能让问题描述更清楚。

把更新分成三个独立动作

客户端升级、内核更新和订阅刷新应分开执行并分别验证。先记录当前可用状态，再完成其中一个动作，检查配置能否加载和常用目标能否访问，最后进行下一个。若把程序、内核、订阅和 DNS 一次全部更换，即使问题得到缓解，也很难知道真正原因，更难在下次出现同类问题时快速恢复。

升级前阅读变更说明，尤其关注配置字段、服务模式和默认行为变化。不要仅凭版本数字判断是否适合当前环境，也不必为了追求最新而随意替换客户端内核文件。部分图形客户端要求内核与界面配合，手动替换后可能出现控制接口或配置生成不兼容；优先使用客户端正式提供的更新路径，并保留回退所需的本地配置。

按范围缩小故障

故障发生时，先判断影响范围：是所有应用还是单个应用，是所有目标还是一个域名，是当前网络还是切换网络后也一样。随后回到第五章基线，固定配置和出口做对照。只有一个目标失败时，重点看规则、目标服务和出口限制；所有请求都没有记录时，重点看入口和进程；记录里集中出现解析错误时，再查 DNS。

需要详细日志时，临时提高日志级别并重现一次最小操作，记下准确时间，然后恢复日常级别。长时间保留调试日志会增加存储与检索负担，也可能留下更多访问细节。不要把数小时日志直接堆给维护者，应筛选故障前后的相关片段，说明预期行为、实际行为和已经做过的对照测试。

速度变慢应与无法连接分开排查。下载任务、无线信号、设备负载、运营商路径和远端拥塞都可能影响体验，单次节点探测无法代表持续吞吐。保持同一测试目标、相近测试条件和固定出口，比较更换节点或网络后的变化；不要只根据一个自动测速排序频繁切换，以免长连接被不断打断。

恢复顺序与长期整理

严重异常时，先关闭 TUN 和系统代理，恢复基础网络，再加载最后可用配置。若问题来自订阅更新，尝试使用保留的本地副本进行对照；若来自自定义覆写，暂时禁用该层，而不是删除整个客户端。只有确认程序文件或用户目录确实损坏时，才考虑重新安装，并在清理前保存必要配置。

定期删除不再使用的订阅条目、失效规则和重复启动项，检查是否仍有旧客户端常驻。对多份配置的用途、切换方式和更新策略有疑问，可阅读Profile 与多配置管理笔记。维护的目标不是每天调参，而是让每次变更有记录、异常有证据、恢复有明确路径。

第九章 · 从稳定配置到进阶管理

先学习代理组，而不是复制整套配置

进阶的起点是一份已经验证可用的配置。先学习代理组之间如何引用，再学习自动选择和故障切换；不要直接复制包含大量未知规则、脚本和远程资源的整套文件。每引入一个功能，都应该能说明它解决什么问题、依赖哪些条件、如何验证以及怎样撤销，否则配置复杂度只会增加后续排查成本。

手动选择组适合明确控制出口，自动测试组可按指定探测目标比较候选节点，故障切换组则按自身逻辑寻找可用项。探测目标必须能代表要观察的连通性，但没有一个地址能够代表全部业务。某节点探测正常而视频、游戏或工作服务异常时，应查看实际业务连接，不要把探测结果当作全面健康结论。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    use:
      - daily
    url: https://example.com/
    interval: 600

这段示例依赖名为 daily 的代理提供器，必须先在完整配置中定义它；不能只复制代理组片段便期待出现节点。示例测试地址也应按实际可达性和使用目的调整。AUTO 被 PROXY 引用，流量只有选中 AUTO 时才交给它的选择结果；界面里存在自动组，不代表所有连接都会自动使用该组。

理解提供器与覆写的维护边界

代理提供器适合把节点来源与本地策略分开管理，规则提供器则把规则内容与主配置分离。两者都会引入远程获取、缓存和格式兼容问题，应分别命名并明确用途。资源下载失败时，先检查本地是否有可用缓存，再判断启动是否受影响；不要把所有资源都依赖同一条尚未建立的代理路径，以免形成启动依赖循环。

覆写适合保存个人策略，但合并行为由客户端决定。列表可能替换，也可能追加，脚本还可能在合并后继续修改内容，因此不能假设所有客户端都使用相同顺序。调整复杂配置前先做一个很小的实验：加入可识别的组或规则，观察最终配置的位置与内容，再决定正式组织方式，避免一开始就写大段难以验证的逻辑。

控制接口与局域网访问

外部控制接口用于管理内核，具有不同于普通代理入口的权限含义。没有远程管理需求时，保持仅本机可访问，不随意监听全部网卡。确需局域网管理时，应同时设置认证、系统防火墙和来源限制，确认管理页面与接口的安全边界；不要因为界面打不开，就直接取消所有访问控制或把接口暴露到公网。

同样，开启局域网代理需要同时考虑监听地址、端口、访问设备和防火墙。只修改 allow-lan 并不保证其他设备能够连接，也不代表应该让所有网络都能访问。先在受信任网络中用一台设备测试，明确代理入口与控制接口的区别；离开该网络或改用公共无线网络前，关闭不再需要的共享能力。

建立可重复的实验方法

每次进阶实验保留原始配置、副本和变更说明，准备一组固定测试：普通网页、需要分流的目标、局域网服务以及退出恢复。修改 DNS、规则或 TUN 中任意一层后，都重复这组测试，记录连接命中与错误变化。只有结果符合预期再保留改动，不以“页面偶尔能开”作为配置正确的唯一标准。

接下来不必继续堆叠参数。需要在新设备上复现基础流程，返回快速上手文档；需要更换客户端，查看下载页与选型对比；遇到具体边界问题，再查阅技术笔记。把稳定运行作为基础，把有明确目的的变更作为进阶，才能让配置长期保持可理解与可维护。