【面向小白教程】通过 saas 回源优选加速 Cloudflare 中国大陆访问

CF优选，简单来说，就是用一个在 Cloudflare 上配置好的域名（B），来给另一个我们自己的主域名（A）借道加速，尤其是显著提升中国大陆的访问速度

角色介绍

为了方便理解，我们先给今天的主角们分配好角色：

1. 主域名 (A)：4399.com
   • 这是访客真正访问的域名，我们希望它能享受到 Cloudflare 的服务。
   • 重要：它的 DNS 解析在别的平台管理（比如阿里云、腾讯云、GoDaddy 等），不是在 Cloudflare。
2. 回源域名 (B)：123456.xyz
   • 这是我们的“工具域名”，它在 Cloudflare 上进行全部配置，充当一个中间桥梁。
   • 它本身不重要，访客也看不到它。
3. 你的服务器 IP：1.2.3.4 (这里用一个假的 IP 地址举例)
   • 这是你网站内容真正存放的地方。

我们的目标：当用户访问 4399.com 时，实际流量会通过 123456.xyz 在 Cloudflare 上的配置，最终安全地访问到你的服务器。

---

🎉 操作开始：一共六个步骤

第一步：配置“回源域名” (123456.xyz)

首先，我们要把我们的“工具域名”123456.xyz 配置好。

1. 登录你的 Cloudflare 账号。
2. 进入域名 123456.xyz 的管理后台。
3. 点击左侧的 “DNS” → “Records”。
4. 添加一条 A 记录，指向你的真实服务器 IP。
   • 类型 (Type): A
   • 名称 (Name): origin (你可以自定义，但用 origin 比较清晰)
   • IPv4 地址 (Content): 1.2.3.4 (换成你自己的服务器 IP)
   • 代理状态 (Proxy status): 务必点亮那朵橙色的小黄云！ 这代表流量会经过 Cloudflare。

现在，访问 origin.123456.xyz 就应该能看到你服务器上的网站内容了，并且是经过 Cloudflare 加速的。

第二步：设置“回退源” (Fallback Origin)

这一步是为了让 Cloudflare 知道，当收到访问 123456.xyz 的请求时，应该去哪里找内容。

1. 在 123456.xyz 的管理后台，点击左侧的 “SSL/TLS” → “自定义主机名”。
2. 向下滑动，找到 “回退源 (Fallback Origin)” 部分。
3. 点击 “添加回退源 (Add Fallback Origin)”。
4. 在输入框里填入我们上一步创建的子域名：origin.123456.xyz。
5. 点击保存。

保存成功后，状态应该是有效 (Active)。

第三步：添加“自定义主机名” (Custom Hostname)

这是最关键的一步！我们要告诉 Cloudflare：“我授权你用 123456.xyz 的配置来服务 4399.com 这个域名。”

1. 在 123456.xyz 的管理后台，继续停留在 “SSL/TLS” → “自定义主机名 (Custom Hostnames)” 标签页。
2. 点击 “添加自定义主机名 (Add Custom Hostname)”。
3. 在弹出的窗口中，输入我们的主域名：4399.com。
4. 其他设置保持默认，点击右下角的 “添加自定义主机名” 按钮。

完成后，Cloudflare 会开始处理，但此时状态会是“待验证 (Pending Validation)”。它需要你证明 4399.com 确实是你的。

第四步：验证“主域名”的所有权

Cloudflare 会给你一条 TXT 记录，你需要把它添加到 4399.com 的 DNS 解析记录里。

1. 在刚才的“自定义主机名”页面，你会看到 4399.com 旁边有“查看验证 TXT”之类的链接，点开它。
2. 你会得到两条 TXT 记录，一条用于域名所有权验证，一条用于证书验证。记下它们的主机名 (Name)和值 (Value)。
3. 登录 4399.com 的 DNS 管理平台（比如阿里云、腾讯云等）。
4. 添加那两条 TXT 记录。
   • 主机记录: 复制 Cloudflare 提供的 Name。
   • 记录类型: TXT
   • 记录值: 复制 Cloudflare 提供的 Value。
5. 添加完成后，回到 Cloudflare 页面，耐心等待几分钟到几小时（DNS 生效需要时间）。

当你看到 4399.com 的主机名状态和证书状态都显示为  有效 (Active) 时，就说明验证成功了！

第五步：将“主域名”指向 Cloudflare

万事俱备，只欠东风！现在我们要让 4399.com 指向我们刚刚在 Cloudflare 搭建好的“桥梁”。

1. 再次回到 4399.com 的 DNS 管理平台。
2. 找到主域名的解析记录（通常是 @ 或者 4399.com 本身）。
3. 修改或添加一条 CNAME 记录。
   • 主机记录: @ (或者 www，取决于你想让哪个生效)
   • 记录类型: CNAME
   • 记录值: origin.123456.xyz

✨ 优选技巧：
为了获得国内更快的速度，你可以不直接 CNAME 到 origin.123456.xyz，而是使用 优选 CNAME 地址 或者 A 记录。这些地址可以帮助你连接到速度更快的 Cloudflare 节点。
你可以在一些第三方优选工具网站上找到这些地址。找到一个适合你网络的 CNAME 地址（例如 cloudflare.182682.xyz），然后把上面的记录值换成这个优选的 CNAME 地址。

