Clash 全平台安装配置指南

通用准备：区分客户端、内核与订阅

先确定安装对象与配置来源

图形客户端负责导入订阅、选择策略组和修改系统设置，内核负责监听端口、处理协议与匹配规则，两者不是同一层。mihomo 是内核项目，Clash Verge Rev、FlClash 等提供图形界面；同样标有 Clash 的应用，也可能使用不同配置实现。本站支持的平台优先从 Clash Plus 开始选择，再按功能需求查阅其他客户端。不要仅凭软件名称判断某个 YAML 字段一定可用，字段是否生效还取决于实际内核及客户端的配置生成方式。

准备一条由服务提供方给出的订阅地址，或一份已知可用的配置文件。客户端本身通常不附带可连接的服务。订阅可能返回完整 Clash 配置，也可能只是其他格式的服务器列表，后者不能直接当作完整 YAML 使用。先查看提供方标注的兼容格式；需要 Clash 订阅转换时，优先使用可信的本地方案。订阅链接中的查询参数可能具有访问权限，不应提交到公开讨论区，也不要为了排查而上传整份原始配置。

建立可回退的初始状态

安装前记录已有 VPN、系统代理和手动 DNS 设置，暂时退出其他会接管流量的软件。多个工具同时修改默认路由或代理端口时，日志中的报错往往只是结果，不是起因。首次连接先用单一客户端、单一配置和单一接管方式验证；成功后再启用开机启动、自动更新、局域网共享等附加功能。已有配置应导出一份备份，保留原文件名称与用途，避免把测试覆盖当成长期配置保存。

核对系统时间、磁盘空间和设备架构。时间明显错误会影响 HTTPS 证书验证，安装包架构错误则可能导致无法运行或额外的兼容层开销。订阅更新失败也不一定是代理故障：网络登录门户尚未认证、地址失效、账户到期都需要分别处理。先用当前可用网络完成系统登录和必要授权，再打开客户端。排障时记录操作顺序与错误文本，比连续点击连接按钮更有价值。

理解最小配置的边界

下面只展示 mihomo 的本地监听片段，不包含节点、策略组或规则，不能替代订阅。mixed-port 同时接收 HTTP 与 SOCKS 代理连接；绑定回环地址并关闭局域网访问，适合单机验证。端口值不是必须为 7890，但客户端、系统代理与测试命令必须保持一致。首次运行不要随意开放外部控制接口，也不要把监听范围改成所有网卡来解决本机连接问题，那会扩大暴露范围，却未必修复故障。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

完整配置中的规则通常按从上到下的顺序匹配，命中后停止。策略名必须对应已有的策略组或节点，不能把示例中的名称机械复制进去。导入后先确认配置被选为当前配置，再检查内核是否启动；“下载成功”只说明文件已取得，不代表配置语法正确，更不代表流量已经经过代理。这几个状态分开验证，后续排查会少绕很多弯。

Windows：安装、系统代理与服务模式

下载正确架构并完成首次运行

从Windows 安装包列表选择客户端，首推 Clash Plus；其他选择依次有 Clash Verge Rev、FlClash、Clash Nyanpasu，以及已停止维护的 Clash for Windows。归档客户端仅适合确有兼容需求的旧环境，新配置优先使用仍在维护的客户端。进入“设置 → 系统 → 系统信息”查看系统类型，再对照下载页提供的架构选择。ARM 设备不要仅凭系统名称选择普通桌面安装包，先确认该客户端的实际支持范围。

安装时使用稳定的本地目录，不要把需要长期运行的程序放在下载临时目录、压缩包内或会被自动清理的位置。首次启动可能弹出防火墙或服务安装授权，应先核对程序来源和用途。仅本机使用时不需要主动开放局域网入站访问。若系统阻止运行，先检查文件来源、系统要求及安全软件提示，不能把关闭全部防护当作通用安装步骤。

导入订阅后检查配置与监听

在客户端的订阅或配置页面新建远程配置，粘贴完整地址并执行更新。出现多个配置时，明确选中刚导入的项目，确认其更新时间和节点列表。若页面只有配置名称而节点为空，打开更新日志，区分请求失败、返回登录网页与配置解析失败。不要先改 DNS；服务器返回的内容不对，解析器再努力也只能读到一页 HTML。敏感链接应只在客户端内部输入，排查截图不要包含完整地址。

选用规则模式，并在实际使用的策略组中选择一个可用节点。随后检查客户端设置中的本地代理端口，再开启系统代理。在 Windows 的代理设置中查看手动代理是否指向回环地址与同一端口。某些应用使用独立网络栈，不读取系统代理，因此浏览器成功而终端失败并不矛盾。先在 PowerShell 中执行显式代理测试，将“客户端通不通”与“系统有没有接管”拆开确认。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/
Get-NetTCPConnection -State Listen -LocalPort 7890

第一条仅检查端口能否建立 TCP 连接，第二条才会经过代理请求目标站点。使用 curl.exe 可避免部分 PowerShell 环境中同名别名造成参数差异。第三条用于确认监听状态，若提示权限不足，再在受控情况下提升终端权限查询。端口已被其他程序占用时，关闭重复客户端或修改当前客户端端口，并同步修改系统设置；只改一边会制造一个新的故障。

TUN 开启顺序与 Windows 特有问题

只有在系统代理验证成功后，再尝试 TUN。部分客户端需要安装服务组件并授予管理员权限，以创建虚拟接口和写入路由；服务模式不等于每次都用管理员身份运行整个界面。先按客户端说明安装或启动服务，观察日志是否完成虚拟设备初始化，再打开 TUN。若立即断网，先关闭 TUN恢复原网络，检查安全软件、其他 VPN 和虚拟网卡冲突，不要同时切换网络栈、DNS 和 MTU。

WSL、Docker 和虚拟机属于额外网络环境，Windows 上的 127.0.0.1 不应被视为它们通用的宿主机地址；实际访问方式取决于网络模式和系统设置。确需让其他环境连接本机代理时，再配置可达地址、访问控制和防火墙范围。不要为了让一个容器联网直接把代理对整个局域网开放。游戏与语音应用涉及 UDP 时，也要确认上游协议支持，开启 TUN 不会自动补足节点能力。

退出客户端前先关闭系统代理和 TUN。若程序异常退出后浏览器全部报代理错误，回到 Windows 代理设置清除残留手动代理，再确认基础网络恢复。开机自启与自动连接应在整条链路验证后启用，并实际重启一次检查服务是否先于界面就绪。睡眠唤醒或切换 Wi-Fi 后异常时，先重新连接当前配置；仍无效再核对路由与 DNS，避免直接重装软件导致证据全部消失。

macOS：芯片架构、网络授权与代理恢复

选择安装包与处理系统授权

打开“关于本机”查看芯片或处理器信息，再进入macOS 下载区。Clash Plus 为首推选择，也可按需求选 Clash Verge Rev 或 FlClash；ClashX Meta 已停止维护，应作为兼容性归档看待。Apple Silicon 与 Intel 安装包需要对应选择，不要因为应用能通过兼容层启动就忽略原生架构。安装前同时核对客户端支持的系统要求，某个安装包能下载并不表示旧系统能够运行。

使用磁盘映像分发的应用，应先拖入“应用程序”目录，再退出映像并从正式目录启动，避免后续更新、权限关联和登录项指向临时挂载路径。首次打开时按系统提示核实开发者与来源。若被系统安全机制拦截，应阅读“隐私与安全性”中的具体原因并对照项目说明处理，不要执行来历不明的命令批量移除文件属性，更不要关闭整个系统的应用安全检查。

导入配置并核对当前网络服务

在客户端添加远程订阅，更新后选择为活动配置，再检查策略组是否包含预期节点。若使用本地 YAML，确认文件的读取位置与更新机制：部分客户端导入后保存副本，继续编辑原文件不会改变运行配置。需要长期自定义规则时，优先使用客户端支持的覆写或合并功能，并确认最终生成的配置。直接修改订阅缓存文件通常会在下一次更新时丢失，保存成功不等于持久化成功。

开启系统代理后，到系统设置的网络详情中核对 HTTP、HTTPS 或 SOCKS 代理项。macOS 的代理设置通常关联具体网络服务，Wi-Fi 与有线网卡切换后应重新确认，不能只看菜单栏图标。终端可用下列命令观察当前状态，再做一次显式代理请求。命令仅用于诊断，不会直接修改系统代理；如果实际端口不是 7890，应同步替换测试端口。

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 https://example.com/

