Clash 首次安装设置清单：跨平台初始化步骤与常见误区

首次配置 Clash 时，真正需要确认的项目并不多：客户端与系统架构匹配、配置能够正常加载、策略组已经选定、代理入口处于启用状态。问题通常出在操作顺序。比如订阅尚未更新就打开系统代理，或者在基础连接未验证前同时修改 DNS、规则和 TUN，最后很难判断是哪一项造成异常。

Clash 是一类规则代理核心及其客户端生态的常用称呼。不同桌面端和移动端的界面名称可能不同，底层核心也可能是 Clash Meta（现常称 mihomo），但初始化思路基本一致。下面的清单不依赖某个特定界面，适合 Windows、macOS、Android、iOS 与 Linux 上常见的兼容客户端。

一、安装前确认客户端、系统与配置来源

下载之前先确认设备平台与处理器架构。Windows 常见为 x64，部分新设备使用 ARM64；macOS 需要区分 Apple 芯片与 Intel 芯片；Linux 除架构外，还要留意安装包格式以及桌面环境支持情况。架构不匹配时，程序可能无法启动，也可能通过兼容层运行但出现服务安装、托盘显示或性能问题。

安装前清单

确认操作系统版本：查看客户端发布说明中的最低系统要求，较旧系统可能缺少运行组件或系统 API。
确认处理器架构：不要仅凭设备品牌判断，直接在系统信息页面查看 x64、ARM64、Apple Silicon 或其他架构标记。
保留订阅入口：准备服务提供方给出的订阅地址、配置文件或导入方式。订阅地址通常具有访问凭据属性，不应发送到公开聊天、截图或日志中。
记录现有网络设置：如果系统此前配置过手动代理、VPN、网络过滤器或企业安全软件，先记下状态，方便连接异常时逐项恢复。
避免同时运行同类工具：多个程序争用系统代理、虚拟网卡、DNS 或本地端口，会让首次验证结果失去参考价值。

如果设备上曾安装其他代理客户端，退出程序并不一定等于代理设置已经复原。Windows 和 macOS 都可能保留手动代理地址，移动系统也可能继续显示 VPN 配置。安装 Clash 客户端前，可以先检查系统网络设置，确认没有遗留的代理端口指向已经停止运行的程序。

二、按平台完成安装与必要权限授权

客户端能打开只代表图形界面已经启动，不代表系统流量已经交给代理核心。首次运行时，应先观察核心状态、配置目录和权限提示，再决定是否安装系统服务或启用虚拟网卡。管理员权限不是所有操作的前提，但服务模式、TUN 驱动和部分系统级设置通常需要额外授权。

Windows：先确认核心启动，再处理服务模式

Windows 安装后先正常启动客户端，查看核心是否成功运行，以及本地代理端口是否已经监听。若客户端提供“服务模式”“管理员服务”或类似功能，它通常用于帮助普通权限下的界面管理 TUN、路由或系统设置。首次测试系统代理时不一定需要立即安装服务；等基础代理能够访问后，再按客户端提示安装更容易定位问题。

如果安装程序被系统安全提示拦截，应核对下载来源和发布者信息，不要通过关闭系统防护来绕过。公司或学校管理的设备可能限制驱动、服务和代理修改，这类权限应由设备管理员处理。

macOS：关注芯片架构与网络扩展权限

macOS 上应选择与芯片匹配的构建。首次打开时，系统可能要求确认应用来源；启用 TUN 或增强模式时，还可能出现管理员密码、网络扩展或 VPN 配置授权。授权后如果功能没有立即生效，可先完全退出客户端并重新打开，再检查系统设置中的 VPN 与过滤器项目。

不要在首次启动阶段同时迁移旧客户端的全部规则、脚本和覆写设置。先导入原始订阅并完成连通测试，能够区分是系统权限问题，还是旧配置与新核心不兼容。

Android 与 iOS：理解系统 VPN 授权

移动端通常通过系统 VPN 接口接管流量。第一次点击连接时，系统会弹出 VPN 配置授权；只有用户确认后，状态栏中的 VPN 标记和客户端连接状态才有实际意义。Android 的电池优化可能在后台停止客户端，若出现锁屏一段时间后断流，可为所用客户端调整后台运行策略。不同厂商系统的入口名称不同，不必在首次安装时改动所有省电选项，先观察是否确实发生后台中断。

