Clash 完整手册

阶段 01 / 建立概念

核心概念：客户端、内核与连接路径

先分清界面和实际转发程序

Clash 生态中，客户端通常指带窗口、托盘菜单和配置管理功能的应用；内核负责读取配置、建立代理连接、匹配规则及处理 DNS。mihomo 是这一生态中持续发展的内核。界面提供的开关不等于内核全部能力，同一个内核在不同客户端中也可能使用不同名称。遇到教程截图不一致，先找设置含义，不必机械寻找完全相同的位置。

把连接拆成几个环节：应用产生请求，系统或应用设置决定是否交给本地代理，内核按当前模式选择处理路径，代理策略再决定实际出口。订阅只是提供配置或节点信息，不能替代这些步骤。导入成功只能证明配置被客户端接受；代理开启只能证明入口已设置；网页能够加载才说明相关链路基本贯通，三种状态不能相互替代。

区分节点、策略组和规则

节点包含服务器地址、协议和认证参数，描述连接远端服务的方法。策略组把节点或其他策略组合在一起，提供手动选择、自动检测或故障转移等行为。规则则回答某个连接应交给哪个策略。手动组中选择了一个节点，不代表所有连接都会使用它；只有命中该组的流量才受这次选择影响。排错时必须同时看命中规则和最终出口。

完整配置通常包含本地监听端口、代理节点、策略组、规则与 DNS 等内容；节点列表则可能只有服务器信息。两者都可能通过链接获取，但不能默认互换。客户端支持解析某类节点列表，也不代表它能自动补出符合预期的分流规则。后续选择订阅格式时，要确认提供方给出的究竟是完整 Clash 配置，还是需要进一步组织的节点集合。

把本地代理和远端服务分开理解

本地混合端口是应用与内核交换流量的入口，不是远端服务器的端口。常见示例使用 mixed-port: 7890，但实际值由当前配置与客户端设置共同决定。不能因为教程写了这个数字，就直接覆盖正在使用的端口。远端服务还依赖账号状态、协议支持和网络可达性，本地程序运行正常并不能证明远端也正常。

系统代理主要影响愿意读取系统代理设置的应用；TUN 则通过虚拟网络接口接管符合路由条件的流量。二者并不是规则模式的替代项，而是流量进入内核的不同入口。可以把入口与分流看成两个维度：先确认请求是否进入内核，再确认进入后走向哪里。这个顺序能避免把入口故障误判成规则错误，也能减少不必要的 DNS 调整。

开始操作前，记录操作系统、客户端名称、配置来源和希望改变的访问行为。例如浏览器需要代理、局域网设备保持直连，便比“所有功能都打开”更容易验证。代理软件也不等同于匿名工具，远端服务、目标网站和本地应用仍各自处理相关数据。只导入可信配置，按所在地要求与网络管理规定使用，不把网络入口开放给不需要的设备。

阶段 02 / 选择工具

选择客户端：先看平台，再看配置兼容

优先确认当前设备的使用方式

新安装优先从 Clash Plus 开始，按下载页选择平台入口。选择时同时看系统架构、系统支持范围、订阅格式和所需权限，不只看软件名称。桌面客户端适合管理配置与查看连接，移动端更依赖系统提供的网络扩展或 VPN 接口。需要长期运行的服务器或路由器，则可以考虑内核方式部署，但要自行负责服务与配置维护。

Windows 用户可依次了解 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu；Clash for Windows 属于已停止维护的归档选项。寻找 Clash for Windows 替代时，应先保存原有订阅来源和自定义规则，再确认新客户端是否支持同类配置。旧软件的目录结构和界面设置通常不能直接照搬，迁移重点是配置内容，不是把全部应用数据复制过去。

macOS 可选择 Clash Plus、Clash Verge Rev、FlClash；ClashX Meta 属于已停止维护的归档选项。Apple Silicon 与 Intel 安装包需要区分，先在系统信息中确认芯片类型。更换客户端时还要检查旧程序是否仍在登录时启动，避免两个托盘应用反复修改系统代理。只有一个代理入口管理者，系统设置才容易保持一致，也便于判断退出后的恢复行为。

理解移动端和 Linux 的差异

