1. 反向代理（Reverse Proxy）+ SNI 路由#

1
用户访问 site1.com ──┐
2
用户访问 site2.com ──┼──→ Cloudflare IP (104.16.x.x) ──→ 根据信息分发到不同源站
3
用户访问 site3.com ──┘

关键技术：SNI + Host 头双重路由。

1
你的浏览器 → Cloudflare:443
2

3
Client Hello:
4
  - SNI: "site1.com"  ← 明文传输
5

6
Cloudflare 根据 SNI：
7
  - 找到 site1.com 的证书
8
  - 返回 site1.com 的 TLS 证书

1
HTTP GET / HTTP/1.1
2
Host: site1.com  ← 决定请求转发给哪个源服务器

2. Anycast 技术（全球共享 IP）#

这是 Cloudflare 的独特之处：

1
传统 DNS：
2
- site.com → 1.2.3.4（美国服务器）
3
- 中国用户访问慢
4

5
Cloudflare Anycast：
6
- 104.16.249.249 同时在全球广播：
7
  - 北京用户访问 → 被路由到北京机房
8
  - 纽约用户访问 → 被路由到纽约机房
9
  - 伦敦用户访问 → 被路由到伦敦机房

同一个 IP 地址，物理上对应全球数百个数据中心。

3. 边缘计算（Edge Computing）#

对于 Workers/Pages：

1
用户请求 example.worker.dev
2
           ↓
3
到达最近的 Cloudflare 边缘节点
4
           ↓
5
不转发到源站，直接在边缘节点执行 JavaScript 代码
6
           ↓
7
返回结果

一个 IP 既是反向代理入口，又是代码执行环境。

4. 边缘应用为什么几乎不占资源#

边缘应用（Worker）是 Serverless 无服务器架构，特点是：

• 不是一直开着一台服务器等请求
• 来一个请求，临时启动一段代码
• 执行完（通常几毫秒～几十毫秒）直接销毁
• 不请求时，完全不占资源

一个节点上可以同时跑几万个用户的边缘函数，资源是极度共享、极度轻量化的。对 Cloudflare 来说，这点算力几乎可以忽略不计。

5. 写 API、鉴权、查数据库会不会很耗资源？#

并不会，而且架构是这样的：

• 边缘节点：只做轻逻辑（校验、路由、拼接、简单计算）
• 数据库：依然放在中心服务器 / 云数据库（比如阿里云、腾讯云、PlanetScale）
• 边缘节点 → 发请求 → 中心数据库拿数据

不是每个边缘节点都装数据库。只是用户到边缘近，边缘到数据库那一步是厂商优化过的内网专线，整体依然很快。

6. 对比传统后端#

• 传统后端：买 1 台 / 3 台 / 10 台服务器，自己扛所有流量，崩了要自己重启扩容
• 边缘后端：厂商全球几百个节点自动兜底，流量再大也自动分配，不用管服务器数量