部署 工具

从申请服务器到搭建 sub2api 中转站：一份完整实践记录

记录我如何选择服务器和域名、配置 Tailscale 出口、部署 sub2api、接入 Nginx 与 HTTPS，并完成账号绑定。

这篇文章记录一下我从零准备一台服务器，到最终把 sub2api 跑起来并作为反代中转站使用的完整过程。

整个过程并不是单点安装某个程序，而是一条完整链路：

  • 先选服务器
  • 再选域名
  • 配好基础网络出口
  • 然后部署 sub2api
  • 再接上 Nginx 和 HTTPS
  • 最后完成账号绑定和实际可用验证

如果把这件事拆开看，每一步都不算复杂；但如果第一次做，很容易卡在某一个细节上，比如域名解析、反向代理、证书签发或者出口网络。

一、先做服务器比价，最后选择新加坡轻量云

在真正动手之前，第一步其实不是安装软件，而是先挑服务器。

我当时的思路很明确：这台机器主要是跑一个轻量级中转服务，不是数据库重负载场景，也不是需要高性能计算的业务，所以重点不是极限性能，而是下面几项：

  • 价格是否足够低
  • 海外线路是否相对稳定
  • 带宽和流量是否够用
  • 系统镜像是否方便直接上 Ubuntu
  • 控制台和安全组是否省心

这一类场景里，常见可选项一般会包括：

  • 腾讯云轻量应用服务器
  • 阿里云轻量应用服务器
  • 部分海外 VPS 厂商
  • 传统云服务器标准实例

如果只是部署 sub2api 这种中小型服务，轻量服务器通常比传统 CVM / ECS 更合适，因为：

  1. 价格更直接
  2. 自带公网 IP
  3. 管理界面简单
  4. 比较适合个人项目或中小流量工具站

综合权衡之后，我最后选择了腾讯云新加坡区域的轻量云服务器。

这个选择背后的考虑大致有三点：

  1. 新加坡区域在亚洲访问延迟相对更友好
  2. 对个人用途来说，价格和稳定性比较平衡
  3. 后续配域名、Nginx 和证书都很常规，资料比较多

系统方面，直接选择 Ubuntu 就够了。后续所有部署动作基本都围绕下面这些组件展开：

  • apt
  • systemd
  • nginx
  • certbot
  • tailscale

二、域名不需要贵，但最好专业、好记、能长期用

服务器确定之后，下一步就是域名。

我当时没有去买特别昂贵或者过于花哨的后缀，而是选择了一个 cloud 结尾的域名。原因很现实：

  • 价格便宜
  • 可选空间相对多
  • 看起来比很多冷门后缀更正式
  • 用在技术服务和工具站上违和感小

对个人项目来说，域名最重要的不是“看起来很高级”，而是：

  1. 便于记忆
  2. 不容易输错
  3. 适合长期续费
  4. 作为主域名时不显得太随意

最后我用这个域名同时承载了不同用途：

  • 主服务走主域名
  • 博客走子域名
  • 后续不同组件都可以拆分到不同子域名下

这种方式的好处是结构清晰，后续扩展也方便。

三、先把流量出口问题想清楚：用 Tailscale 把本机作为出口

部署 sub2api 这种服务时，一个非常实际的问题是：服务运行在服务器上，但某些访问链路未必适合直接走服务器本地网络。

所以我当时的处理思路是：

  • 在服务器上安装 Tailscale
  • 把自己的本地设备加入同一个 tailnet
  • 让本机作为出口节点
  • 使服务器的相关流量通过本机出口转发

这么做的核心价值，不在于“更酷”，而在于网络路径可控。

1. Tailscale 的角色

Tailscale 本质上是一个基于 WireGuard 的组网方案。它的优点是：

  • 安装简单
  • 节点互联快
  • 不需要自己维护传统 VPN
  • 可以很方便地指定出口节点

这类方案特别适合：

  • 个人多设备协同
  • 家里电脑和云服务器互通
  • 临时把一台设备当作统一出口

2. 典型操作思路

这一部分大致会包含下面几个动作：

  1. 在本机安装 Tailscale
  2. 在云服务器安装 Tailscale
  3. 登录同一个账号或组织网络
  4. 在本机开启 exit node 能力
  5. 在服务器侧指定该 exit node

从结果上说，就是服务器虽然部署在云端，但某些流量可以按你的规划经由本机网络出去。

3. 这一步为什么重要

很多人搭服务时，默认认为“服务器能联网就够了”。但实际一旦进入真实使用，网络出口路径、可访问性、登录状态和上游连接稳定性都会影响最终可用性。

所以我认为，Tailscale + exit node 并不是额外花活，而是这类中转服务里非常实用的一环。

四、账号准备：把环境准备和服务部署分开看

这一步我更愿意把它理解为“账号环境准备”，而不是部署本身的一部分。

因为从工程角度看，服务器、域名、代理、证书、服务进程，这些都是基础设施问题；而账号登录、订阅状态、客户端绑定，则更接近上游服务接入问题。

我这里不展开写过细的支付或区域性操作细节，只保留思路层面的经验：

  • 尽量把账号环境准备和服务器部署分开处理
  • 优先保证账号本身状态正常可登录
  • 再去做后面的 OAuth 绑定

这样做的好处是排障更清楚。否则一旦失败，你很难判断问题到底出在：

  • 服务器网络
  • 反向代理
  • HTTPS
  • OAuth 回调
  • 还是账号自身状态

五、正式部署 sub2api：先让服务能跑起来

