Clash 客户端与订阅配置完整手册

一、核心概念：客户端、内核与配置

请求经过哪些环节

Clash 生态并不是一款界面完全统一的程序。客户端负责提供配置导入、模式选择、系统设置和日志查看入口，内核负责接收连接、解析规则并建立出站连接。两者通常随安装包一起分发，但更新节奏不一定相同。判断功能是否支持时，既要看界面有没有开关，也要看实际运行的内核能否识别对应字段，不能仅凭客户端名称作结论。

一条请求可以按应用、接入方式、内核、规则、出站这条路径理解。应用可能主动使用本地代理端口，也可能通过系统代理设置转交请求；启用 TUN 时，还可能由虚拟网络接口接管流量。内核收到请求后，依据模式和规则决定直连、拒绝或交给某个策略组。理解这条链路，才能区分网页失败究竟发生在应用接入、域名解析还是远端连接阶段。

订阅不等于全部配置

订阅 URL 是获取远程资源的地址，不是连接开关。返回内容可能是一份完整配置，也可能只是供代理提供者使用的资源文件。完整配置通常同时涉及代理、策略组、规则和 DNS，而资源文件只承担其中一部分。把节点列表直接当作完整配置导入，可能出现格式错误，也可能只有资源却没有可用策略组。因此，导入前需要先确认提供方标注的格式与目标客户端要求。

配置文件常用 YAML 表达层级，缩进本身具有含义。根级字段与子级字段不能随意交换，列表项通常以短横线起始，缩进应使用空格而不是制表符。同名字段重复出现时，不同解析器的处理可能不同，应主动合并而不是依赖后一个覆盖前一个。即使文本能够解析，也不代表策略组引用、资源路径与运行权限都正确，语法通过只是第一层检查。

配置来源与运行状态

客户端界面中的原始订阅、覆写文件和最终生效配置应分开看待。远程订阅可能在更新时重新下载，覆写机制则用来保存本地端口、规则或 DNS 调整，最终配置是客户端合并后交给内核的结果。遇到设置恢复、字段未生效或规则顺序变化，应先查看最终配置，而不是反复编辑下载后的临时文件。不同客户端合并数组的方式不同，不能假定所有覆写都会追加。

还要区分“配置已保存”“内核已加载”和“目标应用已使用代理”三个状态。编辑器保存成功，不代表内核接受了新内容；内核加载成功，也不代表浏览器或其他应用已接入。可靠的验证需要同时查看加载结果和连接记录，再用目标应用发起新的请求。旧连接可能继续使用原有出站，观察旧标签页或现存会话容易把缓存行为误认为设置没有生效。

二、客户端选型：平台、内核与维护方式

先确定系统与使用方式

客户端选型先看操作系统，再看处理器架构与使用场景。日常桌面和手机使用优先选择图形界面，服务器与路由器才考虑直接运行内核。本站下载页在支持的平台优先列出 Clash Plus；需要桌面端配置管理与 mihomo 相关能力时，也可比较 Clash Verge Rev 和 FlClash。首推顺序不是所有功能完全相同的承诺，订阅格式、接入方式和平台权限仍需逐项核对。

Windows 下载前可在系统设置中查看系统类型，重点区分 x64 与 ARM64。macOS 需要确认 Intel 或 Apple Silicon，不能只按操作系统名称选择文件。Android 可优先选择与设备架构匹配的安装包，不确定时再查看下载页提供的通用包选项。Linux 除架构外，还涉及发行版的软件包格式与桌面环境，能安装并不必然代表托盘、服务管理和权限提示行为一致。

功能兼容不能只看名称

Clash、Clash Meta 与 mihomo 存在演进关系，但不能把它们视作永远支持相同字段的别名。协议、规则类型和 DNS 选项会随内核实现变化，网上配置也可能针对不同分支。迁移客户端时，先记录当前使用的核心功能，再在目标客户端逐项确认，尤其注意代理提供者、规则提供者、脚本相关功能以及平台专用接入方式，不要一次搬入所有历史配置。

手机端还要特别核对格式。Surfboard 的配置体系与 Clash YAML 并不等同，不能因为下载页同属代理客户端，就把同一个文件直接导入所有应用。iOS 可通过下载页前往 Clash Plus 商店详情，并在官网 clashplus.io 核对产品说明。应用支持什么导入入口，应以其实际界面为准，桌面端字段也不能机械映射到移动端设置。

