macOS 安装 Clash 客户端:网络扩展授权与钥匙串权限处理

一、安装前确认架构、系统版本与应用位置

Apple 芯片与 Intel 安装包不能只看文件名

打开苹果菜单 →「关于本机」，查看“芯片”或“处理器”字段。Apple M 系列优先选择 Apple Silicon、ARM64 或 aarch64 构建；Intel 机型选择 x64 或 x86_64 构建。Universal 构建通常包含两种架构，但仍须满足客户端标明的最低 macOS 版本。

• 记录完整系统版本，例如 macOS 14.7，而不只写“Mac 系统”。
• 确认下载来源、项目名称与安装包架构；遇到来源不明的重新打包文件，应停止安装。
• 打开 DMG 后，将应用拖到「应用程序」，弹出磁盘映像，再从「应用程序」启动。
• 首次启动前退出旧客户端，避免多个程序同时更改系统代理或争用监听端口。

不要长期从 DMG 或“下载”目录运行。固定安装位置有利于更新器、辅助程序与权限记录保持一致；从不同位置启动多个副本，容易让钥匙串授权对象和实际运行对象不一致。Apple 芯片运行 Intel 构建时还可能出现 Rosetta 安装提示，这与代理权限不是同一件事。

二、Gatekeeper 提示：先判断是否允许继续

Gatekeeper 检查发生在应用启动阶段。此时内核可能还没有运行，修改订阅、DNS 或规则通常没有帮助。不同 macOS 版本的提示文案略有差异，应按提示类型处理。

可信应用的单次允许路径

1. 从「应用程序」尝试打开一次，并阅读系统提示。
2. 进入苹果菜单 →「系统设置」→「隐私与安全性」。
3. 在“安全性”区域查找刚刚被阻止的应用；只有出现对应入口且来源确认可信时，才选择「仍要打开」。
4. 完成系统要求的身份验证，再次核对应用名称后打开。

macOS 13、14、15 的入口与按钮显示条件可能不同，受管理设备还可能禁止用户自行允许。没有按钮时，应查明签名、系统兼容性或设备策略原因，而不是连续重复启动。

三、系统代理、TUN 与网络扩展分别如何授权

系统代理：让遵循系统设置的应用连接本地端口

系统代理通常把 HTTP、HTTPS 或 SOCKS 请求指向客户端的本地监听地址。它并不自动接管所有进程，也不等于建立了 TUN 接口。部分客户端可以直接更新代理设置，另一些会在安装辅助程序或修改网络配置时要求管理员验证。

在 macOS 13 及更新版本中，可进入「系统设置」→「网络」→ 当前使用的 Wi-Fi 或以太网服务 →「详细信息」→「代理」检查设置。使用系统设置搜索“代理”，也能更快找到对应入口。

• 本地地址通常是 127.0.0.1，但端口应以当前客户端配置为准。
• 若配置为 mixed-port: 7890，该端口可同时接受 HTTP 与 SOCKS 连接；这只是示例，不代表每个客户端都使用 7890。
• 设置了代理但内核没有监听对应端口时，浏览器可能立即报连接失败。

TUN：先确认客户端采用哪种实现

TUN 模式把流量引入虚拟网络接口，再交给内核处理。创建接口、配置路由或 DNS 可能需要更高权限。常见实现包括特权辅助程序启动内核，以及客户端集成的 Network Extension；两者的安装和授权流程不能互相套用。

macOS 15 可在「系统设置」→「通用」→「登录项与扩展」中检查“网络扩展”；具体项目是否出现，取决于客户端实际安装了什么。较早系统可能要求在「隐私与安全性」中允许被阻止的系统软件。应优先遵循当前系统弹窗给出的入口，并核对开发者名称。

如果客户端只安装了特权辅助程序，找不到网络扩展开关可能是正常现象。启用普通 TUN 也不意味着必须进入恢复模式降低启动安全性。只有客户端明确说明需要某类扩展时，才按其对应文档核查；不要把旧式内核扩展教程套到所有 mihomo 客户端上。

四、钥匙串弹窗：访问密码与管理员密码有何区别

钥匙串用于保存密码、令牌等敏感数据。客户端可能把订阅凭据或其他账户信息存入其中，但并非每个客户端都会这样做。出现弹窗时，应阅读请求访问的应用名称与钥匙串项目名称，而不是看到密码框就输入。

先识别弹窗类型

• “想要进行更改”并要求管理员验证：通常涉及安装辅助程序或修改系统配置，不等于读取钥匙串。
• “想要使用储存在钥匙串中的机密信息”：这是针对某个条目的访问请求，应确认条目用途。
• 要求解锁“登录”钥匙串：通常需要该钥匙串自身的密码；它不一定与当前账户登录密码同步。

