Clash 全平台
安装配置指南

区分客户端界面与代理内核

Clash 生态中的客户端通常负责订阅管理、代理组选择、日志展示和系统网络设置，内核负责读取配置、建立连接并执行规则。mihomo 是可独立运行的代理内核，不等同于某个图形客户端。两个客户端即使使用同类内核，也可能采用不同的配置合并方式、权限服务和更新机制。排错时应同时记录客户端名称、内核信息、操作系统架构与接管模式，不能只用“Clash 出错”概括现象。

桌面和移动平台优先从安装包页选择适配的客户端。Windows、macOS、Android 和 iOS 首推 Clash Plus，Linux 可先考虑 Clash Verge Rev。需要兼容旧环境时，再结合系统要求选择其他客户端。Clash for Windows 与 ClashX Meta 属于已停止维护的归档项目，不宜作为新系统长期部署的默认选择。图形界面、配置兼容性和系统权限支持应一起判断，不能仅凭名称相近直接替换。

准备订阅，先确认配置格式

订阅地址是配置获取入口，不是代理节点本身。导入前确认提供方支持目标客户端，或者能输出 Clash／mihomo 可读取的 YAML。仅包含节点链接的文本与包含代理组、规则、DNS 的完整配置不是同一类文件。首次导入后，应看到可选择的配置和代理组；若只有导入成功提示却没有节点，需要检查响应内容、订阅状态及格式，而不是反复切换系统代理。订阅请求失败也可能只是下载入口当前不可达。

订阅链接经常包含访问凭据，不要提交到公开转换页面、问题截图或公开仓库。确需订阅转换时，优先使用能够自行控制的数据处理环境，并确认转换结果是否保留规则和代理组。配置备份也应视作敏感资料，只保存在受控位置。准备修改前先导出一份当前可用配置，记下原代理端口、DNS 设置及代理组选择；恢复时这些信息比一张连接成功截图更有用。

先用系统代理，再判断是否需要 TUN

系统代理通知遵循该设置的应用，把流量发送到本机代理端口；它通常不接管所有应用，也不能直接等同于整机流量隧道。TUN 通过虚拟网络接口配合路由接管流量，覆盖范围仍受路由排除、应用行为和权限影响。首次部署宜先验证普通代理链路，再启用 TUN。若订阅本身不可用，同时调整虚拟网卡和 DNS 只会增加变量，使问题难以归因。

规则模式、全局模式和直连模式决定内核如何选择出口；系统代理和 TUN 决定应用流量如何进入内核，两者属于不同层次。规则模式会按顺序匹配配置中的规则，全局模式适合短时对比出口是否可用，直连模式也不一定关闭虚拟接口。记录每次修改前后的模式，只改变一项再测试。已有公司 VPN、其他代理客户端或网络过滤工具时，先确认是否允许停用，避免竞争路由和本地监听端口。

建立可重复的测试基线

开始前检查系统时间、普通直连网络和剩余磁盘空间，确认能够保存配置并启动应用。准备一个允许访问的 HTTPS 页面和一个实际需要代理的服务，分别记录开启前后的表现。浏览器能打开页面不代表终端、游戏或更新服务也已接管；延迟测试有结果也不代表账户登录和大文件传输正常。每次测试至少观察请求是否进入连接列表、命中了哪条规则、最终使用哪个出口，必要时再查日志中的错误。

选择安装包并建立单客户端环境

先在系统设置的“系统信息”中查看处理器与系统类型，再到Windows 安装包区域选择。首推 Clash Plus，也可按需求考虑 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Clash for Windows 仅作为归档选择。不要把安装包的位数与浏览器位数混为一谈。ARM 设备还需要确认客户端及其内核、服务组件是否支持当前环境，应用能通过模拟启动不等于虚拟网卡组件也能正常工作。

安装前退出其他代理客户端，先关闭它们的系统代理开关，再从托盘菜单退出，避免旧进程保留监听端口。按照安装向导选择目录，首次启动时留意安全软件和系统授权提示。若安装受到阻止，应查看具体拦截原因及文件来源，不要直接关闭全部防护。企业管理设备可能限制网络服务或虚拟适配器安装，此时应先确认组织策略，不应通过修改安全策略绕过限制。

导入订阅并确认本地端口

