来源: https://t.me/appshub_channel/276
首先，快速说下这是用来干嘛的，说白了就是用来加密(订阅)文件用的，使用了密钥对之后，只有当你有了Private key(下面统称为私钥)之后，才能打开由对应的Public key(一下统称为公钥)加密的(订阅)文件
事情的缘由大概是这样，某知名客户端CVR搞了一套叫CVD的东西出来，美其名曰: 环境恶劣，保护订阅，对抗封锁，以wwq为首的Mihomo内核组在看过方案之后对比嗤之以鼻，认为其方案不仅实现非常一般并且会导致用户失去了选择权，同时有泄露用户隐私或(硬件ID)被精准定位的风险等，具体细节请参见相关公开讨论，这里不开CVR吐槽大会，只看事情本身，篇幅原因也不做过多评价，了解即可
在上述事情的催化下，Mihomo在1.19.26版本发布还不满一周的情况下，火速更新到了1.19.27正式版并顺势推出了Age key功能，如果站在机场主的角度，订阅在国内平台传播被肆意抓取显然不是一件好事情，结合前面的介绍可以得出一个结论，Age Key(能)解决的最大的事情，还是订阅被公开抓取或者滥用的问题(以及个人可以使用Gist)，因为订阅文件被强制加密，只有你手里有私钥才能解开
(我认为的)常见的理想中的情况1 : 机场使用公钥对订阅文件进行加密，后台面板应有对应的一键复制私钥(再次小科普一下，公+私是一对，所以叫做密钥对)，流程: 用户首先导入Url订阅，但是只有填写(复制后台面板的)正确的私钥后，订阅文件才能被正常解析打开。
另外一种情况2 ，则是由用户自己生成密钥对，把公钥填入机场后台面板后，然后再由机场加密下发，依然是只有填写(自己生成的)正确的私钥后，订阅文件才能被正常解析打开。
补充:情况3 ，用户自己生成密钥对，可以在导入订阅文件时，在header里主动带上请求头X-Age-Public-Key(公钥)，机场后端收到后，然后再(使用公钥)下发加密订阅，大致流程其实和情况2 一致，这种方式可以免去用户再去机场面板后台操作，也更加适用于自己写配置添加Providers规则
相关内容:
