Clash 全平台安装配置指南

通用准备工作

客户端、内核与连接配置

Clash 生态需要区分三个层次：客户端负责界面、配置管理和系统集成；内核负责协议连接、规则判断与 DNS；订阅或本地配置提供服务器、策略组及规则。安装完成只代表程序可以运行，不代表已经具备可用线路。本文桌面配置示例面向 mihomo；其他实现应以自身支持的字段为准，不能只因名称接近就直接套用。

选型从 Clash Plus 开始，再根据系统和操作习惯比较其他客户端。Windows、macOS、Android 与 iOS 均有对应入口；Linux 可选 Clash Verge Rev 或 FlClash。不同界面可能把同一功能称为配置、订阅或配置档，判断时看其作用：保存远程地址的是配置来源，选择连接出口的是策略组，决定哪些应用进入代理的是流量接管设置。

确认架构与配置来源

先在系统信息中确认操作系统、处理器架构和可用存储空间。Intel、AMD 桌面处理器通常使用 x64 或 AMD64 包，Apple Silicon 使用 ARM64 包；Windows ARM 设备也应单独核对。文件扩展名只能说明分发形式，不能说明架构。遇到不能运行的程序，先检查安装包与系统是否对应，不要立即调整网络参数。

准备由可信服务提供的 Clash 兼容订阅地址，或已经验证的 YAML 文件。订阅链接可能包含账户识别信息，分享日志、截图和配置前应删除查询参数及服务器凭据。浏览器能够打开链接，也不代表客户端一定可以导入：返回内容可能是登录页、流量提示页或其他格式。判断依据是客户端解析结果及配置中的实际字段。

先建立可解释的连接基线

第一次测试应退出其他代理客户端，暂时断开不必要的 VPN，并记录原来的系统代理和 DNS 设置。导入配置后先选规则模式，再手动指定一条已知可用线路。用同一个浏览器访问一个原本可直连的站点和一个需要代理的站点，同时观察连接日志。两个样本分别验证直连路径和代理路径，比只看一个延迟数字更有解释力。

系统代理是给遵循操作系统代理设置的应用提供入口，通常适合浏览器等桌面软件。TUN 则通过虚拟接口和路由接收更多 IP 流量，可能涉及管理员权限、DNS 劫持与其他 VPN 冲突。二者都不等于更换线路，也不能修复服务端失效。先验证代理出口，再扩大接管范围，可避免把出口问题误判为虚拟网卡问题。

下面是本机诊断用的最小配置，不含代理节点，只让受支持的连接直连。它适合检查 YAML 能否加载、监听端口能否建立，不适合测试海外代理连通性。实际使用时应加载服务提供的配置，并核对端口是否被客户端覆盖。若当前配置已有同名顶层字段，应修改原字段，不能简单在文件尾部重复追加。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

备份还应包含接管方式和权限状态，而不只是节点列表。完成本章准备后，只进入所用平台的章节；不需要把五个平台的命令全部执行。若希望先理解内核、策略组、fake-ip 等名称，可查阅术语表，再将术语与界面中的对应选项逐项对照。

Windows 安装配置

选择安装包并完成首次启动

从Windows 下载入口选择 Clash Plus；需要其他界面时，再依次比较 Clash Verge Rev、FlClash 和 Clash Nyanpasu。Clash for Windows 已停止维护，应作为旧环境归档选择，而不是新设备的默认方案。客户端切换时先退出旧程序，避免多个进程同时修改系统代理或占用本地监听端口。

在设置中的系统信息页面确认系统类型，区分 x64 与 ARM 设备。安装时保留可识别的安装路径，启动后确认主窗口和托盘入口均可使用。遇到系统安全提示，应核对下载来源及发布信息，按系统提供的具体说明处理；不要为了让程序启动而整体关闭安全防护。企业管理设备还可能限制安装或服务注册，应遵循设备管理要求。