Android 可了解 Clash Plus、Clash Meta for Android、FlClash 和 Surfboard。注意 Surfboard 使用的配置体系与 Clash YAML 不相同，不能把所有订阅链接当成通用输入。选择之前先核对提供方的格式说明。系统显示的 VPN 图标通常表示本地网络接口已经建立，不应单凭这个图标判断流量已到达预期代理出口，还需要观察应用访问结果。

iOS 优先查看 Clash Plus 的商店入口，并通过官网 clashplus.io了解产品信息。系统网络扩展、后台生命周期及应用沙盒会影响配置路径，不能照抄桌面端的服务安装步骤。Linux 图形桌面可优先考虑 Clash Verge Rev，再了解 FlClash；按发行版选择包格式，并区分系统代理设置与整个系统的路由接管。

用实际功能完成选型

如果配置使用较新的协议、规则提供器或 DNS 参数，应确认客户端实际搭载的内核能够解析这些字段。客户端名称中出现 Clash，并不能保证所有扩展语法都一致。导入时报“不支持字段”时，先对照内核文档和当前配置格式，不要盲目删除整段内容。删除参数可能让配置通过解析，却同时改变原有安全设置或分流行为。

对多数新用户而言，配置导入清楚、错误提示可读、系统代理可恢复，比开关数量更重要。对需要排查应用分流的人，连接详情、规则命中与进程识别能力更重要。对笔记本和手机，休眠唤醒、网络切换及后台策略也应纳入测试。先列出真实需求，再安装一个候选程序完成验证，不必为了比较界面一次装齐全部客户端。

确定客户端后，保留当前可用安装包和导出的自定义设置，并记录订阅更新方式。后续迁移时先在新程序中完成配置解析，再停用旧程序的流量入口，最后启用新程序的入口。这个交接顺序能够减少断网，也避免把端口冲突误认为新软件不可用。具体包型、平台入口及维护标记以下载页的当前说明为准，不根据历史截图推断。

阶段 03 / 建立运行环境

安装与权限：确认内核启动和端口归属

先完成普通启动，再处理高级权限

下载与系统架构相符的安装包，关闭仍在运行的同类客户端，再按系统提示安装。首次启动先不要打开 TUN、局域网访问和自动启动等选项，先确认界面能够打开、内核可以运行、配置页能够访问。把安装、配置解析和系统接管拆成独立步骤，后面出现错误时才知道变化发生在哪一层，而不是在一堆同时打开的选项里反复尝试。

Windows 中，图形界面和后台服务可能分别运行。TUN 或某些系统级操作需要客户端提供的服务模式或管理员授权，但普通界面不必因此长期以最高权限运行。若服务安装失败，先阅读应用日志和系统提示，确认安全软件是否阻止了相关操作。不要下载来历不明的修复脚本，也不要为了通过安装直接关闭整套系统防护。

macOS 应将应用放到适合长期使用的位置后再启动，按系统提示处理来源确认和网络相关授权。系统代理需要修改网络服务设置，TUN 可能还需要额外权限，具体取决于客户端实现。遇到无法启动时，应核对应用来源、芯片架构和系统兼容范围，而不是直接复制网上的权限绕过命令；不同系统版本的授权位置可能不同。

观察移动端授权与 Linux 服务

Android 首次连接通常会请求建立 VPN 连接，确认请求来自正在使用的客户端后再授权。若已有另一个使用系统 VPN 通道的应用，二者可能无法同时接管网络；需要先决定保留哪一个。iOS 同样需要按系统提示授权相关网络配置。授权完成后回到客户端观察运行状态，不能在系统弹窗出现后就认为订阅与出口也已经准备完成。

Linux 图形应用能打开，不代表它能成功修改桌面代理或创建虚拟接口。根据所选客户端说明处理服务权限，避免对整个安装目录赋予过宽写入权限。使用内核部署时，应明确服务账号、配置目录、工作目录和日志归属。不要把下载包直接作为长期工作目录使用，否则清理下载文件时可能同时删除正在引用的规则文件和配置。

核对混合端口，而不是反复改数字

启动日志出现地址占用时，先查明占用进程。可能是旧客户端没有退出，也可能是同一程序的另一个实例，甚至是无关服务。确认后只保留需要的实例，或为当前客户端选择空闲端口。端口改变后，浏览器扩展、命令行环境变量及手动代理配置也要同步调整；只改内核一侧，会留下应用仍然访问旧入口的问题。

# Windows PowerShell：查看示例端口的监听记录
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux：查看示例端口的监听记录
ss -ltnp 'sport = :7890'

# macOS：查看示例端口的监听记录
lsof -nP -iTCP:7890 -sTCP:LISTEN

这些命令只能辅助观察本机监听，部分进程信息可能需要额外权限才能显示。看到监听记录后，结合进程名称和客户端日志判断归属，不要直接结束陌生系统进程。没有监听记录也不一定代表安装损坏，内核可能还在等待有效配置，或者实际使用了另一个端口。先检查设置页和日志中的当前值，再决定是否调整安装环境。

最后测试退出恢复：在能够接受短暂中断的时间，退出客户端并确认系统代理是否被正确清除，再重新打开应用。若应用退出后浏览器无法访问，而系统仍指向本地代理端口，说明入口没有恢复。优先通过系统网络设置关闭残留代理，然后重新启动客户端排查退出流程。这个测试应在配置完成前做一次，避免以后把正常退出后的问题当作网络故障。

阶段 04 / 准备有效配置

订阅与配置：导入、启用和保留本地修改

确认输入格式，再执行导入

打开客户端的配置或订阅页面，选择从 URL 导入，粘贴可信来源提供的完整链接。先检查复制内容是否包含前后空格、换行或聊天软件附加的标点，再执行下载。订阅地址可能携带账户访问凭据，不要发到公开讨论区，也不要粘贴到不可信的在线转换网站。截图时应隐藏完整地址，尤其不能只遮住域名而留下后面的敏感参数。

导入本地文件时，选择有效的 YAML 配置，并确认文件不是网页保存结果或被系统追加了文本扩展名。完整配置、Base64 节点列表和单个分享链接的结构不同，客户端是否接受取决于导入器能力。需要区分格式时，可阅读订阅 URL、本地 YAML 与 Base64 格式说明，不要靠反复修改文件后缀尝试兼容。

下载完成后，还要在配置列表中选择并启用这一份配置。部分客户端允许同时保存多份订阅，但内核实际只加载当前选中的配置或其合并结果。检查页面上的当前标记，再看代理页是否出现预期策略组。配置名称能够显示，只代表记录存在；如果内核报解析错误，仍应回到日志定位字段、缩进或引用名称的问题。

理解 YAML 结构与策略引用

YAML 使用空格表达层级，不能随意混用制表符。数组项目通常以连字符开头，字段名称与值之间需要符合语法的分隔。包含特殊字符的文本可以使用引号，但要确保成对闭合。排查时优先看日志提供的位置及其前后几行，因为错误常由上一行遗漏符号造成。不要直接把整个配置发到公开平台，节点密码和认证信息也可能藏在较深的结构中。

# 最小直连演示：用于理解层级，不包含远端代理节点
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

这个示例可以用于理解结构，但所有连接最终都会直连，不应拿它替换期望访问远端服务的订阅。规则中的策略名称必须在配置中存在，大小写与文字也应对应。日常修改建议利用客户端提供的覆写、合并或扩展机制，具体名称因应用而异。直接修改下载生成的配置，可能在下一次订阅刷新时被覆盖，造成设置“自动消失”。

安排刷新，并处理失败分支

自动更新间隔是维护选项，不是连接速度设置。某些界面以分钟计，另一些以秒计，输入前要看单位。例如界面若明确使用分钟，填写一千四百四十代表一天；不能把这个值直接复制进要求秒数的提供器字段。也不宜通过极短间隔持续请求服务端，频繁刷新不能修复格式不兼容，还可能触发提供方的请求限制。

更新失败先区分网络超时、认证失效、返回网页和配置解析错误。超时需要检查访问路径；认证失效应核对账号与订阅地址；返回网页可能是登录页或错误页面；解析错误则需要检查格式及内核支持范围。“经代理更新”只有在现有代理仍可用时才有帮助，如果当前配置已经失效，可能需要暂时改为直连获取，或使用提供方支持的其他更新方式。

每次成功更新后，确认当前配置仍被启用，再测试策略组选择是否按预期保留。保留一份不公开分享的可用配置用于回退，并把自定义规则另行备份。更完整的报错路径见订阅更新失败与自动更新间隔设置。先恢复可用连接，再整理失败原因，比连续删除并重建订阅更容易保留线索。

阶段 05 / 验证流量入口

代理模式：分清系统代理、规则与全局

先决定请求怎样进入内核

完成配置导入后，先选定一个可用策略，再开启系统代理，使用普通浏览器发起一次新的访问。打开连接列表，观察是否出现对应域名及处理策略。如果网页失败且完全没有连接记录，应优先检查系统代理和浏览器自身代理设置，而不是先改规则。浏览器扩展、应用内独立代理和系统设置可能互相覆盖，需要明确当前请求究竟读取哪一个入口。

系统代理通常把支持它的应用引向本机地址和端口，并不保证所有程序都会遵循。命令行工具、游戏、后台服务及某些商店应用可能使用自己的网络栈。Windows 上的 UWP 应用还可能涉及回环访问限制，不能把所有相关错误都归因于订阅。需要时查看客户端提供的回环设置或系统说明，但只对确有需求的应用调整，不要批量放开全部应用权限。

按用途选择规则、全局或直连

规则模式按配置中的条件分配连接，适合日常分流；全局模式通常把进入内核的连接交给全局策略；直连模式则让进入内核的连接直接访问目标。这里的“全局”不等于系统所有流量都已经被接管：没有进入内核的请求，不会因为选择全局模式就自动改道。先验证入口，再选择模式，是整个手册最重要的排错顺序之一。

全局模式适合短时间对比测试。某个目标在规则模式失败、全局模式成功时，说明规则或其关联策略值得检查，但也可能涉及不同出口带来的 DNS、连接复用等差异，不能直接认定某一条规则就是唯一原因。测试结束应恢复原来的模式，并关闭旧连接或重新启动相关应用，让后续请求按照新设置建立，避免旧会话干扰判断。

用显式代理建立对照

在本地混合端口确实为七八九零时，可通过下面的命令显式指定代理。命令中的目标是公开示例站点，只用于观察连接能否建立。Windows PowerShell 使用 curl.exe可避免某些环境中的同名命令别名差异。若端口不同，需要替换为当前值。命令成功仅证明这次请求的路径可用，不能据此推断所有应用或所有目标都正常。

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

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

显式代理可以访问而浏览器失败时，检查浏览器扩展、独立代理设置和缓存连接；二者都失败且日志有请求时，转向策略选择、节点可用性及目标访问限制。日志没有请求则再次确认端口、内核是否运行和请求是否真的执行。不要仅根据浏览器显示的通用错误页判断，因为同一个错误提示可能由解析失败、连接拒绝或远端断开共同触发。

命令行环境变量也可能留下历史代理入口。排错时检查当前终端是否设置过 HTTP_PROXY、HTTPS_PROXY或 ALL_PROXY，以及应用是否遵循这些变量。修改变量后通常只影响新启动的进程，已运行程序可能仍保留旧值。不要为了让一个终端使用代理就全局修改所有会话；先在单个终端中验证，再决定是否持久化。

完成本章后，应能说明哪个应用走系统代理、哪个应用需要显式设置，以及当前模式的作用范围。若仍出现“已连接却打不开网页”，按照系统代理、端口占用与规则排查清单逐项检查。每次只改一个变量，记录改动前后的结果，避免一次切换模式、节点和 DNS 后失去比较依据。

阶段 06 / 控制连接走向

规则分流：按顺序匹配并验证实际命中

先理解顺序，再写条件

规则列表通常从上到下匹配，第一条满足条件的规则决定处理策略，最后使用兜底规则接住其余流量。因此规则并不是“条件越具体就自动优先”，位置同样重要。把覆盖范围很大的条件放在前面，可能让下面的细分条件永远没有机会生效。修改前先写清目标：哪些域名直连、哪些交给某个策略组、没有匹配时怎样处理。

域名规则与 IP 规则观察的对象不同。DOMAIN匹配指定域名，DOMAIN-SUFFIX用于域名后缀，IP-CIDR针对地址网段，GEOIP依赖地理数据库。域名后缀规则并不等于随意的字符串包含条件，也不会自动处理与该网站有关的所有独立资源域名。一个页面可能同时请求登录、图片、接口等不同主机，需要按实际连接记录补齐判断。

从可理解的最小规则开始

下面的片段演示常见顺序，需要并入已有完整配置，且其中的 PROXY必须是已经定义的策略或策略组。示例将一个域名后缀交给代理，将私有网段直连，再对中国大陆地址使用直连规则，最后交给代理兜底。这只是学习用的分流结构，不代表任何网络环境都适合原样采用，尤其需要结合局域网路由和服务方建议调整。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve可以避免为了匹配这一条 IP 规则而主动发起域名解析，不是关闭整个配置的 DNS，也不是让目标永远没有 IP。当连接已经具有可用地址时，仍可能进行地址匹配。是否使用它，要看希望怎样处理域名请求和解析成本。地理数据库则需要有可用数据来源，数据库缺失或过旧时，相关规则的表现也可能与预期不同。

保留局域网访问与服务发现

路由器管理页、打印机、文件服务器和企业内网常需要保持直连，但不能只依赖几个私有网段解决所有问题。内网可能使用专用域名、分流 DNS 或其他地址范围，跨子网访问还受实际路由影响。遇到内网域名失败，应分别确认域名解析和目标地址可达性，不要简单把整个顶级域名都加入直连，以免把不相关服务也一起改道。

规则提供器适合维护较大的规则集合，但必须区分规则行为类型与文件格式。域名集合、地址集合和经典规则集合的写法不同，引用时的类型要与内容对应。使用前先确认来源可信、更新周期合理以及下载失败时是否有本地可用内容。不要把不理解的大型规则合集直接叠加，因为重复条件、过宽范围和更新覆盖会让命中结果越来越难解释。

用连接详情闭环，而不是只看配置文本

每次调整规则后，确认配置已重新加载，再为目标建立新连接，查看连接详情中的域名、目标地址、命中规则和最终策略。有些应用会复用长连接，旧连接不会因为规则文本变化就立刻更换出口。需要时只关闭对应连接或重启测试应用，不必清空所有系统网络设置。验证结果应来自新请求，而不是已经加载在页面中的缓存内容。

若目标仍未按预期分流，先确认请求有没有域名信息，再核对规则顺序、策略名称和配置是否被订阅更新覆盖。进程规则还依赖平台能力与进程识别条件，不适合在所有设备间盲目同步。把新增规则保持在较小范围，写下注释说明用途；一段时间后删除已经失去依据的临时规则，比持续堆叠例外更容易维护。

阶段 07 / 扩展接管范围

TUN 与 DNS：先建立接管，再核对解析

明确启用 TUN 的必要性

需要让不读取系统代理的应用进入内核时，再考虑 TUN。它通过虚拟网络接口与路由设置扩大接管范围，但能否覆盖某类流量仍取决于系统权限、路由、协议支持和客户端实现。不要把 TUN 当成“所有网络问题的修复开关”。在系统代理路径已经可用的基础上启用它，才有清晰的对照结果，出现问题时也能迅速退回原来的入口。

启用前记录正在使用的 VPN、容器、虚拟机和企业网络工具。它们可能同时修改路由或 DNS，组合运行时需要明确谁负责默认路由、谁负责内网访问。若启用后出现内网失联或远端连接循环，先关闭 TUN 恢复基线，再检查路由冲突。不要同时修改网卡优先级、防火墙和解析服务，否则很难判断哪一步真正改变了结果。

理解几个常见 TUN 参数

auto-route用于让内核自动配置相关路由，auto-detect-interface用于辅助选择出口接口，dns-hijack用于接管符合条件的 DNS 请求。它们不是脱离平台条件就一定有效的开关。笔记本从有线网络切换到无线网络后，出口识别和路由可能需要重新建立，应按客户端方式重连或重启内核，而不是重复导入订阅。

# 合并到支持这些选项的 mihomo 配置中
# 需要相应系统权限；启用前保留原配置
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

这个片段并非完整订阅，也不适合绕过客户端自身的 TUN 管理机制直接粘贴。配置中的解析服务需要在当前网络可达，内核还必须能够完成该服务域名的初始解析。示例中的假地址池用于内部映射，不是远端代理服务器地址；如果环境与该地址范围发生冲突，应先阅读对应配置说明，再决定调整范围或过滤条件。

区分解析失败与连接失败

