在多渠道的现在，如何把自己的各方订阅接成个人中转？

如果你只是想把自己名下的几个订阅账号整理到一个入口里，sub2api 可以是一个实用工具。

但这件事最好先把边界讲清楚。本文讨论的是个人自用：账号是你自己的，服务是你自己搭的，API Key 也是给你自己的设备或客户端使用。至于代管、转售、共享他人账号，或者绕开上游服务本来的规则，这些都不在本文范围内。

在这个前提下，sub2api 可以被理解成一个自托管 API 网关。你把自己可控的上游账号接进后台，再让常用客户端统一走你自己的接口。官方 README 已经给出了完整部署方式，本文只是把它整理成一条更适合实际操作的路径。

目录

• [sub2api 适合什么场景](#sub2api 适合什么场景)
• 部署前准备什么
• [用 Docker Compose 快速搭建](#用 Docker Compose 快速搭建)
• 第一次登录后要做什么
• 怎么把自己的客户端接进来
• 哪些事情不要做
• 常见问题

sub2api 适合什么场景

先说适合的情况。

• 你已经有自己名下的上游账号或订阅
• 你希望不同客户端统一使用一个自托管入口
• 你想自己掌握后台、数据和密钥，不把管理入口交给第三方
• 你愿意维护一个小型服务，包括升级、备份和日志查看

它不太适合下面这些目标：

• 你只是想找一个现成商业站点，自己不想维护服务
• 你希望把别人的账号也接进来统一分发
• 你要把它当作面向陌生用户的公开平台
• 你并不想碰 Docker、服务器和基础运维

这里的区别很重要。sub2api 本身是一个网关平台，但同一个工具放在不同用法里，性质会完全不同。本文只讨论自有账号、自用访问这一类最收敛的场景。

部署前准备什么

按照官方部署说明，最省事的方式是 Docker Compose。开始前，至少准备好下面几样东西：

1. 一台能长期运行的 Linux 服务器
2. Docker 20.10 以上
3. Docker Compose v2 以上
4. 一个你能访问的域名，或者先直接用服务器 IP
5. 记账本一样保存好管理员账号和自动生成的密钥

如果你只是想先试一遍，域名不是硬要求，直接用 http://服务器IP:8080 也能验证部署是否成功。真正长期使用时，再补反向代理、HTTPS 和备份会更稳。

用 Docker Compose 快速搭建

官方 README 给出的快捷路径已经足够直接。先在服务器上创建部署目录：

mkdir -p sub2api-deploy
cd sub2api-deploy

然后执行官方的一键准备脚本：

curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/docker-deploy.sh | bash

这个脚本会做几件事：

• 下载 Docker Compose 配置和环境变量模板
• 生成 .env
• 自动生成 JWT_SECRET、TOTP_ENCRYPTION_KEY 和 POSTGRES_PASSWORD
• 创建本地数据目录，方便后续迁移和备份

准备完成后启动服务：

docker compose up -d

查看日志：

docker compose logs -f sub2api

如果你更想自己掌控每一项配置，也可以按官方手动部署流程来：克隆仓库、复制 .env.example、自己设置密码，再使用 docker-compose.local.yml 启动。对第一次搭建的人来说，一键脚本已经足够；对需要精细控制的人来说，手动流程更合适。

部署完成后，默认服务端口是 8080。如果你没有修改端口，先打开：

http://你的服务器IP:8080

能看到登录页，说明基础服务已经起来了。

第一次登录后要做什么

第一次进后台，不要急着加账号，先把基础项补齐。

1. 修改默认管理员密码

   如果你在 .env 里自己指定了 ADMIN_PASSWORD，也建议首次登录后确认一次。

2. 记录部署信息

   至少记下部署目录、端口、管理员邮箱、数据目录位置和备份方式。

3. 确认密钥已经固定

   官方部署文档建议固定 JWT_SECRET 和 TOTP_ENCRYPTION_KEY。这样重启后登录态和双因素认证不会因为密钥变化而出问题。

4. 再添加你自己名下的上游账号

   这一步只接入你自己拥有、自己控制的账号。这样后续排查问题时也最简单。

5. 给自己的客户端生成 API Key

   一个常见做法是按用途拆分，例如 desktop-main、laptop-dev、mobile-test。这样后续看日志和停用密钥都更方便。

怎么把自己的客户端接进来

大多数兼容 OpenAI API 的客户端，最终都只需要两项信息：

• Base URL
• API Key

你可以把 sub2api 看成自己这边的统一入口。客户端把请求先发给它，再由它根据后台配置把请求转给上游账号。

为了后续好维护，我建议你这样做：

• 不要所有设备共用同一个 API Key
• 不要把管理员账号和普通调用 Key 混在一起
• 一开始只接一个客户端，确认通了再接第二个
• 先做一次最简单的请求测试，再去折腾更复杂的模型和自动化

如果你后面要接反向代理、域名和 HTTPS，最好在基础调用完全跑通以后再做。问题拆小一点，排查会轻松很多。

哪些事情不要做

这部分比命令更重要。

不要把个人部署写成公开服务

一旦你开始面向陌生用户提供访问，它就已经不是"我自己用"的问题了。权限、计费、滥用、风控和合规都会变成另一套事情。

不要接入你无权管理的账号

别人给你的登录态、你无权长期控制的账号、来路不清的凭证，都不应该被放进这样的系统里。这样做不仅难维护，也会把最基础的信任边界弄坏。

不要忽略上游规则

网关只是网关，不会替你改变上游服务本身的使用规则。账号怎么用、能不能自动化、能不能转供，最终还是要看你所使用服务本身的条款。

不要把备份当成可选项

既然你选择了自建，就等于把一部分责任接回自己手里。数据库、环境变量、管理员凭据，至少都要有一份你自己找得到的备份。

常见问题

sub2api 是不是装完就能直接用？

不是。服务跑起来只是第一步。你还需要登录后台、接入自己的上游账号、生成 API Key，再让客户端使用你的 Base URL 和 Key。

我只想自己用，还需要域名吗？

不一定。第一次验证部署时，直接用 IP 和端口就够了。长期使用如果涉及多设备访问、浏览器管理和 HTTPS，域名会更方便。

为什么官方推荐 Docker Compose？

因为它会把 sub2api、PostgreSQL 和 Redis 一起编排起来，第一次部署更省事。官方文档也把 Docker Compose 作为推荐方案。

自动生成的密码需要保存吗？

需要。特别是 POSTGRES_PASSWORD、JWT_SECRET 和 TOTP_ENCRYPTION_KEY。你可以之后换成自己生成的值，但不要把它们丢了。

这篇文章为什么一直强调个人自用？

因为工具的技术用途和实际使用方式不是一回事。本文只想写一条清楚、低风险、可维护的个人部署路径，不把范围往外扩。

结尾：把它当作个人基础设施，而不是生意

sub2api 真正适合个人用户的地方，不在于它能把事情讲得多花，而在于它把几件原本零散的事收拢到一个后台里：账号、Key、日志和调用入口。

如果你的需求就是"我自己有账号，我自己搭服务，我自己用"，那它可以作为一个小而实用的基础设施来维护。先按最小范围搭起来，确认链路通了，再逐步补上域名、HTTPS、备份和更细的 Key 管理。

开始之前，先读一遍官方 README：

• 项目仓库：https://github.com/Wei-Shaw/sub2api
• 中文说明：https://github.com/Wei-Shaw/sub2api/blob/main/README_CN.md

够用就行，不必把一个个人工具写成更大的东西。

另外，想要体验，或者不想浪费时间也可以试一试现成的~
https://ai.xingmengmeng.com/register?aff=99FWFPPME396