Clash macOS 安装后网络扩展与钥匙串授权步骤详解

先区分四类授权：打开应用、辅助服务、网络扩展与钥匙串

macOS 上的 Clash 客户端并不采用同一种网络接管方式。图形界面可能调用 mihomo 内核，也可能配合特权辅助服务或 Network Extension。看到其他客户端的授权截图时，先确认当前软件的名称、版本和运行模式，再决定是否需要执行相同步骤。

先在苹果菜单 →「关于本机」记录 macOS 版本和芯片类型，再到客户端的「关于」页面记录客户端版本；若有内核信息页，也记录 mihomo 版本。Apple Silicon 与 Intel 安装包应分别选择对应架构；架构选错通常属于启动兼容性问题，不能靠批准网络扩展解决。

首次打开：分别处理开发者验证与「已损坏」提示

先完成安装位置与来源检查

1. 退出正在运行的旧实例，将应用从磁盘映像拖入「应用程序」，不要长期直接从安装映像运行。
2. 推出安装映像，再从「应用程序」打开，避免后续授权指向临时挂载路径中的副本。
3. 核对下载来源、应用名称与处理器架构；若系统明确提示包含恶意软件，停止运行并重新检查来源。

对于「无法验证开发者」一类提示，macOS 13 Ventura、14 Sonoma 及后续版本通常在「系统设置」→「隐私与安全性」的安全性区域提供针对最近一次拦截的「仍要打开」。macOS 12 Monterey 对应入口是「系统偏好设置」→「安全性与隐私」→「通用」。按钮只有在发生相关拦截且系统允许覆盖时才会出现。

macOS 15 Sequoia 对部分未签名或未公证软件调整了打开流程，不应只依赖旧教程中的按住 Control 点按「打开」。按当前系统弹窗进入安全设置，核对应用后再确认。单位管理的电脑可能限制覆盖，此时应由设备管理员处理策略。

「已损坏」不是普通权限开关

这条提示可能与包内容异常、签名失效或下载隔离处理有关。优先删除当前应用副本，重新获取与当前系统兼容的发行包；不要先关闭整个系统的安全检查。需要进一步定位时，可在终端键入下列命令前缀，再将「应用程序」中的实际应用拖入终端补齐路径，每条命令分别执行：

spctl --assess --type execute --verbose=4
codesign --verify --deep --strict --verbose=2
xattr -l

上述命令均需要应用路径参数，不能直接把三行一起粘贴当作完整诊断。第一条查看系统执行评估，第二条验证现有签名，第三条列出扩展属性。出现 com.apple.quarantine 只说明带有隔离标记，不证明应用有害，也不证明应用可信；签名检查成功同样不等于已通过系统公证。

网络扩展批准：按 macOS 版本查找入口

先在客户端触发一次需要扩展的功能，再查看系统提示。系统扩展通常由应用主动提交激活请求；仅把应用复制到「应用程序」，未必会生成待批准项目。批准时核对开发者名称与该客户端的发行说明，不能只凭弹窗出现时间判断来源。

具体入口还取决于扩展的打包形式与系统小版本。若出现「添加 VPN 配置」提示，应查看申请应用名称后决定是否允许；VPN 配置可以在系统的「VPN」或「网络」相关页面检查。VPN 配置授权与系统扩展批准不是同一个开关，内容过滤器也不等同于 TUN 隧道。

1. 保持客户端打开，在其界面启用需要扩展的网络功能。
2. 按系统提示前往设置，批准匹配的开发者或扩展，并完成系统要求的身份验证。
3. 返回客户端，关闭再开启该功能；只有系统明确要求时再重新启动电脑。
4. 若没有待批准项目，检查客户端日志、扩展安装说明及服务状态，不要反复寻找一个尚未被申请的权限。

可以运行 systemextensionsctl list 查看通过系统扩展机制注册的项目及其状态。但这条命令不是全部网络组件的清单：不同形式的 Network Extension 不一定全部显示，特权服务方式的 TUN 也不能用这里是否有条目来判定成功。

钥匙串弹窗：核对请求进程、项目名称和密码类型

钥匙串访问提示通常包含两个关键信息：哪个进程请求访问，以及要读取哪个项目。项目可能用于保存订阅凭据、代理认证信息或应用自身的访问令牌，具体用途由客户端实现决定。先展开详情确认内容，再选择「允许」或「始终允许」。

三个操作分别意味着什么

• 拒绝：不向本次请求提供凭据；应用可能要求重新登录、重新输入认证信息，或显示凭据读取失败。
• 允许：批准当前这次访问；后续读取仍可能再次询问。
• 始终允许：为该项目记录对当前应用身份的访问许可；适合已核实且需要持续读取的请求。

