先分清：启动拦截、网络授权与钥匙串不是同一个问题

Mac 上的 Clash 类客户端通常包含图形界面、代理内核，以及按需安装的后台辅助服务。部分客户端还使用网络扩展。提示“已损坏”发生在应用启动检查阶段；网络扩展授权影响网络接管；钥匙串弹窗则涉及凭据读取。三者处理入口不同，不能靠反复输入管理员密码一起解决。

看到的现象优先检查先不要做什么
“已损坏，无法打开”安装来源、下载完整性、签名与隔离属性不要直接关闭系统安全检查
“无法验证开发者”「隐私与安全性」中的应用放行入口不要把它当成订阅故障
界面能打开，TUN 启动失败内核日志、服务模式或网络扩展权限不要先删除钥匙串条目
反复要求访问钥匙串请求者名称、条目名称与登录钥匙串状态不要对陌生程序选择“始终允许”

开始前记录 macOS 版本、客户端名称与版本、内核名称和报错原文。以下系统设置路径以 macOS 13、14、15 为参照；其他版本的名称可能调整，应以实际页面为准。不要只记录“Clash 打不开”，这个描述无法区分应用被拦截和内核启动失败。

安装前确认 Apple 芯片、Intel 与应用位置

先选对架构，再处理权限

  1. 打开苹果菜单 →「关于本机」。显示“芯片 Apple M 系列”时，优先选择 arm64 或 aarch64 安装包；显示 Intel 处理器时，选择 x64 或 x86_64。
  2. 标有 Universal 的应用通常包含两种架构，但仍应确认客户端的最低 macOS 要求。支持哪一版系统由具体发行版本决定，不由“Clash”这个名称决定。
  3. 打开磁盘映像后，把应用拖入「应用程序」，弹出磁盘映像，再从「应用程序」启动。不要长期从下载目录、压缩包或挂载的安装盘运行。
  4. 退出其他代理客户端，避免多个程序同时改写系统代理、路由和 DNS。

也可以在「应用程序」→「实用工具」→「终端」执行以下只读命令，记录系统版本和当前终端架构：

sw_vers -productVersion
uname -m

原生运行的 Apple 芯片终端通常输出 arm64，Intel 通常输出 x86_64。如果终端经 Rosetta 转译运行，结果可能反映转译环境，因此最终以「关于本机」为准。Apple 芯片运行 Intel 应用可能需要 Rosetta，但安装 Rosetta 不会修复损坏的签名或缺失的网络权限。

“已损坏，无法打开”：先查来源，再处理隔离属性

第一步：重新获取可信安装包

先退出应用，从项目维护者的发行页重新下载安装包。不要使用来源不明的重打包版本。若系统明确提示“将损坏你的电脑”或检测到恶意软件，应停止打开，不能沿用普通开发者验证提示的放行步骤。

“已损坏”并不一定代表文件传输中断，也可能与签名异常、应用内容被修改或 Gatekeeper 的评估结果有关。移除隔离属性不会修复应用本身，更不能证明程序可信。

第二步：检查系统是否提供放行入口

尝试打开一次应用，然后进入苹果菜单 →「系统设置」→「隐私与安全性」，向下查看“安全性”区域。如果出现对应应用的“仍要打开”，先核对应用名称和来源，再按系统提示验证身份。并非所有拦截都会提供这个按钮；没有入口时，不要通过全局关闭 Gatekeeper 来强行启动。

第三步：仅对确认可信的应用检查隔离属性

以下命令以应用已经安装在 /Applications/Clash Verge.app 为例。若名称不同，先在访达确认实际路径，或把应用拖入终端补全路径，不要原样运行不匹配的命令。

xattr -p com.apple.quarantine "/Applications/Clash Verge.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge.app"
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Verge.app"

xattr 用来查看隔离标记；提示属性不存在，只代表这一项没有设置。spctl 查看系统启动评估，codesign 检查签名完整性。后两者的结果需要结合发行说明判断：签名检查通过不等于来源可信，评估失败也不应直接解释成“需要删除隔离属性”。