scutil --proxy 展示系统代理相关状态，但不能证明每个应用都遵循这些设置。若浏览器可用而命令行工具不通，检查工具是否需要显式代理参数或环境变量；若只有某个浏览器行为不同，查看其扩展、独立代理和安全 DNS 设置。多层设置同时存在时，请求可能绕开客户端，或经过两次代理。先把测试缩减到一个浏览器窗口和一个终端命令，再逐步恢复扩展。

TUN、辅助服务与网络切换

开启 TUN 可能涉及辅助服务、管理员授权或网络扩展，具体机制以所用客户端为准。系统弹窗出现时确认应用名称，完成授权后返回客户端查看日志，不要把已经点过允许当成服务运行成功的证据。若服务安装路径来自已删除的旧应用，更新后可能需要按客户端提供的操作重新安装辅助组件。权限报错与节点连接报错属于不同阶段，先解决设备创建失败，再讨论规则与 DNS。

macOS 的按域解析与网络服务顺序会影响 DNS 行为。公司内网域名可能依赖指定接口的解析器，启用全局接管后出现内部站点失效时，应先确认该域名原本使用的 DNS，再配置定向解析或绕过。不要把公共解析器覆盖到所有场景。睡眠唤醒、切换热点或连接扩展坞后，接口和路由可能改变；重新连接前先看当前网络服务，确认并非基础网络认证尚未完成。

确认基础连接恢复后，再决定是否开启登录时启动。菜单栏常驻、登录项和后台服务是三个不同状态：界面出现不保证内核已加载配置，后台服务存在也不保证订阅更新成功。一次可靠的验收应包含重启后的配置选择、代理监听与目标请求检查。对长期不再使用的客户端，先退出并停用其网络接管，再按该应用的卸载说明移除辅助服务，避免多个旧服务竞争同一端口。

Android：VPN 授权、后台运行与分应用

安装包架构与订阅导入

在Android 安装包列表中优先选择 Clash Plus，也可选 Clash Meta for Android、FlClash 或 Surfboard。不同应用的导入格式和功能范围并不完全一致，尤其不要假定 Surfboard 能直接使用全部 mihomo YAML 字段。先确认服务提供方支持的客户端和格式，再决定安装哪一个。常见新设备使用 ARM64，但仍应根据设备实际架构选择；无法确认时，只有下载页确实提供通用包的客户端才可选择通用包。

通过浏览器或文件管理器安装时，Android 可能要求允许该来源安装应用。仅对实际使用的来源按需授权，完成后可回到系统设置收回权限。若安装提示签名不一致，先检查是否已有不同来源的同名应用，不要直接卸载唯一保存订阅的旧实例。先备份能够导出的配置和应用设置，再决定迁移；客户端间的备份格式通常不能互相恢复，订阅地址与自定义规则也应分开保存。

在应用内添加订阅、执行更新并将其设为当前配置。若订阅一直转圈，先暂停连接，使用可访问该订阅的基础网络更新，查看应用是否显示 HTTP 错误或解析错误。某些订阅需要由现有代理访问，这时需要按提供方的说明选择更新通道，但不能因此形成“必须先加载这份配置才能取得这份配置”的循环。可使用已授权的另一网络完成首次导入，再验证后续更新路径。

系统 VPN 接管与后台保活

多数 Android 代理客户端通过系统 VPN 接口接管应用流量，首次启动会出现系统授权框。这里的 VPN 是操作系统提供的流量接入方式，并不意味着协议一定变成某一种传统 VPN。通常同一用户空间只能运行一个此类 VPN 服务，因此广告过滤器、企业 VPN 和其他代理工具可能冲突。先停用其他接管程序，再启动当前应用，并确认系统状态栏与客户端日志都显示服务已建立。

连接几分钟后正常、锁屏后失效，重点检查电池优化、后台活动权限和厂商的自动启动限制。允许客户端持续后台运行，并观察系统是否显示前台服务通知；不要为了隐藏通知而关闭维持服务所需的权限。部分系统还会在清理最近任务时终止应用，是否需要锁定后台取决于设备实现。判断标准不是设置名称，而是锁屏一段时间后重新打开网页，确认客户端进程、VPN 接口和配置仍然存在。

