Clash 全平台
安装配置指南

一、Clash 安装前的通用准备

先区分客户端、内核与订阅

客户端负责提供界面、保存配置、启动内核以及申请系统权限；内核负责解析规则、建立代理连接和处理 DNS。订阅则是配置的交付方式，通常包含节点、策略组与规则，也可能只包含代理列表。三者不是同一个东西。安装客户端不会自动获得可用代理，导入一个链接也不代表其中的全部字段都被当前内核支持。

新安装优先从安装包页面选择 Clash Plus，再按实际需求比较其他客户端。Clash for Windows 已停止维护，适合已有环境的归档查阅，不宜因为熟悉旧教程就忽略维护状态。不同客户端的按钮名称可能不同，本手册按“配置管理、策略选择、流量接管”说明操作；出现 Profiles、Proxies 等英文名称时，应结合当前界面对应查找。

确认设备架构与配置来源

下载前先查看操作系统、处理器架构和软件要求。桌面设备不能只凭品牌判断架构，手机也不能只凭 Android 版本判断安装包类型。安装包页面提供的平台与架构入口应与设备信息对应。升级已有客户端之前，记录当前客户端名称、配置来源和接管方式，并导出需要保留的设置，避免把迁移问题误认为网络问题。

订阅链接通常具有访问凭据性质，应从自己的服务账户取得。不要把完整链接发到公开评论、截图或日志分享页面。导入前确认服务说明提供的是 Clash 或目标客户端兼容格式，而不是普通网页地址、登录页或另一种软件专用链接。服务过期、套餐流量用尽和链接被重置，也会造成导入失败或节点连接失败，重装客户端不能解决这些情况。

了解三种流量入口的边界

第一次配置建议先使用较简单的入口。桌面端可先验证本地代理端口与系统代理，确有应用不遵循代理设置时再考虑 TUN；移动端通常通过系统 VPN 接口接管流量。这里的 VPN 标志说明存在本地网络接管，并不表示客户端自动提供远端服务。TUN 也不是代理模式，开启它以后仍需由 Rule、Global 或 Direct 决定流量策略。

按固定顺序完成首次验证

推荐顺序是安装并启动客户端、导入配置、选中配置、检查策略组、启用一种接管方式，最后用实际应用验证。每一步都应留一个可观察结果：配置有名称、策略组能选择、内核运行正常、请求能在连接记录中找到。只看托盘图标或系统 VPN 标志不足以判断远端连接已经成功，也不要同时开启多个客户端来“提高成功率”。

验证时先访问平常可以直接打开的站点，确认基础网络正常，再访问需要代理的目标。随后查看请求命中了哪条规则、使用了哪个策略。策略选择成功不等于域名解析正常，浏览器可用也不等于命令行已经采用代理。分开验证这些环节，能把问题限制在一个层次，避免每次失败都把 DNS、端口和节点一起改掉。

退出客户端前先关闭它设置的系统代理或网络接管，尤其是在准备切换到另一款客户端时。保存一份正常状态下的端口、策略和接管方式记录，比保存整屏节点截图更有排错价值。后续章节沿用这条验证链，只补充各平台的安装、权限与后台运行差异。

二、Windows 安装、系统代理与 TUN

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

在Windows 安装包中优先选择 Clash Plus；其他可选项包括 Clash Verge Rev、FlClash 和 Clash Nyanpasu。Clash for Windows 作为已停止维护的归档客户端保留。先到系统“设置 → 系统 → 系统信息”确认系统类型，再按下载页列出的架构选择，不要把 x64 与 ARM64 当成可以任意互换的标签。

安装型程序按向导完成安装；压缩包形式应先解压到固定目录，再启动主程序，不要直接从压缩软件的临时目录运行。第一次启动若出现安全提示，应先确认文件来源和发布者信息，不能以关闭全部系统防护作为处理步骤。普通界面运行不必始终使用管理员身份；服务安装、虚拟网卡与路由修改则可能另行要求授权。

导入订阅并确认当前配置

打开配置管理页，粘贴服务提供的订阅地址并执行导入；在 Clash for Windows 中对应 Profiles 的下载入口。导入完成后选中该配置，等待内核加载。若只出现配置名称却没有策略组，先看解析日志，确认返回内容不是登录页面，也不是只含代理列表、却被当作完整配置使用的文件。不要连续点击导入来替代错误检查。