DNS 负责把域名与访问目标联系起来，不能仅靠更换一个解析服务器修复节点认证或端口占用。fake-ip 模式为请求分配用于映射的地址，使内核能够保留域名关联；redir-host 通常返回解析得到的实际地址。两者在兼容性与处理路径上不同，没有适用于所有设备的固定答案。某些局域网应用、特殊检测程序或直连服务可能需要例外处理。

nameserver、fallback和相关过滤设置有各自职责，备用解析也不是简单地“主服务器坏了才查询一次”。最终结果选择与过滤条件有关，配置前应理解当前内核的处理逻辑。避免把多个解析地址随意堆在一起，以为数量越多就越稳定。需要逐项理解字段时，阅读mihomo DNS 配置与 fake-ip 说明，再把改动限制在明确的问题范围内。

浏览器或应用自身的加密 DNS 可能绕过普通的五十三端口请求路径，因此 DNS 劫持并不等于控制所有解析。排错时应记录应用是否启用独立解析，并与系统解析路径进行对照。不要为了观察日志就长期关闭所有应用安全功能；应在可控测试中判断差异，确认影响后再选择统一解析或保留应用自身策略。

启用后的验证分三步：先看普通网页是否可用，再看原先不走系统代理的目标应用是否进入连接列表，最后测试局域网与休眠唤醒。移动端还要观察后台策略与电量表现，相关取舍见手机后台运行与 TUN 常驻说明。如果只在 TUN 开启时异常，先退回已验证入口，带着路由和日志证据继续排查。

阶段 08 / 保持可恢复

日常维护：备份、更新和故障定位顺序

给可用状态留一个回退点

把维护对象分成应用、内核、订阅和本地覆写四类。应用升级可能改变界面与系统集成，内核升级可能改变字段支持或默认行为，订阅刷新会替换远端内容，本地覆写则保存个人分流。四类内容最好分别记录，不要在同一时间全部更新。发生异常时，能够指出最后改变的是哪一类，往往比一大段未经整理的日志更有帮助。

备份不只保存订阅地址。还应记录当前策略选择、自定义规则、DNS 例外、混合端口和客户端的系统集成设置。某些导出功能不包含系统服务、登录启动项或本地规则文件，需要根据应用说明补齐。备份中可能含有访问凭据，应放在受控位置，不公开分享，也不要让云端公开链接成为长期配置分发方式。

把更新变成一次可验证的变更

更新前先保存当前配置，并在可以接受短暂断网的时段操作。更新后检查内核启动、配置加载、普通浏览器访问、关键应用和局域网服务，再决定是否清理旧文件。遇到字段废弃或解析行为变化，先阅读变更说明，定位具体配置段。不要为了追求全部启用而同时打开新选项，稳定运行的基线比功能列表更有参考价值。

自动启动也需要验证顺序。应用随登录启动，不代表网络已经准备完成；订阅和规则提供器在网络未连接时刷新失败，也不一定是配置损坏。观察网络恢复后能否重新更新，必要时使用客户端支持的延迟启动或重试选项。笔记本休眠后失败，则应比较出口接口、系统代理和内核状态，避免第一时间删除所有订阅。

按入口、内核、出口、目标排错

第一步确认入口：内核是否运行、端口是否监听、应用是否真正使用该入口。第二步确认配置：当前启用的配置是哪份，是否有解析错误，策略组引用是否有效。第三步确认出口：同一个策略下的远端服务是否可用，是否有认证或协议错误。第四步确认目标：其他网站和应用是否正常，异常是否只限某个域名或特定网络。

日志应围绕一次可重复的失败收集。先记下时间和操作，再发起请求，保留前后相关行。临时提高日志级别有助于观察，但长期详细日志可能增加写入并包含访问域名，排查结束后应恢复适合日常使用的级别。分享前隐藏订阅地址、认证信息和不希望公开的域名，不要只截取最后一行通用报错而丢掉前面的原因。

处理网络切换与退出残留

从家庭网络切换到办公网络时，可能同时改变 DNS、认证门户和访问限制。先完成网络自身要求的登录，必要时暂时关闭代理入口，确认直连路径可用后再恢复配置。企业环境可能明确限制代理或 VPN，应遵守相关管理要求，不通过反复改端口或隐藏进程规避策略。只有当前网络允许的路径可用，后续客户端测试才有意义。