第六步：大功告成，最终检查！

现在，所有的配置都完成了！

等待几分钟让 DNS 解析在全球生效后，在浏览器里输入 https://4399.com。

你会发现，打开的网站和你直接访问 origin.123456.xyz 或者你的服务器 IP 所看到的网站一模一样，但此时 4399.com 已经成功套上了 Cloudflare 的 CDN 加速和安全防护！

---

🔅 背后发生了什么？

当你完成所有设置后，一个访客（比如小明）打开网站的奇妙旅程是这样的：

第 1 步：用户访问主域名
小明在浏览器里兴冲冲地输入 https://4399.com，然后按下回车。

第 2 步：DNS 指路
小明的电脑向 DNS 系统发出询问：“4399.com 的服务器在哪？”
4399.com 的 DNS 解析服务（在阿里云/腾讯云等平台）回应说：“我这没直接地址，但你去找 origin.123456.xyz（优选地址） 就行了，它知道在哪。” (这就是我们设置的 CNAME 记录在起作用)

第 3 步：找到 Cloudflare 的加速节点
小明的电脑继续问：“那 origin.123456.xyz 在哪？”
这次，Cloudflare 的 DNS 系统接管了。它会智能地分析小明的位置，并告诉他一个离他最近、访问速度最快的 Cloudflare 加速节点服务器的 IP 地址。
（如果你用了优选 CNAME，这里会分配到更适合国内网络的节点！）

第 4 步：连接到“接待员”
小明的浏览器连接到这个近在咫尺的 Cloudflare 加速节点，并递上“名片”说：“你好，我是来访问 4399.com 网站的。”

第 5 步：Cloudflare 核对身份并服务
Cloudflare 加速节点（我们的“接待员”）收到请求后，立刻查看自己的“贵宾名单”（我们设置的“自定义主机名”）。
它发现 4399.com 确实是授权过的贵宾，于是开始为它提供服务。

第 6 步：智能中转与缓存 (配置与123456.xyz保持一致)

• 如果节点有缓存：接待员发现自己手上正好有 4399.com 的网页内容备份，就直接把内容发给小明。（速度飞快，网站秒开！）
• 如果节点没缓存：接待员会通过 Cloudflare 的内部高速专线，去联系我们远在海外的真实服务器（IP: 1.2.3.4），抓取最新的网页内容。这个过程比普通访问快得多也稳定得多。

第 7 步：内容安全送达
Cloudflare 节点把从服务器取来的新鲜内容，或者它自己的缓存，安全地交给小明的浏览器。

小明输入 4399.com → 浏览器问DNS → DNS通过解析 优选地址 (一个优选的高速CNAME或IP)，最终为小明挑选出Cloudflare节点IP → 浏览器连接这个高速节点IP并说：“我要 4399.com” → Cloudflare节点核对“贵宾名单”，确认 4399.com 已被授权（自定义主机名） → 节点于是套用 123456.xyz 的全套服务（缓存、安全规则等）来处理请求 → 节点根据这些规则，检查缓存或去真实服务器取回内容 → 内容安全返回给小明 → 小明成功看到网站

最终，小明愉快地看到了 4399.com 的网站，全程体验如丝般顺滑。他完全不知道自己的访问请求已经进行了一次“全球旅行”，而我们的真实服务器 IP 也被完美地隐藏了起来，非常安全🌞

🔅 为什么能加速？

看到这里，你可能心里在犯嘀咕，绕了这么大一圈，凭什么就能给国内访问加速了？而且既然加速了，为啥速度还是比不上真正的国内服务器？

哈哈哈哈哈把一次完整的访问拆成两段路来看就明白了：

第一段路：从你的电脑 → 到 Cloudflare 的节点

这通常是国内用户访问海外网站时 最堵、最慢 的一段路。你可以把它想象成下班高峰期出城的路，所有车都挤在运营商的国际出口那几个收费站，延迟高得吓人（动不动就 200ms+），还老丢包。

而“优选”干的事，就是给你找了条 VIP 通道。

你用的那个“优选 CNAME”或“优选 IP”，它背后走的不是普通拥挤的公用出口，而是像 CN2 GIA、CMI 这种高质量的专线。它直接绕开了那个大堵点，让你的访问请求“嗖”地一下就抵达了 Cloudflare 在海外的服务器节点。

说白了，加速的核心就是优化了这“第一段路”，让用户的请求成功“出海”的过程变得丝般顺滑。

那速度瓶颈又在哪？

既然第一段路这么快，为啥整体体验还是超不过国内的服务器呢？

答案在第二段路：从 Cloudflare 节点 → 回到你的源站服务器（回源）

你想想，就算你的请求光速到达了 CF 的节点，但网站内容还在你那台 1.2.3.4 的服务器上放着呢。CF 节点得亲自跑一趟，跨越重洋去你的服务器上把数据取回来，然后再交给你。

