目 录CONTENT

文章目录

【用CF加速halo】通过域名托管到 cloud flare 让 halo 博客网站使用国外的非优化线路也能做到国内秒开

JIN
JIN
2026-02-22 / 0 评论 / 0 点赞 / 30 阅读 / 0 字
广告 广告

Halo(海外VPS)用 Cloudflare Workers 加速:把“随机红省份”变成稳定秒开(第一阶段)

适用场景:Halo 部署在海外 VPS,国内访问经常 TTFB 很高,测速(itdog 之类)出现 部分省份绿、部分省份红 的“随机现象”。
第一阶段目标:让 HTML 页面也能被 Cloudflare 边缘缓存,并且避免因域名/跳转导致缓存碎片化。


0️⃣ 你要先理解一件事:你慢的不是“站坏了”,而是“回源”发生了

你看到的“同一时间,有的省 0.2s,有的省 10s”,通常意味着:

  • 有的节点命中了缓存(HIT)→ 秒开
  • 有的节点没命中(MISS)→ 回源到海外 → 直接红

所以第一阶段的核心不是换机房、换线路,而是:

把 Halo 生成的 HTML 也交给 Cloudflare 缓存,并且让缓存键稳定一致。


1️⃣修正 Halo 的 external-url)

否则缓存会被域名“撕碎”

很多人以为 Halo 后台“外部访问地址”能改,其实 Halo2 后台可能是只读的;真正生效的是启动参数:

  • --halo.external-url=...

如果你仍然是这种:

  • http://localhost:8090/

那就会出现一种非常致命的情况:

  • 你访问的是 https://www.xxx.com
  • 但 Halo 输出的 canonical、链接、API 地址仍然是旧域名/localhost
  • Cloudflare 看到“同内容不同 URL/跳转链”,缓存会碎、命中率会乱

1.1 进入 halo 目录,修改 docker-compose.yml

cd /root/data/docker_data/halo
nano docker-compose.yml
- --halo.external-url=http://localhost:8090/

改成你的最终访问域名(推荐统一用 www + https):

- --halo.external-url=https://www.jinruncheng.blog/

⚠️ 注意末尾的 /:建议保留,避免 Halo 生成链接时出现奇怪的拼接。

1.2 重启 Halo

docker compose down
docker compose up -d

建议等 20~30 秒,让 Halo 完全起来。


2️⃣ 创建 Cloudflare Worker

很多教程让你去 “Workers & Pages” 里找 Route,容易走错。

正确路径:先进入你的域名(Website)内部再操作

2.1 进入域名面板

  • Cloudflare 首页 → Websites → 点击你的域名

2.2 创建 Worker(新版位置)

在域名左侧菜单找:

  • Compute (Workers)Create application → 选择 WorkerStart with Hello World

3️⃣ 替换 Worker 代码

把默认 Hello World 全删,粘贴下面这份(核心逻辑:绕过后台/API/登录态/非GET/静态资源,只缓存游客 HTML):

(Halo 专用代码)

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // 不缓存后台
    if (url.pathname.startsWith("/console")) return fetch(request);

    // 不缓存 API
    if (url.pathname.startsWith("/apis")) return fetch(request);

    // 不缓存登录态
    const cookie = request.headers.get("cookie") || "";
    if (cookie.includes("token=") || cookie.includes("JSESSIONID")) return fetch(request);

    // 只处理 GET
    if (request.method !== "GET") return fetch(request);

    // 静态资源交给 CF 默认处理
    if (url.pathname.match(/\.(js|css|png|jpg|jpeg|gif|webp|svg|ico|woff|woff2)$/i)) {
      return fetch(request);
    }

    // 只缓存 HTML(更稳,避免误缓存其他类型)
    const accept = request.headers.get("accept") || "";
    const isHtml = accept.includes("text/html");
    if (!isHtml) return fetch(request);

    // 缓存 Key(可选:这里保持原样,不做参数清洗)
    const cacheKey = new Request(url.toString(), request);
    const cache = caches.default;

    // 查缓存
    let response = await cache.match(cacheKey);
    if (response) return response;

    // 回源 + 强缓存策略
    response = await fetch(request, {
      cf: {
        cacheEverything: true,
        cacheTtl: 86400, // 1天
        cacheTtlByStatus: {
          "200-299": 86400,
          "404": 60,
          "500-599": 0,
        },
      },
    });

    // 写入 Cache API
    const newResponse = new Response(response.body, response);
    newResponse.headers.set("Cache-Control", "public, max-age=86400");
    ctx.waitUntil(cache.put(cacheKey, newResponse.clone()));

    return newResponse;
  },
};