进入代理或策略组页面，日常通常选择规则模式，再在手动选择组里指定可用策略。自动策略组的结果取决于配置中的测试地址和参数，不代表每个实际网站都能访问。打开一个目标应用后，回到连接记录查看命中规则与出口；如果没有任何新记录，应先查应用是否进入本地代理，而不是马上更换节点。

先用系统代理验证本地端口

确认客户端显示的 HTTP 或 mixed 监听端口，再开启 System Proxy。常见示例中的 7890 不是所有客户端的固定值，以当前设置为准。Windows 系统代理、浏览器独立代理扩展和应用自身代理可能同时存在，测试时尽量只保留一个明确入口。启用局域网访问并不是本机上网的必要条件，不需要共享时保持关闭。

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

上面的命令仅用于本地监听端口确为 7890 且支持 HTTP 代理的情况。它显式指定代理，可绕开应用是否读取系统设置的差异。若显示无法连接本地端口，检查内核是否运行、监听地址是否正确、端口是否被占用；若已连接本地代理但远端失败，再查策略、服务状态与 DNS。终端是否自动采用系统代理，取决于具体工具。

需要 TUN 时再检查服务与权限

当目标应用不遵循系统代理，或需要接管特定 UDP 流量时，再按客户端说明安装服务并启用 TUN。旧版 Clash for Windows 的 Service Mode 与 TUN Mode 需要分别检查，其他客户端也可能采用自己的服务机制。授权后确认虚拟接口、路由和 DNS 设置已生效。开关显示开启只是界面状态，不能代替实际连接验证。

企业 VPN、虚拟机网络、容器网络和其他代理都可能改动路由。出现开启 TUN 后局域网设备不可达的情况，应先关闭 TUN 对照测试，再检查私有网段绕过设置与现有路由。不要直接删除不认识的虚拟网卡。休眠唤醒后失联时，可先重启内核并重新启用接管；若问题反复发生，再对照日志检查接口变化。

处理退出残留与旧客户端迁移

客户端异常退出后，如果浏览器提示代理服务器无法连接，打开 Windows 的网络和 Internet 代理设置，检查是否仍指向已停止监听的本地端口。先恢复系统网络，再重新启动客户端。不要把“代理设置自动检测”“脚本地址”和“手动代理”全部随意切换；记录原值，尤其是单位管理设备，避免覆盖组织下发的设置。

从 Clash for Windows 迁移时，优先重新导入原始订阅，再逐项迁移规则与覆写，不建议直接覆盖新客户端的数据目录。配置内核差异可能让旧字段失效，TUN 参数也可能变化。先让新客户端在默认接管方式下工作，再恢复开机启动等便利设置。长期保留两个客户端时，确保同一时刻只有一个负责系统代理或 TUN。

三、macOS 安装、授权与网络扩展

按芯片类型选择客户端

打开苹果菜单中的“关于本机”，确认设备使用 Apple 芯片还是 Intel 处理器，再进入macOS 安装包选择对应构建。首推 Clash Plus，另有 Clash Verge Rev、FlClash 可选；ClashX Meta 为已停止维护的归档客户端。不要因为旧文章使用某个界面，就将其安装步骤原封不动套到所有客户端上。

如果下载内容是磁盘映像，打开后按提示把应用放入“应用程序”目录，再从该目录启动。直接在映像或临时下载目录运行，可能影响更新、辅助组件路径和权限记录。首次启动出现系统拦截时，先确认下载来源与应用身份，然后查看“系统设置 → 隐私与安全性”的相关提示，不要先执行递归修改权限或关闭系统安全机制的命令。

区分代理授权、辅助服务与网络扩展

macOS 客户端可能请求修改网络代理、安装辅助服务或添加网络扩展，这些是不同能力，不一定每款客户端都会全部使用。只启用系统代理时，与运行 TUN 所需的权限可能不同。授权弹窗应在刚执行相关操作后出现，并与应用名称对应；如果弹窗来历不明，先取消，再回到客户端操作一次确认触发来源。

网络扩展的批准位置会随系统版本和客户端实现变化，应按应用提示进入系统设置查看。批准后有的服务需要重新连接，有的需要重启应用。不要把“扩展已允许”和“代理已连接”混为一谈。受管理的电脑可能由配置描述文件限制网络扩展，此时需要遵循设备管理策略，而不是不断重复安装或尝试绕过权限。

导入配置并验证策略选择