退出客户端后断网，优先检查残留系统代理；重启系统后断网，还要检查自动启动程序和持久化环境变量。出现故障时保留一个明确的恢复动作，例如关闭系统代理或停用 TUN，而不是立即重置所有网络组件。一般性问答可以在FAQ继续查阅；提交问题时附上系统、客户端、入口方式、复现步骤和已做对照，不必公开整份配置。

阶段 09 / 逐项扩展

进阶路线：提供器、自动策略与部署边界

先掌握配置层次，再增加自动化

能稳定使用并不意味着需要继续增加功能。进阶学习应围绕具体问题展开：节点较多时学习代理提供器，规则更新频繁时学习规则提供器，远程设备需要常驻时学习服务管理。每个阶段都保留最小可用配置和单独测试目标，避免从网上复制一份包含大量未知字段的配置后，再依赖随机开关解释它的行为。

代理提供器将节点来源与主配置分开，便于更新和复用，但需要明确来源格式、保存路径、更新周期以及被哪个策略组引用。提供器下载成功不等于节点已经被使用，策略组还要引用相应名称。健康检查也需要有可达的测试目标，其结果只代表某条测试路径；不能把测试成功当成所有业务请求都成功，更不能据此推断实际访问速度。

理解自动选择的测量范围

手动选择组的行为最容易观察；自动测速组、故障转移组和负载均衡组则各有用途。自动选择依赖测试条件，故障转移依赖可用性判定，负载均衡还涉及不同连接如何分配。不要只看名称就把所有组都叠在一起。先确认目标应用是否依赖出口稳定，例如需要保持会话的服务，再决定自动切换是否会引入额外登录或连接中断。

测试间隔、超时与容差共同影响自动策略。间隔过短可能增加网络请求和移动设备耗电，间隔过长又可能延后发现路径变化。某个测试地址在当前网络不可达时，整组结果都会失真。先用手动选择确认基础连接，再启用自动检测；出现异常时比较检测目标和实际业务目标，而不是把所有失败都解释为节点质量问题。

把命令行内核当成独立部署任务

服务器或路由器部署需要额外处理运行账号、服务启动、配置权限、日志轮转与网络转发。桌面系统代理的经验不能直接替代这些工作。直接运行内核只会提供配置中启用的功能，不会自动把整个局域网都变成代理网络。旁路或网关方案还涉及默认网关、转发、防火墙与回程路由，必须按设备拓扑设计，不宜在生产网络上边试边改。

# 在已经安装 mihomo 的环境中检查配置语法
mihomo -t -f ./config.yaml

# 指定工作目录运行；该目录需要按配置准备相关资源
mihomo -d ./profile

语法测试通过仅说明内核能够接受相应配置，不证明远端服务、DNS 和规则下载在运行环境中一定可用。检查时尽量使用与正式运行一致的内核及工作目录，并注意相对路径引用。服务方式启动时，环境变量、权限和当前目录可能与交互式终端不同；“手动运行成功，服务启动失败”应优先比较这些环境差异。

控制管理接口与局域网暴露

管理接口可以用于面板和自动化控制，但它具有改变代理状态的能力。只在确有需要时启用，优先限制到本地回环地址，并按内核支持设置认证。混合代理端口、管理接口和 DNS 监听口是不同入口，不能因为其中一个需要局域网访问，就把其他入口也一起绑定到所有接口。对外开放之前还需要配合主机防火墙限制来源。

让其他设备使用代理时，要逐项确认监听地址、局域网访问开关、认证和防火墙规则。不能把共享网络上的每台设备都视为可信，也不要直接将端口映射到公网。路由器上的持久化部署还要考虑设备重启、存储空间及规则资源更新失败后的行为。先在隔离测试环境验证，再考虑承担长期网络入口，避免一次配置错误影响整网访问。

学习顺序可以保持为：先读懂当前配置，再独立修改规则，接着理解 DNS 和 TUN，最后处理提供器与服务部署。每一步都回答三个问题：解决什么问题、如何验证生效、怎样退回原状。需要重新核对基础流程时回到入门指南，需要更换工具时查看客户端下载页。能够解释一条连接的入口、命中规则和最终出口，就是从能用走向可维护的关键。