Clash 全平台安装配置大全

01 / PREPARATION

通用准备：客户端、订阅与接入路径

区分界面、内核与服务

Clash 生态中的图形客户端负责配置列表、策略组选择和系统接入；内核负责解析配置、匹配规则并建立连接。mihomo 是常见内核，但不同客户端集成的能力和配置入口并不完全相同。安装客户端本身不会生成可用节点，也不等于已经具备代理服务。开始前需要准备服务方提供的订阅地址，或一份包含有效节点、策略组与规则的完整配置，并确认账号状态及设备数量限制。

桌面和 Android 平台优先从下载页的 Clash Plus 开始选择；已有稳定工作流时，再按系统需求比较 Clash Verge Rev、FlClash 等客户端。Linux 图形界面选择 Clash Verge Rev 或 FlClash。配置能否跨客户端复用，要看订阅格式、协议支持和实际内核，不能只看名称相似。归档客户端适合保留旧环境，不宜作为新设备的默认部署路线，具体清单见客户端选型指南。

检查架构与订阅内容

下载前先查看系统的处理器架构。桌面系统常见 x64 与 ARM64，macOS 则区分 Intel 和 Apple Silicon。安装包能否启动，首先由系统、架构及最低系统要求决定，与订阅是否有效没有关系。不要靠反复更换订阅解决程序打不开的问题，也不要把手机应用包与桌面安装文件混用。下载页提供的平台入口和系统要求应当与设备信息逐项对应。

订阅地址通常具有访问凭据的作用，粘贴时应保留完整查询参数，去掉首尾空格和聊天软件追加的标点。先辨认服务方给的是 Clash YAML 订阅、单节点链接，还是用于浏览器登录的管理页面。完整 YAML 通常含有节点或节点提供器、策略组和规则；仅有一串编码文本不一定能被当前导入入口直接识别。需要转换时，优先使用服务方提供的适配地址，细节见订阅格式与转换说明。

先建立可回退的最小环境

首次配置只保留一个代理客户端和一条接入路径。先用规则模式、一个手动选择的策略组和一个确认可用的节点完成网页访问，再逐步加入 TUN、覆写、规则提供器或复杂 DNS。系统代理与 TUN 不是必须同时开启的两个步骤；二者叠加可能让排错对象增加。手机通常通过系统 VPN 能力建立隧道，并不对应桌面端逐项相同的开关名称。

以下片段用于认识常见字段，不含远端节点，不能代替服务方订阅。混合端口可同时接受 HTTP 与 SOCKS 请求；仅监听回环地址可限制本机以外的访问。示例端口不是每个客户端的固定默认值，实际值应以当前设置为准。图形客户端可能自行生成这些字段，直接修改生成文件后也可能被下一次保存覆盖。

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

建立连接前记录当前系统代理、DNS 和其他 VPN 的状态，保留一份能正常启动的配置副本。测试时区分“节点测试成功”“请求命中代理规则”和“目标网页正常加载”三个结果：它们分别验证不同环节。完成基础连接后再测试需要使用的应用，而不是只依靠面板的一次延迟结果判断整个网络已经正常。

02 / WINDOWS

Windows：安装、系统代理与服务权限

选择安装文件并完成首次启动

打开Windows 下载入口，首选 Clash Plus，也可按既有需求选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu。Clash for Windows 属于已停止维护的归档选项。进入系统设置的“系统—系统信息”查看系统类型，按架构选择下载页提供的文件。不要因为设备名称包含某个处理器品牌就推断架构；安装包若提示无法运行，应先核对系统要求与文件类型。

运行安装程序后使用普通用户身份启动界面，按提示选择安装位置。需要系统服务或虚拟网卡能力时，再在客户端设置中执行相应安装操作，并阅读系统的权限确认。日常并不需要为了打开面板就始终以管理员身份运行整个程序。首次启动若被安全软件拦截，应查看拦截项目和文件来源，不要通过关闭整套系统防护来跳过定位。

导入订阅并选中正在使用的配置

在“配置”“订阅”或同类页面选择新增远程配置，填入完整地址并执行下载。列表出现条目后，还需要选中或激活该配置；“下载完成”不代表内核已经切换。进入代理页面检查策略组是否出现、组内是否有节点。若只有直连选项，先确认订阅内容与导入类型，再观察内核是否报告不支持的协议或字段，不要立即修改系统路由。