在配置页添加订阅链接，导入后明确选中要使用的配置。若客户端同时支持远程订阅与本地文件，先弄清当前编辑的是哪一份，避免改了本地文件却仍运行另一份远程配置。导入完成后查看策略组是否出现、规则模式是否选中，再选择可用策略。订阅更新失败时保留已有配置，有助于区分原连接问题与更新请求问题。

验证时先使用浏览器打开目标，再检查连接记录。部分应用拥有独立网络设置，浏览器扩展也可能覆盖系统代理。若浏览器能访问但终端不能，先为命令显式指定代理测试；若只有某个应用失败，检查它自己的代理、证书或联网权限。不要因为一款应用失败，就立即修改整个系统的 DNS 或所有网络服务顺序。

系统代理与 TUN 分开测试

开启系统代理后，可到当前网络服务的代理设置中核对目标地址与端口。切换 Wi-Fi、有线网卡或扩展坞网络后，活动网络服务可能改变，原来生效的代理设置未必覆盖新服务。应重新确认当前网络，而不是只看客户端开关。系统代理对遵循该设置的应用生效，无法保证接管每个进程和每种协议。

启用 TUN 前先关闭其他负责路由接管的工具，并确认客户端的辅助服务或扩展正常运行。TUN 失效时，先对照关闭后的网络状态，再看 DNS 与路由日志。若远程桌面、局域网打印或网络存储受影响，检查局域网绕过和私有地址规则；不要为了让一个站点打开而把所有本地网络都强制转发到远端代理。

处理应用异常与网络切换

“应用已损坏”是系统提示，不等于可以直接判断文件真的损坏或一定安全。先检查是否选错架构、下载是否完成、应用是否来自确认的来源，再查开发者发布说明。涉及隔离属性或系统扩展的操作，应先理解作用范围。更多权限流程见macOS 网络扩展与钥匙串处理，不要把网络上的一行命令当作所有提示的统一答案。

升级或迁移前先导出配置与自定义覆写。更换客户端后，应在旧客户端关闭系统代理、退出接管，再启用新的客户端。合盖唤醒、切换热点或接入公司网络后，先检查基础网络与门户认证是否完成；必要时暂时断开代理完成认证，再重新连接。这样可以避免把网络入口尚未放行误判为订阅节点故障。

四、Android 安装、VPN 授权与后台运行

选择安装包与客户端

进入Android 安装包，优先选择 Clash Plus，其他选项包括 Clash Meta for Android、FlClash 和 Surfboard。设备架构与可安装的应用 ABI 有关，不能只凭手机外观或处理器宣传名称判断。若安装包不兼容，先查看设备信息与下载页提供的构建类型，不要反复下载同一个包，也不要把安装失败直接解释成网络被阻断。

通过浏览器或文件管理器安装时，系统可能要求为当前来源开启安装授权。只对实际使用的来源授权，完成后可按需要关闭。安装器提示应用冲突时，检查是否已有同包名但不同签名的应用。卸载旧应用可能同时删除配置与本地设置，因此先备份；不要在不了解原因时直接清除数据来解决所有安装提示。

先确认订阅格式再导入

打开配置管理入口，选择从链接导入，粘贴自己的订阅并保存。配置下载完成后需要选中并启用，不能仅停留在下载列表。Clash Meta for Android、FlClash 与 Surfboard 的配置体系并不完全相同，尤其不能把 Clash YAML 默认当作 Surfboard 配置导入；使用 Surfboard 时应从服务提供方取得兼容格式，再按该客户端流程操作。

如果导入报错，先核对链接是否完整、有无复制进多余空格，以及返回内容是否为预期配置。移动网络与 Wi-Fi 下的结果不同，可能与当前网络的 DNS、门户认证或连接限制有关。先保留错误提示，再尝试另一张可信网络对照。不要把订阅链接粘贴到公共在线转换页面排错，链接泄露后应在服务账户重置。

理解 VpnService 授权与系统状态

首次启动接管时，Android 会弹出 VPN 连接请求。Clash 类客户端常通过 VpnService 建立本地虚拟接口，把流量交给内核处理。批准后状态栏出现 VPN 标志，表示接口已经建立，不等于远端代理可用。实际是否连接成功，还要查看配置是否加载、策略是否选对，以及目标请求能否得到响应。

普通个人配置下通常只能有一个活动 VPN 服务。公司 VPN、另一款代理或某些使用 VPN 接口的过滤工具，可能与当前客户端互相替换。遇到启动后立刻停止，先检查系统中是否有其他 VPN 正在连接。不要同时开几个应用反复争用接口；需要企业网络访问时，应先了解单位 VPN 的使用要求，再决定采用哪一套接管方式。