首次打开时先观察内核运行状态与配置列表。部分客户端启动界面后还需要选择配置，内核才会进入可用状态。若窗口可以显示但日志持续提示端口占用，先退出其他代理程序，再检查后台是否残留旧进程。连续重复安装通常无法解决端口冲突，因为冲突来源可能是另一项常驻服务。

导入订阅与确认策略组

进入配置或订阅管理页，选择添加远程配置，填写名称与订阅地址并保存。等待获取和解析完成后，主动选中这份配置；新增成功并不一定自动切换。查看代理页面是否出现节点与策略组，再进入实际被规则引用的组选择线路。若只有 DIRECT 等内置策略，应返回配置日志检查订阅内容，而不是继续开启系统代理。

远程更新失败时先区分下载失败和解析失败。前者通常涉及地址失效、认证或访问路径，后者常见于收到网页、缩进错误或内核不支持字段。保留上一份可用配置，不要立即删除重建。客户端若提供通过代理更新的选项，只在现有代理已可用时尝试；否则会形成必须先连接才能下载连接配置的循环。

系统代理、TUN 与权限

先开启系统代理，用浏览器验证规则模式。系统代理地址应指向本机实际监听端口，本文示例中的 7890 不是所有客户端的固定值。Windows 的手动代理和自动配置脚本是不同入口，旧脚本残留可能覆盖预期设置。关闭客户端代理开关后，也应确认系统设置已经恢复，特别是在程序异常退出之后。

需要接管不遵循系统代理的应用时，再查看客户端是否支持 TUN。通常需要安装服务或以获准的提升权限启动相关组件；服务安装与每次运行界面都是管理员权限不是同一件事。优先使用客户端自己的服务管理入口，按提示重启内核。启用后检查虚拟接口、默认路由和 DNS 日志，不要只依据开关颜色判断是否接管成功。

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

这段配置仅展示 mihomo 的 TUN 参数，不能替代完整订阅。客户端可能管理这些字段，手写文件之前先检查界面是否会覆盖。auto-route 负责添加路由，auto-detect-interface 用于识别出口接口，dns-hijack 将匹配的 DNS 流量交给内核处理。若启用后反而断网，先关闭 TUN 恢复基线，再逐项查路由与 DNS。

Windows 特有问题与退出顺序

浏览器正常而命令行失败，常见原因是命令行工具没有读取系统代理。可对单次请求显式指定代理，以区别应用适配与节点故障。下面命令使用 Windows 自带的 curl 可执行文件，端口必须替换为当前实际监听端口；测试地址本身不代表代理出口一定正确，还要结合日志查看请求匹配到的策略。

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

休眠唤醒、切换 Wi-Fi 或有线网络之后，出口接口可能变化。若系统代理模式正常而 TUN 异常，先重启内核使接口重新识别，再检查其他 VPN、虚拟机网络和防火墙规则。退出时依次关闭接管、确认系统代理恢复、再结束程序。不要直接删除虚拟网卡或批量重置网络；这些操作会扩大影响，也会丢失原本可用于定位的状态。

macOS 安装配置

区分芯片架构与安装形式

在苹果菜单的“关于本机”查看芯片信息。Apple Silicon 对应 ARM 安装包，Intel 机型对应 x64 安装包。优先从macOS 下载入口选择 Clash Plus，其他选择包括 Clash Verge Rev 和 FlClash。ClashX Meta 已停止维护，保留旧配置时可用于查阅，但不应据此假设其内核支持当前所有配置字段。

若下载的是磁盘映像，打开后按分发说明将应用放入应用程序目录，再从该目录启动。不要长期直接从映像卷运行，否则更新、辅助组件定位或重启后的路径可能出现差异。首次启动遇到安全限制时，在系统隐私与安全设置中阅读对应提示并核对来源。不要使用来源不明的终端命令批量移除系统安全限制。

