Clash 第一次安装设置全流程:跨平台通用要点与常见坑

先确认客户端、内核与安装包

第一次配置失败，常见原因不在节点，而在第一步就选错了文件。Clash 是代理规则体系与内核的通称，桌面或手机上实际操作的是带图形界面的客户端。当前常见内核是 Clash Meta，也称 mihomo；客户端负责订阅管理、策略选择、系统代理和日志展示，内核负责协议连接、规则匹配、DNS 与流量转发。

下载前先确认三个信息：操作系统、处理器架构、安装包格式。Windows 10 22H2 与 Windows 11 的普通 Intel、AMD 电脑通常选择 x64；Windows on ARM 设备选择 arm64。Apple Silicon Mac，也就是 M1、M2、M3、M4 系列，优先选择 arm64 或 universal；较早的 Intel Mac 选择 x64。Android 应用若提供多个架构，近年的主流手机通常是 arm64-v8a。

安装被系统拦截时怎么处理

• Windows：若 Microsoft Defender SmartScreen 显示保护提示，先核对文件是否来自项目发布页或本站下载中心。确认来源后，再使用提示中的「更多信息」继续。企业电脑若由管理员策略阻止安装，需要联系设备管理员，反复运行安装程序不会绕过策略。
• macOS：将应用拖入「应用程序」后，如果系统阻止首次打开，进入「系统设置」→「隐私与安全性」，在安全提示区域确认打开。不要长期关闭 Gatekeeper。
• Android：系统可能要求允许浏览器或文件管理器安装未知应用。授权只针对当前安装来源，安装完成后可在「设置」→「应用」→「特殊应用权限」中关闭该权限。
• Linux：AppImage 下载后需要执行权限，可在文件属性中启用，也可运行 chmod +x 文件名.AppImage。Debian、Ubuntu 使用 .deb，Fedora、RHEL 系发行版通常使用 .rpm。
• iOS：应通过 App Store 获取兼容 mihomo 或 Clash 配置格式的代理客户端。不同客户端的菜单名称不同，但都需要在首次连接时批准系统 VPN 配置。

导入订阅前先验证链接状态

订阅链接不是普通主页地址。它通常包含一段账户标识，用于返回 YAML 配置或节点列表。复制时不要漏掉查询参数，也不要把聊天软件生成的预览跳转地址当成订阅地址。订阅链接等同于访问凭据，不应发布到截图、论坛或公开代码仓库。

桌面客户端的典型路径是「配置」或「Profiles」→「从 URL 导入」→ 粘贴订阅地址 →「导入」。Android 客户端常见路径是「配置」→ 右上角加号 →「从 URL 导入」。iOS 兼容客户端一般在「配置」或「订阅」页面添加远程资源。界面文字会随客户端版本变化，但核心动作都是创建远程配置，而不是手工新建单个代理节点。

导入后应该看到什么

1. 配置列表出现新的订阅名称，并显示最近更新时间。
2. 切换到「代理」或「Proxies」页面后，可以看到策略组和节点。
3. 配置文件中存在 proxies、proxy-groups 与 rules 等字段，或由订阅转换服务生成等价内容。
4. 选中的配置处于启用状态，而不只是下载到了本地列表。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自动选择
      - DIRECT

上面的 YAML 只展示字段层级。实际端口、策略组名称和节点由配置提供。不要为了“照着教程设置”而覆盖现有配置，尤其不要删除订阅生成的 proxy-groups 与 rules。YAML 对缩进敏感，Tab、少一个空格或重复键名都可能导致加载失败。

订阅导入失败的错误分流

• 提示 401 或 403：链接凭据失效、账户状态异常，或服务端限制访问。回到订阅提供方重新生成地址。
• 提示 404：地址路径不完整，或旧订阅入口已被移除。检查复制内容是否从 https:// 开始并包含完整参数。
• 请求超时：先关闭 Clash，用当前直连网络在浏览器测试订阅域名是否可访问。必要时切换手机热点，区分本地网络与服务端问题。
• 下载成功但解析失败：返回内容可能是网页错误页、Base64 节点列表，或不兼容当前客户端的配置格式。查看响应开头是否为 HTML，再确认客户端支持的订阅类型。
• 配置存在但节点为空：检查订阅是否过期、流量是否耗尽，以及当前启用的是不是刚导入的配置。

