先把访问链路说清楚

guoguohui.si 的域名在 OVH 注册，DNS 管理由 Cloudflare 承接，网页文件由 Mac 上的 Caddy 提供。cloudflared 从 Mac 主动建立到 Cloudflare 的出站隧道，公网请求再经隧道转发到本机的 HTTP 服务。本站没有为这条链路配置路由器的入站端口映射。

当前根域、www 与 blog 子域名接入同一服务。它们是同一个内容站点的不同入口，不是三台独立服务器。栏目使用 /projects/、/notes/ 和 /blog/ 等路径，便于在一份静态站点中组织内容。

浏览器
  ↓ HTTPS
Cloudflare 公网入口
  ↓ Cloudflare Tunnel
Mac 上的 cloudflared
  ↓ HTTP，127.0.0.1:8080
Caddy → 网站静态文件

域名迁移与服务连接是两件事

在 Cloudflare 添加域名之后，需要到 OVH 的 DNS servers 页面替换权威名称服务器，使用 Cloudflare 为该域名实际分配的地址。域名仍在 OVH 注册与续费，更换 DNS 托管不等于转移注册商。控制台出现等待传播时，也不能把 Tunnel 已连接当作域名已激活。

本站先验证临时隧道，再接入固定 Tunnel，并为三个主机名配置应用路由。2026 年 10 月 18 日上午验收时，域名已激活，固定 Tunnel 显示 Healthy；三个入口的 HTTPS 首页和 /health.txt 均返回 200，证书验证正常。

HTTPS 与隧道传输协议要分开看

浏览器访问的是 HTTPS；这不表示 cloudflared 到 Cloudflare 的连接也必须使用 HTTP/2。本站测试中，QUIC 隧道注册成功，而强制 HTTP/2 的测试没有建立连接。成功测试经过当时启用的 VPN/TUN 网络，因此这份记录不能证明关闭 VPN 后的直连也一定可用。

同样，本机返回网页只说明 Caddy 正常；Tunnel Healthy 说明连接器状态正常；公网域名能通过证书验证并取得预期内容，才把 DNS、证书、隧道和源站这条访问链路串了起来。

上线以后，维护也要能够重复

Caddy 与 cloudflared 分别由 macOS 用户 LaunchAgent 管理，用户登录后自动启动。运行文件放在内置盘，源项目可以保留在外置盘；更新时只同步网站公开目录。这样既不需要一直打开终端，也能避免把脚本、日志和凭据当作网页一起发布。

下面是通用的分层检查示例。请求不使用跳过证书验证的选项；健康端点应返回预期正文，而不仅是一个看似成功的状态码。

# 先检查本机网页服务
curl --fail http://127.0.0.1:8080/health.txt

# 再检查完整的公网访问链路
curl --fail https://guoguohui.si/health.txt

参考与延伸阅读

继续阅读

给问题、推导和记录一个位置 →