维护页面的变通方法——这能做到吗？

支持 安装
22

是的，我会分阶段进行：

  1. 获取一台性能稍强的服务器
  2. 完成两个容器的安装配置

如果此时你已满意，可以到此为止，或者：

  1. 按照 @Lilly 上面提供的优秀指南来实现维护页面。:+1:
23

哈哈，很高兴你问了这个问题，因为我之前没花时间解释这部分（我应该解释的——这里有很多内容需要说明，而且 Cloudflare 很复杂！）

当设置了 Workers 路由页面时，论坛上的每一个图片加载和页面浏览都会通过该 Worker 进行路由。

Cloudflare 免费 CDN 计划包含 Worker 路由每天 100,000 次请求的限制。

因此，如果你的论坛流量相对较大，为了防止在一天内达到免费版的上限，最好不要一直开启它。这里指的是 Worker 路由，而不是维护页面——你可以一直保留维护页面，除非你开启了 Worker 路由，否则它不会被触发。这仅仅是指 上面步骤 2 中你分配路由的部分（设置和删除都很简单）。除非你使用的是 Cloudflare 付费计划，否则良好的做法是仅在进行自己的维护时才开启它。

  1. 前往你域名的 Cloudflare Workers 路由页面，点击路由右侧的按钮。

Screenshot 2026-08-01 at 5.06.14 PM
Screenshot 2026-08-01 at 5.06.14 PM1652×552 43.9 KB

  1. 在编辑屏幕底部，点击 remove（移除）按钮，将 Worker 页面从路由中分离。

Screenshot 2026-08-01 at 5.09.01 PM
Screenshot 2026-08-01 at 5.09.01 PM742×658 40.5 KB

  1. 别担心，Worker 代码本身不会被删除，只是路由规则被移除。下次你进行重建/更新时，可以像 上面的步骤 2 那样再次添加它。

如果你使用的是 Cloudflare 付费计划，那就不用担心了。不过，那样的话你可以直接使用 Cloudflare 的错误页面，而不是使用 Workers 页面……（我是不是说过 Cloudflare 挺复杂的？LOL）

:warning: 下方为高级管理员配置

如果想在免费版上完全自动化更新，则应使用 Cloudflare API 令牌、你的区域 ID (zone-id) 以及 curl 命令来获取 Worker 的 route id（路由 ID）。然后编辑 /root/update-web.sh 脚本，添加一些有趣的内容，以自动开启和关闭 Worker 路由：

#!/bin/bash
cd /var/discourse

CF_TOKEN="your_actual_token_here" #<---Cloudflare API 令牌
ZONE_ID="xxxx" #<---来自你的 Cloudflare 个人资料页面
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"

echo "➡️ 正在拉取最新的 Discourse Docker 脚本..."
git pull

echo "➡️ 在后台引导新的 Web 容器..."
./launcher bootstrap web_only

if [ $? -eq 0 ]; then
    echo "✅ 引导成功！"
    
    # 开启 Cloudflare 维护 Worker
    echo "🚧 正在启用维护页面..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null

    # 交换容器（30秒的停机窗口）
    echo "🔄 正在交换容器..."
    ./launcher destroy web_only && ./launcher start web_only
    
    # 关闭 Cloudflare 维护 Worker
    echo "🌍 正在禁用维护页面..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":null}' > /dev/null

    echo "🚀 完成！网站已更新，且无可见停机时间。"
else
    echo "❌ 引导失败！中止交换以保持当前网站在线。"
fi

我使用的是旧版本的脚本，因为我不想自动化所有事情，而且我喜欢亲自参与更新/重建过程。我只需要在更新前添加 Workers 路由，然后在更新后移除它。这只需要几秒钟。

我的一般步骤如下：

  1. 在 Cloudflare 上添加 Workers 路由
  2. SSH 连接到 Hetzner
  3. 执行任何系统更新（例如：sudo apt update && sudo apt upgrade -y，如有必要则重启服务器）
  4. 如果需要重启，则再次 SSH 连接
  5. 运行 ./update-web.sh
  6. 在 Cloudflare 上移除 Workers 路由
24

我对编程和开发领域几乎一无所知，除了很久以前我用 Visual Basic 做过一个“Hello World”的小程序。但我还是能搞定一些事情，因为我更熟悉如何管理我的 WordPress 和 Mastodon/Pixelfed 服务器，以及我的 Discourse 论坛。此外，现在还有所谓的 AI（这对新手来说并没有广告宣传的那么轻松）。

我不确定在 Discourse 中是否真的可行，因为它是基于 Docker 的。但在普通的 Nginx-Varnish-WordPress 环境中，我构建了一个系统：当 Plesk 服务器检测到 5xx 错误时，会显示一个错误页面。实际上，我有三套配置：如果 Varnish 宕机，前端的 Nginx 会显示生成的快照内容；如果与 WordPress 相关的后端宕机，Varnish 会开始使用快照来提供未缓存的内容；第三种情况是，如果前端 Nginx 无响应，则显示错误页面。

Varnish 相关的配置在 Discourse 中不可行，但我看不出有什么理由不能在 Docker 环境中构建类似的“蛛网”系统，使得任何 5xx 错误都能显示一个错误页面。

不过，这可能是一个非常容易出错的系统。而且，如果有超过少数几个用户，我完全不知道会发生什么。

当然，还有一个最明显的答案：在 Discourse 之前使用 Nginx。在我转向双容器架构之前，我就是这么做的。