Clash 配置完整手册

核心概念：连接经过哪些环节

Clash 的基本任务是接收应用连接，依据配置选择出站方式。一个完整使用环境通常包含图形客户端、代理内核、配置文件和远端代理服务。安装客户端只是准备好本地工具，并不等于已经拥有可连接的远端节点。先分清这些角色，才能判断问题出在安装、订阅、规则还是网络本身，避免把所有连接失败都归结为客户端故障。

客户端负责操作，内核负责连接

图形客户端提供订阅管理、模式切换、日志查看和系统集成；内核解析配置、处理 DNS、执行规则并建立连接。mihomo 是 Clash 生态中继续发展的内核，常见的 Clash Meta 名称与它的演进有关。不同客户端可能采用不同内核和封装方式，因此界面名称相似，并不代表支持完全相同的配置字段。排错时应同时记录客户端名称与内核信息。

配置文件描述本地监听端口、节点、策略组、规则及 DNS 行为。订阅通常是用来获取配置或节点信息的地址，但不同服务返回的内容不一定相同：有的提供完整 YAML，有的只提供节点集合。客户端能导入其中一种格式，不代表能自动识别全部格式。遇到解析错误，应先核对订阅提供方标注的目标格式，而不是反复修改本地网络开关。

从应用到出站的处理链

以浏览器打开网页为例，连接先通过系统代理或 TUN 进入内核，再由规则判断应当直连还是交给某个策略组；策略组继续选择具体节点，最终由该节点连接目标服务。DNS 可能在其中多个位置参与解析，具体取决于接管方式和配置。理解这条链后，查看日志就有了顺序：先确认连接是否进入，再看命中规则，最后检查选中的出站。

直连表示由当前设备所在网络直接访问目标，不表示流量没有经过本地规则判断。代理表示连接交给指定出站，也不等于目标网站必然可访问。远端服务器故障、账户限制、目标服务拒绝和本地 DNS 异常，都可能让已经进入代理链的连接失败。延迟测试成功只能说明特定测试请求完成，不能替代实际应用验证。

建立最小的验证方法

学习阶段只选一个客户端、一份已激活配置和一个手动策略组。先记录未启用代理时的网络状态，再打开系统代理，访问一个可重复测试的页面，并在连接列表中查找对应域名。能看到连接及其出站，才说明本地接管链路建立。不要同时启用多个代理工具，它们可能争抢端口、系统代理设置或默认路由，让结果难以解释。

后续章节都沿用这条验证链。如果没有看到连接，回到入口设置；看到连接却选错策略，检查模式和规则；策略正确但请求失败，再看节点与目标网络。这个顺序比依次尝试所有开关更容易保留有效证据，也能减少对正常配置的误改。

选择客户端：先看平台与配置需求

初次使用优先从 Clash Plus 开始，先把安装、订阅和连接验证走通，再考虑其他界面或管理方式。选型的重点不是客户端名称多少，而是设备系统、处理器架构、配置格式以及需要的系统集成能力。各平台的安装包和可选项目以下载页为准；需要并列查看差异时，可以结合客户端横向评测阅读。

按设备确定候选范围

Windows 可选 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu，以及用于历史环境的 Clash for Windows。macOS 可选 Clash Plus、Clash Verge Rev、FlClash 与归档的 ClashX Meta。Android 可选 Clash Plus、Clash Meta for Android、FlClash、Surfboard。iOS 优先查看 Clash Plus 的商店入口；Linux 则从 Clash Verge Rev 与 FlClash 中选择适合发行版的包。

Clash for Windows 与 ClashX Meta 已停止维护，适合了解旧配置或处理现有环境，不建议作为新设备的首选。归档客户端可能缺少新协议、系统兼容修复或配置扩展支持。已有用户迁移时应先备份订阅来源和个人规则，再用新客户端单独导入测试，不要直接覆盖旧目录；确认新环境可连接之后，再移除旧程序。

架构与发行包不能混选