对目标服务对应的策略组先做手动选择。配置中可能同时包含默认代理、流媒体、下载或其他业务分组，修改一个组不会自动改变所有组。选中节点后切换到规则模式，查看一次真实访问的连接记录，核对命中规则和最终出站。延迟测试可用于筛查连接失败，但并不代表网页吞吐或应用兼容性，选点方法可参考节点延迟、倍率与地区对照。

先验证系统代理，再考虑 TUN

开启系统代理后，到 Windows 的代理设置中核对本地地址与端口是否与客户端一致。使用自动配置脚本的环境还应检查脚本入口，避免把不同接入方式当成同一项。浏览器通常可以采用系统设置，但终端、开发工具或自行实现网络栈的软件可能不会采用。某个程序仍然直连时，应先查看它的代理选项，而不是直接把所有规则改成全局代理。

在 PowerShell 中可以用显式代理请求隔离系统设置因素。下面的请求只有在客户端实际监听相同端口时才有意义；它验证本地 HTTP 代理入口与后续连接，不证明所有应用都已被接管。若显式代理可用而浏览器失败，再查浏览器扩展、独立代理配置和缓存。若连接本地端口就失败，应先处理内核启动、监听地址或端口冲突。

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

需要接管不遵循系统代理的应用时，再开启 TUN。客户端可能要求先安装服务、启用服务模式或授予管理员权限，具体以界面提示为准。启用后检查虚拟网卡是否出现、内核日志是否成功创建设备，以及路由是否安装。VPN、虚拟机网络、容器网络与企业安全软件都可能影响路由选择；排查时先停用非必要的同类隧道，再重复同一个请求做对照。

休眠、更新与异常退出后的恢复

唤醒后失去连接不一定是订阅失效。先确认物理网络恢复，再刷新节点连接；切换无线网络或有线网络后，旧接口的路由可能需要重建。若退出客户端后所有网页都无法打开，检查系统代理是否仍指向已关闭的本地监听端口。正常退出前先关闭接入开关；异常退出后的恢复应优先还原代理设置，再处理客户端本身，避免在断网状态下继续下载新包。

端口被占用时，通过监听结果中的进程编号确认占用者，再决定关闭重复客户端或修改当前端口。修改后要同步应用手动代理、系统代理和终端变量；只改配置文件的一处会造成部分应用继续访问旧端口。更新客户端前备份订阅来源、覆写及策略选择，更新后复查服务状态。更完整的定位命令见本地端口冲突排查。

03 / MACOS

macOS：处理器架构、网络服务与后台组件

区分 Apple Silicon 与 Intel 安装包

从“关于本机”查看芯片或处理器信息，再进入macOS 下载入口。新设备配置首选 Clash Plus，也可选择 Clash Verge Rev 或 FlClash；ClashX Meta 为已停止维护的归档客户端。Apple Silicon 与 Intel 安装文件分别对应不同架构。不要优先依靠转译运行来绕开架构选择，尤其当客户端还需要安装网络相关后台组件时，界面能启动并不代表附属组件也匹配。

对于磁盘映像形式的应用，将程序复制到“应用程序”后再启动，避免长期从挂载的映像内运行。首次打开若出现系统安全提示，先确认下载来源、文件是否完整下载以及是否符合系统要求，再按照 macOS 提供的正常授权流程处理。不要把批量移除安全属性作为默认安装步骤；组织管理的电脑还可能受管理策略限制，需要先确认是否允许安装网络工具。

导入远程配置并理解菜单栏状态

在配置管理中新增订阅地址，等待获取成功后显式激活该条目。菜单栏图标存在通常只表示应用正在运行，不等于订阅已加载、节点已选定或系统代理已开启。进入策略组检查可选节点，再用连接页面观察真实请求。若导入成功却没有预期分组，检查服务方是否返回了错误页面、套餐是否到期，以及当前导入入口期待的是完整配置还是单节点列表。

需要长期保留的自定义规则应写入客户端支持的覆写或合并入口，而不是直接改订阅缓存。远程更新通常会替换缓存内容，临时编辑可能在下次刷新后消失。修改前先导出副本，确认规则的顺序和策略组名称完全一致。配置中的名称区分字符，末尾空格、全角标点或改名后未同步引用，都可能使规则无法按预期指向目标出站。

