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

Tue, 26 May 2026 13:25:00 +0800

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

apt
systemd
nginx
certbot
tailscale

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Tailscale 的角色

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

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

这类方案特别适合：

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

2. 典型操作思路

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

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

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

3. 这一步为什么重要

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

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

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

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

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

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

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

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

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

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

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

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

1. 基础环境准备

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

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

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

二进制部署
Docker 部署
systemd 托管

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

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

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

先确认程序在本机端口已经成功启动
再用 curl http://127.0.0.1:端口 验证是否有响应
最后才挂到 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
自动续期方便

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

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

完成后，服务会从：

http://chen-api.cloud

变成：

https://chen-api.cloud

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

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

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

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

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

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

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

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

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

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

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

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

1. 域名解析没生效

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

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

正确顺序应该始终是：

先跑服务
再测本地端口
再接反代
再签证书

3. HTTPS 没配置完整

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tailscale on CHEN 的博客