设置后台运行，但保留必要限制

若熄屏一段时间后断开，进入系统应用设置，检查电池优化、后台运行和自启动权限。不同厂商的入口名称不同，应按应用电池管理页面查找，而不是机械照搬另一款手机的菜单路径。可为正在使用的客户端放宽后台限制；同时确认系统流量节省模式没有禁止它在后台联网，避免只有亮屏时恢复连接。

前台服务通知有助于维持接管状态，不建议仅为了隐藏状态提示而停用相关服务。最近任务锁定只是部分系统的辅助措施，不能替代后台权限。若仍然断连，记录发生在熄屏、切换网络还是系统清理之后，再查日志。更多设置思路见Android VpnService 与省电白名单指南，调整应针对症状，而不是把所有系统限制一起关闭。

分应用代理与网络切换

客户端若支持按应用接管，应先读清“仅所选应用”和“绕过所选应用”的含义，两者方向相反。修改后可能需要重连才能刷新接口配置。对于无法联网的单个应用，先确认它是否被排除，再检查规则和 DNS。系统下载组件、浏览器与应用内网页可能使用不同进程，不能仅凭应用图标判断全部请求都走了同一条路径。

从 Wi-Fi 切到移动数据后，已有连接可能需要重建。先等待网络稳定，再重新连接客户端，观察新请求是否恢复。进入酒店、机场等需要网页认证的网络时，应先完成门户登录。若启用了系统“始终开启 VPN”以及阻止未通过 VPN 的连接，断开客户端期间可能连认证页也打不开，调整前要理解该开关对整个设备的影响。

移动端不要照搬桌面端的 System Proxy 开关教程。Android 的主要接管路径、权限提示和后台生命周期与桌面不同。完成配置后分别测试前台访问、熄屏后恢复以及网络切换，确认都能正常使用，再逐项添加按应用规则等定制设置，便于发现是哪一项改变了行为。

五、iOS 安装、订阅与隧道连接

从商店安装 Clash Plus

iPhone 与 iPad 优先选择 Clash Plus。可先查看iOS 客户端入口，再前往 App Store 的 Clash Plus 页面，开发者官网为 clashplus.io。商店页面中的系统要求与应用说明应先阅读，安装完成后再进行配置，不要仅凭搜索结果中相似的名称判断应用身份。

iOS 会管理应用的网络扩展与 VPN 配置，桌面系统中的服务安装、端口接管步骤不能直接搬到手机上。使用本手册时，把流程理解为“导入兼容配置、选择策略、批准系统隧道、验证实际请求”。客户端界面可能随更新调整，优先按当前页面的功能名称操作，不必寻找旧截图中完全相同的位置和图标。

导入订阅并保护账户信息

从服务账户复制兼容订阅，回到应用的配置或订阅管理入口粘贴并保存。某些网页会尝试唤起应用导入，跳转后仍应核对来源、配置名称与内容，不要因为应用被打开就认为导入已经完成。若需要从剪贴板读取，系统可能给出提示；确认复制的是自己的链接后再允许，避免误把其他文本当作配置保存。

订阅地址与网页登录地址通常不同，复制一个需要先登录才能查看的网页，往往只会下载到页面内容。导入失败时应先确认格式与账户状态，再尝试刷新。完整链接可能包含访问凭据，不应放入公开备忘录或共享截图。向他人求助时可以描述错误类型与发生步骤，但要遮盖地址中的个人标识和凭据部分。

批准 VPN 配置并开始连接

第一次启动连接，系统可能询问是否允许添加 VPN 配置，并要求设备认证。这是在系统中登记网络接管配置，不是让用户把设备密码交给订阅服务。批准后返回应用，检查当前配置与策略组，再启动连接。若设备由组织管理、装有受限描述文件或已经运行其他 VPN，连接行为可能受到系统策略影响。

状态栏或控制中心的 VPN 标志说明系统隧道处于活动状态，但不能单独证明规则、DNS 和远端服务都正常。验证应包含实际打开目标、查看连接记录和核对策略。若连接持续转圈，先看应用显示的错误，再到系统 VPN 设置确认是否有冲突配置；不要连续添加多个同用途条目，让后续判断变得更困难。

理解规则模式与移动端接管