按当前网络服务检查系统代理

macOS 的代理设置与具体网络服务有关。无线网络和有线网卡可以具有不同设置，切换接口后应检查当前正在使用的服务，而不是只查看上一次连接的无线网络。先开启客户端的系统代理，再在系统网络设置中查看代理地址与端口。已有自动代理配置、浏览器代理扩展或其他网络工具时，要明确哪个组件负责最终配置，避免多个工具互相覆盖。

下面的命令用于列出网络服务并查看某个服务的代理。示例使用常见名称“Wi-Fi”，实际服务可能被重命名，应先读取列表再替换。HTTPS 网页经过本地 HTTP 代理时通常使用 CONNECT，系统中的安全网页代理项因此也需要检查。只看到网页代理开启，并不能确认 HTTPS 应用采用了相同设置。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
curl --proxy http://127.0.0.1:7890 -I https://example.com

TUN 权限与开发环境的差异

启用 TUN 前先完成系统代理路径的测试，再按客户端提示安装辅助组件或授权网络能力。不同实现可能使用特权辅助程序、系统扩展或其他接入机制，授权入口不必完全相同。检查系统设置中的相关批准状态，完成后重新启用隧道。若日志出现设备创建或权限错误，应先修复组件状态，不要通过连续更换节点掩盖本地权限问题。

终端程序不一定采用图形界面的系统代理。临时测试可通过命令的代理参数指定入口；若使用环境变量，应只在需要的会话或工具中设置，注意大小写变量和工具支持差异。Docker、虚拟机及远程开发环境拥有各自网络上下文，其中的回环地址不是宿主机。容器里访问本机代理失败时，先确认访问的是哪台主机，再评估是否需要开放受限的局域网入口。

睡眠唤醒、网络服务顺序变化和公司 VPN 都可能影响连接。先用相同网址对照直连与显式代理，再检查路由和 DNS；局域网打印机、文件共享或开发域名失效时，应考虑本地域名处理与直连规则，而不是把所有私有地址送往远端。卸载客户端前先关闭系统代理与隧道，并通过客户端提供的入口移除辅助服务，避免只删除应用后留下仍在运行的组件。

04 / ANDROID

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

选择兼容安装包并保留迁移路径

进入Android 下载入口，按顺序可选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard，首次使用优先 Clash Plus。设备架构与最低系统要求决定安装兼容性，不能只按手机品牌选择。多数新设备使用 ARM64，但旧设备和特殊系统仍应查看实际信息。安装器若明确提示不兼容，先排查架构和系统要求，再考虑其他客户端。

通过系统文件管理器打开下载文件时，Android 可能要求允许当前来源安装应用。授权应限于本次使用的浏览器或文件管理器，安装完成后可恢复原设置。覆盖安装失败还可能由签名不同、已有其他发行渠道的应用或版本回退限制导致。卸载前先导出配置及覆写，确认订阅仍可重新获取；直接删除应用会同时丢失本地策略选择和部分运行设置。

区分订阅更新与当前运行配置

在配置页新增 URL 订阅，执行下载并切换到该配置。成功后进入代理页面，确认目标策略组中出现节点，再手动选一个进行测试。若从浏览器使用快捷导入，返回客户端后仍应核对地址、配置名称和当前激活状态。系统可能安装了多个能够处理同类链接的应用，快捷导入进入另一个客户端时，并不会同步修改当前正在运行的那个实例。

Clash Meta for Android 等客户端的配置入口与其他应用可能不同，Surfboard 支持的配置语法也不应直接等同于 Clash YAML。服务方提供多种订阅类型时，选择与当前客户端匹配的一项。导入报错后先阅读格式或协议错误，不要反复把同一地址添加成多个条目。对于只含节点的内容，还需要客户端提供规则和分组逻辑，节点列表本身不是完整的路由策略。

批准 VPN 连接并确认接管范围

点击连接或启动后，系统通常显示 VPN 连接确认框。批准后查看客户端是否报告服务已启动，同时观察系统的 VPN 状态。普通个人用户环境下，同一用户空间通常只能由一个 VPN 服务占用该位置；广告过滤、防火墙、工作网络或其他代理应用都可能竞争。出现启动后立即断开时，先检查是否存在另一项 VPN，而不是立即修改远端节点参数。