在配置管理界面选择从 URL 导入，填入订阅地址并执行更新，随后明确切换到这份配置。有的客户端把“添加订阅”和“设为当前配置”分成两步，只完成添加不会让运行内核自动使用新文件。打开代理组，确认至少有一个实际可选的出口，并查看配置载入日志。若提示字段不支持，检查订阅是否为目标内核格式；不要把解析错误误判为防火墙阻止连接。

启用系统代理前，先查看客户端实际监听的 HTTP 或混合代理端口。下例使用混合端口 7890；只有客户端确实监听该端口时才照此执行，否则替换为实际数值。PowerShell 中显式调用 curl.exe，可避免与同名命令别名混淆。显式代理测试只验证该次命令的请求路径，不会自动改变其他程序的网络设置。

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

显式代理可用后再打开系统代理，用浏览器访问测试页面，并在连接列表核对进程、规则和出口。Windows 的用户代理设置、WinHTTP 设置以及应用自带代理并不总是同步，终端服务或后台任务可能完全不读取当前用户的设置。不要为了让一个程序走代理就直接修改整机服务代理；先查看该程序是否提供单独代理参数，或者判断是否确实需要 TUN 接管。

按需启用服务模式与 TUN

TUN 通常需要安装或启动客户端提供的权限服务，授权提示应对应正在使用的客户端。完成授权后，检查服务状态，再开启 TUN，观察虚拟接口与路由是否建立。无需把所有图形界面长期以管理员身份运行来代替正确的服务配置。若启动失败，日志中的权限不足、接口创建失败和路由添加失败应分别处理；先停用其他隧道工具，再按客户端提供的修复入口重新安装服务。

Windows 防火墙允许哪种网络配置文件，会影响本机与局域网连接行为。仅供本机使用时，不必打开“允许局域网连接”，也不应为所有网络放开整个入站范围。需要给其他设备使用时，应单独限制监听地址、认证与防火墙来源。UWP 应用在使用本地代理时可能涉及回环限制，只有确认该应用受此限制后再使用客户端提供的回环豁免功能，避免对全部应用扩大权限。

休眠、退出与迁移后的检查

睡眠唤醒或切换无线网络后，先观察客户端是否仍有内核进程、订阅是否正常载入，再重启接管功能。若退出客户端后无法上网，查看系统设置中的手动代理是否仍指向本机已关闭的端口，关闭残留代理后再测试直连；这与订阅失效不是同一问题。迁移到新客户端前，先在旧客户端关闭系统代理和 TUN，再退出并导入备份，确认新客户端能独立运行后才清理旧配置。更多 Windows 防火墙、端口占用与授权分支见Windows 安装排错文章。

区分 Apple Silicon 与 Intel

在“关于本机”查看芯片信息，再选择对应安装包。Apple Silicon 通常对应 ARM64，Intel 对应 x64；若提供通用包，以发布说明列出的支持范围为准。macOS 下载区首推 Clash Plus，同时列出 Clash Verge Rev 与 FlClash，ClashX Meta 为已停止维护的归档项目。不要仅因旧客户端能启动就认为它适配了新系统的网络扩展、安全机制和权限流程，长期使用应优先选择仍在维护的方案。

打开磁盘映像后，按提示将应用放入应用程序目录，再从该目录启动，避免长期直接在挂载映像中运行。首次启动若被系统阻止，先确认来源与系统提示，再使用系统设置中针对该应用的正常确认流程。不要执行批量移除安全标记或关闭系统保护的命令。涉及网络扩展、后台辅助组件或系统权限时，应核对申请者名称和用途；普通订阅导入本身不需要授予与网络无关的广泛权限。

载入配置与核对活动网络服务

通过客户端的配置入口导入订阅，更新完成后选择为当前配置，并在代理组中选择出口。先运行一次显式代理请求，再启用系统代理。macOS 的代理配置附着于网络服务，无线网络、有线网卡和 USB 网卡可能各自保留不同设置。插入扩展坞或切换网络后，应检查当前正在使用的网络服务，而不是只看上一次修改过的无线网络代理页面。网络服务名称可以被用户重命名，命令示例里的名称不能直接假定存在。

可用下列命令先列出服务，再查询常见无线服务的 HTTP 与 HTTPS 代理。若列表中的服务名称不是 Wi-Fi，使用实际名称替换。查询结果只说明系统记录的代理设置，不证明端口正在监听，也不能证明目标应用遵循这些设置。代理地址应与客户端显示一致；本机用途通常指向回环地址，不应误填订阅服务器地址或节点服务器地址。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

TUN 权限与多个隧道的关系

