小内存 VPS 部署 sub2api 规划笔记

手上有一台小内存 VPS，想给自己搭一个统一的 AI API 入口？这篇是我们在一台 2 核、1.6G 内存 + 2G swap 的 Ubuntu 24.04 服务器上规划部署 sub2api 的笔记。重点是两件事：怎么把内存压住，不把机器上已有的网站挤垮；以及怎么只给自己用、不暴露到公网。

先说明：这是一份规划，写于 2026-10-16，最终没有执行安装，所以文中没有部署后的运行数据。文中标 [当天读数] 的是那天在这台服务器上查看到的数字，标 [估算] 的是推算值，标「待核实」的部署时要再验证。

先读这一段：条款和封号风险

sub2api（GitHub，LGPL-3.0）的 README 把自己定位为"订阅额度分发平台"，主打把 Claude、ChatGPT 等个人订阅账号通过 OAuth（一种授权登录方式）转成 API。这篇笔记不讲、也不建议这种用法。 原因如下（条款原文均在 2026-10-16 打开核对）：

• Anthropic 消费者条款（原文）：除非通过 Anthropic API Key 或官方明确允许，禁止通过脚本等自动化方式访问服务；禁止共享账号或让他人使用账号；禁止转售。条款没有为"个人自用"开例外，所以即使不分享，用第三方程序调用订阅也绕不开"自动化访问"这一条。
• OpenAI 使用条款（ChatGPT 等个人服务，2026-01-01 生效版本，原文）：禁止共享账号凭证；禁止程序化提取输出、绕过速率限制。
• Google Gemini、xAI Grok：消费者条款本次没有核实原文，「待核实」，在核实前按同样有风险处理。
• sub2api 作者自己的提示：使用本项目可能违反上游服务商条款，一切风险由用户自行承担，作者不对账户封禁负责。
• 后果：服务商有权暂停或终止账号，订阅费一般不退；会不会被封、多快被封，无法预测。

所以本文的前提是：上游只接你本人、通过正规渠道申请的官方 API Key（比如 Anthropic API、OpenAI API 这类按量付费、条款允许程序调用的服务），网关只有你一个人用。不分享 key、不拼车、不转售、不开放注册。

坦白讲：如果只接官方 API Key，sub2api 最大的卖点就用不上了，而且它要 PostgreSQL + Redis，比可以用 SQLite 的 new-api 更重。选型对比见new-api 和 sub2api 怎么选。如果你还是想用 sub2api，再往下看。

机器现状：还剩多少内存

2026-10-16 用 free -m、ps、df -h 只读查看的结果：

available 比 free 更能代表"还能塞多少东西"，因为它把可回收的缓存也算进去了。机器上已经跑着网站和几个常驻服务，最大的一个占了约 296MB [当天读数]，它以后可能增长，是最大的不确定因素。

新服务要吃多少

sub2api 的 README 没写资源要求（「待核实」），下面是按单用户场景的估算：

装完后，乐观剩约 690MB，悲观剩约 510MB；就算三个服务都顶到下面设的硬上限（合计 424MB），也还剩约 400MB 给原有服务。

方案：不用 Docker，原生安装

内存紧张时，Docker 本身也要占资源，所以规划用 apt 装 PostgreSQL 和 Redis，sub2api 用官方预编译的二进制文件，全部交给 systemd（Linux 管理后台服务的工具）。

用 systemd 给每个服务设内存上限

systemd 可以给单个服务设内存"天花板"：MemoryHigh 是开始回收的软上限，MemoryMax 是硬上限，超了只会杀掉这个服务本身，不会连累其他程序。

OOMScoreAdjust 调高，意思是系统真的内存不够时，优先杀这几个新服务，保住网站。示例（用 systemctl edit sub2api 写入）：

[Service]
MemoryAccounting=yes
MemoryHigh=160M
MemoryMax=200M
MemorySwapMax=100M
OOMScoreAdjust=500
Restart=on-failure
RestartSec=10

Redis 的 swap 上限设 0，因为它被换到硬盘上会让延迟暴涨，宁可重启。

PostgreSQL：单独建一个小集群

用 pg_createcluster 16 sub2api --port 5433 单独建集群，不影响机器上其他数据库。关键调优：

listen_addresses = '127.0.0.1'
port = 5433
max_connections = 20
shared_buffers = 32MB
work_mem = 2MB
max_parallel_workers = 0
max_wal_size = 256MB

pg_hba.conf 只允许本机的 sub2api 用户用密码登录。sub2api 那边的连接池上限想设到 10 以内，但是否有这个配置项「待核实」。

Redis：为什么选 noeviction

bind 127.0.0.1
port 6380
requirepass <至少 32 位随机密码>
maxmemory 48mb
maxmemory-policy noeviction

据 README，Redis 在 sub2api 里负责缓存、队列、并发限制和会话。如果用"内存满了自动删旧数据"的策略，可能导致限流失效、会话错乱；noeviction（满了就报错、不删数据）能让问题暴露出来。单用户 48MB 应该够，日志里出现写入报错再加到 64MB。为安全可以禁用 FLUSHALL、CONFIG 等危险命令，但 sub2api 是否需要 CONFIG 命令「待核实」。

安全：只监听本机，只走 SSH 隧道

• 所有服务只绑 127.0.0.1（只有本机能访问）。注意 README 示例里 sub2api 默认监听 0.0.0.0（所有网卡），安装向导也会让你用"服务器 IP:8080"打开，一定要改成 127.0.0.1。
• 不开公网端口，防火墙不新增入站规则，不改现有的 nginx 和网站配置。
• 访问方式用 SSH 隧道，把服务器的 8080 端口"接"到你电脑上：

ssh -N -L 8080:127.0.0.1:8080 用户名@你的服务器

然后浏览器打开 http://127.0.0.1:8080，客户端的 base URL 也指向这里。需要手机等多设备访问时，可以考虑 Tailscale 这类组网工具，同样不开公网端口。

• 独立系统用户 sub2api，配置文件 600 权限；systemd 加上 NoNewPrivileges、ProtectSystem=strict 等加固项。
• 不要 curl ... | sudo bash 一键安装：下载固定版本，先看脚本、校验 checksum，再手动执行。
• 管理员密码 20 位以上并开两步验证（README 提到支持 TOTP）；关闭注册、不启用支付；README 提到的 Simple Mode（RUN_MODE=simple）适合单人使用，具体参数以所装版本为准（「待核实」）。

部署步骤（规划）

1. 备份：记下 free -m、ss -ltnp（看哪些端口在监听）、服务列表的快照。
2. apt 安装 PostgreSQL 16 和 Redis，建 5433 集群和 6380 实例，写入上面的配置。
3. 建 sub2api 用户，放固定版本二进制，写 systemd 服务（监听 127.0.0.1:8080）和内存上限。
4. 启动，通过 SSH 隧道打开安装向导，建管理员、开两步验证。
5. 只添加你本人的官方 API Key 作为上游，再给自己建一个调用 key。
6. 验证：ss -ltnp 只能看到 127.0.0.1 上的新端口；网站访问正常；原有服务正常。
7. 观察一周。

日常监控和回滚

• 每天看：systemctl status 三个服务；systemd-cgtop -m 看各服务内存；free -m 看 available。
• 告警线：available 低于 250MB、swap 用量超过 600MB，或日志里出现 oom-kill（内存不足被系统杀进程）。
• 备份：每天 pg_dump 导出数据库，压缩保留 7 天；预计数据库加日志不到 1GB。
• 回滚：停用三个服务；需要的话先 pg_dump 留底，再 pg_dropcluster 删集群；删掉程序目录、数据目录、配置和系统用户；最后到上游控制台吊销给 sub2api 用的 API Key。因为没改网站和 nginx，回滚不影响网站。

小结

• 在 1.6G 内存的 VPS 上跑 sub2api 可行：原生安装 + systemd 内存上限，最坏也留约 400MB 给原有服务。
• 安全靠"只监听本机 + SSH 隧道"，不开公网端口。
• 最大的风险不在技术，而在条款：只接自己的官方 API Key、只给自己用，别接订阅账号，别分享或转卖。

如果你只是想要一个轻量的个人 AI 网关，也可以考虑 new-api 的 SQLite 部署方式，我们之后会在「部署与实验」栏目里写。小内存服务器的内存上限和 SSH 隧道访问，后面也会单独成篇。选型对比可以先读new-api 和 sub2api 怎么选。