处理器架构决定安装包能否运行。Windows 设备需要在系统信息中确认系统类型；macOS 在“关于本机”查看芯片或处理器；Android 则按设备支持的 ABI 选择。Linux 除了区分 AMD64、ARM64，还要确认包管理格式。相同系统名称下面可能有多个包，不能只看文件大小猜测。下载页没有对应架构时，也不要用另一架构的包强行替代。

不要把兼容 Clash 配置理解成每个字段都能通用。比如规则提供器、特定 DNS 选项或协议参数，需要对应内核支持；图形界面也可能重写部分字段。Surfboard 属于另一套配置使用路径，导入前应遵循它支持的格式说明，不能默认把完整 Clash YAML 原样交给它。换客户端后出现解析失败，先对照格式与能力，再判断订阅是否损坏。

用同一条件做迁移比较

比较两个客户端时，保持设备、网络、订阅、节点和测试目标一致，并且一次只运行一个接管网络的实例。先测试相同节点能否连通，再观察所需功能是否可用。不要仅凭一次延迟读数判定优劣：测试 URL、超时时间、是否复用连接和当时网络状态都可能不同。真正影响日常体验的是连接稳定性、规则可解释性与维护成本。

服务器、路由器或需要自行编排进程的环境可以考虑直接运行 Mihomo 内核，但这会增加服务管理、权限和控制接口保护的工作。普通桌面用户先用图形客户端更容易观察状态。iOS 用户可在下载页查看 Clash Plus，并通过其官网 clashplus.io了解产品信息；安装后仍然需要完成配置导入和连接授权。

安装与检查：先让本地入口正常工作

安装阶段的目标是客户端能启动、内核能运行、本地端口能监听，而不是立即开启所有网络功能。先从下载页选择正确的系统与架构，完成安装后保持默认设置，暂时关闭其他代理工具。首次启动记录程序的数据目录、当前混合端口和日志入口；这些信息会在导入配置、处理端口冲突及迁移备份时反复用到。

桌面平台的安装顺序

Windows 先正常安装并启动程序，确认主界面没有内核启动失败提示，再导入订阅。系统询问网络访问权限时，应根据实际使用范围选择网络类型；不需要局域网共享时，不必为其他设备开放代理入口。若安装在便携目录，确认当前账户能够写入配置和日志。程序放在只读目录可能表现为设置无法保存、重启后订阅消失或更新失败。

macOS 按安装包形式将应用放入合适的位置，再首次打开。系统拦截时先核对下载来源和系统提示，不要通过批量关闭安全机制解决。TUN 或后台服务需要额外授权时，等基础连接验证完成再处理。Linux 使用与发行版相符的软件包，留意安装过程中的依赖错误；界面启动成功但内核立即退出，往往需要进一步查看日志中的权限或配置报错。

移动平台先确认连接授权

Android 首次建立本地 VPN 接口时会出现系统授权提示，授权后才能通过该入口接管连接。系统通常限制同时生效的 VPN 服务，因此其他 VPN、防火墙或基于 VPN 的过滤工具可能发生冲突。iOS 安装 Clash Plus 后，按系统提示添加连接配置并授权。两类平台都应先在前台验证可用，再观察锁屏、切换网络和后台运行是否影响连接。

不要把移动端的 VPN 标识理解为已经成功连接远端节点，它只说明系统侧的网络扩展或接口正在工作。节点不可达、订阅未激活或规则配置错误时，标识仍可能存在。应以实际请求和客户端连接记录为准。Android 如果在锁屏后频繁断开，再检查省电策略、后台活动限制和应用自动启动设置，避免一开始就同时修改多项系统权限。

识别端口占用与启动失败

混合端口通常同时接收 HTTP 与 SOCKS 代理请求，具体数值以客户端当前设置为准。示例中的 7890 不是所有设备的固定要求。如果日志出现监听地址已被占用，应先退出其他代理程序，再检查是否有旧内核进程残留。也可以改用空闲端口，但手动设置过代理的浏览器、终端和开发工具必须同步修改，不能只改客户端一侧。

# Windows PowerShell：查看本地端口监听
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux：查看监听该 TCP 端口的进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