某些桌面客户端通过菜单栏驻留，关闭窗口不等于结束内核。开始配置前检查菜单栏与活动监视器，确认没有另一套代理在后台运行。若界面没有显示配置，先检查当前用户的数据目录访问权限；不要把应用程序目录与配置目录混为一谈。迁移设备时，应从客户端导出配置或备份指定目录，而不是仅复制应用本体。

订阅导入与配置持久化

在配置管理中新增远程地址，保存后等待完整获取，再将其设为当前配置。确认节点列表与策略组出现，并选择目标线路。macOS 客户端的菜单栏快捷选项往往只切换策略，不负责更换配置来源；节点没有变化时应先检查当前配置名称，而不是反复点击同一个代理组。订阅名称建议能区分用途，避免同名条目造成误选。

本地 YAML 的相对路径通常以客户端配置目录为基准，不一定以下载目录为基准。配置引用规则集、证书或其他文件时，应确认文件能被内核实际读取。远程订阅则应保留更新机制，自定义字段通过客户端支持的覆写入口管理。每次更新后查看最终配置中的规则顺序，避免本地补充规则被放到 MATCH 之后而永远不被命中。

网络服务代理与辅助组件

先启用系统代理，使用浏览器完成连接测试。macOS 的代理设置与网络服务有关，Wi-Fi、有线网卡和其他网络服务可能分别保存设置。切换连接方式后若突然失效，应确认当前活跃服务是否仍指向正确的本地地址和端口。客户端退出后网络仍异常，也应先检查该服务的代理，而不是直接修改 DNS。

可用下面的只读命令查看当前系统代理摘要，重点看启用标志、主机与端口。命令不会修改设置，也不会显示每个应用自己的代理行为。若摘要与客户端界面不一致，先尝试关闭再开启系统代理，并检查是否有另一项网络工具持续写回设置。组织管理的配置描述文件也可能锁定这些选项。

scutil --proxy

TUN 通常需要客户端的特权辅助组件完成虚拟接口和路由操作。安装辅助组件时应阅读系统授权提示，确认请求来自正在使用的客户端。若授权失败，先看应用日志中具体的服务错误，不要反复输入密码。学校或工作设备可能限制网络扩展及系统服务安装，此时应使用允许的接管方式，而不是尝试绕过管理策略。

唤醒、局域网与应用差异

从睡眠恢复后，先检查当前网络是否需要重新认证，以及内核识别的出口是否变化。仅 TUN 失效时可以先重启内核，不必重新导入订阅。若打印机、网络存储或局域网服务异常，应查看这些连接是否进入代理及其匹配规则；按所用网络添加准确的直连规则，不要未经判断就把全部私有地址范围交给远程出口。

终端程序是否使用代理取决于程序本身和环境变量，而不是菜单栏图标。可用显式代理参数做单次对照测试，再决定是否配置终端环境。停止使用时先关闭 TUN 与系统代理，再退出客户端，并检查网络服务设置是否恢复。卸载前还应通过客户端提供的入口移除不再需要的辅助服务，避免只删除应用后留下仍在运行的组件。

Android 安装配置

安装来源、架构与升级

从Android 下载入口选择 Clash Plus，也可依次比较 Clash Meta for Android、FlClash 与 Surfboard。不同应用支持的配置格式和高级字段不完全相同，尤其不能认为所有软件都直接使用 mihomo 的完整 YAML。先根据已有订阅格式选择兼容应用，再考虑界面习惯，能够减少后续转换和排错。

多数近期手机使用 ARM64，但旧设备、模拟器及特殊系统可能不同。若无法确认，应查设备规格或使用下载页提供的适配说明。安装应用包时，仅为实际使用的浏览器或文件管理器授予必要安装权限，完成后可收回。提示与已安装应用冲突时，检查包名、签名和来源；不要急于卸载旧应用，以免先丢失配置与本地规则。

升级前记录订阅地址、策略组选择以及分应用设置。覆盖升级能否保留数据取决于应用标识和签名是否一致，不应仅凭图标或显示名称判断。不同客户端之间通常不能完整迁移应用内部设置，即便导入同一订阅，也需要重新检查 VPN 授权、应用排除和后台运行权限。导入前先保存旧客户端的可用状态。

导入配置与系统 VPN 授权

进入配置管理页添加订阅地址，等待下载完成后选中配置，再打开代理或策略页面核对线路。若返回内容无法解析，应先查看该客户端支持的格式，联系配置提供方确认适配方式。不要把含有账户信息的地址提交给不明转换页面。离线文件导入适合排查下载路径，但之后不会自动跟随远程订阅变化，需明确维护方式。

点击连接后，Android 通常会弹出建立 VPN 连接的系统确认。该授权允许应用创建本地虚拟接口，并不表示手机已连接到某个传统 VPN 服务商；实际出口仍由配置中的策略决定。状态栏出现 VPN 标识只能说明接口已建立，还应打开网页并查看连接日志，确认目标应用确实进入所选线路。

Android 通常只允许一个普通 VPN 服务处于活动状态，其他 VPN 类工具可能替换当前客户端。本地防火墙、流量过滤器或某些加速工具也可能使用同一机制。发生连接后立刻断开的情况，应先检查这些应用与系统始终开启 VPN 设置，再考虑更换节点。桌面系统代理的操作步骤不能直接搬到手机，二者接管入口不同。

分应用代理与后台保活

分应用功能通常提供仅代理所选应用或排除所选应用两类逻辑，两者含义相反。设置前先读清当前模式，再用一款应用作为样本测试。被排除的应用可能完全绕过内核，因此在日志中看不到连接是正常结果，不是规则没有加载。修改应用名单后可能需要重建 VPN 接口，按客户端提示断开再连接即可。

若亮屏时正常、锁屏后失联，重点查看电池优化、后台活动限制和厂商的自启动管理。只为正在使用的客户端开放必要权限，并观察问题是否消失，不必批量放宽所有应用。部分系统在省电模式、长时间待机或内存紧张时仍可能结束服务；应把断开时间与系统状态对应起来，而不是把每次恢复都归因于线路波动。

移动网络、DNS 与热点边界

从 Wi-Fi 切换到移动数据后，底层网络地址和路由可能变化，现有连接也可能中断。先等待短暂重连，再检查客户端是否重新识别网络。只有某个网络失效时，应区分网络认证、DNS 可达性和代理服务器可达性。机场、酒店等需要网页登录的网络，可能要在建立代理前先完成认证，否则所有节点都会表现为不可用。

系统私人 DNS、应用自身的安全 DNS 与客户端 DNS 可以同时存在，不能只改一个开关便断言解析路径已经统一。需要结合客户端日志与测试结果确认域名由谁处理。不要把检测页面显示的解析地区直接等同于泄漏结论；代理服务器所在网络、递归解析器出口及测试页面的识别方式都可能影响显示结果。

长期运行前完成三项验证：锁屏后能否恢复连接，切换网络后是否需要手动重连，排除应用是否按预期直连。保留一份普通规则模式配置作为基线。出现问题时先关闭分应用等附加选项，再逐步恢复；这样能够确定故障来自基础连接、系统后台限制，还是应用选择规则。

iOS 安装配置

商店安装与功能边界

iPhone 与 iPad 优先选择 Clash Plus，可从App Store 的 Clash Plus 页面安装，并通过官网 clashplus.io核对产品说明。下载入口也集中列于iOS 平台页面。安装前阅读商店中的系统兼容要求，以设备实际显示的信息为准，不凭客户端名称推断支持范围。