客户端的 TUN 实现可能依赖辅助服务、虚拟接口或网络扩展，具体授权步骤并不完全相同。按当前客户端提示安装组件，然后在系统设置中完成相关确认。开启后观察日志是否报告接口就绪和路由建立，不要仅依据菜单栏图标判断。若每次启动都重复请求授权，应查看组件是否安装到预期位置、是否被管理策略阻止，以及应用是否仍从临时目录运行。

公司 VPN、其他网络过滤软件和现有隧道可能与 TUN 同时修改默认路由及 DNS。出现部分域名无法访问时，先在允许的条件下停用额外隧道，再测试单客户端环境。不要直接删除陌生的虚拟接口或系统网络配置文件，因为它们可能属于组织管理软件。需要并存时，应明确哪些目的网段由哪一条隧道处理，并检查解析内网域名所需的 DNS 是否仍可达，避免代理接管后失去内部服务访问能力。

终端代理、证书与睡眠恢复

终端程序通常不会仅因菜单栏显示系统代理已开启就自动使用该代理。可以使用命令自身的代理参数，或在当前终端会话设置代理环境变量；测试结束后及时撤销，避免之后关闭客户端仍让命令连接本机空端口。HTTP、HTTPS 与 SOCKS 的参数含义不同，远端解析与本地解析也可能不同。排查时先使用一种明确的代理协议，不要同时叠加环境变量、应用设置与 TUN，造成路径难以判断。

HTTPS 证书错误不应通过关闭证书验证处理。先检查系统时间、目标站点和网络中的证书替换策略，确认客户端配置没有意外启用流量解密功能。普通代理连接不要求为每个网站安装根证书。睡眠唤醒后如果只能访问部分地址，先重新建立网络连接并重启代理接管，再检查 DNS 与路由；若关闭客户端后仍异常，回到活动网络服务中检查残留代理。更新前保留订阅和覆写配置，但不要将旧辅助组件文件手动复制到新安装目录。

安装适合设备架构的客户端

从Android 下载区选择客户端，首推 Clash Plus，也可根据配置兼容性考虑 Clash Meta for Android、FlClash 或 Surfboard。多数较新的设备采用 ARM64，但应以设备实际支持的应用架构为准；系统是六十四位芯片并不总能推断所有软件环境。安装提示与现有应用冲突时，先确认包名、签名来源和已装渠道，保留可恢复的配置后再决定是否卸载，不能期待不同签名的安装包直接覆盖。

通过浏览器或文件管理器安装时，Android 可能要求允许该来源安装应用。只为当前使用的来源按需授权，完成后可恢复限制。若安装失败，应区分系统版本不满足、架构不匹配、空间不足和签名冲突；反复下载同一文件不会改变这些条件。首次启动先熟悉配置列表、代理组、日志与连接开关的位置，不要立即打开开机启动、始终开启 VPN 和分应用名单等全部选项。

导入订阅，完成 VPN 连接授权

在配置页面添加订阅 URL，更新后选中配置，确认存在有效节点和代理组。Android 的剪贴板访问、文件选择和二维码导入由各客户端自行实现，入口名称可能不同。导入链接后如果页面只显示配置名称，应继续检查内容是否实际下载、是否出现解析错误。移动网络下订阅拉取失败而无线网络正常时，应先验证请求路径及提供方限制，不要先修改应用分流列表。

启动连接时，系统通常弹出 VPN 连接请求。批准后客户端使用 Android 的 VPN 服务接收设备流量，这不意味着它与桌面端 TUN 的每个配置项完全相同。系统显示 VPN 图标只能证明服务已建立，实际出口还要看客户端规则和连接记录。普通情况下同一用户空间只能有一个活动 VPN 服务；如果另一个工具同时依赖 VPN 接口，后启动者可能替换先启动者，需要先确定保留哪一个。

分应用名单与后台存活

分应用设置通常存在“仅代理所选应用”与“绕过所选应用”两种语义，修改前必须确认当前模式。把浏览器加入名单，不一定意味着浏览器会绕过代理，也可能意味着只有浏览器被接管。先用一个明确的测试应用建立最小名单，保存后按客户端要求重新连接，再查看连接记录。系统组件、工作资料和多用户环境可能不在同一应用列表中，不能只凭包名相似判断接管范围。