这些命令只用于观察，不会自动修复冲突。端口未监听时，继续检查内核是否启动以及配置是否通过解析；端口有监听时，核对进程归属，避免把别的服务误认成 Clash。若终端提示命令不可用，可以使用系统自带的网络或进程管理工具完成同类检查，不需要为了执行示例安装不相关的软件。

安装检查结束时，应能找到日志、确认内核状态并知道本地代理端口。接下来导入订阅，而不是先尝试 TUN。Windows 的防火墙、自启和服务模式细节可继续阅读Windows 安装配置全流程，首次启动的跨平台检查则见初始设置清单。

订阅导入：区分下载、解析与激活

订阅导入成功需要经过三个独立环节：客户端下载到内容，内核能够解析内容，当前运行环境使用了这份配置。列表中出现一个订阅名称，只能证明建立了一个配置条目，不能证明它已经生效。建议先保留一份可用的原始订阅，再逐步添加本地覆写。订阅地址往往包含账户访问参数，应像密码一样保存，不要放进公开截图或求助文本。

从导入到实际启用

打开客户端的订阅、配置或配置文件页面，选择通过链接导入，粘贴完整地址并保存。地址前后的空格、换行和聊天软件附带的标点都可能造成请求失败。导入后执行更新，观察下载结果和解析提示，然后在配置列表中选择该条目作为当前配置。不同客户端的按钮名称可能是启用、使用或激活，判断依据是当前配置标记和节点列表是否同步变化。

本地文件导入与链接订阅不同。文件导入得到的是当时的内容副本，通常不会自动从远端获取后续节点变化；链接订阅则可以在更新时重新获取内容。如果收到的是压缩文件、网页或登录页面，不应直接当作 YAML 导入。也不要凭扩展名判断内容正确：返回状态正常的网页仍然可能让解析器报告缺少字段或出现意外字符。

按失败环节定位原因

下载失败先看错误类型：超时可能涉及当前网络与订阅服务器之间的连通性；证书错误要检查设备时间和请求路径；授权失败可能意味着订阅地址已失效或账户状态发生变化。解析失败则检查目标格式、缩进和内核能力。只有在内容下载并通过解析之后，才适合继续检查策略组和节点，不应把所有订阅问题都当成节点不可用。

某些网络中订阅服务器需要通过已有代理才能访问，而新设备尚未建立可用代理，这会形成启动依赖。应先使用订阅提供方支持的可达入口，或导入此前保存的有效配置，再考虑更新请求的代理设置。不要把含有账户参数的地址交给陌生的在线转换服务；转换过程中对方可以接触原始链接及返回内容，风险不只是配置格式变化。

让个人修改独立于远端内容

远端订阅更新时可能重建配置文件，直接编辑其中的规则、端口或组名容易被覆盖。优先使用客户端提供的覆写、合并或扩展配置机制，并确认它是在订阅更新之后应用。不同客户端的合并规则并不统一，尤其要核对列表是追加还是替换。先用一个小改动验证效果，例如增加一条明确的测试规则，再扩大到整套个人分流。

订阅中出现的策略组名称需要保持一致。若本地规则写向一个已被提供方删除或改名的组，配置可能无法加载。更新后应检查组是否仍存在、手动选择是否保留，以及是否发生了节点名称变化。不要仅依靠界面旧缓存判断更新结果，必要时重新加载配置并查看内核接受的实际内容，但应先保存当前可用状态。

如果订阅能够正常更新但访问失败，继续阅读代理模式章节。更多常见错误可在常见问题查阅，求助时只提供错误类型、客户端名称和脱敏后的配置结构，不必展示完整订阅地址。

代理模式：把接管入口与出站选择分开

规则、全局和直连决定进入内核的连接如何出站；系统代理和 TUN 决定应用连接是否进入内核。这是两组不同的设置。开启全局模式不会自动接管忽略系统代理的应用，关闭系统代理也不一定停止已经由 TUN 接管的连接。遇到“已经切换模式但应用没有变化”，首先应确认该应用使用的入口，而不是继续更换节点。

日常使用优先规则模式