选择运行模式与第一个可用节点

订阅导入成功后，先把运行模式设为「规则」或 rule。规则模式会从上到下匹配域名、IP、进程等条件，并把请求交给对应策略组。全局模式会让大部分请求统一经过指定代理，适合临时对照测试；直连模式则绕过代理。第一次配置不建议停留在全局模式，因为它会掩盖策略组和规则配置中的问题。

节点测试不要只看延迟数字

在「代理」页面找到主策略组，常见名称包括「节点选择」「PROXY」或「手动选择」。先选一个延迟能返回结果的节点，再打开网页验证。延迟 80 ms 不等于下载速度一定快，延迟测试只说明探测地址在测试时刻可达。连续出现 3000 ms、5000 ms 或 Timeout，才需要优先检查节点状态或网络连通性。

1. 对同一地区的 3 个节点分别执行一次延迟测试。
2. 优先选择延迟波动小、连续两次都有结果的节点。
3. 打开一个需要代理的网站，观察连接记录是否出现新请求。
4. 若网页失败，切换第二个节点复测，不要立刻修改 DNS。
5. 若所有节点同时超时，再检查订阅、系统时间和直连网络。

系统时间偏差会让 TLS 证书校验失败。Windows 可进入「设置」→「时间和语言」→「日期和时间」开启自动设置时间；macOS 路径是「系统设置」→「通用」→「日期与时间」。手机也应启用自动日期、时间与时区。时间修正后，完全退出客户端再重新连接。

系统代理与 TUN 模式不要同时乱开

节点可用不代表应用流量已经进入 Clash。客户端至少需要一种流量接管方式：系统代理或 TUN。第一次设置应先用系统代理，因为路径更短、排查更直接。Windows 与 macOS 桌面客户端通常提供「系统代理」开关；开启后，支持系统代理的浏览器和应用会连接本机监听端口。

系统代理的正确检查方式

常见配置使用 127.0.0.1:7890 作为 mixed-port，它可同时接收 HTTP 和 SOCKS 流量；部分旧配置可能分别使用 7890 与 7891。端口必须以当前配置和客户端界面显示为准。若配置写的是 7897，系统代理却仍指向 7890，结果就是客户端运行正常但网页无法连接。

• Windows 可在「设置」→「网络和 Internet」→「代理」查看当前代理状态。
• macOS 可在「系统设置」→「网络」→ 当前网络 →「详细信息」→「代理」查看。
• 浏览器若安装过独立代理扩展，先停用扩展，避免扩展端口覆盖系统代理。
• allow-lan: false 只影响局域网其他设备访问，不妨碍本机连接 127.0.0.1。

哪些情况需要 TUN

TUN 会创建虚拟网络接口，接管不遵循系统代理的应用、部分命令行工具和游戏流量。桌面客户端开启 TUN 时，可能要求安装服务模式或授予管理员权限。以常见桌面客户端为例，通常先在「设置」→「系统设置」中安装服务模式，再开启 TUN；Android 与 iOS 则通过系统 VPN 授权建立虚拟接口。

首次排查不要同时开启系统代理、TUN、浏览器扩展和另一个 VPN。建议先关闭其他接管工具，只开系统代理完成网页测试。如果某个应用仍然直连，再关闭系统代理、开启 TUN 单独测试。两种方式都开并非必然冲突，但会增加路由、DNS 与排除规则的判断成本。

五个平台的首次权限核对

Windows：服务模式与残留代理

普通系统代理通常不要求管理员权限，TUN 和开机启动相关功能可能依赖服务模式。若服务安装失败，先退出旧版客户端，再检查任务管理器中是否仍有相关内核进程。客户端异常退出后，Windows 可能保留手动代理，表现为 Clash 已关闭但浏览器完全断网。此时进入「设置」→「网络和 Internet」→「代理」，关闭失效的手动代理，重新打开客户端后再启用系统代理。

