很多静态站点（Astro / Next SSG / Hugo 等）默认部署到 Cloudflare Pages 就够用了：全球访问快、配置简单、缓存做得也不错。但在国内/亚洲网络环境里，Cloudflare 偶发的可达性与抖动会让“能打开”变成一个概率事件。
这篇记录一个很朴素的做法：同一份站点产物同时部署到 Cloudflare Pages 与 EdgeOne Pages，然后用 Cloudflare 的规则按访问者地区做路由：
- 亚洲（尤其是中国大陆及周边）→ EdgeOne Pages（提升在国内/亚洲的可用性与稳定性）
- 其他地区 → Cloudflare Pages（继续吃 Cloudflare 的全球网络与生态）
目标与前提
目标很明确：用户就近访问、同时尽量少改代码。
前提/假设：
- 站点是纯静态或“可前端化”的内容（不依赖复杂的服务端会话）。
- EdgeOne Pages 与 Cloudflare Pages 都能部署同一份构建产物（或同一仓库）。
- 你接受一个现实：如果“路由规则”本身依赖 Cloudflare 边缘执行，那么在 Cloudflare 连接不稳定的地区，这条路由能力也会一起变弱；但在很多“可用但不稳”的场景下，它仍然能显著改善体验。
架构：双部署 + 双域名（推荐）
最容易落地、也最容易回滚的结构是 两个 Hostname：
www.example.com：Cloudflare Pages（默认全球入口）asia.example.com：EdgeOne Pages（亚洲入口）
然后在 Cloudflare 上对 www.example.com 做“按地区跳转”到 asia.example.com。
为什么推荐双域名而不是“同域名分流到不同源站”？
- Cloudflare 的 Redirect Rules 足够好用，落地成本低。
- 失败模式更清晰：规则一关，
www全量回到 Cloudflare Pages；EdgeOne 侧单独维护不影响全球。
当然，双域名也带来一个问题：URL 发生变化（www → asia），需要你在 SEO / 统计 / Cookie 上做一些取舍（后面写）。
部署：同一份构建产物同时发到两边
思路：
- 本地或 CI 里构建一次（例如
pnpm build） - 将产物分别上传/发布到：
- Cloudflare Pages（推荐用 Git 集成或
wrangler pages deploy） - EdgeOne Pages（用 EdgeOne 的 Git 集成或其 CLI/上传发布方式）
- Cloudflare Pages（推荐用 Git 集成或
关键点是“产物一致”。这样路由只是“从哪个平台拿同一份静态资源”，而不是“两个站点内容不一致”。
Cloudflare 规则：把亚洲路由到 EdgeOne Pages
下面以 Cloudflare Redirect Rules 为例（在 Cloudflare Dashboard 的 Rules 体系里）。核心是匹配“访问者国家/大洲”，然后拼出目标 URL。
规则 1：亚洲 → asia.example.com
When…（条件）（示例逻辑）：
- Hostname 等于
www.example.com - 访问者大洲为 Asia（
AS）或访问者国家在你指定列表内（例如CN/JP/KR/SG/...） - 可选：排除健康检查路径、后台路径、静态资源等（避免没必要的跳转）
Then…（动作）：
- Redirect（建议先用 302 验证，稳定后再考虑 301）
- Target：
https://asia.example.com${uri.path}?${uri.query}
说明：
- Cloudflare 的表达式字段名会随着产品迭代有所变化（国家/大洲字段在 Ruleset Expression 里通常以
ip.src.country、ip.src.continent这类形式出现）。你在规则编辑器里点字段选择器即可，不必死记。 - 如果你只关心“国内”，也可以把条件缩小成
ip.src.country == "CN"，把“亚洲”交给你自己的业务判断（比如只路由东亚/东南亚，不包含中东等）。
规则 2：非亚洲 → 保持在 Cloudflare Pages
这条通常不需要写：因为 www.example.com 默认就已经是 Cloudflare Pages，只有命中“亚洲规则”才会跳走。
你真正需要的是：确保没有其他规则把非亚洲也重定向走。
高可用性：为什么 EdgeOne Pages 在国内/亚洲更稳
把“亚洲入口”落到 EdgeOne Pages 的意义，主要在于两点：
- 链路更贴近国内网络现实：对国内用户来说，跨境链路与某些国际 CDN 的波动，是“平均很快但偶发超慢/打不开”的常见原因；选择一个在国内网络环境更友好的边缘网络，往往能把 p95/p99 拉回正常。
- 多平台冗余：Cloudflare 出现区域性波动时，至少亚洲用户可以绕开；反过来 EdgeOne 侧出现问题，也能一键把亚洲规则关掉回到 Cloudflare。
这里的“高可用”并不神秘：它不是单平台做到 99.99%，而是用 两个相对独立的交付网络 来降低同一时间同一地区一起挂掉的概率。
细节与坑
SEO：301/302、Canonical 与重复内容
双域名带来的第一个问题是重复内容与权重分散。
建议：
- 初期用 302 做验证，确认跳转策略正确、不会误伤爬虫/接口后，再考虑 301。
- 在两套站点都设置 canonical（例如都指向
https://www.example.com/...），并确保 sitemap、RSS 等也尽量统一到一个“主域名”。 - 如果你希望亚洲用户的 URL 永久是
asia.，那就把 canonical 指向asia.，但要接受“主域名不再是www”的现实。
统计与登录态
- 统计：跨域跳转会让一次访问被拆成两段，UTM/Referrer 也可能变形；尽量用同一套统计方案，并确保跨域场景下参数传递正常。
- Cookie：
www与asia是不同子域，默认 Cookie 不共享；如果你有登录态（即便是静态站点也可能有评论系统/会员系统），要么统一用顶级域 Cookie（Domain=.example.com），要么接受“不同入口不同会话”的体验差异。
缓存与更新
双平台要避免“一个已更新、一个还是旧的”：
- 发布顺序固定（例如先发布 EdgeOne，再发布 Cloudflare，最后切换/开启规则）
- 两边都配置好缓存刷新/版本化资源（静态资源文件名带 hash）
进阶：不换域名的同域分流（可选）
如果你非常在意 URL 不变，可以考虑用 Cloudflare Workers 做“反向代理分流”（按 request.cf.country 选择上游），这样用户始终访问 www.example.com。
但注意：这种方式依然要求请求先到达 Cloudflare 边缘，因此它解决的是“在 Cloudflare 可达但不稳”时的体验问题，而不是“完全不可达”的情况。
小结
这套方案的核心是：
- 内容部署双份（Cloudflare Pages + EdgeOne Pages）
- 路由策略按地区（亚洲 → EdgeOne，其他 → Cloudflare）
- 出问题时可快速回滚（关规则即可）
如果你更具体的目标是“只要中国大陆走 EdgeOne”，或者你想把“亚洲”细分成多个国家/运营商策略，我也可以把 Cloudflare 规则表达式拆得更细，并给一个可直接复制的规则模板（包含排除静态资源、排除特定路径等）。
Some information may be outdated