规则模式按照配置中规则的顺序，为每条连接选定策略。一个连接可能被安排直连，另一个连接则经过代理组，具体结果由域名、地址、进程等匹配条件决定。它适合日常使用，但前提是规则完整且组名有效。首次测试时先选择一个手动策略组中的可用节点，再观察目标域名命中哪条规则，避免把规则选错出站误认为节点故障。

全局模式通常将进入内核的连接交给全局策略，仍需要在对应策略中选择正确的节点或组。它适合短时间排除规则因素：同一个目标在规则模式失败、全局模式成功，说明需要重点检查分流结果。这个比较必须保证应用确实进入内核，而且全局策略与原来的代理策略最终选中了同一个节点，否则改变了两个变量，结论就不可靠。

直连模式让进入内核的连接使用直接出站，常用于确认基础网络状态。它不等同于退出客户端，也不一定关闭本地监听或虚拟接口。若需要完全撤销客户端对系统网络的影响，应按顺序关闭 TUN、关闭系统代理，再正常退出程序。单纯切到直连，不能用于判断系统代理残留是否清理干净。

用显式代理建立对照

终端工具不一定读取桌面系统代理，浏览器插件也可能覆盖系统设置。需要验证本地入口时，可以让单次命令明确使用混合端口。这能把系统代理读取行为与内核出站行为分开。下面命令假定当前混合端口是 7890；如果已改端口，应同步修改。Windows PowerShell 中使用明确的可执行文件名，可以避免与命令别名混淆。

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

# macOS / Linux
curl --proxy http://127.0.0.1:7890 -I https://example.com

返回响应说明这一次请求走通了指定入口，但不能证明其他应用使用相同路径。测试时同时打开连接列表，确认请求域名、规则和出站。若命令立即提示无法连接本地端口，回到安装章节检查监听；若已连接本地端口但远端超时，再检查节点。测试目标本身也可能有限制，必要时更换另一个已知正常的目标重复验证。

切换后重新建立连接

模式切换通常首先影响新连接，已经建立的长连接可能继续沿用原出站。验证结果时应重新加载页面、关闭相关连接或重启测试应用，避免把复用连接的表现当成设置未生效。视频、即时通信和浏览器的连接池尤其容易让结果延迟变化。关闭全部连接会中断正在进行的传输，因此应在可以接受中断时操作。

规则分流：从匹配顺序到策略组

规则分流的核心是自上而下查找匹配项，通常由先命中的规则决定出站。因此写规则前先回答三个问题：希望匹配什么连接、匹配后交给谁、这条规则应该比哪些规则更早执行。规则数量不是质量指标，清晰的顺序和稳定的策略组引用更重要。建议先理解内联规则，再接触外部规则集，避免一次引入过多无法追踪的条件。

先认识三类常见匹配

DOMAIN 用于精确匹配域名，DOMAIN-SUFFIX 用于匹配指定域名及其子域名，IP-CIDR 用于匹配地址范围。MATCH 是最后的兜底规则，不应提前放在仍需执行的规则上方。域名规则依赖内核掌握目标域名；若应用只发起纯 IP 连接，某些域名条件就可能无法直接命中，需要结合实际连接信息判断。

策略组不是规则本身，而是被规则引用的出站选择器。手动选择组适合学习和固定出口；自动测试组通常依据指定测试目标的结果选择；故障转移组则关注可用性和候选顺序。组的具体能力取决于内核支持。自动测试得出的结果只反映测试目标，不能保证同一节点对所有网站、地区服务或长时间传输都表现相同。

# 规则片段：合并到已有配置，不是完整订阅
# DIRECT 是内置直连出站
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

这段示例展示顺序与语法，所有出站都使用内置直连，便于在没有节点的环境理解规则。实际需要代理时，应将对应出站改为当前配置中真实存在的策略组名称。不要直接使用教程里的示意组名。最后的直连兜底也不是通用建议：如果期望未匹配连接默认代理，就应让兜底指向已经验证可用的代理组，并评估这一改变覆盖的流量范围。

理解 no-resolve 与 DNS 的关系