iOS 应用受系统网络扩展机制和沙盒约束，操作方式与桌面客户端不同。本文使用配置、策略、连接等功能名称描述流程，具体按钮以当前界面为准。不能因为桌面配置里存在某个 mihomo 字段，就假定手机应用能解释相同字段；导入结果、应用说明与实际连接行为才是判断依据。尤其不要直接粘贴桌面 TUN 段落来替代手机的连接设置。

订阅导入、选中与更新

准备应用支持的订阅地址，在配置管理入口选择从链接添加，填写便于识别的名称后保存。获取完成后选中该配置，并检查是否出现预期的策略组和线路。若应用提供从文件导入，也应确认文件编码与格式完整，避免从聊天软件复制时丢失换行。含账户信息的链接不要保存在公开笔记或发到群聊中。

导入成功与当前配置生效是两件事。新增配置后应查看当前选中项，再检查策略组是否指向可用线路。只有节点集合的订阅可能还需要应用支持的规则或配置模板；遇到缺少规则的提示，应按应用说明处理，而不是把另一个客户端的整份文件直接拼接进来。重复导入不能修复不兼容字段，还会增加同名配置的辨认成本。

更新订阅时保留上一份可用配置，先看获取是否成功，再看节点或策略是否变化。若只在连接状态下才能更新，应确认应用的更新请求走向；若已有线路完全不可用，则需要先在可达网络下取得配置。手动改动可能在下次更新中被替换，长期自定义应使用应用明确支持的持久化方式，并在更新后重新检查。

连接授权与受接管范围

首次连接时，系统可能要求允许添加 VPN 配置，并通过设备认证确认。允许后回到应用启动连接，观察系统状态和应用日志。VPN 标识说明网络扩展正在工作，不代表节点已经连通，也不代表每个应用的流量都按相同方式处理。应使用明确的访问样本验证直连与代理，再核对策略选择，避免只用开关状态判断成功。

iOS 不提供与桌面完全相同的全局 HTTP 系统代理开关体验。Wi-Fi 详情页中的 HTTP 代理属于特定无线网络设置，应用中的隧道连接则由网络扩展承担，两者不可混为一谈。一般使用按应用提供的连接流程即可；若同时保留手动 Wi-Fi 代理，应记录其用途，并检查是否造成重复代理或在退出应用后仍影响访问。

设备上其他 VPN、网络过滤或受管理的网络配置可能与当前连接冲突。若点击连接后马上变为断开，先查看系统是否启用了另一份配置，再阅读应用的失败原因。工作或学校设备应按管理策略使用网络，不要删除来源不明的描述文件来试错。只有明确知道配置来源和用途时，才调整其状态。

网络切换、解析与恢复

Wi-Fi 与蜂窝数据切换时，现有连接可能需要重新建立。先确认应用具备蜂窝数据权限，再比较同一线路在两种网络下的表现。仅 Wi-Fi 失败时检查是否需要网页认证，仅蜂窝数据失败时检查网络权限及服务器地址可达性。不要在一次测试里同时更换线路、模式和 DNS，否则即使恢复，也无法知道是哪项改动起作用。

网页显示的出口信息需要结合请求路径理解。iCloud 专用代理在受支持条件下可能影响部分 Safari 流量，应用自身的解析与连接策略也会影响观察结果。排错时记录这些功能的原始状态，在允许范围内进行单变量对照，再恢复原设置。一个浏览器测试结果不能自动代表设备上的全部应用，更不能据此判断所有 DNS 请求路径。

锁屏后中断时，应区分网络本身变化、线路超时和扩展重启。先看重新打开应用后是否自动恢复，再查日志时间点，不要把强制结束应用当作日常保活操作。恢复默认连接时，先在应用内断开，再检查系统 VPN 状态和 Wi-Fi 代理。需要移除旧配置时在系统设置中确认名称与来源，避免误删其他业务所需的网络配置。

Linux 安装配置

图形客户端与独立内核