归档客户端与迁移成本

Clash for Windows 与 ClashX Meta 在下载页作为已停止维护的归档选项保留，更适合旧环境兼容与历史配置查阅，不宜把旧教程截图当作新安装的唯一依据。选择仍在维护的客户端时，也应了解配置存储位置、日志导出方式和卸载后的系统设置处理。能够清楚备份与恢复，比界面按钮数量更重要，尤其是需要跨设备迁移或长期维护的场景。

不要同时安装多个客户端后直接叠加运行。不同程序可能争用同一端口、系统代理或 VPN 通道，使结果难以解释。比较客户端应采用同一配置、同一网络、同一应用的顺序测试，每次先退出前一个程序。把成功条件记录下来，再决定保留哪一个。安装包与平台入口统一见客户端下载页；内核关系可另读Clash、Clash Meta 与 mihomo 差异说明。

三、安装与检查：权限、端口与首次启动

安装前保留可回退状态

开始安装前，先退出正在运行的其他代理客户端，并记录系统原有代理设置。如果设备处于企业网络、校园网络或使用专用 VPN，应先确认管理要求，避免把正常业务连接中断。已使用过旧客户端的设备，还要检查后台进程与自动启动项；关闭窗口不一定结束内核进程。首次安装尽量使用当前用户可管理的常规路径，不要先叠加复杂目录权限或同步盘配置。

Windows 按安装向导完成后，首次启动先保持 TUN 关闭，确认主界面、配置页和日志页能够正常打开。遇到系统保护提示，应核对下载来源与发布说明，而不是直接关闭整套安全功能。安装目录需要写入权限与运行数据目录需要写入权限是两回事；若客户端可以启动但无法保存配置，应查看数据目录权限、磁盘空间以及是否有同步或安全软件占用文件。

macOS 按当前软件包的安装方式完成部署，再根据系统提示授予必要权限。应用移动位置后，旧的启动项或后台服务可能仍指向先前路径，因此建议先确定最终位置再启用自动启动。Linux 使用适合发行版的软件包管理方式安装，出现依赖错误时应读取包管理器输出，区分缺少依赖、架构不匹配和图形环境问题，不要把所有启动失败都归因于订阅内容。

移动端权限与后台限制

Android 导入配置前后可能需要授予 VPN 连接权限，这是系统建立网络接管通道的授权，不等同于订阅认证。首次授权后，仍需在客户端中启动连接。若锁屏后连接容易断开，应检查电池优化、后台活动和厂商的自启动设置，但只授予当前功能真正需要的权限。iOS 同样需要按系统提示允许网络配置，并确认其他 VPN 应用没有同时占用连接通道。

端口冲突与内核启动

桌面端常见本地监听包含 HTTP、SOCKS 或混合端口。混合端口可以同时接受相应的 HTTP 代理与 SOCKS 连接，但并非任何程序都会自动使用它。示例中的 7890 只是可选端口，不是所有客户端的固定值。如果日志出现地址已被占用，应先找出占用进程，再决定结束旧程序或更换端口；不要只改应用代理地址而忘记同步修改客户端监听设置。

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

# macOS：查看 TCP 监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 监听与进程
ss -lntp

检查命令的空结果只说明没有找到相应监听，不能证明客户端一定损坏。端口可能不同，内核可能尚未加载配置，某些进程信息也可能需要更高权限才能显示。先在客户端界面确认实际端口与运行状态，再对照日志定位。若进程反复退出，应优先查看配置解析错误、资源路径与权限提示，而不是连续重装；重装可能保留原数据目录，因此未必改变故障条件。

四、订阅与更新：导入、资源间隔与覆写

按内容选择导入入口

在客户端的配置或订阅页面选择新增、导入或同类入口，将完整订阅 URL 粘贴到对应地址栏。复制时注意链接是否被聊天工具折行，开头与结尾是否混入空格，认证参数是否完整。导入成功后，还需要将该配置设为当前使用。配置列表出现新条目只代表记录已建立，是否完成下载、解析和内核加载，应继续查看状态提示与日志，不要只凭列表名称判断。