地址规则中的 no-resolve 表示不为了这条地址匹配主动把域名解析成 IP；它不是禁止所有 DNS，也不意味着对已知目标 IP 不再匹配。对私有网段规则使用它，可以减少仅为判断该网段而触发的额外解析。若依赖目标解析结果进行分流，就需要结合 DNS 配置考虑是否应保留解析过程，而不是给所有地址规则机械添加相同参数。

DNS 答案会影响地址规则与实际连接目的地，域名规则却不一定要求先完成目标地址解析。fake-ip 模式下还会出现合成地址，它用于维持域名与连接的映射，并不是远端服务器真实地址。看到合成地址不能立即判断为污染。应查看内核识别到的域名、命中规则和最终出站，再确定是否需要调整 DNS 或排除特定应用。

修改规则后做命中验证

先备份当前配置，在本地覆写中只添加一条目标明确的规则，重新加载后访问对应域名，并从连接详情确认实际命中项。若没有命中，检查是否存在更靠前的宽泛规则、应用是否复用旧连接，以及客户端是否真的把覆写应用到了运行配置。若配置无法加载，先查缩进、逗号和组名，恢复上一份可用内容后再逐项修复。

规则集适合把大量同类域名集中维护，但应核对提供器的格式、行为类型、更新周期与本地缓存路径。下载失败时是否仍有缓存可用，会影响配置能否正常运行。不要同时叠加用途重合、来源不清的多个规则集，否则相同域名可能被不同条件提前截获。先建立清晰的分类策略，再选择与这些分类相符的规则内容。

更细的匹配顺序、后缀范围和兜底写法见Clash 自定义规则与优先级详解。开始维护个人规则时，给每条修改记录用途与验证目标，后续迁移会更容易。

TUN 模式：扩大接管范围并处理 DNS

TUN 通过虚拟网络接口接收连接，适合处理不遵循系统代理的应用，但它不是所有问题的通用修复开关。启用前应确认普通系统代理路径已经可用，否则一旦接管范围扩大，原本局部的配置错误可能变成整机访问异常。还要区分 TUN 接口存在、路由已经接管、DNS 已被接管这三个状态，它们不一定同时成立。

先确认权限与冲突条件

桌面平台通常需要服务模式、辅助服务或提升权限才能创建接口和修改路由，具体方式由客户端实现。先阅读界面的服务状态提示，再按需授权。设备上已有公司 VPN、虚拟机网络、容器网络或其他代理时，应记录其状态。两个工具都修改默认路由或 DNS，可能形成环路、抢占或局部不可达；测试时先让网络环境尽量单一。

移动平台的网络接管由系统提供的 VPN 或网络扩展机制管理，界面不一定直接出现与桌面相同的 TUN 参数。不要把桌面 YAML 中的全部网络选项原样复制到手机。系统限制、客户端实现和配置覆写方式都可能不同。即使使用同一份订阅，也应分别验证 Wi-Fi、移动网络、锁屏和网络切换后的表现。

认识常见参数的职责

# mihomo TUN 配置片段，需合并到已有配置
# 先确认客户端是否已经通过界面生成相同设置
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable 控制接口启用，stack 选择网络栈，auto-route 让内核按平台能力设置路由，auto-detect-interface 尝试识别出站接口。示例不是完整配置，也不代表所有环境都适合相同组合。若客户端界面已经管理这些字段，应以它的合并机制为准，避免配置文件与界面相互覆盖。

dns-hijack 用于接管匹配的 DNS 流量，但它并不自动覆盖所有应用内置的加密解析方式。浏览器的安全 DNS、应用自带解析、硬编码 IP 和系统缓存都可能改变观察结果。启用后既要检查普通网页，也要测试本地网络名称和实际需要的应用；不要只看到一个网站能打开，就判断全部 DNS 路径都符合预期。

按可恢复的顺序启用