Linux 桌面优先从下载页选择 Clash Verge Rev，也可使用 FlClash。先核对发行版的包管理体系、处理器架构与桌面环境，再选对应安装形式。独立 mihomo 内核更适合服务器、路由器或需要自行管理服务的用户；它不提供完整桌面配置界面，安装之后还需要准备配置、进程管理和日志查看方式。

DEB 与 RPM 不是通用压缩包，不能在不匹配的发行版上直接互换。图形应用还依赖桌面环境和运行库，安装失败时应阅读包管理器报告的依赖问题，而不是直接改文件权限。通过系统包管理器安装本地包，能够保留依赖和卸载记录。不要为了避开依赖错误，把桌面应用整体以 root 身份运行。

下面展示常见的本地包安装命令，文件名是操作示例，不是实际下载地址。执行前将路径换成已下载的对应文件，并确认它适合当前系统。安装完成后从应用菜单启动，观察是否能正常显示托盘、读取配置并启动内核；窗口成功出现只验证图形层，不代表代理监听和网络权限已经可用。

sudo apt install ./client.deb
sudo dnf install ./client.rpm

导入订阅与桌面代理差异

图形客户端的订阅流程与其他桌面平台相似：添加远程配置、等待解析、选中配置，再到策略组指定线路。Linux 桌面环境对系统代理的存储和读取方式不同，某些应用只读取环境变量，另一些读取桌面设置或自身设置。开启系统代理后浏览器正常、终端失败，并不能直接说明内核出错，应先确定终端工具实际使用了什么入口。

命令行可以先对单个请求指定本地代理，不必立即修改整个会话的环境变量。下面分别测试 HTTP 入口与 SOCKS 入口，后者的主机名形式会让 curl 将目标域名交给 SOCKS 端处理。端口应与当前配置一致；若显示连接被拒绝，先检查内核是否运行和监听地址是否正确，再检查远端节点。

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

若需要配置环境变量，先在当前终端短期测试，并注意大小写变量及应用支持差异。带有 NO_PROXY 的排除列表可能让某些请求绕过代理，sudo 也可能清理环境。排错时记录实际执行上下文，避免用普通用户测试成功后，就假定系统服务或容器里的程序也继承了相同设置。

独立内核的配置与服务权限

独立内核应使用单独的数据目录，放置配置与需要下载的数据文件。先以前台方式运行并阅读日志，确认配置正确后再建立后台服务。不要一开始就隐藏日志并设置自动重启，否则语法错误会表现为进程反复退出。下面命令假定可执行文件已安装且配置目录已经存在，路径按实际环境调整。

mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

-t 用于测试配置，能够帮助发现语法和引用问题，但测试通过不代表服务器可达或路由正确。后台服务还应明确工作目录、运行用户和文件权限。若需要读取含凭据的配置，限制其访问范围；若配置由其他用户创建，也应确认服务账户能够读取必要文件，而不是通过开放整个目录权限解决问题。

TUN、DNS 与发行版差异

Linux TUN 涉及虚拟设备和网络管理权限。图形客户端优先使用自身服务安装入口；独立部署则应按照服务管理方式授予所需权限，不要把所有程序都长期提升权限。容器或受限主机还可能缺少虚拟设备访问能力，单纯修改 YAML 无法突破这些环境限制。先确认宿主环境支持，再检查内核参数。

系统可能同时使用 NetworkManager、systemd-resolved 或其他解析组件。直接编辑 /etc/resolv.conf 可能被网络服务覆盖，也可能破坏本来的符号链接。应先查明管理者，再决定如何让 DNS 进入内核。启用 TUN 后若 IP 请求正常而域名失败，重点看解析入口、53 端口处理和上游可达性，不要先更改节点协议。

本机代理也不会自动接管容器、虚拟机或局域网其他设备。它们有独立的网络命名空间、网关与防火墙路径，需要单独设计转发方案。停止服务时确认自动路由已清理、桌面代理与终端变量已恢复。远程服务器上调整默认路由前保留备用管理通道，避免把当前管理连接也导入一条尚未验证的代理路径。

