sub2api完整部署实战，网页账号转换成标准OpenAI
很多工具链只认 OpenAI 格式的接口，但真实账号又是网页版。
sub2api 就是把这类网页账号转换成标准 OpenAI API 接口的代理服务，部署后可以统一接入 ChatBox、沉浸式翻译或自定义脚本。
本文从零开始讲清楚部署条件、操作命令和验证方法，照着做就能把服务跑起来。
部署前要准备什么
准备一台能长期在线的 Linux 服务器，建议系统为 Ubuntu 20.04 或 Debian 11 以上版本。
需要提前装好 Docker 和 Docker Compose 插件，没有装的话先执行这两条命令：
curl -fsSL https://get.docker.com | bash
systemctl enable --now docker此外要能正常访问你需要转换的网页服务，部分上游接口存在地区限制，服务器地区选错会导致连接失败。
建议先确认服务器到上游服务之间网络通畅。
用 Docker Compose 启动 sub2api
先创建项目目录并进入：
mkdir -p /opt/sub2api && cd /opt/sub2api在当前目录新建 docker-compose.yml，内容参考如下：
services:
sub2api:
image: ghcr.io/sub2api/sub2api:latest
container_name: sub2api
restart: always
ports:
- "3000:3000"
volumes:
- ./data:/app/data
environment:
- PORT=3000
- DATABASE_PATH=/app/data/sub2api.db配置好后启动：
docker compose up -d启动后可用 docker compose logs -f 查看运行日志，看到监听端口相关的输出就说明启动正常。
注意镜像名和标签会随项目更新，建议发布前先到项目仓库确认最新镜像地址。
添加网页账号并生成 API Key
服务启动后，通过浏览器访问 http://服务器IP:3000 打开管理面板。
首次访问会引导你创建管理员密码，这个密码用于登录后台，不要和接口令牌混淆。
登录后进入账号管理页面，填入你已有的网页版账号 Cookie 或登录凭证。
不同服务添加方式略有区别，但核心都是把“账号令牌”存储到 sub2api。
保存成功后，在令牌管理页生成一个新的 API Key，这里生成的 Key 就是后续传给 OpenAI 客户端使用的密钥。
如果访问不了面板，检查服务器安全组是否放行对应端口，本地可以用 curl http://127.0.0.1:3000 先确认服务进程本身正常。
验证转换后的 OpenAI 兼容接口
拿到 API Key 后，先用 curl 做一次最小化验证，判断转换链路是否完整。
curl http://你的服务器IP:3000/v1/chat/completions \
-H "Authorization: Bearer 你的APIKey" \
-H "Content-Type: application/json" \
-d '{"model": "任意模型标识", "messages": [{"role": "user", "content": "你好"}]}'如果返回 JSON 数据且包含 choices 字段，说明接口已经生效。
再把 API 地址改成 http://你的服务器IP:3000/v1 填入 OpenAI 兼容客户端，同样填上刚才的 Key 即可正常使用。
避坑提醒和高频问题
账号会话过期是最常见的问题。
网页账号的 Cookie 通常有时效，过期后接口会返回 401 或 403，需要定期更新。
建议在管理面板中留意状态提示，或写一个定时任务自动检测。
端口被占用会导致启动失败。
如果 3000 端口已被其他服务占用，改一下 docker-compose.yml 里的宿主机映射端口即可。
反向代理时注意路径。
如果用 Nginx 转发，务必把 /v1 和面板路径都代理到 sub2api 容器，并开启 WebSocket 支持，否则流式输出会断。
还有一点容易被忽略：sub2api 只是格式转换，并发能力和稳定性取决于上游账号质量与服务器带宽。
不同账号类型支持的最大并发数不一样，转换后不代表可以无限并发。
如果你也打算在生产环境长期使用，建议先把账号会话、端口映射和反向代理这三项确认好，再接入主要业务。
遇到接口报错时，优先查看 docker compose logs 和上游账号状态，多数问题都能快速定位。
