先算清楚：你的订阅链接值多少隐私
多数人把订阅链接当成一个「不过是一串网址」的东西随手贴进各种在线转换网站。拆开看这串链接背后的信息量：
- 节点完整凭证：服务器地址、端口、密码/UUID、加密方式——拿到即可直接使用你的节点
- 消费关系：你订阅了哪家机场、什么套餐，消费画像清晰
- 使用习惯：配合访问日志，能还原你的使用时段和频率
把这样一份东西贴进第三方在线服务，等于把家里钥匙交给陌生店员保管——服务本身可能无害，但你的数据进了别人的数据库，后续用途不受你控制。自托管订阅管理不是极客的情怀，是敏感数据的基本卫生。
SubBoost 的数据安全设计
SubBoost（开源协议 AGPL-3.0）在数据安全上有几个值得展开的设计点：
加密存储
部署时配置的 ENCRYPTION_KEY 是订阅数据的加密密钥，远不止一个普通「配置项」那么简单：节点凭证等敏感信息以加密形态写入 PostgreSQL，数据库文件即使被拖走（服务器被入侵、备份泄露），没有密钥也读不出明文。
这带出一个重要的运维责任：密钥即数据。ENCRYPTION_KEY 丢失 = 加密数据永久无法解密。它需要和数据库备份放进同一个安全等级里管理——建议的做法是密码管理器存一份 + 离线备份存一份，绝不放在服务器本机的明文文件里裸奔（.env 文件权限收紧到应用用户可读）。
自托管的边界
自托管解决了「数据不进第三方」，但把服务器的安全责任交还给你。SubBoost 自身的攻击面控制，加上服务器的基础安全，两层都要做：
应用层：
- 管理界面走 HTTPS（反代上证书，Caddy 方案直接复用）
- 管理员账号用独立强密码——首次访问创建管理员后，这个账号控制着你全部订阅数据
- 健康检查端点（
/api/health/*）公开无妨，管理路径不暴露公网或加访问限制
系统层：
- 服务器只开必要端口（SSH 改非默认 + 密钥登录、应用端口走反代）
- Docker 部署时容器端口绑定
127.0.0.1再由反代转发，而不是直接0.0.0.0暴露 - 定期更新镜像——订阅工具处理的是网络数据，及时打补丁是基本功
这些和本站在 AgentDock 安全实践里讲的「最小暴露面」原则完全同构——自托管服务的安全清单是通用的。
备份策略：三件套
自托管订阅管理最疼的翻车不是被入侵，而是自己把自己数据搞丢：服务器磁盘坏了、迁移时忘了导出、升级时 volume 没挂对。备份抓三样东西：
| 备份对象 | 内容 | 频率建议 |
|---|---|---|
| PostgreSQL 数据 | 订阅、节点、分组、全部管理成果 | 每日自动 |
.env 文件 | ENCRYPTION_KEY 等密钥 | 变更时 + 离线保存 |
| Docker Compose 配置 | 部署定义 | 变更时 |
数据库备份一条 cron 就能自动化：
# 每日 4 点备份数据库，保留 7 份
0 4 * * * docker exec 数据库容器 pg_dump -U 用户名 数据库名 | gzip > /backup/subboost_$(date +\%u).sql.gz关键认知：数据库备份和 ENCRYPTION_KEY 必须分开存放——都放在同一台服务器上，一次入侵全部带走，加密形同虚设。密钥放密码管理器，数据库备份放备份盘/NAS，这是「分开存放」的最低标准。
在线服务与自托管的折中路线
如果暂时不想维护服务器，官方在线站点（subboost.org）提供了免部署的选项。使用在线服务时把隐私损耗控制到最低的做法：
- 只导入「损失得起」的订阅——自建节点凭证、主力机场凭证不上传
- 在线服务里只做体验和试错，定型后把体系搬回自托管
- 记得清理不再使用的在线账户
折中路线的本质是分级：数据敏感度低的操作用云，敏感资产放本地。这个思路和所有自托管决策一致——本站写 GPT-Load 网关、雷池 WAF 时都是同一个逻辑：能自己托管的敏感层，就别托管给别人的云。
自托管安全巡检清单
安全不是配完就完事，按周期过一遍这张清单：
| 检查项 | 频率 | 合格标准 |
|---|---|---|
| HTTPS 证书 | 每月 | 反代证书有效，无过期告警 |
| 端口暴露面 | 每月 | 只开必要端口，容器端口绑定 127.0.0.1 |
| 管理路径访问 | 每季度 | 管理界面未裸露公网，或已加访问限制 |
| 镜像版本 | 每季度 | 跟进官方更新，及时升级 |
| 备份任务 | 每月 | pg_dump 定时任务正常产出，抽查备份可解压 |
| 密钥存放 | 每季度 | ENCRYPTION_KEY 不在服务器明文裸放 |
| 管理员凭证 | 每季度 | 独立强密码，存于密码管理器 |
自托管常见问题 FAQ
Q：ENCRYPTION_KEY 可以中途更换吗？
把它当成「数据库的另一半」对待：密钥换了，旧加密数据的解密关系就断了。确需轮换时，先确认手里有完整的数据库备份和旧密钥，并按官方文档操作——这份谨慎和「密钥即数据」是同一件事。
Q：服务器只有我一个人用，还需要这么严吗？
需要。自托管服务的暴露面是给全网扫描器看的，和用户量无关。订阅数据里是可直接使用的节点凭证，这份数据的价值不随使用人数下降——泄露一次，全部机场账号跟着遭殃。
Q：在线站点和自托管到底怎么选？
按数据敏感度分级：在线站点适合体验功能和低敏订阅试错，定型后的完整体系（主力机场凭证、自建节点）放自托管。分级使用，不是二选一。
Q：AGPL-3.0 协议对自托管用户有影响吗？
自托管、个人使用没有任何额外义务。协议约束的是二次开发后的分发与对外服务场景——你把修改版作为网络服务提供给别人用，才需要遵守相应的开源义务。
最后一课：订阅体系的「灾备演练」
备份做了不算数，恢复演练过才算数。每半年做一次：用备份的数据库 + 密钥，在新环境里把 SubBoost 完整拉起来，确认订阅能导出、客户端能拉取。十五分钟的演练，换来的是真正需要迁移/恢复时的从容——这件事，和你的所有自托管服务都值得做一遍。