“始终开启 VPN”和“阻止未使用 VPN 的连接”是系统级策略，不适合在首次配置时同时启用。后者会在客户端未启动、更新失败或服务被系统回收时阻断网络，用户容易误判成手机网络损坏。应先验证重启、锁屏与 Wi-Fi/蜂窝切换，再按实际安全需求启用。若启用后无法联网，先回到系统 VPN 设置检查阻断策略，必要时暂时关闭它以恢复订阅更新和故障定位。

分应用、私人 DNS 与移动网络差异

分应用设置通常有“仅代理选中应用”或“绕过选中应用”两种相反含义，保存前必须核对当前模式。被排除的应用不会再遵循客户端内部的域名分流规则；如果浏览器被排除，修改浏览器域名规则自然不会产生效果。先只用一个已纳入接管的浏览器测试，再加入其他应用。系统组件、工作资料应用和双开应用可能处于不同环境，需要分别确认是否能被所选客户端接管。

Android 的私人 DNS、浏览器安全 DNS 和客户端内置 DNS 可能同时参与解析。出现解析失败时，先记录原设置，用系统自动 DNS 与客户端默认配置建立对照，再逐项恢复。不要把关闭某项设置当作永远正确的结论。移动网络还可能使用 IPv6 或不同的 NAT 路径，Wi-Fi 正常而蜂窝异常时，应分别查看连接日志、目标地址族和节点可达性，而不是把 Wi-Fi 下的结果直接套到蜂窝网络。

最后完成一次真实的网络切换测试：先在 Wi-Fi 下连接，再切到蜂窝网络请求同一站点，随后锁屏并恢复。每一步只检查可达性与日志，不要把连通性探测显示的单个数值当作业务可用性的保证。若只有一个应用失败，优先查分应用规则、应用自身的网络限制和协议需求；若所有应用同时失败，再回到 VPN 服务、订阅状态与 DNS 层排查。

iOS：商店安装、配置授权与按需连接

安装 Clash Plus 并保存订阅

iOS 平台首推 Clash Plus，可从App Store 的 Clash Plus 页面安装，产品信息参见官网 clashplus.io。站内iOS 下载区保留相同入口，便于与其他设备对照。安装前查看商店中的兼容性说明；系统是否满足要求、设备是否受到管理策略限制，都应在导入配置之前确认，避免把安装限制误当作订阅问题。

准备好可用于所选客户端的订阅地址，在应用的配置或订阅管理入口添加远程内容，并检查更新结果。界面名称可能随客户端更新调整，应以“新增远程配置、更新、选为当前配置”这三个动作识别流程。导入完成后不要立刻开启全部自动功能，先查看服务器列表和策略组，确定内容已经被正确解析。若服务提供方只给出某一种客户端格式，应先向其确认兼容方式，不能靠修改文件扩展名完成转换。

从其他设备复制地址时，注意聊天应用可能插入空格、截断查询参数或把符号转成富文本链接。粘贴后检查开头协议与完整长度，但不要把带权限参数的内容展示在截图中。若使用相机扫描二维码，扫描只是减少输入错误，不代表内容可信。更换订阅前保留原配置名称和自定义规则备份；多个远程配置并存时，明确当前选择的是哪一个，否则更新了新订阅却仍可能运行旧配置。

区分系统 VPN 状态与实际代理路径

首次连接需要允许应用添加 VPN 配置，并可能通过设备密码或生物识别完成系统确认。授权后回到应用查看连接结果，再到系统 VPN 设置核对当前提供该连接的应用。系统显示 VPN 标识只说明隧道接口已经建立，不说明上游节点可达，也不说明每个目标都走代理。下一步应使用浏览器访问一个预期直连目标和一个预期代理目标，同时查看应用能提供的连接或规则记录。

iOS 中不要照搬桌面端“设置本地端口后再打开系统代理”的操作。应用通常通过系统网络扩展处理流量，界面中的规则模式、代理模式和连接开关也属于不同层次。规则模式按域名、地址或其他条件选择策略，全局模式将更多流量交给所选代理策略，但都仍依赖节点正常工作。若切到全局后恢复，只能缩小到规则或策略选择问题，不能证明 DNS、权限和网络环境全部正确。