配置常见问题与分层排错

配置能加载，为什么仍不能上网

按配置获取、内核运行、本地监听、应用接管、DNS 解析、策略匹配和远端连接的顺序排查。每层只验证一个问题：配置是否解析成功，端口是否监听，目标应用是否产生连接日志，日志使用了哪个策略，远端握手是否完成。先找到第一个失败环节，再修改对应设置，比同时更换订阅和网络模式更容易得到稳定结论。

解析错误先看行号及上下文。YAML 的层级依赖空格，不能用制表符代替缩进；同一映射中不要重复定义 dns、tun 或 rules。含特殊字符的字符串应正确引用。客户端的原始订阅、覆写片段和最终配置可能是三个不同对象，确认当前编辑对象后再修改，否则保存成功也可能没有进入内核实际读取的文件。

规则模式、全局模式与策略引用

规则模式按列表顺序匹配，通常在首次命中后停止。全局模式把受接管连接交给全局策略，但不会让原本未被接管的应用自动进入内核；直连模式也不等于关闭客户端或虚拟网卡。模式适合作为诊断变量：全局可用而规则不可用时，重点检查匹配结果与策略组；两者都失败时，先核对出口和接管。

下面示例只让指定域名后缀进入人工选择组，其余直连。选择组暂时只有 DIRECT，因此它是规则结构演示，不提供远程代理。实际配置需要把已存在的节点或订阅提供者接入组内。规则引用的策略名称必须与组名一致，拼写差异会导致加载失败或行为不符。更多顺序示例见国内外分流规则实战。

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,SELECT
  - MATCH,DIRECT

DNS、fake-ip 与接管边界

DNS 负责将域名关联到地址，代理负责建立连接，二者需要协同但不是同一层。fake-ip 返回用于映射的虚拟地址，由内核在后续连接中恢复域名语义，并不意味着目标网站真的使用该地址。若应用保留旧缓存、绕过内核解析或使用自身加密 DNS，规则所见信息可能不同，应该结合连接元数据判断。

下面是 mihomo 的 DNS 局部示例，监听地址仅在本机开放。它不会自动更改系统解析设置，也不会单靠这段配置阻止所有外部解析。TUN 的 DNS 劫持主要处理匹配的传统 DNS 流量，应用自带的加密解析还需要结合路由与应用设置分析。上游地址必须在当前网络可达，否则会形成所有域名都失败的现象。

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

改变解析模式后，旧缓存可能使现象暂时延续。先按客户端支持的方式清理 DNS 缓存，并重建测试应用连接，再比较结果。只对受影响域名设置必要例外，不要为解决一款应用的问题而取消全部规则。检测步骤和结果边界可继续阅读DNS 泄漏检测与修复；虚拟接口参数见TUN 模式设置说明。

保存证据与恢复可用状态

日志应保留发生时间、目标应用、网络类型、模式、命中规则和错误摘要，同时删除订阅地址、服务器凭据及个人访问记录。临时提高日志级别能够补充线索，完成测试后应恢复常用级别，减少信息积累。节点延迟测试只覆盖特定探测请求，不能替代实际网站访问，更不能证明 UDP、长连接或所有目标都正常。

若问题由最近一次更新触发，先恢复上一份可用配置，再逐项比较变化，包括策略名称、规则集、DNS 上游和客户端覆写。规则集下载失败与节点连接失败是不同问题，GeoIP、GeoSite 数据也有独立更新机制，可查阅数据库更新与规则引用方法。不应通过频繁重装来替代对错误层次的判断。

需要重新开始时，先断开客户端接管，再恢复系统代理与原 DNS，确认普通网络可用，然后导入已保存的配置副本。初次连接流程可回到教程页逐步核对，模式差异可查阅规则、全局与直连模式对照。手册中的示例用于解释参数与诊断边界，不能替代真实有效的连接配置。