这个“回源”的过程，物理距离是硬伤，跨国光缆的延迟是实打实存在的。虽然 Cloudflare 的内部网络已经很牛了，但它也变不出消除这段路程的耗时。

核心知识点：优选IP只管“去”，不管“回”

用“优选IP”当跳板，让国内访客不走运营商拥堵的国际出口，直接抄近道连上 Cloudflare；再通过“自定义主机名”功能，让你网站套用上另一域名预设好的加速配置。

加速效果完全取决于“优选IP”的质量。这个IP会变慢、会失效，需要定期更换。

Cloudflare 回源到你服务器的延迟是硬伤，所以速度再快也快不过优秀的国内服务器，因为当Cloudflare节点把数据（下行）发回给用户时，它走的是Cloudflare自己的BGP路由网络。这条路不受我们选择的优选IP影响。

优选 IP 是有“时效性”的。今天测速飞快的 IP，明天可能因为用的人太多、或者被运营商盯上而变慢。所以，把它当成一个动态优化的过程，而不是一劳永逸的配置。手里多准备几个备用节点，定期检查速度，才能确保你的网站时刻保持在最佳状态

---

🎃 如何处理多个子域名服务？

如果 4399.com 旗下还有 blog.4399.com 和 shop.4399.com 等多个子域名，它们该如何一同享受加速服务？

第一步：为所有子域名添加“自定义主机名”

首先，需要在 123456.xyz 的 “自定义主机名” 列表里，将每一个需要加速的子域名都添加进去并完成所有权验证。

例如，列表中应包含：

• 4399.com
• blog.4399.com
• shop.4399.com

第二步：理解“回退源”的唯一性限制

这里的关键在于！Cloudflare 允许添加多个“自定义主机名”，但 “回退源 (Fallback Origin)” 只能设置一个。

这意味着，无论访客的请求是发往 blog.4399.com 还是 shop.4399.com，Cloudflare 最终都会将所有流量转发到同一个“总出口”——即教程中设置的 origin.123456.xyz，也就是那台作为回源的主服务器（IP: 1.2.3.4）。

第三步：解决方案，引入 Nginx 作为中央反向代理

既然所有子域名的流量都汇集到了同一台主服务器，就需要在这台服务器上部署一个“智能交通指挥官”来根据域名分发流量。这个角色最适合由 Nginx 担任。

Nginx 会检查每个请求的目标域名，然后将其转发到正确的后端服务器。连接后端服务器主要有两种方式：

---

实战来咯，后端流量转发的两种方法

方法 A：标准反向代理 (Direct Proxy_Pass)

这是最直接、最常见的方法，适用于主服务器和后端服务器之间网络通畅（例如在同一内网或公网可直接访问）的情况。

操作：
在主服务器 (1.2.3.4) 的 Nginx 配置文件中，通过 proxy_pass 直接指向后端服务器的 IP 和端口。

Nginx 配置示例：

# 处理博客子域名的流量
server {
    listen 80;
    server_name blog.4399.com;

    location / {
        # 直接转发到博客服务器的 8080 端口
        proxy_pass http://10.0.0.2:8080; 
        proxy_set_header Host $host;
        # ... 其他 header 设置 ...
    }
}

方法 B：SSH 反向隧道代理 (Advanced & Secure)

这种方法适用于后端服务器无法被主服务器直接访问（例如后端在内网 NAT 之后）或需要极高安全性的场景。它通过建立一个加密的 SSH 隧道来传输数据。

工作原理： 由后端服务器主动连接主服务器，并在主服务器上“开一个口”，Nginx 只需将流量送到这个本地的“口”即可。

操作步骤：

1. 在后端服务器上建立隧道：
   登录后端博客服务器 (10.0.0.2)，执行以下命令，与主服务器 (1.2.3.4) 建立连接。

   # 命令格式：ssh -fN -R [主服务器端口]:localhost:[后端服务端口] [主服务器用户名]@[主服务器IP]
   ssh -fN -R 9001:localhost:8080 user@1.2.3.4
   

   • -fN: 让 SSH 在后台运行。
   • -R 9001:localhost:8080: 意思是将主服务器 (1.2.3.4) 的 9001 端口收到的所有流量，通过这条加密隧道，转发到当前后端服务器 (10.0.0.2) 的 8080 端口。
   • 提示: 为保证隧道断开后能自动重连，建议使用 autossh 工具。
2. 在主服务器上配置 Nginx：
   现在，主服务器上的 Nginx 只需将 blog.4399.com 的流量转发给自己的 9001 端口即可。Nginx 配置示例：

   # 处理博客子域名的流量 (通过 SSH 隧道)
   server {
       listen 80;
       server_name blog.4399.com;
   
       location / {
           # 转发到本地 SSH 隧道的入口端口
           proxy_pass http://localhost:9001; 
           proxy_set_header Host $host;
           # ... 其他 header 设置 ...
       }
   }
   

PS
无论使用哪种方法，所有子域名的流量都会经过 Nginx 主服务器。因此，务必确保这台服务器拥有足够大的带宽，以防成为性能瓶颈。