Clash 首次安装与初始设置：跨平台通用步骤与常见坑

安装前先分清客户端与内核

Clash 的图形客户端和内核是两层东西。客户端负责界面、订阅管理与系统代理开关，内核负责解析配置、匹配规则、把流量转发出去。原版 Clash 内核已经停止维护，目前主流客户端默认内置 mihomo 内核（Clash Meta），协议支持、规则类型与 TUN 实现都以 mihomo 为准。

选安装包时先确认两件事：客户端是否自带内核（自带就不必单独下载内核文件）；内核版本是否支持你要用的入站方式。同一台机器不要同时运行两个代理客户端，它们会争抢 7890 端口和系统代理设置，典型表现是「开关显示已打开，但流量不走代理」。

平台	常见安装包形态	首次启动要处理的权限
Windows	.exe 安装包 / 便携版 zip	防火墙提示；TUN 需要管理员权限，通常装一次服务模式解决
macOS	.dmg（按芯片架构分 Apple 芯片 / Intel）	Gatekeeper 放行；TUN 需装一次特权助手并在系统设置里允许
Android	.apk（主流设备取 arm64）	「安装未知应用」；系统 VPN 授权对话框；关闭电池优化
iOS	App Store	添加 VPN 配置时的系统确认
Linux	.deb / .rpm / AppImage	装包需要 root；TUN 需要 CAP_NET_ADMIN 或以 root 运行

通用安装顺序：装包 → 授权 → 导入订阅 → 确认模式

各平台界面不一样，但顺序是同一套。按下面五步走，中间任何一步没出现预期结果就先停下来解决，不要往后跳。

选安装包

Windows 取 .exe；macOS 先确认芯片架构再下对应 dmg；Android 取 arm64 的 apk；Linux 按发行版选 deb 或 rpm。下载页每个平台卡片下都标了适用的系统版本与架构。

安装并处理首次启动的权限请求

Windows 的防火墙提示与提权、macOS 的「仍要打开」与特权助手、Android 的 VPN 授权、iOS 的 VPN 配置确认，都在这一步完成。被拒绝过的权限不会自动再弹，只能去系统设置里手动补。

导入订阅

打开「订阅」或「配置」页，新建一条，粘贴订阅链接后点更新，等配置下载完成。

选节点并确认模式

在「代理」页展开策略组选一个节点；在「设置」页把模式确认为「规则」，首次设置不要用「全局」。

打开系统代理或 TUN

两者先开一个：桌面端先用系统代理验证，确认能上网后再切 TUN。同时开启会让后续排查分不清问题出在哪一层。

Windows：服务模式决定 TUN 能否免提权

改系统代理只需要写当前用户的注册表，普通权限就够；TUN 模式要创建虚拟网卡，必须管理员权限。多数客户端提供「服务模式」开关：装一次系统服务，之后启动就不必每次提权。跳过这一步，TUN 开关点开后会立刻弹回，内核日志里能看到权限相关的报错行。

macOS：先过 Gatekeeper，再放行特权助手

从 dmg 拖进「应用程序」后首次打开，如果提示「无法打开，因为无法验证开发者」，去「系统设置」→「隐私与安全性」，在页面底部找到被拦截的条目点「仍要打开」。启用 TUN 时客户端会要求安装一次特权助手（部分版本走系统网络扩展），需要输入密码确认，并在「系统设置」→「通用」→「登录项与扩展」里把对应项打开，否则开关显示已开，流量仍走直连。

Android 与 iOS：VPN 授权只弹一次，后台保活要单独设

Android 侧载 apk 前，先在「设置」→「应用」→「特殊应用权限」→「安装未知应用」里放行安装来源；第一次点连接会弹系统 VPN 授权对话框，勾选信任并确定。之后到电池设置里把客户端设为不受限制，否则息屏后进程被系统回收，表现为每隔几分钟断一次。

iOS 从 App Store 安装后，首次连接会弹出「添加 VPN 配置」的系统确认，用锁屏密码或生物识别通过。这一步被拒绝，设置里的 VPN 条目不会生成，开关会立刻弹回，需要到「设置」→「通用」→「VPN 与设备管理」里检查是否有残留条目。

Linux：装包用 root，TUN 用 capability

deb 用 sudo dpkg -i，rpm 用 sudo rpm -ivh；AppImage 先 chmod +x 再运行。TUN 模式要创建虚拟网卡，给二进制授予网络管理能力比每次用 root 启动更省事：