本地文件导入通常复制一份 YAML 到客户端管理目录，也可能保留对原文件的引用，具体行为取决于客户端。修改原下载文件后，客户端未必自动同步；相反，某些编辑入口会直接修改当前受管理文件。导入后应明确编辑的是哪一份内容，并保留原始文件备份。若提供方交付的是编码节点列表或其他配置格式，需要选择兼容入口或可信转换方式，不能仅修改文件扩展名。

完整配置更新与资源更新

完整订阅更新会替换远程配置内容，代理提供者更新则通常只刷新该提供者的资源。规则提供者又有独立的下载周期。这三个动作可能由不同入口控制，更新其中一个并不保证另两个已经刷新。客户端界面的订阅间隔可能以分钟表示，而 mihomo 的提供者 interval 字段通常以秒表示，不能把界面输入值原样搬进 YAML，也不能根据一个字段推断整份配置更新频率。

# 本地代理提供者片段：需合并到现有配置
# 文件内容必须符合当前内核的代理提供者格式
proxy-providers:
  local-resources:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 手动选择
    type: select
    use:
      - local-resources

上面的片段展示提供者与策略组之间的引用关系，不会自动创建资源文件。使用前需要在内核实际工作目录下准备文件，并确认客户端允许访问该路径。HTTP 类型提供者还需要真实资源地址、保存路径和更新间隔；地址必须由可信来源提供，不能把管理网页当作资源接口。订阅返回 HTML、登录页面或错误提示时，即使请求成功返回，也无法作为 YAML 资源加载。

把本地修改放在持久层

自定义端口、DNS 或规则应尽量通过客户端支持的覆写、合并或扩展配置机制保存。直接修改远程文件的风险是下次更新被替换，手动复制整份订阅又会失去远程资源维护能力。设置覆写后，要查看最终生效配置，确认字段层级和数组顺序符合预期。尤其是规则列表，有的机制替换全部规则，有的支持前置与后置插入，两者对兜底匹配的影响完全不同。

更新失败时，先记录失败对象和错误类型。认证拒绝应检查链接有效性与账户状态；解析错误应查看返回内容和格式；连接超时应区分本地网络、域名解析及下载路径。某些订阅下载依赖当前代理，当前代理又依赖这份订阅，会形成启动依赖问题。可在受信任网络下恢复已知可用配置后再更新，不要把敏感 URL 粘贴到公共转换服务或公开排错页面。

五、代理模式：接入开关与出站决策

系统代理不是规则模式

系统代理、TUN 与规则模式属于不同层次。系统代理决定支持该系统设置的应用如何把连接交给本地端口；TUN 提供另一种流量接入方式；规则、全局和直连模式决定内核收到连接后怎样选择出站。因此，切到全局模式并不会自动接管没有使用代理的应用，打开系统代理也不代表所有请求都会走远端出站。排错时必须先判断连接有没有进入内核。

日常使用通常从规则模式开始，让域名、地址或其他条件决定去向。全局模式适合临时验证某个出站是否可用，但其策略组仍需要正确选择目标。直连模式可帮助判断远端路径是否引入问题，不过应用如果根本没有接入内核，这次对照就没有诊断价值。比较模式时应使用同一个应用、同一个目标和新的连接，避免把网络环境变化当作模式差异。

建立一条可重复的测试请求

验证系统代理时，先检查客户端监听地址与端口，再查看应用是否有独立代理设置。浏览器扩展、终端环境变量和开发工具内置配置都可能覆盖系统默认行为。终端命令通常不会因为桌面系统代理已开启就自动使用相同路径，适合通过显式参数测试。下面命令将请求明确发送到本机混合端口，端口不同需要同步修改；目标站点仅用于建立简单的 HTTPS 请求。

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

收到响应说明这次请求通过指定端口完成了相应连接，不代表它一定使用了远端代理。最终出站仍取决于当前模式与规则，应在客户端连接页核对。如果命令连接本地端口即失败，先查监听和进程；如果出现证书错误，应核对系统时间、证书环境与目标站点，不要用跳过证书验证作为日常解决方案。具体状态码也需要结合响应来源解释，不能一概当作节点故障。

模式变化与连接生命周期

切换模式或策略组主要影响后续建立的连接，已有长连接可能继续沿用原路径。浏览器连接池、即时通信会话和下载任务尤其容易保留旧连接。需要严格验证时，先在应用中重新发起请求，必要时关闭目标连接或重启该应用，而不是立刻清空整份配置。客户端如果支持主动断开连接，应确认操作范围，避免中断仍在传输的重要任务。