macOS：网络扩展与登录项

macOS 首次启用 TUN 或网络扩展时会弹出系统授权，批准后可能需要输入设备密码或使用 Touch ID。若点击后没有生效，检查「系统设置」→「隐私与安全性」中的提示，以及「系统设置」→「通用」→「登录项与扩展」中的网络扩展状态。不要反复安装多个同类客户端，它们的网络扩展可能争用接管权限。

Android：VPN 授权与电池限制

Android 点击启动后会出现 VPN 连接请求，这是建立 TUN 接口所需的系统权限。同一时间通常只能有一个 VPN 应用处于连接状态。若锁屏几分钟后代理自动停止，进入「设置」→「应用」→ 当前客户端 →「电池」，将后台策略调整为允许持续运行；不同厂商系统的菜单名称会略有差异。状态栏出现钥匙或 VPN 图标，说明接口已建立，但节点是否可用仍要看连接日志。

iOS 与 iPadOS：VPN 配置和按需连接

首次启动兼容客户端时，系统会请求添加 VPN 配置。批准后可在「设置」→「通用」→「VPN 与设备管理」→「VPN」查看。若其他 VPN、企业网络工具或过滤器正在运行，应先断开再测试。按需连接会根据网络条件自动启动，第一次排查建议暂时关闭自动化条件，手动连接并观察客户端日志。

Linux：桌面代理与环境变量

Linux 桌面环境对系统代理的支持不完全一致。GNOME、KDE 中启用系统代理后，终端程序不一定自动继承。可按程序需要设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，端口与客户端监听端口保持一致。若要接管更多程序，使用 TUN 前应确认系统已启用相应权限，并检查防火墙、路由表与 NetworkManager 是否存在冲突。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

开了代理仍没生效的固定排查顺序

此时不要随机切换十几个设置。按流量经过的层级，从配置到出口逐项确认。每一步只改变一个变量，并在修改后刷新同一个测试页面。

1. 确认配置已启用：配置列表中当前选中的应是新导入订阅，不是客户端自带示例。
2. 确认节点可连接：主策略组不能停在失效节点，也不能误选 DIRECT。
3. 确认运行模式：选择规则模式。临时切换全局模式测试一次，可用于判断是节点问题还是规则问题。
4. 确认监听端口：查看内核日志是否出现端口被占用。若 7890 已被其他程序占用，退出旧代理程序后重启客户端。
5. 确认流量入口：只开启系统代理或 TUN 中的一种，刷新网页并查看连接记录。
6. 确认规则命中：请求若命中 DIRECT，检查规则是否将该域名设为直连；请求若命中代理组，再看该组实际选择的节点。
7. 最后检查 DNS：只有出现域名解析失败、IP 能访问而域名不能访问，或日志明确显示 DNS 错误时，再处理 DNS 配置。

用日志区分三类故障

浏览器的安全 DNS 也可能改变解析路径。若普通网站可打开，只有特定域名解析异常，可临时关闭浏览器内的安全 DNS做一次对照测试。确认原因后再决定使用系统 DNS、客户端 DNS 或浏览器指定的 DoH，不要把三套设置同时改掉。

首次设置完成后的检查清单

完成下面项目后，初始配置才算稳定。后续出现问题时，也可以按同一清单快速判断是订阅变化、节点失效，还是系统设置被其他软件改动。

• 安装包与当前系统、处理器架构一致，客户端可以正常启动。
• 订阅导入成功，配置列表显示最近更新时间，代理页面能看到策略组。
• 运行模式为规则模式，主策略组已明确选择一个可用节点。
• 系统代理或 TUN 至少有一种已生效，且不存在第二个 VPN 同时接管。
• 刷新测试网页时，连接记录能显示域名、命中规则、策略组与节点。
• 关闭客户端时会同步关闭系统代理，避免留下指向本机失效端口的设置。
• 已了解订阅更新入口，但没有设置过于频繁的自动更新周期。
• 订阅地址未出现在公开截图、浏览器共享记录或公开文档中。