xattr -d com.apple.quarantine "/Applications/Clash Verge.app"

这条命令只移除指定应用包本身的隔离属性，不会递归处理整个目录，也不修改全局安全策略。执行后仍失败，就回到发行说明和签名结果排查；不要把操作范围扩大到整个「应用程序」目录，也不要随意加上管理员权限。

网络扩展在哪里允许：先确认客户端是否真的使用它

Clash 是一类客户端和内核生态的常用称呼，不代表所有应用都采用相同的 macOS 网络实现。部分客户端使用 Network Extension；另一些 mihomo 图形客户端通过特权辅助服务创建 TUN 接口。系统里找不到网络扩展开关，并不能直接判定安装失败。

使用网络扩展的客户端

  1. 先在客户端启用其 VPN、网络接管或 TUN 相关功能，触发系统授权请求。只有在客户端确实使用该机制时，才会出现相应提示。
  2. macOS 15 可检查「系统设置」→「通用」→「登录项与扩展」→「网络扩展」，查看对应开发者或应用是否已允许。
  3. macOS 13、14 如提示系统软件被阻止，检查「系统设置」→「隐私与安全性」的相关提示；VPN 配置也可在「系统设置」→「VPN」中确认。不同扩展类型的入口并不完全相同。
  4. 核对开发者名称后授权。只有系统明确要求时才重启；返回客户端重新启用功能，查看日志是否仍报权限错误。

“允许添加 VPN 配置”和“允许系统扩展”不是完全相同的授权。不要为了 Clash TUN 默认去降低启动安全性、关闭 SIP，或安装未知内核扩展。常见的现代用户态代理方案不应把这些操作作为普通安装前提。

企业管理设备可能无法自行放行

如果开关不可编辑，或显示由组织管理，检查「系统设置」中的设备管理信息。MDM 策略可以限制 VPN、系统扩展及后台服务。这类限制应交由设备管理员处理，反复重装客户端不会绕过管理策略。

服务模式安装：管理员密码不等于钥匙串密码请求

使用 mihomo 的桌面客户端可能通过服务模式运行特权辅助程序，以便配置 TUN、路由或相关网络设置。服务模式安装成功不代表 TUN 已经开启；它只是补齐客户端执行相应操作所需的权限。

  1. 确认应用已经放进「应用程序」，从固定位置启动。
  2. 在客户端「设置」中查找“服务模式”“安装服务”或“修复服务”。例如 Clash Verge Rev 的相关入口通常位于「设置」→「服务模式」，具体按钮名称以所装版本为准。
  3. 系统请求管理员授权时，核对应用名称。输入的是当前 Mac 上具备管理权限的账户密码，不是订阅密码，也不是 Apple 账户密码。
  4. 安装后确认服务状态，再启用 TUN。打开客户端日志，观察是否还有权限不足、内核启动失败或地址占用等错误。

如果升级后每次启动都要求重新安装服务，先退出旧实例，再使用客户端自己的卸载服务、重新安装服务功能。不要照着不明教程手动删除 /Library/LaunchDaemons 下的文件；误删其他软件的服务会制造新的问题。

服务安装失败还可能来自旧版辅助程序、应用位置变化或管理策略。此时应记录失败时间与错误日志，而不是反复输入密码。关闭 TUN 后，普通系统代理仍可能可用，可以借此区分特权服务故障与订阅、节点故障。

钥匙串弹窗：看清请求者，再决定是否允许

“某应用想使用储存在钥匙串中的机密信息”通常意味着程序在读取已保存的凭据或应用密钥。请求内容由客户端实现决定，并不是每个 Clash 客户端都会出现。它与安装后台服务时的管理员认证属于两条流程。