退出客户端后网页无法访问，常见原因是系统代理仍指向已经停止监听的本地端口。先到系统网络设置关闭残留代理，再检查是否有其他程序重新写入设置。若使用终端环境变量，还需要清理对应会话中的代理变量。能够恢复直连后，再重新启动客户端定位退出流程；反复切换规则或全局模式，无法修复内核已经退出后的本地端口不可达问题。

六、规则分流：匹配顺序与资源组织

从最小规则集开始

规则模式通常按照列表从前到后匹配，先命中的规则决定请求去向。因此，规则内容正确但位置不对，仍可能永远没有机会执行。具体域名或需要优先处理的条件应放在更宽泛的条件之前，兜底 MATCH 应位于末尾。新增规则前，先在连接详情中查看当前命中项，再决定插入位置；不清楚原有顺序就直接追加，往往只增加文件长度而不改变实际结果。

域名规则与地址规则解决的问题不同。DOMAIN 匹配指定域名，DOMAIN-SUFFIX 可覆盖域名本身及其子域，IP-CIDR 则按地址网段判断。应用若直接连接 IP，或域名信息未能传递到内核，预期的域名规则可能无法命中。此时应检查连接记录中的目标信息，而不是不断给同一个域名添加重复规则。规则需要的匹配信息必须真实存在。

# 最小规则片段，不包含远程代理资源
mode: rule
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

这段配置用于理解顺序与语法，所有未匹配请求最终直连，并不是完整代理方案。要把某类请求交给自定义策略组，必须先定义该组，再把规则目标改为完全一致的组名。名称中的空格和大小写都应按配置实际内容处理。no-resolve 表示不要仅为该地址规则主动触发域名解析，不意味着整个请求永远不会发生 DNS 查询，也不是禁止所有地址匹配。

策略组与规则集分开维护

策略组负责选择出站，规则负责选择策略组。手动选择组适合需要明确控制当前出口的场景，自动测试或故障转移组则依赖其测试目标、间隔和判定逻辑。某个测试目标可访问，并不保证目标业务也能正常工作；不同应用可能受协议、区域、认证或远端限制影响。不要只依据一项测试结果替代真实业务验证，也不要把测试间隔设得过密来追求表面上的即时变化。

规则较多时可通过规则提供者拆分维护，但需要匹配资源行为类型。域名列表、地址列表和包含完整规则条件的资源文件格式不同，不能只替换下载地址。定义提供者后，还要用对应规则引用它，否则文件下载成功也不会参与分流。路径、名称和行为类型应一起核对；若资源解析失败，保留旧资源还是加载失败取决于客户端与内核状态，应通过日志确认实际结果。

分流问题按命中结果定位

排查时先记录目标域名、实际目标地址、命中规则和最终策略组，再考虑修改。一个网页通常会同时请求主站、静态资源、认证接口等多个域名，只修正主域名不一定解决完整页面加载。可按请求逐项确认失败对象，而不是把整个服务都归到同一后缀规则。对于局域网设备，还应确认目标实际网段，示例中的私网范围并不覆盖所有家庭、企业或虚拟网络地址。

规则更新也需要考虑供应链边界。选择可理解来源的规则资源，了解它覆盖哪些类别，以及更新是否会改变流量去向。合并多个大型规则集时，重复与重叠条件可能让维护变得困难，规则数量增加并不等于分流更准确。建议先保留少量明确需求，再按连接记录补充例外；每次增加规则，都应写清适用目的，并在更新后检查关键应用是否仍按预期工作。

七、TUN 与 DNS：网络接管和解析边界

先确认是否确实需要 TUN

TUN 通过虚拟网络接口接入流量，适合不遵循系统代理设置的应用，但它不是网络故障的通用修复开关。启用后涉及路由、权限、DNS 和其他网络软件的协同，复杂度高于单纯本地端口代理。建议先让普通代理链路正常工作，再启用 TUN 并比较接入范围。移动端的系统 VPN 接口与桌面端虚拟网卡在权限和实现上不同，不能直接照搬同一套界面操作。

桌面客户端可能通过服务组件获得创建接口与修改路由的权限。启用前要确认服务状态及系统提示，而不是只看开关是否变色。若同时运行企业 VPN、容器网络或其他隧道，路由优先级和 DNS 接管可能发生冲突。测试时先保留一种接管方式，记录原路由行为；远程操作设备尤其需要准备恢复通道，避免修改路由后失去管理连接。

