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

在深入之前，我们需要统一一个核心概念：CDN 的本质是基于 Anycast（任播）技术的 HTTP/HTTPS 反向代理集群。它只认应用层（七层）的 Web 流量，这也是为什么所有的代理协议想要套 CDN，都必须先进行伪装。

第一层：协议与伪装（为什么一定要用 WebSocket/gRPC？）

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

直连协议的局限：传统的 Shadowsocks、VLESS/VMess 直接跑在 TCP/UDP 上。当这种纯四层流量撞上 Cloudflare 的边缘节点时，CDN 的网关发现这不是标准的 HTTP 请求，会直接丢弃（Drop）数据包。
WebSocket (WS) 的降维打击：WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。最重要的是，它的握手阶段完全复用了 HTTP 请求。
- 你的客户端向 CDN 发送一个标准的 HTTP GET 请求，带上 Upgrade: websocket 请求头。
- CDN 网关一看，是合法的 Web 请求，于是放行，并代理转发给你的源站。
- 握手成功后，这条 HTTP 通道就会“升级”为双向传输的数据管道，你的代理流量就顺理成章地包裹在里面传输了。
gRPC：类似 WS，它是基于 HTTP/2 协议的，天然被现代 CDN 支持，且在多路复用上性能更好，但配置稍显复杂。

结论：想要接入 CDN，源站 VPS 的入站协议必须配置为 TCP + TLS + WebSocket/gRPC，监听端口通常设为 443。

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

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

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

解析记录配置：在 CF 的 DNS 页面，添加一条 A 记录。
- **Name (名称)**：填你的前缀，比如 proxy（此时完整域名是 proxy.yourdomain.com）。
- IPv4 address：填你 VPS 的真实公网 IP。
- Proxy status：开启**橙色云朵 (Proxied)**。
流量拓扑：

客户端 $\rightarrow$ DNS 查询 proxy.yourdomain.com $\rightarrow$ CF 返回任意边缘节点 IP $\rightarrow$ 客户端发起 TLS 握手 (SNI: proxy.yourdomain.com) $\rightarrow$ CF 边缘节点接收 $\rightarrow$ CF 回源到你的 VPS。
优缺点：最稳定，完全符合 CDN 规范；但强依赖你购买的域名，且默认分配的 CF 节点在晚高峰可能拥堵丢包。

方案 B：Worker 边缘计算反代（代码级路由）

利用 Cloudflare 的无服务器环境（V8 Isolates），在边缘节点执行一段 JavaScript 代码，截获并重定向流量。

代码核心逻辑：

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); // 发起回源请求
  }
};

流量拓扑：

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

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

Cloudflare 使用 Anycast 技术，理论上会自动把你路由到物理距离最近的节点。但由于跨国运营商的对等互联（Peering）策略和商业博弈，地理最近不等于网络最快。有时直连香港节点反而卡顿，绕道美西节点反而流畅。

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

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

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

Address / Server (服务器地址)
- 这里填：优选出来的优质 CF IP 地址（如 104.16.x.x）。
- 底层原理：TCP 握手阶段，你的系统会直接向这个 IP 发起 SYN 报文，完全跳过 DNS 查询。这保证了你的数据包走的是你测试出的最优物理链路。
Port (端口)
- 填：443（如果套了 TLS）。
Host / 伪装域名 (HTTP 请求头)
- 这里填：你的 CF 域名或 Worker 域名。
- 底层原理：这是在第七层（HTTP 层）告诉目标服务器，“我想访问这个网站”。
SNI (服务器名指示)
- 这里填：你的 CF 域名或 Worker 域名。
- 底层原理：这是 TLS 握手阶段（Client Hello 报文）极度关键的字段。虽然你连接的是 104.16.x.x 这个公共 IP，但当你的流量到达 CF 边缘网关时，网关是通过读取 SNI 字段，才知道去哪个客户的配置里拿 SSL 证书，以及该把流量回源给哪个服务器的。如果你不填 SNI 或者填错，CF 网关会直接拒绝连接（Error 1000/1003）。
网络 / 传输（传输协议）
- 填：ws 或 websocket。
- **Path (路径)**：填写你源站 VPS 配置的 WebSocket 路径（例如 /api/v1/sync）。这个路径必须和源站严格一致。

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

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

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