保存当前可用配置，确认退出客户端的方法，然后在界面开启 TUN。先观察内核日志是否成功创建接口，再访问一个日常网站和一个局域网资源，并检查连接记录。局域网打印机、路由器管理页或公司内部地址受影响时，应核对相关网段的路由与直连规则。路由排除和规则直连属于不同层面，不能简单用增加域名规则替代全部路由处理。

如果出现整机断网，先关闭 TUN，保留客户端运行并检查普通系统代理路径能否恢复。恢复后比较两种入口的差别，再检查服务状态、默认接口、DNS 和其他 VPN。不要在失联状态下同时修改网络栈、DNS、规则与节点，这样即使恢复也无法知道原因。远程管理服务器时尤其要保留独立访问路径，避免修改默认路由后失去控制。

UDP 应用需要另外验证。网页可访问只说明部分 TCP 请求正常，不能证明实时通信、游戏或特定 UDP 协议可用。需要同时确认节点支持、服务端策略、当前网络以及客户端配置。切换网络栈不应作为第一步，先找日志中对应连接及错误，再决定是否需要更换出站或调整接管策略。

有关系统时间、抓包工具和 DNS 路径造成的证书问题，可阅读开启 Clash 后网页提示证书错误的排查顺序。完成验证后，只保留确实需要的接管方式。

日常维护：更新、备份与恢复

稳定使用的关键是让每次变化都可追踪、可撤回。客户端更新、内核更新、订阅更新和个人规则修改是四种不同操作，不宜同时执行。先记录当前能工作的状态，再做单项改变并重复同一组测试。这样出现问题时能够恢复到明确的起点，而不是在多份配置、多个节点和多个接管开关之间来回尝试。

备份哪些内容才有用

至少保存订阅来源、当前激活配置、个人覆写规则、策略组选择和关键网络设置。客户端的数据目录中可能包含访问参数或管理接口信息，备份应放在受控位置，不要上传公开仓库。跨设备迁移前先确认导出的文件包含哪些内容：有些只导出规则，有些包含整个运行目录，二者对隐私和恢复能力的影响不同。

订阅原文与个人规则最好分开保存。前者可以从远端重新更新，后者可能只存在于本机。记录端口、是否允许局域网连接、TUN 状态和开机启动设置也很重要，因为它们可能由客户端界面保存，不一定出现在导出的 YAML 中。恢复后不要只检查节点名称，还要验证系统代理指向、监听地址和本地覆写是否真正生效。

更新前后使用同一张检查表

更新前先阅读与自身平台和使用功能相关的变更说明，不必因为看到新包就立刻在全部设备同步安装。更新后确认程序启动、内核解析、订阅加载、规则命中与 TUN 状态，再测试一个代理目标和一个直连目标。若新环境不稳定，应使用此前保存的配置与设置恢复；不同内核之间的缓存或扩展字段不一定可以直接倒退沿用。

日常延迟测试可以用来发现明显不可达节点，但不应高频刷新整个订阅来追逐最低数值。大量并发测试会消耗网络资源，也可能受到服务端限制。下载速度、首次连接耗时和长连接稳定性是不同指标。为常用策略组保留一个已验证的候选，出现异常时用它作对照，比根据一次测试结果不断切换更有判断价值。

用日志形成排错记录

日志先使用日常级别，只有在复现问题的短时间内提高详细程度。记录问题发生时间、应用、目标域名、接管入口、模式、命中规则和错误信息。日志中的超时、连接被拒绝、解析失败和授权失败代表不同环节，不要只摘最后一句“失败”。复制日志前检查是否包含订阅参数、节点地址、内网地址或本机路径，并按需要脱敏。

环境变化也需要记录。切换到新的 Wi-Fi、接入公司网络、启用安全软件或启动虚拟机后才出现问题，往往提示默认路由、DNS 或防火墙规则发生了变化。先恢复到之前网络做对照，再判断是否需要更改客户端。若多个设备在同一网络同时异常，优先检查公共网络与远端服务，而不是分别重装每台设备的客户端。

正常退出与卸载前的处理

