从 GitHub Pages 迁移到国内边缘网络：网站速度提升 10 倍实录

你的博客是不是也经常遇到这种情况：

满怀期待地把新写的文章链接发到技术群里，结果几分钟后，有人回了一张截图 —— 那个令人绝望的 Chrome "连接已重置" 恐龙页面，或者是转了半天也加载不出来的白屏。

这就是 GitHub Pages 在国内的真实写照。

作为一个完全免费的静态托管服务，它是无数开发者（包括我）的启蒙之地。但在 2025 年的今天，在国内复杂的网络环境下，它已经很难承载一个“想被认真阅读”的博客了。它就像是一个“薛定谔的网站”，你永远不知道读者的下一次点击，是秒开还是超时。

于是，我决定做一次彻底的迁移。

为什么它变慢了？

很多人以为这只是单纯的“网速慢”，其实问题要复杂得多。

GitHub Pages 的服务器集群主要部署在美国东海岸和中部的几个数据中心。当你从北京发起请求时，光信号至少需要往返 20,000 公里。物理距离决定的理论最低延迟（RTT）就在 150ms 以上。

但这还不是最致命的。

由于 GitHub 的 IP 资源经常被某些灰产滥用，导致其 Anycast IP 段经常遭遇 SNI (Server Name Indication) 阻断 或 DNS 污染。这就解释了为什么有时候你的博客明明 Ping 得通，但就是打不开 —— 因为在 TLS 握手阶段，连接就被掐断了。

不想折腾服务器，还有解吗？

为了解决这个问题，以前我们通常只有两个选择：

1. 忍受：告诉读者“挂个梯子再看”。但这基本劝退了 90% 的潜在用户。
2. 折腾：买一台国内的云服务器，备案、装 Nginx、配置 SSL 证书、写 CI/CD 脚本。为了一个不盈利的博客，每年要在运维上投入几百块钱和几个周末，显然是本末倒置。

我们需要的是一种 “既有 GitHub Pages 的发布体验，又有国内 CDN 访问速度” 的方案。

这正是边缘计算平台（Edge Network）擅长的事情。

迁移实测：数据说明一切

为了验证效果，我将一个积攒了三年的 Hexo 博客（约 80 篇文章，大量图片），原封不动地“搬”到了上码（Upma）的国内边缘节点。

整个过程没有修改一行博客源码。而在同一时间段、同一网络环境下的对比测试数据，让这种迁移显得无比超值：

从“看运气打开”到“稳如老狗”，这种体验的提升是颠覆性的。

180 秒无痛迁移指南

如果你也是 Hexo、Hugo 或 VitePress 的用户，迁移过程简单到甚至不需要打开浏览器控制台。

1. 确认构建目录

对于 Hexo 用户，你的生成文件在 public 目录；对于 Hugo 或 VitePress，通常在 dist 或 .vitepress/dist。这是我们唯一需要关心的东西。

2. 执行部署

不需要配置复杂的 GitHub Actions YAML 文件。我们直接在本地项目根目录下，使用通用部署命令：

# Hexo 用户
hexo generate
npx upma deploy ./public

# Hugo 用户
hugo
npx upma deploy ./public

如果是初次使用，终端会弹出一个二维码，微信扫码即可登录。随后，你会看到文件被飞速上传。

技术揭秘：这里用到了 CAS (内容寻址存储) 技术。系统会计算你本地文件的哈希值，如果只是修改了一篇博客的错别字，系统只会上传那几 KB 的变动，而不会重新上传几百张图片。发布通常在 3 秒内完成。

3. 接管域名（关键一步）

部署成功后，你会获得一个免费的 xxx.upma.app 临时域名，速度已经飞快。但为了品牌感，你肯定希望用回自己的 blog.example.com。

在 Upma 控制台绑定你的域名，然后去你的域名服务商（阿里云/腾讯云等）添加一条 CNAME 记录。

最棒的是 SSL 证书。你不需要再去申请 Let's Encrypt 的证书并每三个月手动续期了。Upma 会自动为你申请并管理通配符证书，全站默认开启 HTTPS/2 加速。

给内容创作者的建议

写博客的初衷是分享价值，而不是学习 Linux 运维。

我们在挑选托管平台时，应该把 “访问速度” 和 “维护成本” 作为核心考量。GitHub Pages 很好，但它真的不适合面向国内读者的中文博客。

从今天开始，把那些因为“加载慢”而流失的读者找回来。毕竟，在这个快节奏的时代，没有人愿意为了看一篇技术文章而等待 10 秒钟。