Android 的 VPN 接管不等于必须开启一个名为 TUN 的独立开关。许多移动客户端已通过平台 VPN 接口把流量交给内核，网络栈、DNS 和应用分流由应用内部管理。界面中若提供系统栈或用户态栈，先使用默认选项，只有出现明确兼容问题时再做对照。桌面端的 auto-route 等字段未必由移动客户端直接采用，整段照搬可能被忽略或与生成配置冲突。

使用“仅代理选定应用”时，新安装的应用不一定自动进入名单；使用排除模式时，被排除的程序会绕过隧道。先确认当前是包含名单还是排除名单，再检查目标应用是否在正确一侧。浏览器可用但其他应用不可用时，应把应用分流、私有 DNS、应用内部代理以及 UDP 需求分别测试，不要把所有差异都归因于订阅失效。

处理省电限制与网络切换

连接在锁屏后中断，优先查看系统电池设置是否限制后台活动、是否允许必要的自启动，以及前台服务通知是否保留。不同厂商的设置名称差别很大，最近任务中锁定应用也不等同于完整后台授权。建议先调整当前客户端的电池策略，再观察锁屏与唤醒日志。持续重连但没有进程退出记录时，则应继续检查移动网络切换、节点可达性和隧道重建。

从无线网络切换到移动数据时，公网出口与底层连接会变化，已有长连接可能需要重新建立。先等待网络稳定，再重新连接并测试同一个目标。公共无线网络存在认证页时，先完成网络认证再启用代理；VPN“始终开启”与“阻止不经 VPN 的连接”若已启用，停止客户端可能直接阻断网络。排错前应记下这些系统设置，避免把预期的阻断误判成客户端崩溃。

05 / IOS

iOS：商店安装、订阅适配与隧道配置

通过商店安装 Clash Plus

iPhone 与 iPad 从iOS 下载入口进入 Clash Plus 的商店页面，也可直接查看Clash Plus App Store 页面。应用官网为 clashplus.io。安装前阅读商店列出的设备和系统要求，完成后启动应用。iOS 的系统接入由平台网络能力管理，不能把桌面端的安装服务、后台托盘或系统代理菜单当作同样存在的操作。

首次使用先确认设备自身能正常联网，并完成当前无线网络的网页认证。订阅下载通常发生在正式建立隧道之前，如果底层网络尚未接通，就会表现为导入超时。组织管理设备还可能具有网络扩展、描述文件或访问限制；遇到系统不允许添加 VPN 配置的提示，应先确认设备管理规则，而不是尝试修改订阅中的节点协议。

导入完整地址并检查配置兼容性

在应用的配置或订阅管理入口添加远程地址，保留全部参数后执行获取。若页面提供快捷导入，切回应用后检查新条目是否实际出现，并将其设为当前配置。一个订阅可能提供不同客户端格式，应该使用服务方明确标注兼容的一项。不要因为 YAML 能被文本编辑器打开，就认定其中每个字段都适用于移动平台；文件格式正确和功能被支持是两件事。

获取失败时，先区分网络请求错误与内容解析错误。请求超时需要检查当前网络、订阅域名和服务方状态；解析错误则需要核对返回内容是否为登录页、错误提示或不受支持的配置。地址中含访问凭据时，不能将完整地址交给陌生在线工具测试。需要订阅转换时先阅读服务方说明，确认转换后的策略组、规则及协议参数没有因格式差异而丢失。

配置激活后进入策略选择页面，检查目标组是否有可用节点。先手动选定一个节点，再启动连接并打开明确的目标网页。自动测试组可能需要经过一次健康检查才形成可用结果，空组或测试失败时应先检查组内成员和测试条件。不要以一个失败的探测地址否定所有服务，也不要仅凭一个节点可连接就推断所有业务分组已选对。

批准隧道并确认实际路由

首次启动连接时，按系统提示允许应用添加 VPN 配置，再通过设备要求的确认方式完成授权。返回应用检查连接状态，必要时到系统 VPN 设置核对当前启用的项目。状态栏出现 VPN 标识只说明隧道处于工作状态，并不意味着每条请求都经过远端代理。规则模式仍然可以把部分目标交给直连策略，实际出站需要结合应用中的连接记录判断。