同一设备上存在其他 VPN、内容过滤或单位下发的网络配置时，先确认它们的启用状态。受管理设备可能禁止新增或修改配置，这类限制应由设备管理方处理。不要反复删除系统描述文件试错，因为其中可能包含工作网络、证书和访问要求。个人设备需要清理旧客户端时，也应先断开旧连接，再根据其说明移除对应配置，避免误删仍在使用的网络设置。

按需连接、无线网络与后台限制

按需连接应在手动连接稳定后启用。它负责在满足条件时触发或恢复连接，不会修复失效订阅，也不能保证网络登录门户自动完成认证。连接酒店或公共 Wi-Fi 时，如果登录页面打不开，先临时断开代理完成网络认证，再恢复连接。切换 Wi-Fi 与蜂窝数据后，分别测试同一目标，查看问题是否只出现在某一网络；两条网络的 DNS、IPv6 与运营商路径可能不同，不能只靠应用中的连接标记判断。

iOS 的后台运行与桌面常驻进程不同，不能要求用户保持应用界面一直亮着。应通过系统 VPN 状态和实际请求判断扩展是否工作。若切回前台才恢复，查看客户端日志、系统省电状态与自动连接条件，记录发生时的网络类型。配置过于复杂、规则资源过大或外部资源下载失败也可能影响扩展启动，应先用服务提供方支持的精简配置验证，再逐步加入本地规则与额外资源。

DNS 相关排查还要考虑浏览器或系统其他隐私网络功能，它们可能改变解析与出口路径。只做可逆的单项对照：记录原状态，临时调整一项，重新连接后请求相同目标，再恢复设置。检测页面显示的解析服务名称不等于流量一定泄漏，还需要结合客户端接管方式、查询路径和目标连接记录判断。详细方法可参考DNS 泄漏检测与 fake-ip 排查笔记。

Linux：桌面客户端与 mihomo 服务部署

先区分桌面安装与无界面部署

桌面用户从Linux 下载区选择 Clash Verge Rev 或 FlClash，先核对发行版、CPU 架构以及下载页实际提供的包格式。桌面客户端适合需要订阅管理和交互式策略切换的环境；服务器或路由器才优先考虑独立 mihomo 内核。不要因为都是 Linux 就把普通桌面、精简容器和路由系统视为同一种运行环境，图形依赖、权限模型、服务管理器与可用内存都可能不同。

用发行版包管理器安装对应格式的图形客户端，若提示缺少共享库或图形组件，应阅读明确的依赖错误，不要从陌生网站逐个下载动态库。通过图形界面导入订阅并启用配置后，先测试本地代理监听。Linux 桌面环境的系统代理不是统一强制入口：GNOME、KDE、终端工具和独立应用可能各用自己的设置。因此“已启用系统代理”不能作为所有程序都已接管的结论。

终端代理与桌面代理分别验证

下面命令只影响当前终端及其后启动的子进程，不会修改整台机器的路由。HTTP 与 HTTPS 环境变量这里都指向本地 HTTP 代理入口；其中 https_proxy 的名字描述目标请求类型，不要求代理地址本身写成 HTTPS。ALL_PROXY 使用 SOCKS，并通过 socks5h 让支持该语义的工具交由代理解析目标域名。不同工具对变量支持不同，仍应查阅各自文档。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
curl -I https://example.com/
unset http_proxy https_proxy ALL_PROXY no_proxy

先临时设置，验证后再决定是否写入 shell 启动文件。系统服务不会自动继承交互式终端的环境变量，使用 sudo 后变量也可能被清理，所以同一命令换个执行方式就失败并不罕见。包管理器、容器构建和版本控制工具可能有独立代理配置，不要重复叠加而忘记来源。需要显式验证时使用 curl --proxy，并检查大小写形式的旧变量是否仍留在环境中。

独立内核先做配置测试再启动

以下示例适用于使用 systemd 的主机，且假设已将适配本机架构的 mihomo 可执行文件放到 /usr/local/bin/mihomo。先创建专用账户和私有配置目录，把自己已有的完整配置保存为 /etc/mihomo/config.yaml，并允许该账户读取所需文件。示例配置不启用 TUN，只提供本机代理，避免首次部署就扩大进程权限。配置中的数据库与规则资源也需要有明确来源和合适的目录写入权限。

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -m 750 -o mihomo -g mihomo /etc/mihomo
sudo chown mihomo:mihomo /etc/mihomo/config.yaml
sudo chmod 600 /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

