首页 on CHEN 的博客

从申请服务器到搭建 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

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

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

从 0 到上线：我如何搭建自己的 Hugo 博客

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

这篇笔记记录了我从一台空白 Ubuntu 服务器开始，搭建并发布自己 Hugo 博客的全过程。

这次没有走现成面板，也没有用一键脚本，而是一步一步把域名、Nginx、HTTPS、Hugo 和主题都接起来。中间踩了不少坑，但也因此把整个链路摸清了。

一、准备工作

开始之前，服务器上已经跑着一个现有站点 sub2api，域名是 chen-api.cloud。因此这次部署博客时，有一个约束条件很明确：

不能影响现有的 sub2api
博客要部署到新子域名 blog.chen-api.cloud

这个前提决定了后面的 Nginx 配置不能覆盖原站点，只能新增一个独立 server。

二、先把 Hugo 站点跑起来

一开始最先遇到的是两个典型问题。

第一个问题是命令本身输错了。我先输入了大写的 HUGO，系统直接报错：

HUGO: command not found

后来确认应该使用小写命令：

hugo

第二个问题是配置文件 config.toml 写坏了。因为我最开始用 heredoc 写文件时，把 EOF 缩进了，结果它真的被写进了文件里，Hugo 解析时报错：

unmarshal failed: toml: expected character =

修正之后，最小配置大概是这样：

baseURL = "https://blog.chen-api.cloud/"
locale = "zh-cn"
title = "CHEN 的博客"

这里最大的教训是：如果不熟悉 shell heredoc，短文件直接用 printf 或者 nano 会稳很多。

三、给博客准备最小内容

为了先验证整条发布链路，我没有一开始就上复杂主题，而是先做了一个最小首页。

最早的问题并不是 Nginx，而是 Hugo 内容文件 _index.md 写坏了。比如：

YAML 头信息没有正确闭合
每行前面多了空格
文件末尾多写了一行 EOF

这会导致 Hugo 报错：

EOF looking for end YAML front matter delimiter

修正之后，一个最小可用首页类似这样：

---
title: "首页"
---

这是我的 Hugo 博客，已经部署成功。

等 Hugo 能正常构建出 index.html 之后，才适合继续往下接 Nginx。

四、Nginx 配置必须与现有业务并存

由于服务器上已经有 sub2api，部署前先检查了当前站点配置：

sites-enabled 里已有 sub2api
它处理的是 chen-api.cloud
没有占用 blog.chen-api.cloud

这说明博客可以安全新增一个站点，而不必修改原服务。

博客对应的 Nginx 配置逻辑非常简单：

server {
    listen 80;
    listen [::]:80;
    server_name blog.chen-api.cloud;

    root /var/www/blog;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

这里有个关键判断过程。当时博客域名第一次访问并不是 404，而是：

curl: (6) Could not resolve host: blog.chen-api.cloud

这说明问题根本不在 Nginx，而在 DNS。

五、域名解析是最容易忽略的一步

之后用 nslookup 检查，发现子域名一开始是 NXDOMAIN，也就是根本没有这条记录。

必须先去 DNS 后台添加：

类型：A
主机记录：blog
记录值：服务器公网 IP

等 DNS 生效之后，再次检查：

nslookup blog.chen-api.cloud

已经能正确解析到服务器 IP，这时候再访问 HTTP，才真正走到了 Nginx。

六、403 的根因不是权限，而是没生成首页

DNS 生效之后，博客域名开始返回 403 Forbidden。

这一步很容易误判成目录权限问题，但实际排查后发现根因是：

/var/www/blog 目录里没有 index.html
Hugo 因为内容文件错误，根本没有生成首页

也就是说，403 只是结果，真正的问题还是构建失败。

这次部署最大的经验之一就是：先看生成目录里有没有实际产物，再怀疑 Nginx。

七、HTTPS 比部署本身更顺利

当 http://blog.chen-api.cloud 能返回 200 OK 后，HTTPS 基本就是顺水推舟了。

直接使用 certbot --nginx 申请并挂载证书。过程中系统提示这个域名已经存在证书，于是选择了“重新安装已有证书”，而不是重新签发。

最终验证结果：

https://blog.chen-api.cloud 返回 200 OK
certbot.timer 已启用
证书会自动续期

到这里，博客已经算正式上线。

八、换主题时又踩到了 Hugo 版本坑

博客最初虽然可用，但只是一个临时首页，不像正式博客。后来我选择切换到 Hugo Theme Stack。

主题装上之后，新的问题出现了：

function "hash" not defined

排查后发现并不是主题坏了，而是服务器自带 Hugo 版本太旧：

当前版本：0.92.2
Stack 主题最低要求：0.157.0

所以必须升级 Hugo。

九、普通版 Hugo 还不够，必须用 extended

升级到新版本之后，构建又报了另一个错误：

TOCSS: failed to transform "/scss/style.scss"

这说明我虽然把 Hugo 升级了，但装的是普通版，不是 extended 版。

而 Stack 主题会编译 SCSS，因此必须安装官方 extended 版本。

替换完成后，最终版本变成：

hugo v0.161.1+extended

到这一步，主题才真正构建成功，博客首页也切换成了卡片式布局。

十、最终结果

现在这套博客已经具备了基础可用状态：

域名：blog.chen-api.cloud
Web 服务：Nginx
证书：Let's Encrypt
博客引擎：Hugo
主题：Stack
自动续期：certbot.timer

而且整个过程没有影响服务器上原来的 sub2api 服务。

十一、这次部署里最有价值的几个经验

最后总结几条我这次最有体感的经验：

1. 不要过早怀疑 Nginx

访问异常不一定是 Nginx 配错了，也可能是：

DNS 没生效
Hugo 没生成文件
内容文件格式写坏

2. heredoc 对新手并不友好

cat <<EOF 看起来方便，但实际非常容易因为缩进、结尾位置或者误输入，把 EOF 写进文件里。

短配置更推荐：

printf
nano

3. 主题和 Hugo 版本必须一起看

很多 Hugo 主题页面能打开，不代表你的本地环境就能跑。

一定要先确认：

主题最低支持版本
是否要求 extended

4. 先打通最小链路，再追求美观

这次如果一开始就折腾主题、菜单、页面细节，排障会困难很多。

正确顺序应该是：

Hugo 能构建
Nginx 能访问
DNS 正常
HTTPS 正常
再换主题和美化

十二、下一步

博客虽然已经上线，但现在还只是第一阶段。接下来我准备继续补这些内容：

关于页
归档页
搜索页
头像和侧边栏资料
更多正式文章

这篇文章本身，就是这个博客发布出去的第一篇“建站记录”。

博客已切换到 Stack 主题

Tue, 26 May 2026 12:00:00 +0800

博客已经部署完成，并切换到了 Hugo Theme Stack。

接下来会逐步补充文章、页面和更多配置。