iOS 上的客户端需要遵循系统提供的网络扩展机制。订阅能够导入但 VPN 无法建立时，应查看系统是否已经存在失效的 VPN 配置，或设备管理策略是否限制新增配置。

Linux：检查执行权限、桌面会话与代理范围

Linux 客户端可能以发行版软件包、压缩包或 AppImage 等形式提供。安装后要区分“程序可以启动”和“桌面环境已经采用代理设置”这两件事。不同桌面环境对系统代理的支持不同，命令行程序也未必读取桌面代理。首次测试可先使用客户端内置连接页面或明确支持系统代理的浏览器，不要仅凭终端中的某个命令判断整个客户端失效。

三、导入订阅并确认配置确实加载

订阅是远程配置入口，通常包含代理节点、策略组和规则。把地址粘贴进客户端后，还需要执行下载或更新动作，并将下载结果设为当前配置。只保存订阅地址但没有激活配置，是新安装中最常见的遗漏之一。

订阅导入后的四项检查

更新时间：确认订阅刚刚成功更新，而不是停留在空白状态或旧缓存。
配置状态：确认该订阅对应的配置已经被选中，核心日志中没有 YAML 解析错误、字段错误或规则提供器下载失败。
策略组内容：进入代理或策略页面，查看常用策略组是否包含可选节点，避免组内为空。
更新方式：确认客户端是否支持定时更新，并按实际需要设置合理间隔。频繁刷新不会改善节点质量，反而可能触发服务端限制。

有些服务会根据客户端请求生成不同格式的配置。若订阅在浏览器里能打开，却在客户端中提示格式不支持，可能返回的是普通节点列表、其他软件格式或登录页面，而不是 Clash 兼容 YAML。此时应从服务提供方的使用页面重新选择对应订阅类型，不要手工把扩展名改成 YAML。

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

上面的片段只用于理解几个基础字段：mixed-port 是本地混合代理端口，mode: rule 表示按规则处理，allow-lan: false 表示默认不向局域网设备开放。实际订阅通常还包含代理、策略组、DNS 和规则等大量内容，不应把这个片段当作完整配置直接运行。

四、用最少变量完成首次连通验证

配置成功加载后，不要立刻开启所有高级功能。第一次连接的目标，是证明“应用流量能够进入本地代理端口，并按照配置选择可用出口”。最稳妥的方法是使用规则模式、选择一个明确的策略节点、打开系统代理，然后访问几个稳定站点并观察日志。

建议执行的验证步骤

把运行模式设为规则模式。这样既能检查规则匹配，也不会像全局模式那样把所有请求都强制交给同一策略。
在主要策略组中手动选择一个状态正常的节点。延迟测试成功只表示探测请求有响应，不等于所有目标都可访问。
开启系统代理，暂时不要开启 TUN。浏览器通常会读取系统代理，适合作为第一轮测试工具。
打开一个普通网站，再访问需要代理策略处理的目标，查看客户端连接列表是否出现域名、目标地址、规则命中与策略名称。
若无法访问，先关闭系统代理恢复网络，然后检查日志中的超时、拒绝连接、DNS 失败或配置错误。

日志级别保持在 info 通常足够。日志里出现连接记录，说明应用流量已经进入 Clash；如果浏览器报错但连接列表完全没有新请求，应优先检查系统代理是否开启、浏览器是否使用独立代理设置，以及本地端口是否与配置一致。如果连接记录存在但持续超时，则更应检查节点、策略选择、远端网络与规则去向。

规则模式下，每个请求会从规则列表上方向下匹配，命中后交给指定策略。配置末尾通常有兜底规则，用于处理前面未命中的流量。首次测试不必修改规则顺序；原始订阅能够工作之后，再根据实际需求添加域名或进程规则。

五、基础代理正常后再启用 TUN 与 DNS

系统代理主要影响遵循操作系统代理设置的应用。部分游戏、命令行工具、后台服务和使用特殊网络栈的程序可能绕过它。TUN 模式通过虚拟网络接口与路由接管更广泛的流量，覆盖范围更大，同时也更依赖系统权限、驱动、路由表和 DNS 配置。