日常可先用规则模式，让配置中的规则决定哪些请求直连、哪些使用代理。全局模式通常将进入内核的请求交给全局策略，但并不等于能覆盖系统所有行为，也不会修复失效节点。直连模式则适合做对照测试。三种模式的区别可参考规则、全局与直连模式说明，切换后观察新连接，不要只刷新一个仍在复用旧连接的页面。

iOS 的网络扩展受系统生命周期与权限约束，不应期待它与桌面端后台进程完全一致。应用退出界面与隧道停止也不是同一个概念，是否保持连接应以系统和客户端状态为准。低电量、网络变化或扩展异常时，先在应用内查看连接并重新建立隧道，避免把恢复操作变成反复强制退出应用。

处理热点、门户与单个应用异常

从 Wi-Fi 切换到蜂窝网络时，已有连接可能断开重建。先确认蜂窝数据可用且客户端拥有所需联网权限，再重新连接。个人热点下其他设备的流量是否经过手机隧道，取决于系统与应用能力，不能因为手机本身可用就认定热点设备也已被代理。热点设备应独立验证，必要时在设备自身配置客户端。

遇到需要网页登录的公共网络，先完成入口认证，再恢复隧道。若只有某个应用打不开，检查它的联网权限、账户状态与命中规则，不能只靠换模式判断。系统隐私网络功能、已有的加密 DNS 配置和组织管理设置也可能改变请求路径，应一次只调整一项并记录原值，避免失去能够恢复的基线。

配置迁移到另一台设备时，先确认新设备的服务授权与系统要求，重新导入订阅比复制不明来源的整套应用数据更容易核对。导入后再检查策略选择与按需连接设置，不要假设这些本地偏好会随订阅一起迁移；订阅负责交付配置，系统权限仍需要在每台设备分别批准。

六、Linux 安装、桌面代理与服务运行

先区分桌面使用与服务器部署

桌面用户可在Linux 安装包中选择 Clash Verge Rev 或 FlClash，按发行版与页面提供的格式安装。服务器、路由器和需要自行管理进程的用户，可查看Mihomo 内核区。图形客户端已经负责配置路径、进程启动和部分授权，直接内核部署则需要自己处理这些内容，二者的排错入口不同。

先用 uname -m 查看机器架构，再核对发行版、包格式与依赖要求。文件扩展名相同不代表适用于所有发行版，不能把 RPM 包当作 Debian 包安装。桌面图形应用应尽量以普通用户运行，需要网络管理能力时使用客户端明确提供的授权机制，不建议为了省事把整套桌面界面一直放在 root 身份下运行。

通过包管理器安装并观察输出

安装前进入保存安装包的目录，核对文件名称与架构，然后使用当前发行版支持的包管理工具。遇到依赖提示时先阅读输出，不要随意下载来历不明的库文件覆盖系统目录。安装成功却打不开窗口，还可能与显示会话、图形依赖或运行环境有关，不能据此判断订阅失效。先从终端启动应用，保留实际错误再处理。

uname -m
cat /etc/os-release
ss -lntp

这些命令分别帮助确认架构、发行版信息和 TCP 监听情况，不会自动配置代理。ss 在普通用户权限下可能只显示部分进程信息，但仍可核对本地端口是否监听。分享输出前遮盖个人路径、主机名与敏感地址。若端口冲突，先找到占用它的服务，再决定修改当前客户端端口，不能直接终止不认识的系统进程。

导入配置与桌面代理设置

图形客户端中先添加兼容订阅，选中配置并检查策略组，再开启需要的接管方式。Linux 各桌面环境的系统代理机制不完全一致，有些应用读取桌面设置，有些只读取环境变量，有些有自己的独立代理入口。因此，桌面代理开关不能保证所有终端命令、包管理器和后台服务都自动采用同一设置。

curl --proxy http://127.0.0.1:7890 https://example.com/
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

仅在本地端口为 7890 且支持 HTTP 代理时使用这组示例。环境变量只影响当前 shell 后续启动、且支持这些变量的进程，不会追溯修改已运行的应用。https_proxy 中的代理地址仍可使用 HTTP 协议，因为它描述的是到代理的连接方式。测试结束可用 unset http_proxy https_proxy 清除当前会话设置。

TUN 关注权限、路由与 DNS 管理器

Linux 的 TUN 通常涉及虚拟接口、路由表和相应网络权限。图形客户端可能提供服务模式，直接运行内核则要按部署环境配置权限；不要把其他系统的参数完整照搬过来。启用后先确认接口与路由是否生成，再检查 DNS 请求走向。容器、网络命名空间和宿主机是不同范围，在容器内启动并不意味着宿主机流量已经被接管。