遇到弹窗按这个顺序核对

  • 看请求者：应当是刚启动的客户端或其可识别组件。陌生名称、陌生路径先选“拒绝”，再确认来源。
  • 看条目名称：它应与当前应用或正在使用的功能有关。访问无关浏览器、邮件或其他应用的凭据时，不要直接放行。
  • 看密码类型：登录钥匙串通常使用本机登录密码。如果账户密码曾被重置，旧钥匙串可能仍使用原密码。
  • 先尝试单次允许：确认功能恢复后，再按需要决定是否“始终允许”。不要把全部应用加入某个敏感条目的访问列表。

密码正确却反复弹窗怎么办

用 Spotlight 搜索「钥匙串访问」，选择“登录”钥匙串，查找与当前客户端相关的条目。若钥匙串锁定，可先解锁后重试。若问题出现在客户端更新后，可能与签名身份或条目访问控制发生变化有关，应先查看该版本的说明。

只在明确知道用途、并且能重新登录或重新导入配置时，才考虑删除当前应用相关的单个条目。删除前先备份可导出的配置；不要重置整个默认钥匙串作为第一步，否则其他应用保存的密码也会受影响。

授权完成后，分两轮检查系统代理与 TUN

不要把系统代理和 TUN 同时打开后再猜是哪项生效。先测试系统代理，再关闭它测试 TUN，每轮只改变一个条件，才能确认实际故障点。

第一轮：检查系统代理端口

在客户端中查看实际混合代理端口。以下仅以本机 127.0.0.1:7890 为例，若客户端显示其他端口，应按实际值修改。先开启系统代理，在终端执行：

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

scutil --proxy 用于核对系统代理设置，lsof 用于查看端口是否监听，最后一条命令显式通过 HTTP 代理发起请求。收到 HTTP 响应说明这次请求链路有响应，但不代表全部应用都会读取系统代理。终端工具也不一定自动遵循 macOS 的图形界面代理设置。

第二轮：单独验证 TUN

  1. 暂时关闭系统代理，清除当前测试终端里自行设置的代理环境变量。
  2. 开启 TUN，查看日志中的接口创建、路由和 DNS 初始化结果。
  3. 重新发起不带 --proxy 的请求，并在客户端连接记录中核对目标、命中规则和出口策略。
unset http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
curl -I --connect-timeout 10 --max-time 20 https://example.com

这条 unset 只影响当前终端会话。普通网页本来就可能直连成功，所以“网页能打开”不足以证明 TUN 生效；应结合连接记录判断。系统中存在 utun 接口也不能单独证明它属于 Clash，因为其他 VPN 和系统功能同样可能创建该接口。

如果 TUN 开启后出现部分域名无法访问，再检查 DNS、规则和其他 VPN 冲突。权限问题通常能在启动阶段看到明确报错；单个网站超时则应进一步检查节点、规则命中与解析结果，不必重新处理应用隔离属性。

常见问题与恢复步骤

应用能打开了，为什么还需要输入管理员密码？

通过启动检查，只代表 macOS 允许运行应用。安装特权辅助服务是另一项操作，可能需要管理员授权。先确认弹窗是在安装服务时出现，还是在读取钥匙串时出现，再使用对应密码处理。

找不到“网络扩展”，是不是安装包选错了？

不一定。先查客户端采用的是网络扩展还是辅助服务方案。通过 mihomo 与特权服务实现 TUN 的客户端，不一定有可供开启的独立网络扩展条目。架构问题应通过安装包名称、系统信息和启动错误确认。

退出 Clash 后网络不通，先恢复哪一项？

先回到客户端关闭 TUN 和系统代理，再正常退出。若应用无法启动，进入「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」，检查是否残留指向本机已关闭端口的 HTTP、HTTPS 或 SOCKS 代理。只撤销确认由该客户端设置的项目，企业代理配置不要随意删除。

最终按“可信安装包 → 正确架构 → 启动放行 → 服务或扩展授权 → 钥匙串 → 网络测试”的顺序处理。每完成一步就复测一次，保留具体报错。这样既能减少重复操作，也能在需要求助时准确说明故障停在哪个环节。