我以前用 Fruition 把 Notion 页面挂到自定义域名时，遇到过 Cloudflare 1034 错误。
这种错误最容易让人焦躁。
页面打不开，Cloudflare 给出一串代码，旧教程里又常常会出现各种临时解法。那时我第一反应也是搜索“怎么修复”，后来才意识到，更重要的是先弄清楚它到底暴露了哪条链路的问题。
我现在会把 1034 当成一次 DNS 和边缘代理边界的提醒。
它不是玄学，也不应该靠随手复制命令解决。
Fruition 方案里容易混在一起的几件事
Fruition 的思路，是借助 Cloudflare Workers 和 DNS，把 Notion 页面包装成一个自定义域名站点。
这个方案对早期 Notion 建站很有启发，但它也把几层东西放到了一起：
- Notion 原始页面。
- 自定义域名。
- Cloudflare DNS。
- Cloudflare 代理。
- Workers 路由。
- 回源地址或边缘 IP。
任何一层状态变化，都可能让页面表现成同一个结果：打不开。
所以我后来不再把报错代码当成单点答案，而是先拆链路。
我如何理解 1034
Cloudflare 1034 通常和边缘 IP、回源配置、DNS 指向有关。
在一些早期 Fruition 教程里，可能会看到把 A 记录指向特定 IP 的做法。问题在于，这类 IP 和平台策略会变化，旧记录可能在当时能用，几年后就不再适合。
这也是很多旧教程容易失效的原因。
它们记录的是某个时间点的可用路径，不一定是今天仍然可靠的维护方案。
我现在会先问四个问题：
- DNS 记录现在指向哪里？
- 这条记录有没有开启 Cloudflare 代理？
- Worker 路由有没有覆盖当前域名？
- 当前方案是否还依赖早期 Notion 建站的旧假设？
这些问题比直接换一个 IP 更重要。
我不会怎么处理
遇到这种报错时，我不会直接运行来历不明的脚本，也不会把终端里复制来的命令当成默认修复方式。
尤其是涉及网络配置、DNS、系统权限、批量测速、自动替换 IP 的命令，我会先读清楚它做了什么。
原因很简单：域名解析是公开入口，改错以后影响的不只是当前页面，还可能影响搜索收录、用户访问和后续排查。
我也不会一次改很多地方。
DNS、代理状态、Worker 路由、站点代码，最好一次只改一个变量。这样如果页面恢复，我知道是哪一层起作用；如果页面没有恢复，也能直接回滚。
我的排查地图
如果现在重新排查一次 1034，我会按这个顺序做：
- 打开 Cloudflare DNS，记录当前 A/CNAME 配置。
- 查看这条记录是否开启代理，并判断当前验证阶段是否需要临时关闭。
- 检查 Workers 路由是否覆盖了正确域名。
- 对照 Cloudflare 当前文档，确认报错含义。
- 如果旧方案依赖固定 IP，评估是否应该迁移到更稳定的 Notion 建站方案。
- 每次只改一个变量，并记录改动前后的状态。
这里的重点不是背一个固定答案，而是让自己能解释问题。
旧方案和新边界
Fruition 曾经解决了一个很真实的问题：Notion 官方自定义域名能力不完善时，很多人需要一个轻量建站入口。
但工具会变化，平台边界也会变化。
我现在处理这类旧文时，会保留它背后的思路：用 Cloudflare 把内容入口接起来；同时也会补上边界：旧 IP、旧脚本、旧 Workers 代码，都需要重新验证。
这篇文章真正想留下的，不是某个一键修复命令。
而是一种排查方法：当页面挂在 Cloudflare、Notion、Worker、DNS 多层结构上时，先把链路画出来，再用最小变量验证。
能解释故障，比临时恢复一次页面更重要。
Loading...