如果同时安装了其他 VPN 或网络过滤应用，应先明确当前生效的是哪个配置。使用按需连接时，网络条件变化可能触发系统自动重连；手动点击断开后又恢复连接，不一定是按钮失效。排错时暂时关闭当前应用的按需规则，再进行固定网络下的连接测试，确认基础路径后恢复自动行为。不要同时修改节点、规则和按需条件，否则难以还原是哪项设置影响了结果。

DNS、局域网服务与 Wi-Fi 代理的边界

Wi-Fi 详情页中的 HTTP 代理与应用创建的 VPN 隧道不是同一个入口。前者只影响相应网络中采用该设置的流量，后者由应用与系统协作接管。排查时先移除不再使用的手动 Wi-Fi 代理，避免流量先被送往旧的本地或局域网地址。手机自身配置的回环地址只指向手机，不能用它访问电脑上的代理服务；跨设备接入需要电脑的实际局域网地址与明确开放的监听端口。

局域网发现、投屏和本地设备控制受路由与名称解析共同影响。如果公网网页正常而本地设备不可达，先查看本地地址是否被错误代理、DNS 是否将本地域名送往不合适的解析路径，以及系统是否授予应用必要的本地网络权限。改变系统层面的隐私或网络选项前先记录原状态，逐项对照，不要通过永久关闭所有保护功能来解决一个具体的兼容问题。

iOS 会管理后台进程和隧道资源，订阅定时更新是否按预期执行取决于应用实现及系统调度。长时间未打开应用时，可先手动更新配置并查看结果，再测试连接。更换无线网络或从移动数据返回无线网络后，先验证底层网络和订阅状态，再重建隧道。保留一份已知可用配置，但不要把过期订阅当作永久离线资源；节点与授权变化仍需要从服务方同步。

06 / LINUX

Linux：图形客户端与 systemd 服务部署

桌面环境优先使用图形客户端

有桌面环境时，从Linux 下载入口选择推荐的 Clash Verge Rev 或 FlClash，根据发行版的软件包体系安装对应文件。先用 uname -m 确认架构，再核对下载页提供的包型。软件包不存在或依赖不足时，应检查发行版版本与包支持范围，不要直接把其他平台的二进制改名运行。图形界面能启动后，再处理订阅和网络接入。

桌面客户端中新增远程配置、激活订阅并手动选择节点，然后开启当前桌面环境支持的系统代理。GNOME、KDE 以及终端工具对系统代理的采用方式并不一致，图形开关不能覆盖所有程序。先用显式代理请求验证本地端口，再逐个配置开发工具。启用 TUN 则还需要设备权限和路由管理能力，应按客户端提供的服务安装流程操作，避免同时启动另一个独立内核占用端口。

服务器使用独立 mihomo 内核

没有桌面环境时，下载与处理器架构匹配的 mihomo 内核并解压，下面的命令假设当前目录已经有名为 mihomo 的解压后二进制和名为 config.yaml 的完整配置。配置必须预先写入有效节点或提供器，不能把本页的字段片段当作完整服务配置。文件中可能包含订阅凭据，部署时限制目录和文件权限，不要放进公开的网站目录。

sudo install -m 0755 ./mihomo /usr/local/bin/mihomo
sudo install -d -m 0700 /etc/mihomo
sudo install -m 0600 ./config.yaml /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

先执行配置测试，解决语法、策略组引用及资源文件错误后再启动常驻服务。配置依赖外部规则、地理数据库或提供器时，还需确认运行用户能访问相应目录，并能在需要时获取资源。首次启动访问失败不一定是节点故障，也可能是本地缺少资源。若资源下载本身需要代理，应预先准备资源或建立明确的引导路径，避免内核必须先连接才能获取启动必需文件的循环。

用 systemd 管理启动与日志

创建 /etc/systemd/system/mihomo.service，下面示例面向需要 TUN 管理权限的本机部署，未指定用户时服务以 root 运行。仅提供普通本地代理的环境应评估独立低权限用户；创建虚拟网卡、改路由和绑定受限资源则需要额外能力。不要在不了解权限需求时照搬一组限制参数，导致服务看似启动却无法创建网络设备。

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5