若锁屏后连接中断，先检查电池优化、后台活动限制和客户端通知权限。部分系统的自动启动管理与标准电池设置分开，需要按设备实际界面处理。优先为正在使用的客户端设置必要的后台运行权限，不必给所有相关应用全面放宽限制。客户端持续显示通知也不保证内核仍可用；解锁后应观察连接时间、日志和请求是否继续进入内核，区分进程被回收与网络切换导致的重连。

私人 DNS、热点与网络切换

Android 的私人 DNS、浏览器安全 DNS 与客户端 DNS 可能同时存在，它们不一定沿同一路径解析。发生“连接正常但域名打不开”时，先记录当前私人 DNS 设置，再临时改为系统自动模式作对比，并检查客户端 DNS 日志。不要把关闭某个选项直接当作长期答案，应找到是哪条解析路径不可达或与规则不一致。涉及公司或学校配置的解析策略时，应遵循设备管理要求。

手机热点下的其他设备通常不能直接视为已经进入手机 VPN；是否转发热点流量取决于系统和客户端能力，不能仅凭手机能代理就作结论。无线网络切换到移动网络时，旧连接可能断开，新的 DNS 与路由也会变化，应重新测试新建请求而非只刷新旧页面。若启用了始终开启 VPN 或阻止非 VPN 连接，在客户端未能启动时整机网络可能被系统阻止；停用或卸载前应先检查该系统设置，并保留恢复路径。

安装 Clash Plus 并确认功能入口

iPhone 与 iPad 首推 Clash Plus，可从App Store 的 Clash Plus 页面安装，产品官网为 clashplus.io。也可以从本站iOS 安装入口进入商店。安装前查看商店页面的系统要求和设备兼容性，功能名称及可用设置以实际应用界面为准。不要将桌面端某个客户端的菜单截图当作 iOS 操作指南，两个平台的权限与网络接口并不相同。

首次打开后，先找到配置管理、连接状态、代理策略与日志入口。若系统询问是否允许访问本地网络或发送通知，应按实际用途决定；这些授权与建立 VPN 配置属于不同事项。导入订阅不等于立即接管流量，允许 VPN 配置也不等于订阅可用。按“安装应用、载入配置、批准连接、验证请求”的顺序推进，能够把界面问题、配置问题和系统授权问题分开。

使用客户端支持的订阅格式

复制订阅地址后，在应用提供的添加配置或导入入口粘贴，执行更新并选为当前配置。配置提供方应明确支持当前客户端的导入格式，不能假定所有名为 Clash 的订阅都包含相同能力。如果应用支持从文件导入，应使用系统文件选择器打开可读取的文件，并确认导入的是实际文本配置而非网页或错误响应。分享菜单中能看到应用名称，只表示存在接收入口，不保证内容一定兼容。

导入成功后检查代理组是否有可选出口，配置是否处于启用状态，再进行首次连接。若更新订阅时显示认证失败，先检查链接是否完整、账户是否有效以及提供方是否限制请求；不要删除所有本地设置后重新安装作为第一步。手工修改过的规则可能会在更新后被覆盖，优先使用客户端提供的持久化扩展方式。应用不支持某个 mihomo 字段时，应调整配置输出或换用支持的功能，而不是强行复制桌面 YAML。

批准 VPN 配置并核对实际出口

启动连接时，iOS 可能要求允许添加 VPN 配置，并通过设备认证确认。授权后回到应用查看连接状态，必要时再到系统设置中核对当前 VPN。这里的隧道由应用结合系统网络扩展机制建立，不是把桌面“系统代理”开关搬到手机。界面显示已连接仅代表隧道会话状态，规则是否按预期执行、目标服务是否接受当前出口，仍需要通过实际访问和客户端记录验证。

测试时先打开一个允许访问的 HTTPS 页面，再检查目标应用，记录两者是否都出现在客户端连接列表。若网页正常而单个应用异常，要继续区分应用自己的缓存、账户限制、UDP 需求和独立解析行为。不要看到 VPN 标记就断言每个连接必然经过所选节点；规则可能让局域网、特定域名或其他目标直连。切换代理策略后使用新连接测试，已有长连接可能继续沿原路径传输。

按需连接、局域网与系统服务边界

若应用提供按需连接功能，应先验证手动连接稳定，再添加触发条件。频繁在多个 VPN 应用间切换可能改变当前活动配置，排查时暂时保留一个明确的连接来源。无线网络页面中的手动 HTTP 代理只作用于对应网络及遵循该设置的流量，与应用隧道不是同一层；同时启用时可能形成重复代理或指向已失效的局域网地址，应该分别记录并测试，避免把两套设置混在一起。