先保存配置再执行文件权限命令；账户已存在时不必重复创建。部分发行版的禁止登录 shell 路径不同，应按本机实际路径调整。配置测试通过后，将下列单元保存为 /etc/systemd/system/mihomo.service。不要把订阅访问地址直接写进服务启动参数，参数可能出现在进程列表和诊断输出中。日志先保留正常信息等级，有明确问题时再短时提高详细程度。

[Unit]
Description=Mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager
sudo journalctl -u mihomo -n 80 --no-pager
ss -lntp
curl -I --proxy http://127.0.0.1:7890 https://example.com/

此单元不会自动订阅更新，也不会配置透明转发。修改配置后先重新执行语法测试，确认通过再重启服务。若启动日志显示端口占用，优先排查图形客户端或旧服务，不要连续更换端口掩盖重复进程。服务器仅本机使用时保持回环监听；远程访问应经受控的安全通道，并设置访问限制，不能把开放代理暴露在公网。

配置常见问题：按请求经过的层次定位

订阅更新、配置覆盖与 YAML 解析

排障先保存最近一次有效配置，再记录当前错误发生在哪一步。订阅更新失败看 HTTP 状态和响应类型，配置加载失败看行号与字段，内核启动失败看端口和文件权限，目标连接失败再看节点、规则和 DNS。若把这几类错误混成“无法上网”，就容易在订阅服务器返回错误时反复修改本地路由。可结合已连接却无法访问的逐项清单逐层检查，每次只改变一个变量。

YAML 使用空格缩进，不应混入制表符。注意列表项的短横线、冒号后的空格和字符串中的特殊符号；同一层重复定义 dns 或 rules 也应避免，不能依赖解析器替你决定保留哪一段。客户端的本地覆写可能覆盖订阅原值，最终生效内容应以运行配置为准。更新后自定义规则消失时，检查是否直接编辑了远程缓存，把长期调整迁移到客户端支持的覆写入口。

DNS、fake-ip 与规则的依赖关系

下面片段展示 mihomo 的 DNS 与 TUN 关联方式，需要合并到已有完整配置中，并确认端口、权限和所用内核支持。为缩小测试范围，示例暂不启用 IPv6；这不是所有网络的永久建议。dns-hijack 用来接管进入相应 TUN 路径的传统 DNS 请求，不能据此推断浏览器自行发出的加密 DNS 也被接管。启用前先完成系统代理验证，出现回归时可以只关闭 TUN 恢复对照。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

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

fake-ip 返回映射地址，让内核在后续连接时保留域名关联，这不等于伪造节点，也不等于系统 DNS 一定已经被接管。看到测试保留地址本身不应立即判错，关键是后续流量是否进入同一内核。若应用缓存了旧解析结果，可重启应用后复测；确有兼容性问题的域名再加入适当的过滤规则，不要一开始就把所有域名排除，使功能失去作用。

respect-rules 会让相关 DNS 连接遵循分流，需要同时考虑代理服务器域名自身如何解析，避免解析依赖形成循环。它不是单独勾选就能覆盖所有泄漏路径的总开关。nameserver、fallback 与过滤条件也不能凭字段名称推断为简单的主备顺序。需要组合这些参数时，继续阅读mihomo DNS 参数说明，先弄清请求路径，再决定配置。

规则命中、协议能力与恢复顺序

规则模式下，具体域名通常放在宽泛的地理规则之前，最后保留兜底。DOMAIN-SUFFIX 依赖可用的域名信息，GEOIP 依赖目标地址和数据库；请求以 IP 形式出现时，未必能按预期命中域名规则。策略组存在不代表其当前选择有效，还要查看选择是否指向可连接节点。数据库加载报错则应先处理资源路径或下载问题，相关背景可见GeoIP 与 GeoSite 数据库更新说明。

最后按反向顺序恢复：先关闭新增的 TUN 或自动连接，再清理残留系统代理，恢复此前记录的 DNS 设置，确认基础网络，然后重新启用最小配置。能稳定复现后再增加分应用、覆写规则和后台自启。提交问题时提供系统类型、客户端名称、错误时间与脱敏日志即可；不要提供完整订阅或账户凭据。若只需要重新走一遍连接流程，回到快速上手教程；按症状查具体答案则进入常见问题页。