启用 TUN 前，应先记录系统代理下的正常状态，然后关闭系统代理或按客户端推荐方式切换，避免排障时无法确认流量从哪个入口进入。部分客户端允许系统代理与 TUN 同时启用，但首次设置最好只保留一种主要接管方式。开启 TUN 后重新测试浏览器，再测试之前无法代理的应用，并观察连接列表是否新增对应请求。

TUN 启用失败时检查什么

客户端是否获得管理员、VPN 或网络扩展权限。
系统中是否有其他 VPN、虚拟网卡或网络过滤软件同时修改路由。
TUN 设备是否成功创建，核心日志是否报告路由或接口错误。
切换网络后默认网卡是否变化，例如从有线网络切到 Wi-Fi。
局域网、打印机或开发环境网段是否需要直连规则。

DNS 是“已连接但打不开域名”问题的重点。域名访问失败而直接访问已知服务仍有响应，通常说明解析链路需要检查。Clash 或 mihomo 配置可能启用内置 DNS，并采用 fake-ip 或 redir-host 等增强模式；这些模式的适用范围和兼容性不同，不宜在不了解原配置设计时随意互换。

排查 DNS 时，先判断请求是否进入核心，再检查上游 DNS 能否访问、规则是否把 DNS 请求送往错误出口，以及系统或浏览器是否启用了独立的加密 DNS。浏览器自带的安全 DNS可能绕过系统解析路径，因此同一域名在浏览器和其他应用中的结果可能不同。

六、首次设置中容易出现的误区

误区一：节点延迟越低，所有访问就一定越快

延迟测试只反映特定探测目标在测试时刻的响应情况。实际速度还受线路带宽、拥塞、目标站点、传输协议和本地网络影响。选择节点时应同时观察连接稳定性和实际访问结果，不必反复刷新延迟数字。

误区二：导入订阅后无需选择策略

订阅可能把主要策略组默认设为自动选择，也可能停留在某个不可用节点。导入后应打开策略组查看当前选项。若配置采用多层策略组，还要确认上层组最终指向了哪个节点或自动测试组。

误区三：连接按钮亮起就代表流量已经代理

客户端显示运行，通常只说明核心或 VPN 会话已经启动。系统代理可能尚未开启，TUN 路由也可能创建失败。应结合系统状态、连接列表和实际访问验证，而不是只看一个开关。

误区四：遇到问题就同时更换内核、DNS 和规则

一次改变多个变量会破坏排障基线。正确做法是回到原始订阅，关闭自定义覆写和 TUN，只保留系统代理测试。确认基础链路后，再逐项恢复 DNS 覆写、规则集、脚本和虚拟网卡。

误区五：开启局域网访问后不需要额外限制

allow-lan 用于让同一局域网中的其他设备访问本机代理。只有在确实需要共享代理时才应开启，并结合监听地址、防火墙和认证设置限制访问范围。普通单机使用保持关闭更简单，也能减少端口暴露。

误区六：把订阅地址当作普通公开链接

订阅地址通常可以直接获取账户对应配置，应像登录凭据一样保存。提交问题截图时，要遮住完整订阅 URL、查询参数和配置中的认证字段。若地址已经公开，应到服务提供方控制台重置，而不是只删除本地历史记录。

七、安装完成后的收尾清单

首次连通后，可以用下面的清单做一次收尾。每完成一项再进入下一项，后续发生问题时会更容易回到已知正常状态。

客户端版本与系统架构匹配，核心可以稳定启动。
订阅已经成功更新，并设为当前使用配置。
主要策略组已经选定可用节点或合适的自动策略。
规则模式下浏览器访问正常，连接列表能够显示命中规则与策略。
关闭系统代理或断开 VPN 后，系统网络能够恢复原状。
确有需要时再启用 TUN，并单独验证路由、DNS 与局域网访问。
自动更新与开机启动按使用习惯设置，不在排障期间频繁切换配置。
订阅地址与日志中的敏感字段得到妥善保存，不出现在公开截图中。

一套可靠的首次安装流程，重点不是把所有选项都打开，而是建立清晰的正常基线：原始配置可以加载，系统代理可以工作，策略命中能够在日志中看到。之后无论增加 TUN、自定义规则还是 DNS 覆写，都可以在出现异常时快速判断变化来自哪里。