企业官网建设流程全解析

Metapi 生产环境安全加固完整清单：AUTH_TOKEN、PROXY_TOKEN 与凭证加密存储最佳实践

【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapi

Metapi 是一个自托管的 AI API 聚合网关，把你在各处注册的 New API / One API / DoneHub / Sub2API 等站点汇聚成一个 API Key、一个入口。正因如此，它管理的正是最敏感的资产：上游账号密码、管理后台令牌、下游调用密钥。Metapi 生产环境安全加固的核心，就是管好AUTH_TOKEN、PROXY_TOKEN两类令牌，并理解其凭证加密存储机制。本文给出一份可直接照做的加固清单。

一、先搞懂：Metapi 到底在保护什么？

Metapi 是"元聚合层"——它不生产 API，而是代理和路由你所有上游站点的请求。这意味着它的数据库里躺着三类"钥匙"：

Metapi 官方对这三层都做了防护设计，详见 SECURITY.md：凭证在数据库中静态加密、支持 IP 白名单、要求生产环境走 HTTPS。我们要做的，是把这些默认能力一项项"拧到最紧"。

二、两道核心令牌：AUTH_TOKEN 与 PROXY_TOKEN

AUTH_TOKEN：管理后台的"门禁卡"

AUTH_TOKEN是所有管理 API 的身份校验凭证。认证中间件 src/server/middleware/auth.ts 会严格比对请求头中的 Bearer Token，不匹配直接拒绝。

生产加固要点：

• 绝不使用默认值。首次启动默认是change-me-admin-token，只适合本机调试，暴露到公网等于裸奔；
• 生成强令牌。建议 32 位以上随机字符（可用openssl rand -base64 32生成），不要用人话单词；
• 首次启动即注入。Docker Compose 配置 docker/docker-compose.yml 中AUTH_TOKEN是必填项（缺失会直接拒绝启动），这是防止"忘记配置"的第一道保险；
• 定期轮换。AUTH_TOKEN可在后台「设置」页随时修改，保存后即时生效。

PROXY_TOKEN：下游流量的"收费闸口"

PROXY_TOKEN是下游应用（你的 Agent、CLI、客户端）访问代理接口/v1/*时携带的 Token。它支持Authorization: Bearer、x-api-key、x-goog-api-key甚至 URL?key=多种携带方式——兼容性越强，越要防滥用。

加固要点：

• 同样必须是高强度随机值，与AUTH_TOKEN务必使用不同的值（二者职责分离，泄露一个不应牵连另一个）；
• 不要把全局PROXY_TOKEN到处复制分发，团队场景优先用下面的"下游密钥"能力；
• 修改后即时生效，客户端需同步更新。

在管理后台修改令牌的步骤

1. 用AUTH_TOKEN登录管理后台；
2. 进入系统 → 设置（对应 docs/configuration.md 中的「管理员登录令牌」与「下游访问令牌」）；
3. 修改并保存——AUTH_TOKEN与PROXY_TOKEN均保存后即时生效，无需重启；
4. 用新令牌验证一次登录与一次代理请求，确认旧令牌已失效。

💡 记住一个原则：环境变量只负责"首启注入"，日常轮换都走 UI。UI 保存的值会持久化到运行数据库，并覆盖原始默认值。

三、上游凭证加密存储：ACCOUNT_CREDENTIAL_SECRET 原理

Metapi 在录入上游账号密码时，不会明文入库。核心实现在 src/server/services/accountCredentialService.ts：

• 采用AES-256-GCM加密算法（认证加密，篡改即失败）；
• 每次加密使用随机 IV，密文格式为版本:IV:认证标签:密文的 base64url 串，因此同一段密码每次加密结果都不同，无法直接对比碰撞；
• 解密密钥由ACCOUNT_CREDENTIAL_SECRET经 SHA-256 派生；未单独配置时，默认复用AUTH_TOKEN。

由此得出三条关键实践：

1. 务必单独设置ACCOUNT_CREDENTIAL_SECRET（环境变量，无 UI）。与AUTH_TOKEN解耦后，轮换管理员令牌不会"锁死"已加密的历史凭证；
2. 该密钥一旦更换，旧密文将无法解密。迁移前先用 docs/operations.md 的备份流程完整备份data/目录，并在可回滚的窗口操作；
3. 密钥只走环境变量注入，切勿写进会提交到 Git 的文件。

四、网络边界加固：HTTPS 与 IP 白名单

生产环境必须走 HTTPS / TLS

令牌在传输中一旦明文，强度再高也没用。部署指南 docs/deployment.md 提供了 Nginx 与 Caddy 反向代理模板，注意流式（SSE）响应需要关闭缓冲（proxy_buffering off），否则 AI 对话的流式输出会异常。

ADMIN_IP_ALLOWLIST：给管理后台上"门锁"

ADMIN_IP_ALLOWLIST支持精确 IP 与 CIDR 网段（如203.0.113.5或10.0.0.0/8），在令牌校验之前就拦截来源 IP（实现同样在 src/server/middleware/auth.ts）。

• 管理后台入口建议只对你的固定出口 IP / VPN 网段开放；
• 该配置可通过「设置 → 会话与安全」页面修改，保存后即时生效；
• 配合防火墙只放行 4000 端口给反向代理，进一步收窄暴露面。

五、下游密钥：用"最小权限"替代"全局 Token"

与其把全局PROXY_TOKEN发给每个同事/项目，不如使用下游密钥（管理后台：控制台 → 下游密钥），为每个使用方单独签发：

• 独立 Key，支持设置过期时间、费用上限、请求上限；
• 可配置模型白名单、路由白名单——让某项目只能访问指定模型，天然实现权限隔离；
• 可随时启停、重置用量，审计到具体 Key。

一旦怀疑某个 Key 泄露，禁用它即可，无需轮换全局PROXY_TOKEN惊动所有客户端。

六、数据与容器安全收尾项

最后这几项属于"慢功夫"，但决定了事故后的生还率：

• ✅定期备份data/目录（SQLite 模式）或数据库（MySQL/PostgreSQL 模式）——凭证密文也在里面，备份文件本身要加密存放；
• ✅.env永不入库：包含AUTH_TOKEN、PROXY_TOKEN、ACCOUNT_CREDENTIAL_SECRET的.env必须加入.gitignore，并检查历史提交；
• ✅日志不留令牌：不要把令牌贴进排障日志或截图，通知渠道配置页已对敏感字段做了回显屏蔽，排障时同样保持这个习惯；
• ✅容器最小权限：数据卷只挂载必要的DATA_DIR，保持镜像更新以获取安全补丁；
• ✅生产数据库建议用 MySQL/PostgreSQL替代默认 SQLite，便于权限控制与备份策略；
• ✅ 发现疑似漏洞时，按 SECURITY.md 的流程走私有渠道报告，不要公开张贴。

七、上线前 10 项速查清单

🔒 一句话总结：强令牌分开用、凭证加密入库、边界收紧、备份兜底。把这四件事做完，你的 Metapi 生产实例就具备了扎实的防泄露能力。

【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapi