Clash 首次安装与初始设置:跨平台通用要点和易踩的坑

首次设置顺序：先让配置运行，再接管流量

安装成功只说明客户端文件已经放到设备上，不代表代理链路可用。桌面客户端通常由图形界面和代理内核组成：界面管理订阅、策略组与开关，内核负责解析配置、监听端口和转发连接。Clash Meta 后续以 mihomo 名称维护，不同内核支持的协议和字段并不完全相同。

首次使用按下面顺序操作。每完成一步再进入下一步，出现问题时就能定位到具体环节，而不是同时修改 DNS、端口和节点。

1. 确认设备架构，安装对应客户端，并记录客户端版本、内核名称与内核版本。
2. 退出其他正在接管网络的代理程序，确认本机可以正常访问普通网页。
3. 导入订阅或本地 YAML，选中配置，检查内核能否启动。
4. 使用规则模式，在实际承接流量的策略组中选定节点。
5. 桌面端先开启系统代理；Android 端授权客户端建立 VPN 连接。
6. 验证浏览器访问与连接日志，最后再配置 TUN、后台运行和开机自启。

安装包与权限：按平台确认必要条件

Windows：不要把所有故障都归为权限不足

安装后先用普通用户启动。若仅开启系统代理就提示本地端口绑定失败，应先查端口占用，而不是反复“以管理员身份运行”。系统代理改变的是代理入口，不会自动让所有程序都使用代理；部分游戏、命令行工具和独立网络组件会绕过该设置。

macOS：区分安全提示与文件损坏

应用被系统拦截时，先核对下载来源和安装包架构。确认来源可信后，可到「系统设置」→「隐私与安全性」查看是否有对应的打开许可。不要为了启动一个客户端就全局关闭系统安全机制，也不要直接执行来源不明的终端修复命令。

Android：连接权限与后台权限分开处理

VPN 授权解决的是流量入口，电池优化影响的是后台存活。如果前台可用、锁屏后频繁断开，再到「设置」→「应用」→对应客户端→「电池」检查后台限制；具体名称随厂商系统变化。首次测试先保持默认选项，确认连接稳定后再按需放宽限制。

订阅与 YAML 导入：确认内容、兼容性和生效状态

客户端不自动提供可用节点。订阅地址通常来自已有服务的账户面板，链接中可能包含访问令牌，应当按密码处理。不要把完整地址粘贴到公开论坛、截图或共享日志中；发送截图前同时遮住节点凭据。

1. 打开客户端的「配置」或「订阅」页面，选择从 URL 导入或导入本地文件。页面名称以实际客户端为准。
2. 等待下载结束，检查是否出现配置条目。下载失败时先看 HTTP 状态、证书或网络错误，不要立刻修改规则。
3. 选中刚导入的配置，让它成为当前使用项。导入成功和正在使用是两件事。
4. 检查运行日志。存在 YAML 缩进错误、未知协议或缺失策略组时，先修复这些错误，再开启系统代理。

常见的“配置格式错误”并不一定是 YAML 本身有问题：过期订阅可能返回登录页面，某些地址返回的是其他客户端格式，也可能只包含节点列表而非完整配置。若文件开头是 <html>，应检查订阅入口和账户状态，而不是给文件加几行规则。

字段不兼容时，先确认正在运行的内核

能在 mihomo 中使用的协议或扩展字段，不一定能在旧 Clash 内核中运行。查看客户端的「关于」或内核信息页，记录实际版本，再对照对应版本文档。不要只根据安装包文件名判断内核能力，也不要删除不认识的字段来强行通过检查。

端口占用：用 7890 示例检查本地监听

下面是一个本地入口片段，7890 是本文示例端口，不是所有客户端的固定值。mixed-port 同时接受 HTTP 代理和 SOCKS 代理连接。先在界面或生效配置中确认实际端口，测试命令也必须使用同一个值。

# 仅展示本地入口字段，不是完整订阅配置
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

不要把该片段直接替换整个订阅文件，否则原来的节点、策略组和规则会丢失。只供本机使用时，保持局域网访问关闭；也不需要为一次本机测试开放路由器端口或关闭整机防火墙。

Windows：先找到监听进程

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