当服务器、域名和网络出口都准备好之后，就可以进入真正的服务部署阶段。

这一部分的目标不是先追求“最优雅”，而是先让 sub2api 在服务器上稳定跑起来。

1. 基础环境准备

最常规的准备动作一般包括：

  • 更新系统软件包
  • 安装 Git、Nginx 等基础依赖
  • 准备运行目录
  • 规划监听端口

如果服务本身有独立的启动方式，还需要考虑：

  • 二进制部署
  • Docker 部署
  • systemd 托管

从长期维护角度看，我更偏向把服务交给 systemd 或容器托管，而不是单纯用一个前台命令挂着。

2. 先本地端口可访问，再接入反代

这一类服务的正确调试顺序通常是：

  1. 先确认程序在本机端口已经成功启动
  2. 再用 curl http://127.0.0.1:端口 验证是否有响应
  3. 最后才挂到 Nginx

如果一上来就把所有东西混在一起，很容易出现：

  • 服务本身没起来
  • Nginx 也没配对
  • 证书还没签

然后排障就会变得很乱。

六、Nginx 反代：把服务挂到域名上

sub2api 真正对外可用，关键还是靠 Nginx。

常见结构就是：

  • 上游应用监听本地端口，例如 127.0.0.1:3000
  • Nginx 对外监听 80 和 443
  • 外部流量先到 Nginx
  • 再由 Nginx 转发给 sub2api

一个典型的反代思路会像这样：

server {
    listen 80;
    server_name chen-api.cloud;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里的关键不是把配置背下来，而是理解这几个事实：

  • 应用服务尽量只监听本地
  • 公网入口统一交给 Nginx
  • 反代时要把请求头带完整
  • 后面签 HTTPS 会更顺

七、HTTPS 证书是上线的必要条件，不是可选项

当 HTTP 反代已经打通之后，下一步就应该立刻上 HTTPS。

这一步通常会用 certbot + nginx 组合完成。它的好处是：

  • 配置直接
  • 自动改 Nginx
  • 自动续期方便

只要满足下面几个条件，一般就可以顺利签证书：

  1. 域名已经正确解析到服务器公网 IP
  2. 安全组放通了 80 和 443
  3. Nginx 对该域名的 server_name 配置正确
  4. 外部可以通过 HTTP 正常访问到站点

完成后，服务会从：

  • http://chen-api.cloud

变成：

  • https://chen-api.cloud

这不仅是为了浏览器地址栏更好看，更重要的是：

  • OAuth 回调通常更依赖稳定的 HTTPS 环境
  • 中转服务对安全链路要求更高
  • 长期使用时也更规范

八、登录 sub2api 后，通过 OAuth 绑定上游账号

当反代和 HTTPS 都打通之后，才真正进入“业务可用”阶段。

这时一般会做下面几件事：

  1. 打开 sub2api 的管理界面
  2. 登录后台
  3. 找到账号绑定或授权入口
  4. 通过 OAuth 流程绑定 GPT 账号

这一部分最重要的其实不是“点哪个按钮”，而是确保下面三个前置条件已经成立：

  • 站点已经能被公网稳定访问
  • HTTPS 正常
  • 回调链路没有被错误代理或拦截

如果 OAuth 绑定异常，大概率优先排查这些问题：

  • 域名是否正确
  • 证书是否正常
  • Nginx 是否正确转发头信息
  • 服务端日志里有没有回调报错

九、整套链路里最容易出问题的地方

回头看，这一套流程真正容易卡住的地方并不只在安装服务本身，而是在几个看似琐碎的环节：

1. 域名解析没生效

很多“站点打不开”的问题，其实不是程序没跑，而是域名还没指到服务器。

2. 服务没起来就开始配 Nginx

正确顺序应该始终是：

  1. 先跑服务
  2. 再测本地端口
  3. 再接反代
  4. 再签证书

3. HTTPS 没配置完整

证书签发成功，不代表整个 HTTPS 链路一定完全可用。还要看：

  • Nginx 是否正确加载证书
  • 443 是否放行
  • 回调链路是否仍然走错地址

4. 把账号问题误判成部署问题

如果上游账号本身状态不对，哪怕服务器、Nginx、证书全都正确，也依然会表现成“服务不可用”。

所以部署和账号准备必须分开排查。

十、最后的结构其实很清晰

等整条链路走通之后，这套架构本身并不复杂：

  • 一台海外 Ubuntu 服务器
  • 一个正式域名
  • Tailscale 作为可控网络出口方案
  • sub2api 作为核心服务
  • Nginx 负责公网入口与反向代理
  • Let's Encrypt 负责 HTTPS
  • OAuth 完成上游账号绑定

从结果上说，这已经是一套足够个人长期使用的中转服务结构。

它未必是唯一方案，也不一定是最“高级”的方案，但对个人部署来说，胜在：

  • 成本可控
  • 结构清晰
  • 易于维护
  • 扩展方便

十一、如果让我再做一次，我会坚持这个顺序

最后总结一下，如果让我重新从零做一遍，我仍然会按这个顺序来：

  1. 先选服务器和区域
  2. 再买域名并规划子域名
  3. 先解决网络出口问题
  4. 再部署 sub2api
  5. 然后配置 Nginx
  6. 最后接 HTTPS 和 OAuth

因为只有按这个顺序，排障成本才最低。

很多时候，真正节省时间的不是命令敲得有多快，而是步骤顺序有没有走对。

© 2026 CHEN 的博客
使用 Hugo 构建
主题 Stack 由 Jimmy 设计