NetworkManager、systemd-resolved 或发行版自带工具可能共同管理 DNS。直接覆写 /etc/resolv.conf 往往会被网络切换重建，还可能破坏原有链接关系。应先确认文件由谁管理，再通过对应机制调整。SSH 远程操作时尤其谨慎：修改默认路由或防火墙前，应保留现有会话并准备独立恢复渠道，避免把管理连接一起切断。

直接运行内核时明确配置目录

使用 Mihomo 时，配置文件、规则数据和运行目录应有清晰归属。可以先把内核放入可执行路径，将自己的配置保存到固定目录，再在前台检查。下面使用用户配置目录的写法，前提是已经建立目录并准备好有效的 config.yaml。测试成功后才考虑服务化，避免后台重启把真正的解析错误隐藏起来。

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

长期运行时，可用系统服务管理进程，但必须明确运行用户、工作目录、配置路径与所需权限。服务启动成功只说明进程被拉起，还要看内核日志是否完成配置加载。修改配置后先检查语法，再按实际部署方式重载。停止服务后也要恢复由它设置的路由或代理，不能只删除可执行文件就认为网络状态已经还原。

七、配置文件、DNS 与连接问题排查

从最小配置理解字段作用

配置出错时，先区分语法错误与语义不兼容。YAML 依赖缩进，通常使用空格而不是制表符；同级字段缩进应一致，列表项前有连字符。解析通过也不代表每个功能都受当前内核支持。以下片段用于理解本地入口、模式与最终规则，它只会直连，不包含远端代理，不能把它当作可用节点配置。

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

mixed-port 提供兼容 HTTP 与 SOCKS 的本地混合入口；allow-lan 控制是否允许局域网访问相关监听，实际可达性还受绑定地址与防火墙影响；mode 决定策略处理方式。规则按顺序匹配，MATCH,DIRECT 是最终兜底直连。加入自定义规则时应放在兜底规则之前，否则后续规则没有机会处理已经匹配的请求。

订阅更新与 Mixin 覆写分开管理

远程订阅最好保留为上游来源，自定义字段通过客户端支持的 Mixin、合并或覆写功能管理。不同客户端对数组是追加、替换还是特殊合并，行为并不统一，不能凭名称猜测。尤其是规则列表与策略组，错误合并可能让组名不存在、兜底位置变化或整组定义被覆盖。修改后要检查最终生效配置，而不仅是编辑框内容。

若更新后才出现故障，先比较更新前后使用的配置和覆写，不要立即清空所有数据。订阅本身可能改变策略组名称，自定义规则仍引用旧名称就会报错。自动策略组参数也需要结合用途，见url-test、fallback 与 load-balance 对比。恢复时先停用最近增加的覆写，再逐项确认，便于找到最小故障范围。

DNS 先看解析路径再改服务器

DNS 错误可能发生在系统、应用、内核或远端几个位置。域名打不开但已知 IP 可连接，只能作为线索，不能直接证明一定是某个 DNS 服务器失效。先查看日志中是解析失败、本地入口失败还是远端超时，再确认 DNS 请求是否进入内核。应用自带的加密 DNS 可能使用独立路径，TUN 的 DNS 劫持设置也不等于自动接管所有加密解析。

fake-ip 使用合成地址让内核保留域名关联，不是远端网站的真实地址；redir-host 则采用不同的映射方式，兼容性表现也不同。遇到局域网域名或特定应用异常时，应按症状检查过滤与解析设置，不能只不断更换公共 DNS。nameserver、fallback 与过滤规则的配合见Clash DNS 配置详解，修改前先确认当前内核支持对应字段。

按请求走向建立排错顺序

先确认基础网络，再查本地入口、配置加载、规则、远端连接与 DNS。每次只改变一个变量，并用同一个目标重复测试。浏览器会缓存解析结果并复用连接，模式切换后应发起新连接；否则看到的可能仍是旧路径。日志级别临时提高后应及时恢复，分享时删去订阅、凭据和能够识别个人访问的信息。

常见配置问题的直接处理

需要重新建立一条清晰的验证链时，返回快速上手教程按顺序操作；需要换客户端时，先在安装包页面确认平台和维护状态。配置可以逐步调整，恢复路径应始终明确：保留原始订阅、记录本地修改、退出旧接管，再启用新设置。