右上角点 Deploy,看到状态类似 Active / Latest 即可。


4️⃣ 绑定 Worker Route

你会看到 Worker 编辑器右侧有个 HTTP 预览/调试面板,不用改,也不用管它是不是 404。

预览面板报错/404 的常见原因:你还没把 Worker 绑定到你的域名路由;而 xxxx.workers.dev 并不是你的站点域名。

4.1 正确绑定方式(在域名里绑定,不是在 Worker 里找按钮)

回到你的域名(Website)页面:

  • Rules → Workers Routes → Add route

填写(以我的旧博客 www.jinruncheng.blog 为例):

  • Route:www.jinruncheng.blog/*
  • Worker:选择你刚创建的那个
  • Environment:production

✅ 推荐只先绑定 www:减少“根域名 ↔ www”混用导致的缓存碎片。
(后续你想 apex 也走同样策略,再加一条 jinruncheng.blog/* 也行,但第一阶段建议先统一入口。)


5️⃣ 关闭冲突功能

如果你同时开着一些“自动 HTML 缓存/优化”,会和 Worker 的策略打架,导致:

  • 你以为在缓存
  • 实际命中却乱
  • 甚至缓存到不该缓存的内容

按你之前对话里的思路,建议至少做这些:

5.1 Speed → Optimization

关闭(如果你有的话):

  • APO
  • HTML caching(或类似自动 HTML 缓存项)
  • Early Hints(可选)

5.2 Caching → Configuration

把:

  • Browser Cache TTL → 设为 Respect Existing Headers

第一阶段我们要的是:让 Worker 输出的 Cache-Control 生效,而不是被别的规则覆盖。


6️⃣ 清缓存

你刚改过 external-url、又刚上 Worker,Cloudflare 边缘可能还残留旧缓存/旧跳转链。

在 Cloudflare 里:

  • Caching → Purge Cache → Purge Everything

7️⃣ 验证是否成功

7.1 浏览器验证(最靠谱)

用无痕窗口打开一篇文章页:

  • F12 → Network → 点 HTML 文档 → 看 Response Headers

你要看到类似:

  • cf-cache-status: HIT(第二次访问更容易出现)
  • 或至少第一次是 MISS,第二次 HIT

7.2 测速验证(要测两轮)

测速网站如 itdog 经常第一次把你打回源(红),第二次才体现缓存命中(绿/浅绿)。

你会看到典型规律:

次数 现象
第 1 次 部分省份慢(MISS 回源)
第 2 次 明显稳定、整体变绿(HIT 增多)
第 3 次 更趋于稳定

8️⃣ 常见坑(第一阶段最容易踩的)

坑 1:external-url 没改对,导致“缓存命中率永远不稳”

症状:

  • 你明明上了 Worker
  • 但全国依旧随机红
  • 或者总出现奇怪的跳转链(www ↔ apex ↔ http ↔ https)

✅ 处理:

  • external-url 必须是 最终访问域名
  • 建议统一 https://www.xxx/

坑 2:把精力花在 Worker 右侧预览面板

症状:

  • 预览报错、404
  • 你以为 Worker “坏了”

✅ 处理:

  • 不看预览面板
  • 直接访问你的真实域名页面验证 cf-cache-status

坑 3:Route 绑错地方

症状:

  • Worker 代码部署了
  • 访问站点完全没变化

✅ 处理:

  • 必须在 域名 → Rules → Workers Routes 绑定
  • Route 写 www.xxx/*(第一阶段先统一入口)

完成:第一阶段完成后的“合理预期”

完成后你应该能得到:

  • 游客访问文章页:明显更快
  • 国内测速:整体更绿、更稳定(但不保证“全绿”,可能新疆还是红色)
  • 仍然可能存在少量节点偶发 MISS(这是第二阶段才要解决的)

文献参考:

https://blognas.hwb0307.com/linux/docker/1415

https://blognas.hwb0307.com/me

0
  1. 支付宝打赏

    qrcode alipay
  2. 微信打赏

    qrcode weixin
广告 广告

评论区