# mihomo TUN 片段：合并前核对客户端服务与平台支持
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

该片段不是跨平台通用开关。auto-route 用于自动配置相关路由，auto-detect-interface 用于辅助确定出站接口，具体结果仍受系统和网络环境影响。客户端若已通过界面管理这些字段，应选择一种持久配置入口，避免覆写互相覆盖。切换 Wi-Fi、有线或热点后，如果连接异常，应检查接口检测结果与路由是否更新，而不是直接更换订阅。

DNS 与 Fake-IP 的配置关系

DNS 把域名转换为地址，也为域名分流与出站选择提供上下文。系统 DNS、浏览器的加密 DNS、客户端内置 DNS 和远端解析可能同时存在，必须先判断查询实际走哪一条路径。TUN 中接管传统 DNS 端口，不代表所有应用内的加密解析也被接管。仅凭某个检测页面显示了一个解析器，就断定全部请求泄漏或全部解析正确，都缺少足够证据。

Fake-IP 模式会为域名分配虚拟地址，内核再借助映射还原域名并处理连接。这些地址不是网站真实服务器地址，因此看到虚拟地址本身不代表解析错误。部分局域网发现、设备认证或特殊协议可能不适合这种行为，可以针对确有兼容问题的域名设置过滤例外，而不是立即放弃整个模式。例外越宽，行为越难解释，应从单个目标开始验证。

DNS 上游、代理服务器域名解析和直连请求解析之间还存在启动依赖。若解析上游必须经过代理，而代理服务器域名又依赖同一上游，可能形成循环。配置时应明确哪些解析用于建立代理连接，哪些用于普通业务，并按当前内核支持的字段分工。不要复制来源不明的上游列表堆叠在一起；服务器数量更多并不保证结果一致，反而可能增加延迟与排错分支。

验证接管范围与退出恢复

启用 TUN 后，先验证之前未进入内核的目标应用是否出现连接记录，再观察规则和 DNS 行为。若局域网访问异常，检查网段路由、地址冲突与域名例外；若只有切换网络后异常，检查出站接口与 DNS 缓存。停用 TUN 后，应确认虚拟接口、自动路由和系统 DNS 恢复。恢复前不要继续叠加新规则，否则可能把接管问题误诊为分流问题。

八、日常维护：更新、备份与分层排错

把更新拆成不同对象

日常维护至少要区分客户端、内核、完整订阅、代理提供者和规则资源。客户端更新主要涉及界面、集成与平台适配，内核更新涉及协议和网络行为，资源更新则改变配置内容。某个更新入口显示完成，不能代表所有对象都处于相同状态。建议在一次维护中先更新资源并验证，再安排程序更新，避免同时变化后无法判断是哪一层引入兼容问题。

更新程序前保存当前配置、覆写内容和关键设置，记录当前接入方式与端口。备份应包含恢复所需信息，但不应进入公开仓库或聊天群。客户端导出功能可能不包含系统服务状态、外部文件和环境变量，恢复前要确认范围。对于文件型提供者，还应备份相对路径对应的文件；只保存主配置而遗漏资源目录，迁移后可能出现语法正常却找不到资源的问题。

按故障发生位置缩小范围

网页打不开时，先在客户端退出并恢复系统设置后验证基础网络。如果基础网络也不可用，应先处理 Wi-Fi、网关、认证页面或运营网络问题。基础网络正常后，再检查本地端口是否监听、应用连接是否进入内核、规则是否命中、出站是否成功。按这条顺序推进，可以把“没有接入”和“接入后失败”分开，避免无目的地切换全部设置。

订阅更新失败与业务连接失败可能互相独立。订阅接口可能认证过期，但已有配置仍能建立连接；业务出站也可能失效，而订阅接口仍然能下载。记录时应明确失败对象、发生动作和错误类别。日志中的超时、连接拒绝、解析失败与认证失败含义不同，不能统一解释为网络慢。日志过长时先缩小到一次可重复操作，再提取对应时段的信息。

速度、延迟与应用体验

