CF优选，简单来说，就是用一个在 Cloudflare 上配置好的域名（B），来给另一个我们自己的主域名（A）借道加速，尤其是显著提升中国大陆的访问速度
角色介绍
为了方便理解，我们先给今天的主角们分配好角色：
-
主域名 (A)：
4399.com- 这是访客真正访问的域名，我们希望它能享受到 Cloudflare 的服务。
- 重要：它的 DNS 解析在别的平台管理（比如阿里云、腾讯云、GoDaddy 等），不是在 Cloudflare。
-
回源域名 (B)：
123456.xyz- 这是我们的“工具域名”，它在 Cloudflare 上进行全部配置，充当一个中间桥梁。
- 它本身不重要，访客也看不到它。
-
你的服务器 IP：
1.2.3.4(这里用一个假的 IP 地址举例)- 这是你网站内容真正存放的地方。
我们的目标：当用户访问 4399.com 时，实际流量会通过 123456.xyz 在 Cloudflare 上的配置，最终安全地访问到你的服务器。
操作开始：一共六个步骤
第一步：配置“回源域名” (123456.xyz)
首先，我们要把我们的“工具域名”123456.xyz 配置好。
- 登录你的 Cloudflare 账号。
- 进入域名
123456.xyz的管理后台。 - 点击左侧的 “DNS” → “Records”。
- 添加一条 A 记录，指向你的真实服务器 IP。
- 类型 (Type):
A - 名称 (Name):
origin(你可以自定义，但用origin比较清晰) - IPv4 地址 (Content):
1.2.3.4(换成你自己的服务器 IP) - 代理状态 (Proxy status): 务必点亮那朵橙色的小黄云！ 这代表流量会经过 Cloudflare。
- 类型 (Type):
现在，访问 origin.123456.xyz 就应该能看到你服务器上的网站内容了，并且是经过 Cloudflare 加速的。
第二步：设置“回退源” (Fallback Origin)
这一步是为了让 Cloudflare 知道，当收到访问 123456.xyz 的请求时，应该去哪里找内容。
- 在
123456.xyz的管理后台，点击左侧的 “SSL/TLS” → “自定义主机名”。 - 向下滑动，找到 “回退源 (Fallback Origin)” 部分。
- 点击 “添加回退源 (Add Fallback Origin)”。
- 在输入框里填入我们上一步创建的子域名：
origin.123456.xyz。 - 点击保存。
保存成功后，状态应该是有效 (Active)。
第三步：添加“自定义主机名” (Custom Hostname)
这是最关键的一步！我们要告诉 Cloudflare：“我授权你用 123456.xyz 的配置来服务 4399.com 这个域名。”
- 在
123456.xyz的管理后台，继续停留在 “SSL/TLS” → “自定义主机名 (Custom Hostnames)” 标签页。 - 点击 “添加自定义主机名 (Add Custom Hostname)”。
- 在弹出的窗口中，输入我们的主域名：
4399.com。 - 其他设置保持默认，点击右下角的 “添加自定义主机名” 按钮。
完成后，Cloudflare 会开始处理，但此时状态会是“待验证 (Pending Validation)”。它需要你证明 4399.com 确实是你的。
第四步：验证“主域名”的所有权
Cloudflare 会给你一条 TXT 记录，你需要把它添加到 4399.com 的 DNS 解析记录里。
- 在刚才的“自定义主机名”页面，你会看到
4399.com旁边有“查看验证 TXT”之类的链接，点开它。 - 你会得到两条 TXT 记录，一条用于域名所有权验证，一条用于证书验证。记下它们的主机名 (Name)和值 (Value)。
- 登录
4399.com的 DNS 管理平台（比如阿里云、腾讯云等）。 - 添加那两条 TXT 记录。
- 主机记录: 复制 Cloudflare 提供的 Name。
- 记录类型:
TXT - 记录值: 复制 Cloudflare 提供的 Value。
- 添加完成后，回到 Cloudflare 页面，耐心等待几分钟到几小时（DNS 生效需要时间）。
当你看到 4399.com 的主机名状态和证书状态都显示为 
有效 (Active) 时，就说明验证成功了！
第五步：将“主域名”指向 Cloudflare
万事俱备，只欠东风！现在我们要让 4399.com 指向我们刚刚在 Cloudflare 搭建好的“桥梁”。
- 再次回到
4399.com的 DNS 管理平台。 - 找到主域名的解析记录（通常是
@或者4399.com本身）。 - 修改或添加一条 CNAME 记录。
- 主机记录:
@(或者www，取决于你想让哪个生效) - 记录类型:
CNAME - 记录值:
origin.123456.xyz
- 主机记录:
优选技巧：
为了获得国内更快的速度，你可以不直接 CNAME 到 origin.123456.xyz，而是使用 优选 CNAME 地址 或者 A 记录。这些地址可以帮助你连接到速度更快的 Cloudflare 节点。
你可以在一些第三方优选工具网站上找到这些地址。找到一个适合你网络的 CNAME 地址（例如 cloudflare.182682.xyz 填linux.do也行
），然后把上面的记录值换成这个优选的 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，明天可能因为用的人太多、或者被运营商盯上而变慢。所以，把它当成一个动态优化的过程，而不是一劳永逸的配置。手里多准备几个备用节点，定期检查速度，才能确保你的网站时刻保持在最佳状态
[details=“如何处理多个子域名服务？”]
如果 4399.com 旗下还有 blog.4399.com 和 shop.4399.com 等多个子域名，它们该如何一同享受加速服务？
第一步：为所有子域名添加“自定义主机名”
首先，需要在 123456.xyz 的 “自定义主机名” 列表里，将每一个需要加速的子域名都添加进去并完成所有权验证。
例如，列表中应包含：
4399.comblog.4399.comshop.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 只需将流量送到这个本地的“口”即可。
操作步骤：
-
在后端服务器上建立隧道：
登录后端博客服务器 (10.0.0.2)，执行以下命令，与主服务器 (1.2.3.4) 建立连接。# 命令格式：ssh -fN -R [主服务器端口]:localhost:[后端服务端口] [主服务器用户名]@[主服务器IP] ssh -fN -R 9001:localhost:8080 [email protected]-fN: 让 SSH 在后台运行。-R 9001:localhost:8080: 意思是将主服务器 (1.2.3.4) 的9001端口收到的所有流量，通过这条加密隧道，转发到当前后端服务器 (10.0.0.2) 的8080端口。- 提示: 为保证隧道断开后能自动重连，建议使用
autossh工具。
-
在主服务器上配置 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 主服务器。因此，务必确保这台服务器拥有足够大的带宽，以防成为性能瓶颈。
