三件事：博客迁移、Caddy 部署、ChatGPT 账号池搭建

写在前面

今天干了三件事。第一件，把博客从阿里云迁移到海外服务器。第二件，用 Docker + Caddy 重新部署博客。第三件，搭了一套 ChatGPT 多账号反代系统，让多个 GPT 账号通过 CLIProxyAPI + Antigravity 统一出口，接入 ChatWise 和 Hermes 使用。

整个过程用了 Codex + Computer Use 来辅助操作，算是一次比较完整的 AI 辅助运维体验。记录一下。

一、博客迁移：从阿里云到海外服务器

为什么搬

原因很简单：SSL 证书要钱。

阿里云的免费 SSL 证书政策收紧之后，续期和新申请都需要付费。一个技术博客，一年花几百块买证书，不值得。海外服务器配合 Caddy 或者 Cloudflare，HTTPS 证书自动签发、自动续期，零成本。

迁移的动机就这一个，没有更复杂的理由。

迁移做了什么

核心三步：

数据导出 —— 博客数据、配置文件、静态资源从阿里云打包拉下来。如果用的是 Hugo / Hexo 这类静态博客，源文件本身就在 Git 仓库里，这一步几乎零成本。
域名切换 —— 域名托管在 Cloudflare 上，直接改 DNS 记录，把 A 记录指向新服务器 IP。Cloudflare 的 DNS 生效速度很快，改完几分钟内就能解析到新机器。同时 Cloudflare 自带的 CDN 和 DDoS 防护也一并生效，不需要额外配置。
环境重建 —— 在新服务器上用 Docker 部署博客，Caddy 做反代。下面展开讲。

二、Docker + Caddy 部署博客

Docker 部署：数据映射到宿主机

博客跑在 Docker 容器里，但所有持久化数据——文章内容、配置文件、数据库（如果有的话）——全部通过 volume 映射到宿主机目录。

version: "3.8"
services:
  blog:
    image: your-blog-image
    container_name: blog
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - ./data:/app/data
      - ./config:/app/config

这样做的好处是：容器随时可以删掉重建，数据不丢。备份也方便，直接打包宿主机上的目录就行，不需要进容器里操作。

Caddy：本机安装，不走 Docker

Caddy 没有放进 Docker，而是直接装在宿主机上。

原因是 Caddy 作为最外层的反向代理，需要监听 80 和 443 端口。如果也放进容器，端口映射、容器间网络通信、证书存储都要额外处理，反而增加复杂度。本机装一个 Caddy，管理起来最直接。

安装：

sudo apt install -y caddy

为什么选 Caddy 不选 Nginx

就一个原因：配置文件简单。

同样是把 blog.example.com 反代到本地 8080 端口，Caddy 的配置：

blog.example.com {
    reverse_proxy localhost:8080
}

三行，写完了。Caddy 会自动向 Let's Encrypt 申请 SSL 证书，自动续期，自动把 HTTP 重定向到 HTTPS。不需要你操心任何证书相关的事情。

Nginx 做同样的事，需要写 server 块、配 ssl_certificate 路径、配 location 代理、配 HTTP 到 HTTPS 的 301 重定向——十几二十行配置，还得单独跑 certbot 管理证书。

对于个人博客这种场景，Caddy 的简洁是碾压性的优势。

域名：托管在 Cloudflare

域名的 DNS 托管在 Cloudflare 上。Cloudflare 和 Caddy 配合使用时有一个细节需要注意：如果 Cloudflare 开启了代理模式（橙色云朵），Caddy 自动申请证书时可能会遇到验证失败的问题，因为 Cloudflare 的代理会拦截 ACME 的 HTTP-01 验证请求。

两种解法：一是把 Cloudflare 的代理模式关掉，改成仅 DNS（灰色云朵），让 Caddy 自己管证书；二是保持 Cloudflare 代理开启，用 Cloudflare 提供的 Origin Certificate，Caddy 端配置这张证书。

我选的第一种，简单直接。

三、CLIProxyAPI：多 ChatGPT 账号反代

这是今天最折腾但也最有价值的一件事。

问题背景

手上有多个 ChatGPT 和Antigravity 账号。直接用的话，每个账号需要单独管理、单独配置到不同的客户端里。账号多了之后，管理成本很高，而且负载不均衡——一个号用到限速了，另一个还闲着。

解决方案

CLIProxyAPI 做的事情是：把多个 ChatGPT 账号汇聚成一个统一的 API 入口。它在本地起一个代理服务，对外暴露标准的 OpenAI API 格式，对内管理多个账号的 token 轮换和负载均衡。

再配合 Antigravity 做反代，整个链路：

ChatWise / Hermes（客户端）
        ↓
   Antigravity（反代层）
        ↓
   CLIProxyAPI（账号池管理）
        ↓
   多个 ChatGPT 账号

部署过程

git clone https://github.com/router-for-me/CLIProxyAPI.git
cd CLIProxyAPI

按照项目文档配置好账号信息后启动服务，然后在 Antigravity 中配置反代规则，将请求转发到 CLIProxyAPI 的监听端口。

最后在 ChatWise 和 Hermes 的 API 设置中，把 Base URL 指向 Antigravity 的地址，API Key 填 CLIProxyAPI 分配的统一 key。

配置完成后，客户端发出的每一个请求，都会被 CLIProxyAPI 自动分发到不同的 ChatGPT 账号上。单个账号触发限速时，自动切换到下一个。对客户端完全透明。

为什么接入 ChatWise 和 Hermes

ChatWise 的优势在于多模型管理和 MCP 工具生态，适合日常对话和工具调用。Hermes 更轻量，适合快速提问和移动端使用。两个客户端接入同一个反代入口，共享同一个账号池，使用体验统一且稳定，但也只是做备用。

回顾

今天这三件事串起来看，做的其实是同一件事：用尽量低的成本，把自己的工具链搭稳。

阿里云 SSL 要收费，那就换个不收费的方案。Nginx 配置太啰嗦，那就换 Caddy。多个 ChatGPT 账号管理太分散，那就建一个统一入口。

没有什么高深的技术，都是现成的工具拼在一起。但拼的过程本身，就是对自己工作流的一次梳理。

本文部署过程中使用 Codex + Computer Use 辅助完成服务器操作。