连接测试中的延迟只反映特定目标与测试方法下的一次结果，不等于实际下载速度、稳定性或所有网站的体验。排查速度慢，应固定网络与测试对象，分别比较直连、不同出站以及目标应用的实际传输。无线信号、并发下载、远端限制和路径拥塞都可能成为瓶颈。持续重复测速还可能消耗资源，观察正常业务通常比追求单个测试数字更有意义。

若只有一个应用异常，优先检查它自己的代理设置、域名解析和连接缓存。若所有应用同时异常，再考虑内核状态、接入通道或上游网络。若只有规则模式异常而全局模式可用，重点检查命中规则、策略组与相关 DNS 路径。每次对照都应保持其他条件不变，并记录恢复操作；“重启后好了”可以临时恢复，但还需要保留重启前的错误证据才能继续定位。

恢复流程与日常记录

建议保留一份已验证可用的配置基线，并记录本地改动的目的、位置与撤销方式。故障发生后先导出必要日志，再回退最近一次改动；不要先删除所有数据目录。确认客户端能够退出、系统代理能够关闭、TUN 路由能够恢复后，再恢复基线配置。若问题只在新配置出现，可用逐项合并的方法找到触发字段，而不是长期依赖整份旧订阅停止更新。

九、进阶路线：配置分层与内核运维

从能连接到能解释结果

进阶不必从增加更多参数开始，而应先做到能解释一条连接。选一个熟悉的应用，记录它怎样接入、访问哪些域名、命中哪条规则、选择哪个策略组，以及是否使用预期的 DNS 路径。能够重复验证这些环节后，再引入规则提供者、复杂策略组或独立内核。功能越多，依赖越多；缺少观察手段时，增加功能只会让错误隐藏得更深。

配置可按资源来源、公共策略和本机差异分层。远程资源负责需要持续更新的内容，公共策略表达多个设备一致的分流需求，本机层处理端口、路径、接口和权限。这样迁移时不必复制整份运行文件，也能减少订阅更新覆盖本地设置的风险。具体实现应服从客户端提供的合并机制，不能把通用分层思路误认为所有客户端都有相同的覆写语法。

直接运行内核前的准备

服务器或路由器用户可以直接运行 mihomo，但需要自行管理配置目录、进程、日志、权限和启动顺序。图形客户端原先代办的功能不会自动出现，尤其是系统代理、服务守护与资源下载状态展示。先在前台验证最小配置，再接入系统服务管理；启动失败时应保留标准输出与错误输出，避免后台静默退出后只看到端口不可达。

# 先确认当前内核支持的参数
mihomo -h

# 在当前目录检查配置；通过后再以前台方式启动
mihomo -t -d . -f config.yaml
mihomo -d . -f config.yaml

命令假设可执行文件已位于系统搜索路径，且当前目录包含配置与相关资源。-d 指定的工作目录影响相对路径解析，服务运行用户与交互终端用户不同，也可能导致读取失败。配置检查能发现部分语法与引用问题，但不能证明远程资源可达、路由权限充分或真实业务连接成功。服务化前仍需完成一次完整请求验证，并明确停止与回退步骤。

局域网、控制接口与路由器部署

需要让其他设备使用本机代理时，要同时考虑监听地址、允许局域网连接设置和防火墙范围。只开放端口并不等于配置完成，也不应将代理端口直接暴露到公网。优先限定可信网段，必要时配置认证，并核对客户端实际支持的方式。外部控制接口应单独保护，避免把配置管理能力与普通代理入口混在一起；控制面能访问到哪些功能，需要按内核说明理解。

路由器部署还涉及主路由或旁路由角色、客户端网关、DNS 分配与返回路径。旁路由上运行内核，不代表局域网设备已经把流量交给它。先确定设备从哪里获得网关与 DNS，再检查透明接管链路，最后引入分流。家庭网络已有多个 DHCP 服务时，应先消除地址分配冲突。部署方式概览可阅读OpenWrt 与旁路由运行 mihomo，不要直接把桌面端配置当成路由器完整方案。

持续维护的验收标准

自动化更新应以配置检查、成功加载和失败回退为闭环，而不是定时下载后直接覆盖。资源下载失败时保留已知可用文件，配置检查失败时停止发布，重载后再验证关键请求。对规则的维护应保留变更记录，但带凭据的资源不要提交到公开仓库。需要版本管理时，可只记录经过脱敏的规则与覆写逻辑，敏感输入通过受保护的本地配置提供。