如果通过账户恢复或其他方式重设过 macOS 登录密码，旧“登录”钥匙串可能仍使用原密码。此时反复输入新密码不一定能解锁。也不要把订阅服务的账户密码输入系统钥匙串解锁框，两者属于不同凭据。

“允许一次”与“始终允许”的选择

首次核对时可选择单次允许，观察客户端是否恢复读取对应配置。只有确认应用来源、条目用途与请求时机一致，才考虑持续授权。若弹窗发生在更新后，可能与应用签名或访问控制对象变化有关；不能仅凭“刚更新”就断定请求可信。

1. 按 Command + 空格，搜索并打开「钥匙串访问」。注意不要把较新系统的「密码」应用当成同一工具。
2. 选中“登录”钥匙串，用客户端名称或弹窗显示的服务名称搜索。
3. 双击确认相关条目；若该条目提供“访问控制”选项，检查允许访问的应用是否仍指向当前安装副本。
4. 不要为了省事把条目改为允许所有应用访问。只处理能确认属于该客户端的项目。

五、权限异常的定向重置与网络恢复

辅助程序反复安装：先排除多个应用副本

退出所有同类客户端，确认「应用程序」中只保留计划使用的副本，再重新启动。若客户端提供“卸载服务”“安装服务”或“修复服务”功能，应使用该客户端自身的维护入口。不同产品菜单名称并不统一，不要照搬另一款客户端的按钮路径。

完成服务维护后，先观察一次启动日志，再按需重启系统。不要手工批量删除 /Library/PrivilegedHelperTools 或 /Library/LaunchDaemons 下的文件，这些目录还包含其他软件的服务。公司管理的 Mac 若受策略限制，应联系管理员确认允许范围。

客户端退出后无法上网：检查残留系统代理

如果应用异常退出，系统代理可能仍指向已经停止监听的本地端口。先在系统设置里关闭当前网络服务中由该客户端启用的代理，再测试直接连接。以下终端命令只用于查看，第一条列出网络服务名称；后两条示例针对名为 Wi-Fi 的服务。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

如果实际服务名称不同，应使用第一条命令输出中的完整名称。读取结果时重点看 Enabled、Server 和 Port。本地地址仍存在并不一定表示代理正在生效，还要检查启用状态。

只有确认这些代理属于已退出的客户端，且不属于公司网络配置时，才可用下面的命令关闭它们。操作可能要求管理员验证；自动代理配置与自动代理发现是另外的选项，不在这三条命令的处理范围内。

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxystate "Wi-Fi" off

钥匙串持续拒绝：只重建已确认的凭据条目

先退出客户端，备份配置，并确认订阅地址、账户凭据仍可重新获取。在「钥匙串访问」中定位已确认的客户端条目；必要时仅删除该条目，再启动客户端重新导入或登录。删除钥匙串条目不会自动修复配置文件，也不会恢复已经遗失的订阅地址。

不要把“授予完全磁盘访问权限”作为通用修复。正常的代理转发不应仅因网络故障就扩大文件访问权限。只有具体功能明确需要、且客户端文档解释了用途时，才评估是否授予。

六、安装完成后的验证顺序与故障记录

1. 验证启动：从「应用程序」启动客户端，确认内核运行状态正常，日志没有持续崩溃或端口占用错误。
2. 验证配置：导入可信配置，确认策略组与出站条目存在。窗口能打开不代表订阅已经加载成功。
3. 验证系统代理：关闭 TUN，启用系统代理，打开需要验证的网页，并在连接记录中检查目标域名、命中规则与实际出站。
4. 验证 TUN：确有需求时再启用，检查接口建立、路由和 DNS 相关日志。失败时先关闭 TUN，确认系统代理路径仍可用。
5. 验证退出恢复：正常退出客户端，检查系统代理是否还原；如果没有还原，按上一节检查当前网络服务。

网页打不开但日志完全没有对应连接，优先排查接管路径；有连接且记录了规则和出站，但出现超时，再查节点、DNS 与目标服务。网络扩展已允许，只能说明系统允许该组件加载，不能证明订阅可用或目标网站一定可达。

提交反馈时保留这些信息

• macOS 完整版本、Apple Silicon 或 Intel 架构。
• 客户端版本与内核版本，分别记录，不混写。
• 弹窗的完整文字、触发操作，以及当时启用的是系统代理还是 TUN。
• 问题发生前后约 30 秒的日志，并说明是否同时运行其他 VPN、代理或网络过滤软件。

分享截图和日志前，应遮盖订阅 URL、令牌、账户信息与节点凭据。按“启动检查 → 系统代理 → TUN 或扩展 → 钥匙串”的边界逐项验证，通常比重装所有组件更容易保留线索，也能减少对现有网络设置的影响。