网络代理架构与 CDN 流量工程全解析

先限定本文范围：这里讨论的是 Cloudflare 标准橙云代理，也就是基于 Anycast 边缘网络的 HTTP/HTTPS 反向代理。标准橙云只代理 Cloudflare 支持端口上的 Web 流量；Cloudflare 另有 Spectrum、Tunnel 等不同产品，不能把它们和普通橙云混为一谈。

因此，如果代理协议希望通过本文这种标准橙云转发，传输层通常要落在 Cloudflare 能理解的 HTTP(S) / WebSocket / gRPC 等 Web 传输上；REALITY、普通 TCP/UDP 直连则是另一条路线。

第一层：协议与 Web 传输

很多人搭建节点失败，第一步就栽在协议上。

• 直连协议的局限：传统 Shadowsocks、VLESS/VMess 的纯 TCP/UDP 传输不能直接当成标准橙云的 HTTP(S) 流量使用；连接可能被拒绝、重置或根本不会按预期回源。若要代理非 Web 协议，需要使用 Cloudflare 的其它产品或改成兼容的 Web 传输。
• WebSocket (WS)：WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。它的握手阶段从 HTTP(S) Upgrade 开始，因此适合放在支持 WebSocket 的反向代理/CDN 后面。
  • 你的客户端向 CDN 发送一个标准的 HTTP GET 请求，带上 Upgrade: websocket 请求头。
  • CDN 网关一看，是合法的 Web 请求，于是放行，并代理转发给你的源站。
  • 握手成功后，这条 HTTP 通道就会“升级”为双向传输的数据管道，你的代理流量就顺理成章地包裹在里面传输了。
• gRPC：基于 HTTP/2，Cloudflare 可以代理满足其 gRPC 要求的 HTTPS 服务。它不是“任意 gRPC 配好就一定能过 CDN”，还要看客户端、源站、TLS 和 Cloudflare 侧配置是否匹配。

结论：采用本文的 Cloudflare 橙云方案时，客户端通常使用 TLS + WebSocket/gRPC。边缘到源站的协议和端口由回源配置决定；使用 Full (strict) 时源站也应提供有效的 HTTPS 证书。

第二层：源站与 CDN 的桥接方式（常规 vs. Worker）

方案 A：常规 CDN（DNS 路由接管）

这是最正统的架构。你将域名的权威 DNS 服务器修改为 Cloudflare。

1. 解析记录配置：在 CF 的 DNS 页面，添加一条 A 记录。
   • Name（名称）：填你的前缀，比如 proxy（此时完整域名是 proxy.yourdomain.com）。
   • IPv4 address：填你 VPS 的真实公网 IP。
   • Proxy status：开启 橙色云朵（Proxied）。
2. 流量拓扑：
   客户端 → DNS 查询 proxy.yourdomain.com → CF 返回任意边缘节点 IP → 客户端发起 TLS 握手 (SNI: proxy.yourdomain.com) → CF 边缘节点接收 → CF 回源到你的 VPS。
3. 优缺点：最稳定，完全符合 CDN 规范；但强依赖你购买的域名，且默认分配的 CF 节点在晚高峰可能拥堵丢包。

方案 B：Worker 边缘计算反代（HTTP / WebSocket 路由）

Worker 可以在 Cloudflare 边缘处理 HTTP 请求，并通过 fetch() 访问另一个 HTTP(S) 源站；支持 WebSocket 的场景也可以继续升级连接。它不是任意 TCP/UDP 的通用端口转发器，所以这里的“反代”仍然限定在 Worker 支持的 Web 请求模型内。

1. 代码核心逻辑：
   JavaScript

   export default {
     async fetch(request, env) {
       let url = new URL(request.url);
       // 强制修改请求头中的目标主机，指向你的真实 VPS 或 未套 CDN 的域名
       url.hostname = "你的真实源站IP或域名"; 
       let new_request = new Request(url, request);
       return fetch(new_request); // 发起回源请求
     }
   };