如果弹窗要求解锁「登录」钥匙串，通常需要当前用户的登录密码，而不是订阅密码或 Apple 账户密码。若登录密码曾通过其他方式重设，钥匙串密码可能仍是旧密码；持续输入新密码不一定能解锁旧钥匙串。

反复弹窗时按顺序定位

1. 在访达选择「前往」→「实用工具」→「钥匙串访问」；也可通过聚焦搜索打开。
2. 选择「登录」钥匙串，按弹窗显示的项目名称搜索，不要批量删除无关密码。
3. 打开匹配项目，检查「访问控制」中允许访问的应用。部分项目不提供相同的编辑选项，应以实际界面为准。
4. 核对是否同时安装了两个应用副本，或更新后签名身份发生变化。先保留一个明确的安装位置，再重新发起访问。

重置默认钥匙串会影响其他已保存凭据，不应作为首次排障动作。需要删除客户端专用项目时，先确认可以重新输入相应凭据，并记录项目名称；删除后由客户端重新保存，而不是修改其他应用的访问控制来绕过提示。

TUN 权限：先验证系统代理，再启用虚拟接口

系统代理主要向遵循 macOS 代理设置的应用提供 HTTP、HTTPS 等代理入口；TUN 则通过虚拟网络接口和路由接管流量。终端工具是否读取系统代理取决于工具本身，因此「浏览器能访问、命令行不能访问」并不足以证明权限缺失。

建议先关闭 TUN，仅测试本地代理监听和规则，再处理路由接管。以下使用 127.0.0.1:7890 作为示例地址，必须以客户端显示的 HTTP 或 mixed 端口为准；7890 不是所有客户端的固定默认值。

lsof -nP -iTCP:7890 -sTCP:LISTEN
scutil --proxy
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

• lsof 有监听输出：继续核对进程是否属于当前客户端；没有输出时先检查内核启动与实际端口。
• scutil --proxy：查看当前生效的系统代理信息。它不负责证明 TUN 路由已经建立。
• curl 返回响应头：说明本次显式代理请求有响应；仍需结合状态码和客户端连接记录判断具体请求结果。

确认服务与运行时配置

若客户端采用 mihomo 特权服务，按其设置中的服务安装入口完成管理员验证，再开启 TUN。菜单可能称为「服务模式」「辅助服务」或「安装服务」，应以该版本实际界面为准；不要把整个图形界面长期用管理员身份运行。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

这只是 TUN 相关字段，不是可独立运行的完整配置。stack 的可用值与行为应以当前内核版本为准；这些字段也不能替代系统权限。客户端可能在启动时覆盖订阅中的同名字段，应检查最终生效配置，而不是只检查下载到的 YAML 文件。

开启后可用 ifconfig 查看接口，用 netstat -rn -f inet 查看 IPv4 路由，用 scutil --dns 查看解析器状态。macOS 自身及其他 VPN 也会创建 utun 接口，单独看到 utun0 或其他编号，不能证明它属于当前客户端。需要同时对照启用前后的变化、客户端日志与实际连接记录。

授权完成仍不通：按现象缩小排查范围

订阅成功导入，只表示客户端拿到了配置，不表示节点认证、DNS、策略组选择与系统路由全部正常。测试时在连接页面核对目标域名命中的规则与出口；若命中 DIRECT，就应先检查规则顺序，而不是继续批准系统扩展。

排查冲突时，先暂停其他 VPN、内容过滤器或抓包工具，再单独启用当前客户端。每次只改一个条件，并记录修改前后的日志时间。不要同时重装应用、删除钥匙串和修改 DNS，否则即使恢复连接，也无法判断哪一项修复真正生效。

升级与卸载：核对服务状态，保留可恢复的网络设置

1. 升级前：记录客户端版本、内核版本和当前工作模式；保存需要保留的本地规则，避免覆盖后失去修改。
2. 升级后：先打开应用，再检查服务是否需要更新；只有出现新的授权请求时，才核对并重新批准。
3. 卸载前：在客户端关闭 TUN 和系统代理，使用其内置入口卸载辅助服务或停用扩展，再退出应用。
4. 卸载后：macOS 13 及后续版本可在「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」检查遗留设置；macOS 12 对应「系统偏好设置」→「网络」→ 当前服务 →「高级」→「代理」。

不要删除其他 VPN 的配置，也不要看到 127.0.0.1 就一律清空。先确认该地址和端口确实由已卸载的客户端设置；工作网络可能另有管理员配置的代理。若设备受管理，相关设置应由管理员确认。

完成排查后，应能分别回答四个问题：应用是否正常启动、当前模式是否需要扩展、钥匙串请求是否来自已核实的应用、代理或 TUN 流量是否命中预期规则。这四项分别核对，比重复输入密码或反复重启更容易定位问题。