架构
架构：谁负责一次请求的哪一段
用职责边界、数据流和故障归属理解 Cloudflare 请求生命周期。
编辑与核验：橙宝书编辑团队 ·
ARCHITECTURE · 请求边界逻辑视图核验：2026-08-26
架构页回答的是“谁拥有哪段职责”，不是重复操作步骤。下面的图只表达主请求流，不把 DNS 管理面、日志异步流或缓存层级硬塞进同一张图。
详细说明
客户端解析 DNS 后连接 Cloudflare 边缘。边缘负责 TLS、策略和缓存决策；匹配 Worker 时运行代码。Worker 可以直接响应，也可以向源站发起 fetch，最后响应沿原路径返回客户端。
- 01Client boundary
拥有请求意图、方法、URL 与客户端缓存。
- 02DNS boundary
拥有名称解析与代理入口选择。
- 03Edge boundary
拥有 TLS、规则、安全与缓存判断。
- 04Compute boundary
Worker 代码拥有应用级边缘逻辑。
- 05Origin boundary
拥有源数据与未在边缘完成的计算。
关键架构决策
| 决策 | 默认建议 | 何时改变 |
|---|---|---|
| 是否运行 Worker | 只有需要应用逻辑时才加入 | 鉴权、改写、聚合、边缘 API |
| 是否访问源站 | 能直接响应就减少回源 | 需要源数据、动态渲染或写操作 |
| 是否缓存 | 从数据新鲜度与隐私出发 | 公共、可复用且有明确失效策略 |
| 故障归属 | 先用证据定位层级 | 不以“Cloudflare 有问题”作为诊断 |
运行边界不是套餐猜测
已核验的服务事实
与当前部署架构直接相关的 Free 限制
Cloudflare 可能调整套餐与额度；实施前请重新打开官方来源。
图中箭头不是部署保证
Worker 可以直接返回响应，不一定每次都访问源站。架构图表达允许的主路径；真实请求必须通过日志、响应头和测试验证。
架构审查清单
- 每个节点是否只有一个清晰职责？
- Worker 失败时是 fail open 还是 fail closed，是否符合安全目标？
- 源站是否只信任预期入口，敏感数据是否越过了不必要边界？
- 缓存与应用状态是否被误认为同一件事？
遇到缓存异常时进入缓存状态排障。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。