sudo setcap cap_net_admin+ep /usr/local/bin/mihomo

注意重新安装或升级二进制后 capability 会丢失，需要再执行一次；用 systemd 常驻的话，也可以在 unit 里直接指定以 root 运行。

订阅导入与模式确认

导入动作本身只有三步：复制订阅链接 → 打开客户端「订阅」/「配置」页 → 新建并粘贴链接 → 点更新。配置下载成功后，节点会出现在「代理」页的策略组里。

卡在这一步的通常是下面三种情况：

链接被截断。订阅链接很长，从聊天软件复制时容易少字符。粘贴后检查结尾，或者直接用客户端的「从剪贴板导入」。
更新报 TLS 或证书错误。先看系统时间是否准确，时间偏差过大会导致证书校验失败。
更新成功但没有节点。看内核日志里的具体报错，常见原因是订阅返回的不是 Clash 格式的 YAML，而是 base64 编码的节点列表。

模式确认同样重要。客户端一般给出「规则」「全局」「直连」三个选项，首次设置保持「规则」，由内核按 rules 段自上而下匹配；需要验证节点本身是否可用时，临时切到「全局」测一次，测完切回「规则」。

下面这段是客户端图形界面里改动的实际字段，用来对照检查生效值：

mixed-port: 7890
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

mixed-port 同时接受 HTTP 与 SOCKS5 请求，浏览器代理插件填 127.0.0.1:7890 即可；external-controller 是面板与外部控制的监听地址，保持 127.0.0.1 不要改。

三类最容易踩的初始设置坑

权限类：TUN 开关打开又弹回去

基本只有三种原因——Windows 没装服务模式、macOS 的特权助手或网络扩展没在系统设置里放行、Linux 缺 CAP_NET_ADMIN。判断方法很直接：看内核日志里有没有 operation not permitted 或配置 TUN 接口失败的报错行。

端口类：7890 被占用，或者被暴露到局域网

7890 是最容易被抢的端口，浏览器代理插件、旧版客户端、抓包工具都可能占着它。先查占用进程：

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

拿到 PID 结束进程，或者把 mixed-port 换成一个空闲端口（比如 7891），同时改掉浏览器和系统代理里填的端口，否则会出现「端口换了但浏览器还在连旧端口」。

另一个方向是暴露：external-controller 写成 0.0.0.0:9090 且没设 secret，同一局域网内任何人都能读到配置、切换节点。

外部控制地址保持 127.0.0.1

需要远程看面板时用 SSH 端口转发到本地，不要把 9090 直接监听在 0.0.0.0，更不要在没有 secret 的情况下暴露到公网。

系统代理类：客户端退出后网页全部打不开

系统代理是写进操作系统的设置，客户端被强杀或崩溃时来不及还原，浏览器会一直往没人监听的 7890 端口发请求，表现为所有网页都连不上。手动还原的位置：

Windows：「设置」→「网络和 Internet」→「代理」→ 关闭「使用代理服务器」。
macOS：「系统设置」→「网络」→ 当前网络「详细信息」→「代理」→ 取消 HTTP、HTTPS、SOCKS 三项的勾选。

还有一个隐蔽的冲突源：浏览器装了代理管理扩展并启用了自己的 PAC 规则，它会覆盖系统代理，造成「客户端显示已连接，但浏览器不走代理」。排查时先禁用这类扩展，再复测一次。

首次连通性自检：按顺序走一遍

看内核日志。出现 DNS 监听、规则加载完成的记录说明启动正常；有 error 行先解决它。
看节点延迟。在「代理」页点延迟测试，能出数值说明订阅与网络都通；全部超时先回去确认订阅是否更新成功。
确认模式是「规则」，并在「连接」页看一条实际连接命中了哪条规则，避免所有流量都落到 MATCH 兜底。
绕过浏览器直接测端口：
```
curl -x http://127.0.0.1:7890 -I https://example.com
```
返回 200 状态码说明内核到节点的链路正常，问题在系统代理或浏览器一侧。
检查 DNS。开启 fake-ip 后默认网段是 198.18.0.1/16，如果局域网或公司 VPN 也用了这一段地址，会出现部分域名解析异常，需要换一段不冲突的地址。
最后做一次对比：关掉系统代理、只开 TUN，访问同一个站点。两种方式都通，首次安装与初始设置就算完成。