访问打印机、家庭存储或其他局域网设备失败时，查看客户端是否提供局域网绕过，以及系统本地网络权限是否允许对应应用访问。iCloud 专用代理等系统功能也可能改变部分请求路径，条件允许时可临时停用作对照，但应记录原设置以便恢复。遇到公司管理设备或按应用 VPN 时，应由管理员确认策略范围，不宜直接删除受管理的描述文件来尝试恢复普通代理。

切换网络、系统升级或设备重启后，重新确认应用是否需要手动连接，订阅是否仍能更新，以及按需连接条件是否符合当前网络。卸载前先断开连接并处理相关按需设置，备份订阅来源和必要规则；应用沙盒中的文件可能随卸载删除。若 VPN 关闭后仍有网络异常，再检查无线网络手动代理、DNS 和设备管理策略，而不是反复创建新的 VPN 配置。证书错误也应从时间、站点和网络证书链入手，不应关闭验证来掩盖问题。

按发行版与架构选择安装方式

Linux 图形桌面可优先选择 Clash Verge Rev，也可使用 FlClash，具体包格式见Linux 下载区。先通过 uname -m确认架构，再判断发行版使用的包管理系统；AMD64 与 ARM64 不能混用，DEB 和 RPM 也不是可直接互换的文件。桌面包是否适合当前系统，还取决于图形会话和运行库。安装器报告依赖缺失时，应从发行版可信软件源解决依赖，不要下载来源不明的单个共享库填补。

安装完成后先以普通桌面用户启动，导入订阅并选择当前配置，再确认代理组和内核日志。图形应用的安装权限不等于运行内核所需的网络权限，不要长期把整个桌面应用作为 root 运行。桌面环境的系统代理通常只影响读取相应设置的应用；终端、容器、包管理器和系统服务可能另有规则。显式代理测试成功而软件更新服务不通时，应检查该服务的代理入口，不应立即判定内核失效。

独立运行 mihomo 的最小检查

服务器或路由器用户可从内核下载区选择对应构建。解压后按实际文件名重命名并赋予执行权限，先运行帮助命令确认可执行文件与平台兼容。将配置放入独立目录，再使用测试参数检查配置；测试过程可能需要读取规则集等资源，网络错误与语法错误应分开看待。下面假定已经把二进制保存为当前目录的 mihomo，配置保存为 config.yaml，命令不会自动安装系统服务。

uname -m
chmod u+x ./mihomo
./mihomo -h
./mihomo -t -f ./config.yaml
./mihomo -f ./config.yaml

下面是只提供本地直连代理的最小基线，可用于检查端口监听与应用代理参数。它没有远程代理节点，不能用于验证远程代理出口。先用这份配置理解本地入口，再载入可信订阅；不要在运行正常的订阅文件末尾直接粘贴重复的顶层键。相同键的重复定义可能被解析器拒绝或覆盖，使实际结果与阅读顺序不一致。

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

TUN、路由与 DNS 的权限要求

Linux 上的 TUN 需要系统提供对应设备及必要网络权限。受限容器、共享主机或最小化系统可能没有可用的 /dev/net/tun，仅修改 YAML 无法补齐宿主环境能力。若日志报告权限不足，先检查运行身份、服务限制和设备可见性；不要直接给全部程序扩大权限。授权策略应仅覆盖需要的内核进程，并在升级后确认二进制替换是否影响既有能力设置。

启用自动路由前，先记录默认路由、远程管理入口和现有防火墙规则。远程服务器上错误的路由接管可能中断 SSH，操作前应准备控制台或其他恢复通道。DNS 可能由 NetworkManager、systemd-resolved 或其他服务管理，必须明确客户端 DNS 监听在哪个端口、系统请求如何送达该入口。只写了内核 DNS 配置却没有改变系统解析路径，不代表所有应用已使用它；反过来，也不要覆盖受管理的解析文件后期待长期生效。

服务化、容器与局域网边界

前台运行验证完成后，再根据发行版机制建立后台服务，明确可执行文件的绝对路径、配置路径、工作目录和运行用户。相对路径在服务中往往与交互终端不同，规则集和缓存文件也需要适当写入权限。启动失败时查看服务日志，而不是反复重启整个系统。停止服务后应确认自动添加的路由和 DNS 设置是否恢复，尤其要验证机器自身仍能进行域名解析和远程管理。

容器内的回环地址指向容器自身，不是宿主机；把宿主机代理填为 127.0.0.1通常不能让桥接容器访问它。需要共享代理时，应设计明确的网络入口、绑定地址与防火墙范围，并考虑认证，不能直接把监听改为所有接口后暴露公网。路由器部署还涉及网关、DNS 下发和透明代理路径，不宜照搬桌面配置。相关拓扑与边界可参阅OpenWrt 旁路由部署概览，普通桌面用户不必为了使用代理而部署旁路由。

先分层，再修改

排错按“配置载入、内核监听、流量接管、规则匹配、出口连接、目标响应”的顺序进行。配置解析失败时，系统代理和 TUN 的开关不能修复 YAML；内核没有监听时，浏览器代理设置正确也无法连接；请求未进入内核时，更换节点通常不会产生效果。先找最早失败的一层，保留日志中的具体错误、发生时间与操作步骤，再修改一个变量。向他人求助前隐藏订阅凭据、节点认证和访问记录中的敏感部分。

导入提示成功但不能使用时，确认当前生效的是哪份配置，以及客户端是否在启动时合并覆写。YAML 缩进使用空格，不要用制表符；列表层级、冒号后的空格和字符串引号都可能影响解析。特别注意规则引用的代理组名称必须存在且完全一致。订阅提供方更新了组名后，旧的自定义规则可能仍指向已删除的组；这类问题需要修正规则目标，不是改动系统 DNS。

规则按顺序匹配，兜底放在最后

mihomo 的常规规则按自上而下首次命中处理。域名规则适合按服务分流，IP 网段规则适合明确的网络范围，MATCH用于接住前面未匹配的连接。下例只使用内置直连与拒绝策略，演示规则顺序而非完整订阅。no-resolve用于避免为了该 IP 规则主动发起域名解析，不表示关闭全部 DNS。已有订阅应通过客户端扩展入口插入规则，并确认插入位置位于订阅兜底规则之前。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,invalid,REJECT
  - MATCH,DIRECT

修改后以新连接验证，检查实际命中的规则，而不是只看规则文件中有无目标域名。应用可能连接多个域名、使用缓存地址或复用已有连接，因此单个页面加载会出现多条不同策略记录。需要代理时，应把规则目标改为配置中确实存在的代理组；不能只粘贴一个任意组名。更详细的类型、排序和覆盖关系见自定义规则语法与优先级。

DNS 设置必须与请求路径一起检查

DNS 决定域名如何转换为地址，规则与路由决定后续连接从哪里发送。Fake-IP 模式使用合成地址维持域名映射，Redir-Host 则通常向应用返回真实解析结果，两者不是速度优劣的简单比较。开启 Fake-IP 后若个别局域网服务或设备发现异常，应先检查例外域名和实际接管路径，而不是随意扩大例外范围。DNS 泄漏判断也应看具体请求送往哪里，不能仅凭检测页面显示的解析服务名称下结论。

浏览器自带加密 DNS、Android 私人 DNS、系统解析器和内核解析器可能并行工作。排查时先选择一条明确路径测试，再逐项恢复其他设置。加密解析地址本身还需要可达的连接路径，错误的代理依赖可能形成启动循环：连接节点需要解析域名，而解析请求又被送往尚未建立的节点。规则依赖 GeoIP 或 GeoSite 时，还要检查数据库是否下载成功、字段是否与当前内核匹配，相关方法见GeoIP 与 GeoSite 更新说明。

把延迟、带宽和连接稳定性分开

节点延迟测试主要反映指定测试地址在特定条件下的请求耗时，并非实际下载带宽。低延迟节点仍可能因拥塞、出口限制或目标服务策略表现不佳。测试时记录目标、时段、网络类型和出口，先比较同一条件下的结果；不要连续切换多个设置后只保留一个结论。涉及握手与 URL Test 的细节可读延迟测试与实际网速的区别，更多独立问题可在常见问题中查阅。

恢复顺序应与部署相反：先关闭 TUN 或应用隧道，再关闭系统代理，最后退出内核，确认系统解析与默认路由回到预期状态。保留最后一份可用配置和修改记录，下一次出现问题时先回到这个基线。若只有单一目标服务异常，而其他代理请求与直连都正常，应检查目标服务的账户、证书、地域和协议要求，不要用重装客户端替代定位。首次部署主线仍可回到快速上手教程逐步复核。