退出前先关闭 TUN 和系统代理，再正常结束程序。若程序异常退出后浏览器无法访问，检查系统代理是否仍指向已经停止监听的本地端口；只有确认端口已失效，才按当前网络需要撤销残留设置。不要直接执行来源不明的网络重置脚本，全面重置可能同时清除公司代理、静态地址或其他原本有效的网络配置。

进阶路线：从配置使用到可控维护

进阶不等于打开更多选项，而是能够预测配置变化会影响什么，并用记录证明实际结果。完成前面八个阶段后，建议按配置结构、规则提供器、DNS、运行管理的顺序学习。每次只引入一种能力，先在可恢复的测试配置中验证，再合并到日常环境。对于没有明确用途的字段，保持默认通常比照抄整份“优化配置”更稳妥。

先建立配置的依赖关系

一份配置可以看成由入口、出站、策略组、规则和 DNS 组成的依赖网络。规则引用策略组，策略组引用节点或其他组，提供器负责获取外部内容，系统集成再把应用流量送入入口。修改名称时应沿引用链检查，删除节点来源前先确认是否仍被策略组使用。能解析成功只是第一步，还要验证最终出站是否符合原先目的。

学习规则提供器时，先创建一个小规模、内容已知的规则集合，再检查格式、行为类型和更新结果。不要直接接入一长串外部列表，把分流逻辑交给无法解释的组合。更新周期也需要合理设置：规则内容不需要每几秒重新获取，过频刷新只会增加网络依赖。要理解首次启动没有缓存和日常更新失败但存在缓存的区别。

再研究 DNS 与连接元数据

DNS 学习应先弄清系统解析、内核解析和应用自带解析的区别，再比较 fake-ip 与返回实际地址的处理方式。对每次测试同时记录请求域名、解析结果、命中规则和出站路径。某个模式解决了一个应用的问题，也可能影响局域网发现或使用特殊解析流程的应用，因此调整时需要保留覆盖常用场景的回归检查，而不是只验证单个网站。

流量嗅探可以在一定条件下补充域名信息，但不等于能够看到所有应用内容，也不能保证每条连接都能正确补全目标。它的效果受协议、加密方式与应用行为影响。先理解没有嗅探时的连接信息，再按需要评估是否启用；不要把嗅探当成替代正确 DNS 接管或规则设计的手段。涉及敏感业务时还应遵循所在网络的管理要求。

使用命令行内核时先保护边界

直接运行内核适合服务器和路由器环境，但同时需要自行管理配置路径、工作目录、进程重启、日志保留和权限。先在前台完成配置检查，再交给系统服务管理。以下命令假定已安装可执行的 mihomo，且当前目录存在配置文件；它用于测试配置，不负责下载安装，也不会证明所有远端节点都可访问。

# 检查当前配置的语法与可加载性
mihomo -t -f ./config.yaml

# 以前台方式运行指定配置
mihomo -f ./config.yaml

配置测试通过后，还应在实际运行中验证规则和连接。服务环境与交互终端的工作目录、环境变量、用户权限可能不同，因此前台能运行不代表服务一定能找到同一份文件。使用绝对路径和明确的数据目录有助于降低歧义，但应依据实际部署位置填写，不要照搬其他设备的路径。

允许局域网连接会扩大本地代理入口的可达范围，外部控制接口则可能提供更强的配置管理能力。两者都不能随意暴露到公网。只在确有共享或管理需求时启用，限制监听地址和网络访问范围，并使用客户端支持的认证机制。不要为了从手机访问面板就直接开放路由器端口；先确认访问边界与撤销方法，再进行配置。

把排错方法整理成个人手册

为常用环境保留一套固定测试：基础直连目标、需要代理的业务、局域网资源、终端显式代理以及实际需要的 UDP 应用。一次调整后逐项重复，记录结果而非印象。问题出现时按入口、解析、规则、出站、远端五个环节定位。这样积累的记录能直接服务于后续迁移，也更容易向他人描述可复现的问题。

能够解释每项改动的目的、验证它的结果并恢复旧状态，就已经具备独立维护配置的基础。后续选择功能时仍然遵循同一原则：先确认问题属于哪个环节，再选择对应能力，不为了追求参数数量增加不必要的复杂度。