2. 流量拓扑：
   客户端 → DNS 查询 xxx.workers.dev → 连接 CF 边缘节点 → 边缘节点触发代码 → 代码执行 fetch 指令拉取真实源站数据。
3. 优缺点：灵活性极高，自带免费域名；但部分地区的运营商会对 .workers.dev 域名进行 DNS 污染（可通过在 Worker 绑定自定义域名解决）。

第三层：流量工程与优选 IP（打破 Anycast 限制）

Cloudflare 使用 Anycast 技术，同一组 IP 会从多个数据中心宣告。实际由运营商的 BGP 路由、对等互联和当时网络状态决定流量进入哪个 Cloudflare 数据中心，并不保证物理距离最近。地理最近也不等于网络最快，因此不同运营商、不同时间的实际路径可能差异很大。

优选 IP 的本质，是在本地进行四层（传输层）强制路由，同时保留七层（应用层）的域名特征。

核心参数拆解与客户端配置

无论你用什么代理客户端（v2rayN, Clash, Sing-box），以下参数的逻辑是通用的：

1. Address / Server (服务器地址)
   • 这里填：优选出来的优质 CF IP 地址（如 104.16.x.x）。
   • 底层原理：TCP 握手阶段，你的系统会直接向这个 IP 发起 SYN 报文，完全跳过 DNS 查询。这会连接到该 IP 当前由运营商路由选择的边缘节点，实际路径仍可能随时间变化。
2. Port (端口)
   • 填：443（如果套了 TLS）。
3. Host / 伪装域名 (HTTP 请求头)
   • 这里填：你的 CF 域名或 Worker 域名。
   • 底层原理：这是在第七层（HTTP 层）告诉目标服务器，“我想访问这个网站”。
4. SNI (服务器名指示)
   • 这里填：你的 CF 域名或 Worker 域名。
   • 底层原理：这是 TLS 握手阶段（Client Hello 报文）极度关键的字段。 虽然你连接的是 104.16.x.x 这个公共 IP，但当你的流量到达 CF 边缘网关时，网关是通过读取 SNI 字段，才知道去哪个客户的配置里拿 SSL 证书，以及该把流量回源给哪个服务器的。SNI 或 Host 填错可能造成证书校验、TLS 握手或站点路由失败，不能把这些情况统一等同于 Error 1000/1003。
5. 网络 / 传输（传输协议）
   • 填：ws 或 websocket。
   • Path (路径)：填写你源站 VPS 配置的 WebSocket 路径（例如 /api/v1/sync）。这个路径必须和源站严格一致。

第四层：安全、防爆破与细节收尾

将节点暴露在公网，尤其是套了 CDN 后，会有新的安全挑战：

1. 源站真实 IP 保护：
   • 既然使用了 CDN，你的 VPS 就不应该再接收除了 Cloudflare 以外的任何流量。
   • 防火墙策略（iptables/UFW）：强烈建议在 Linux 源站配置防火墙，仅允许 Cloudflare 的 IP 段（CF 官网有公布）访问你的 443 端口，丢弃所有其他来源的 TCP 握手。这能限制非 Cloudflare 来源访问该服务端口；其他开放端口仍需分别管理。
2. TLS 指纹特征（Client Hello）：
   • 在极度严格的网络审查环境下，纯粹的 TLS + WS 流量依然可能因为 TLS 指纹（如 JA3 指纹）被识别出是代理客户端而非正常浏览器。
   • 如果你追求极致的隐蔽性，可以考虑在源站采用更新的协议（如 Xray 的 VLESS + REALITY），但注意，REALITY 协议本身是为直连设计的，不适合也不需要套 CDN。 CDN 玩法目前最成熟的依然是 WS/gRPC + TLS。

现在，整个 CDN 反代、协议封装和流量路由的底层逻辑已经彻底铺开。