[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 检查实际监听，再通过本地代理请求验证出站。控制接口若需启用，应绑定回环地址并设置访问凭据；远程管理优先通过受控隧道访问。开放控制接口与开放代理端口是两种不同风险，均不应直接暴露到公网。服务器本机的回环地址也不会被远程电脑直接访问，浏览器面板的连接目标必须与部署位置相符。

TUN 与维护时的回退

Linux TUN 需要内核设备与网络管理权限。容器内运行还涉及设备映射和相应能力，普通容器进程通常不能直接改宿主机路由。以下片段应合并到已通过测试的 mihomo 配置中，且只有在当前内核支持对应字段时使用。auto-detect-interface 用于辅助识别出站接口，但多网卡和策略路由环境仍需检查实际结果。

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

远程服务器启用自动路由前，保留第二条管理会话和控制台回退方式，确认管理流量不会被错误接管。网络正常后再设置开机启动策略，配置变更先测试再重启。命令行内核不会自动替你实现所有图形客户端的订阅定时更新功能，更新脚本应采取临时下载、配置测试、成功后替换的流程。部署路线与服务维护细节还可查阅Linux 桌面与 systemd 部署文章。

07 / DIAGNOSTICS

配置常见问题：端口、规则、DNS 与回退

按连接链路定位，而不是一次修改全部设置

排错顺序应固定为底层网络、配置加载、本地监听、接入方式、规则命中与远端连接。先在关闭代理后确认设备能访问普通网页，再确认内核没有启动错误，然后用显式代理请求检查监听端口。这个顺序能把本机故障与远端故障分开。只有同一请求在前一个环节已经通过，下一步测试才有解释价值；同时更换 DNS、节点和模式会让成功结果无法复现。

日志先保持信息级别，记录失败请求的时间、目标和错误类型。需要短时调试时再提高详细程度，完成后恢复，避免记录过多访问内容。连接被拒绝常见于目标端口没有监听；连接超时可能涉及网络、防火墙或远端服务；配置解析错误则发生在出站连接之前。错误词只能缩小范围，不能单独证明责任方，仍需结合相同条件下的对照请求。

规则顺序与持久化覆写

规则通常从上向下匹配，先命中的项目决定策略，因此更具体的域名规则应放在宽泛规则之前，兜底规则放在末尾。下面示例假设配置已经存在名为 PROXY 的策略组；若实际名称不同，必须同步替换。直接复制不存在的组名会导致加载失败或规则失效。规则更新后用连接记录验证，不要只看编辑器保存成功。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

节点提供器更新和完整订阅替换不是同一种操作。前者可能只更新节点资源，后者可能连同规则与策略组一起替换。需要保留的自定义内容应使用客户端明确支持的覆写功能，并核对合并是在配置生成前还是生成后执行。组名改变后，旧的选择记录不一定还能对应到新组；遇到更新后部分业务失效，应重新检查当前激活配置与每个相关分组。

DNS 与 TUN 的联动边界

TUN 接管 IP 数据包，域名规则却需要可靠的域名信息。DNS 劫持、内核 DNS、Fake-IP 或其他映射机制共同影响域名如何与连接关联。仅开启虚拟网卡并不能保证每个应用的名称解析都交给内核；应用内置加密 DNS、系统私有 DNS 以及已有缓存会改变解析路径。排查时对照同一域名的解析与连接记录，必要时按应用说明清理缓存后复测。

判断 DNS 泄漏时，要先说明预期由谁解析哪些域名。直连域名采用本地解析可能是明确的分流设计，不能只凭检测页显示本地运营商就认定全部配置错误。相反，代理目标若绕过预期解析路径，也可能带来隐私和兼容问题。不要用一个公共 DNS 地址覆盖全部场景；企业域名、局域网名称和远端服务可能需要不同路径，相关原理见TUN、路由与 DNS 接管说明。

常用判断与恢复操作

完成修复后保留最小可用配置，记录改动项和验证结果，再逐步恢复自动更新、按需连接与扩展规则。需要重新走一遍连接主线时，返回快速上手指南；更换客户端前先查阅选型指南。迁移的目标是明确配置归属与接入边界，而不是让多个客户端同时管理同一套系统网络设置。