客户端指南

Mihomo 的 age-secret-key 能保护订阅吗？公钥和私钥别放反

age-secret-key 用于解密 age armor 格式的 proxy-provider 内容，不会隐藏订阅 URL，也不替代 HTTPS、访问认证或来源核验。

发布于 2026/8/24 · 更新于 2026/8/24 · 3 项可核验来源

先看重点`age-secret-key` 是留在本地的解密私钥，只能打开服务端按对应公钥加密的 age armor 格式 provider。它不会自动隐藏订阅 URL、请求凭据或已经加载的节点，也不能证明配置来源可信。`age1...` 公钥可以交给服务端；`AGE-SECRET-KEY...` 私钥只应留在受控设备。

机场后台写着“age 加密订阅”，旁边给了一串 age1...；另一份配置里却出现 AGE-SECRET-KEY...。两串字符看着很像，作用正好相反。把后者发给客服、贴进群聊或公开配置，等于把解密能力也交了出去。

真正该保密的是 secret key。 Mihomo 的这项功能只负责解开经过 age 加密的 provider 内容，不会把普通订阅自动升级成“加密订阅”，更不是隐藏订阅地址和账号凭据的一键开关。

它包住的是 provider 文件内容

Mihomo 的 proxy-providers 可以从 URL 下载节点集合。官方文档说明，配置了 age-secret-key 时，内核会尝试用这把私钥解密 age armor 格式的配置文件。v1.19.27 的官方发布记录列出了这项能力以及相应的校验错误处理。

这条数据路径里仍然存在 provider 的 url、请求头、更新间隔和下载出口。age 加密改变的是服务端返回的文件内容：没有匹配私钥的一方拿到密文，也不能直接读出里面的节点配置。它不会抹掉 URL，也不会替 HTTPS 核验服务器身份或替访问 token 完成授权。

服务端还必须先按你的公钥加密内容。普通 YAML 不会因为本地多写一行 age-secret-key 就变成密文；Mihomo 也不会主动把公钥发给服务端。官方文档提供了 X-Age-Public-Key 请求头作为一种传递方式，同时保留由服务方通过其他方式取得公钥的可能。

公钥可以交给服务端，私钥只能留在设备

age 官方项目把 recipient 定义为用于加密的公开值，把 identity 定义为用于解密的私密值。Mihomo 文档里的命名与这层关系一致：

常见开头	角色	合适的去向
`age1...` 或 `age1pq1...`	公钥 / recipient	交给明确支持该功能的服务端，用来生成发给你的密文
`AGE-SECRET-KEY-1...` 或 `AGE-SECRET-KEY-PQ-1...`	私钥 / identity	只留在需要解密 provider 的受控设备或本地密钥配置中

公钥出现在请求头或服务后台并不等于私钥泄露。反过来，私钥即使没有附带订阅 URL，也不适合发进工单截图：拿到对应密文的人可能用它解开原本发给这把密钥的内容。

Mihomo 还支持通过命令行参数或 CLASH_AGE_SECRET_KEY 环境变量加载私钥，但图形客户端是否暴露、保存或同步这些设置属于客户端自己的实现。不能因为内核文档有字段，就假定任意 Clash 界面已经安全接入。

能解密，不代表来源已经可信

任何拿到公钥的人都可以为它生成密文。由此可知，成功解密只能说明内容与这把私钥匹配，不能单独证明是谁生成了文件。服务端域名、HTTPS、账号认证和配置来源仍要分别核对。

通过 proxy-providers 解开的内容仍是一组代理条目。它可以提供预期节点，也可能把连接交给你并不信任的服务器，或带着陌生的协议参数；age 不会审查这些条目是否安全。若使用命令行参数或环境变量解密整份 Mihomo 配置，范围才会进一步包括 DNS、路由和远程资源。相关权限边界可对照陌生 Clash 订阅能执行脚本吗。

同样地，这项功能不保证本机解密后的信息永远不可见。内核必须读取节点才能使用它们，客户端界面、运行日志、配置备份和设备权限都会形成新的暴露面。公开求助前仍应按代理日志脱敏方法遮住节点凭据、请求头和密钥。

provider 仍加载失败：核对 armor、密钥和内核版本

官方当前限定得很具体：远端内容需要使用 age 的官方 ASCII armor 格式，密钥类型支持 X25519，以及 ML-KEM-768 与 X25519 的混合类型。内核版本还要包含 v1.19.27 引入的这项功能。

这些条件只要错一项，结果都可能是 provider 无法加载：服务端仍返回普通 YAML，密文加给了另一把公钥，私钥格式不受支持，或者客户端实际运行的内核太旧。服务端没有收到公钥也很关键，因为 Mihomo 不会自动上报；这不是靠反复刷新订阅就能补齐的步骤。

本文没有拿你的服务端、密文或客户端做兼容性测试，也不提供一段可直接粘贴的真实密钥示例。服务商若只让你提交私钥，却说不清公钥怎样使用、返回格式是什么，先不要继续；正常设计只需要服务端取得公钥。

私钥泄露后，订阅 token 可能还要另行处理

私钥和订阅 token 保护的对象不同。更换 age 密钥后，服务端要改用新公钥生成密文，旧私钥才不会继续打开后续内容；订阅 URL 中的 token 若也公开过，还要在机场后台单独重置。只换其中一项，不能自动让另一项失效。

已经把私钥贴进公开仓库、群聊或工单时，不要只删除消息。在受控设备上生成新的密钥对，只把新公钥交给服务方，并让对方停止使用旧公钥加密；同时检查公开内容里是否还带着订阅 URL、Authorization 或节点凭据。订阅链接本身的处置可参考订阅链接泄露后的处理方法。

如果服务商没有明确提供 age provider，这个字段无需为了“更安全”自行添加。它解决的是双方已经约定好公钥加密时的配置内容保密问题；来源可信、访问授权和本机密钥保管，仍是三件独立的事。

资料来源

以下来源于 2026/8/24 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题