第一条命令检查包含该端口的连接记录。重点找本地地址以 :7890 结尾且状态为 LISTENING 的行，最后一列是 PID。第二条中的 1234 是示例，应换成实际 PID；确认程序身份后正常退出它，不要盲目结束系统进程。

macOS 与 Linux：检查同一端口

# macOS；Linux 安装 lsof 后也可使用
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

查看其他用户进程的信息可能需要额外权限。若旧客户端仍在后台运行，先退出旧实例再重启当前内核。确实需要更换端口时，例如改为 7892，还要同步更新手工代理设置、浏览器插件和终端环境变量；只改配置文件会让应用继续连接旧端口。

代理模式与 TUN：先验证规则链路

首次使用选择规则模式。它按配置中的规则顺序，把连接交给直连、拒绝或相应策略组。全局模式把流量交给全局策略，并不会自动挑出一个可用节点；直连模式也不是“断开客户端”，而是改变流量处理方式。

进入策略组查看当前选择。假设规则末尾指向名为 Proxy 的组，就应确认该组最终落到可用节点，而不是只看另一个测试组的延迟。界面出现延迟数值，只代表特定测试目标当时可达，不代表所有网站、协议和地区服务都能正常使用。

• 桌面浏览器测试：开启系统代理，暂时禁用会自行指定代理的浏览器扩展，访问需要验证的网站。
• 终端测试：使用显式代理参数，避免把终端未读取系统代理误判为客户端故障。
• 连接记录：在客户端查看目标域名、命中的规则、策略组和最终节点，确认请求确实经过预期路径。

# Windows PowerShell，显式调用 curl.exe
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 https://example.com/

此命令只验证指定目标的一次 HTTP 请求。返回站点响应说明该请求链路有结果；连接被拒绝通常先查监听端口，长时间超时则结合日志检查节点与目标。示例网址可达不等于其他网址也可达，仍需测试实际用途。

TUN 模式放到最后开启

TUN 通过虚拟网络接口接管被路由到它的流量，适合处理不读取系统代理的应用。实际覆盖范围还受路由、排除项和 DNS 设置影响，不能把它理解为必然接管一切。Windows、macOS 和 Linux 上通常涉及服务、驱动或系统网络权限；Android 的 VPN 接口由系统授权管理。

只有在基础链路正常、确实需要接管额外应用时才开启 TUN。若开启后内网域名、公司 VPN 或局域网设备访问异常，先关闭 TUN 对照测试，再逐项检查路由与 DNS。不要同时更换 DNS、启用 Fake-IP 和修改多个路由选项；相关字段可查阅YAML 手册的 DNS 设置与Fake-IP 说明。

开机自启与重启验收：检查界面、内核和代理状态

开机启动界面、启动代理内核、自动开启系统代理，通常是三个不同状态。确认手动启动稳定后，再到客户端设置启用相应选项。Windows 可在「设置」→「应用」→「启动」核对启动项；macOS 可在「系统设置」→「通用」→「登录项与扩展」查看登录与后台项目，具体名称随系统版本变化。

Android 的开机启动与后台运行限制取决于客户端和系统实现。需要长期保持连接时，先确认锁屏后是否仍能正常访问，再决定是否调整电池限制。系统提供的“始终开启 VPN”和“阻止未使用 VPN 的连接”也不是同一个选项；后者会在 VPN 不可用时限制联网，应理解影响后再启用。

第一次重启后逐项验收

1. 确认客户端和内核已运行，当前配置仍是预期订阅。
2. 确认监听端口未变化，规则模式与策略组选择仍然正确。
3. 桌面端检查系统代理或 TUN 是否按预期恢复；Android 检查 VPN 连接状态。
4. 分别测试普通网页、目标服务和局域网资源，避免只看托盘图标。
5. 通过客户端正常退出，确认桌面系统代理已关闭；若退出后断网，检查残留代理设置。

Windows 可到「设置」→「网络和 Internet」→「代理」检查是否还指向本地端口；macOS 可到「系统设置」→「网络」→当前连接→「详细信息」→「代理」查看。修改前记录原设置，尤其是受单位管理的设备，不要覆盖已有组织代理。

完成以上验收后，再添加分流规则或调整 DNS。订阅相关问题可查看订阅常见问题，模式区别可查看代理模式教程。每次只改变一个设置，保留可恢复的工作配置。