将静态资源托管至全球 CDN 节点,利用智能缓存策略和回源配置,极大提升用户访问网站的速度和可用性。本指南以全球最流行的 Cloudflare 为例进行实战教学——从基础接入到 Tunnel 零端口暴露、R2 对象存储、新一代 Cache Rules,覆盖 2026 年最流行的 CF 玩法。
🌐 CDN 是什么 (CDN 原理)
CDN (Content Delivery Network),即内容分发网络。它是一个由分布在全球各地的服务器组成的网络,旨在更快、更可靠地将网站内容(如图片、CSS、JavaScript 文件)传送给用户。
工作原理
当未使用 CDN 时,所有用户都直接访问您位于单一地点的源站服务器。这会导致地理位置远的用户访问速度慢。
使用 CDN 后,CDN 会将您网站的静态内容缓存到其遍布全球的"边缘节点"(Edge Node)。当用户请求访问您的网站时:
- 用户的请求会被智能 DNS 解析到离他最近的 CDN 边缘节点。
- 如果该节点有缓存的内容,则直接返回给用户,实现秒开。
- 如果节点没有缓存(首次访问),它会向您的源站服务器请求内容,获取后再返回给用户,并同时在节点上缓存一份以备后续使用。
⚡ 为何使用 CDN
为网站接入 CDN 能带来多方面的好处,是现代网站架构的标配。
全球加速
用户从最近的节点加载资源,极大降低延迟,提升访问速度。
高可用性
当源站服务器宕机时,CDN 缓存的资源仍可访问,提升网站在线率。
节省成本
CDN 处理大部分请求,大幅减少源站服务器的带宽消耗和负载压力。
安全防护
提供 DDoS 攻击缓解、WAF 等安全功能,保护源站服务器安全。
🏢 CDN 服务商选择
市面上有许多优秀的 CDN 服务商,选择哪家取决于您的预算、目标用户群体和功能需求。
Cloudflare
提供 CDN、DNS、托管证书以及 Workers、Pages、R2、Tunnel 等产品。各产品的免费计划、合理使用、协议和功能边界并不相同,应按当前文档与账户页面核对,而不是把整个平台理解为不限量免费服务。
国内厂商
如阿里云 CDN、腾讯云 CDN、又拍云等。如果您的主要用户在中国大陆,使用备案域名接入这些服务商能获得最佳的境内访问速度。
其他国际厂商
如 Bunny CDN、KeyCDN、Amazon CloudFront。通常是按量付费,提供更精细化的配置选项,适合有特定需求的用户。Bunny CDN 性价比极高,国内访问速度优于 Cloudflare 免费版。
🚀 Cloudflare 接入实战
下面我们将一步步演示如何将您的网站接入 Cloudflare 的免费 CDN 服务。
注册并添加站点
访问 Cloudflare 官网 注册账号,然后点击"添加站点",输入您的域名。
选择套餐
选择底部的 Free (免费) 套餐,然后点击继续。
检查 DNS 记录
Cloudflare 会自动扫描您现有的 DNS 记录。请确保指向您 VPS IP 地址的 A 记录(通常是根域名和 www)的"代理状态"已开启(即变成 橙色的云朵图标)。
修改域名服务器 (NS)
这是最关键的一步。Cloudflare 会提供两个新的 NS 地址。您需要登录您的域名注册商(如 GoDaddy, Namecheap),将您域名的默认 NS 服务器修改为 Cloudflare 提供的这两个地址。
🕳️ Cloudflare Tunnel:出站连接与源站边界
传统 CDN 接入后,源站通常仍需接受 Cloudflare 回源连接。Cloudflare Tunnel 由 cloudflared 主动建立到 Cloudflare 的出站连接,因此被发布的服务可以不开放公网入站端口。但 Tunnel 不会自动清除历史 DNS、邮件、其他服务或同机应用泄露的地址,也会引入 cloudflared、Cloudflare 控制面和出站网络依赖。
减少入站暴露
被发布服务可不开放公网入站端口,但主机、凭据、应用和隧道进程仍需加固。
无需公网 IP
家宽、NAT VPS、内网服务器都能通过 Tunnel 对外提供服务,无需公网 IP。
核对计划限制
可用功能、协议、访问控制和计划限制以当前官方文档及账户页面为准。
安装 cloudflared
# ── 方法一:在 Cloudflare 控制台创建 Tunnel(推荐,图形化)──────────────────
# 1. 登录 Cloudflare Dashboard → Zero Trust → Networks → Tunnels
# 2. 点击 "Create a tunnel",命名(如 my-vps),复制安装命令
# 3. 在 VPS 上运行 Cloudflare 自动生成的安装命令(含 Token)
# ── 方法二:命令行安装 cloudflared ────────────────────────────────────────────
# Ubuntu/Debian
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | gpg --dearmor -o /usr/share/keyrings/cloudflare-main.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared jammy main" | tee /etc/apt/sources.list.d/cloudflared.list
apt update && apt install cloudflared -y
# 登录并授权
cloudflared tunnel login
# 创建 Tunnel
cloudflared tunnel create my-vps
# 会生成一个 UUID 和凭证文件,记住 UUID(下面要用) Tunnel 配置文件(多服务映射)
# 文件路径:~/.cloudflared/config.yml
# 将本地服务通过 Tunnel 暴露到公网,完全不需要开放防火墙端口
tunnel: 你的Tunnel_UUID
credentials-file: /root/.cloudflared/你的UUID.json
ingress:
# 规则1:将 blog.yourdomain.com 转发到本地 Nginx 的 8080 端口
- hostname: blog.yourdomain.com
service: http://localhost:8080
# 规则2:将 status.yourdomain.com 转发到本地 Uptime Kuma 的 3001 端口
- hostname: status.yourdomain.com
service: http://localhost:3001
# 规则3:将 ssh.yourdomain.com 转发到本地 SSH(可用 cloudflared 客户端 SSH)
- hostname: ssh.yourdomain.com
service: ssh://localhost:22
# 兜底规则(必须有,否则 Tunnel 无法启动)
- service: http_status:404 注册为系统服务并启动
# 将 cloudflared 注册为系统服务(开机自启)
cloudflared service install
# 启动服务
systemctl start cloudflared
systemctl enable cloudflared
# 查看状态
systemctl status cloudflared
# 查看连接日志
journalctl -u cloudflared -f
# 在 Cloudflare DNS 面板中,会自动创建 CNAME 记录指向 Tunnel,
# 无需为该主机名配置源站 A/AAAA;仍需检查其他 DNS、邮件和历史记录是否泄露 IP。 💡 Tunnel vs 传统 CDN 接入的选择: 如果您的主要诉求是网站加速和隐藏 IP,传统橙云代理接入更简单;如果您要暴露多个内部服务(Uptime Kuma/Nextcloud/Jupyter 等)、家宽/内网服务器,或者极度在意安全(不想开放任何入站端口),Tunnel 是更好的选择。两者可以并存——同一域名下不同子域名分别用两种方式接入。
🪣 进阶:Cloudflare R2 + CDN 静态资源托管
Cloudflare R2 提供 S3 兼容接口,可托管图片、CSS、JS 等静态对象。成本不能只看出站流量:还要计算 GB-month、A/B 类操作、存储类型、取回、最短存储期和计费单位取整。免费额度及价格会调整,部署前应查看 R2 当前官方计费,并设置用量监控与预算边界。
R2 上线前成本检查
创建存储桶与上传文件
# ── 通过 Cloudflare Dashboard 创建 R2 存储桶 ────────────────────────────────
# 1. 登录 Cloudflare Dashboard → R2 → Create bucket
# 2. 取名(如 static-assets),区域选 Auto
# 3. 创建完成后进入存储桶 → Settings → Custom Domains
# 添加自定义域名(如 cdn.yourdomain.com),Cloudflare 自动配置 CDN
# ── 通过 Wrangler CLI 管理 R2(推荐自动化场景)────────────────────────────────
npm install -g wrangler
# 登录
wrangler login
# 上传单个文件
wrangler r2 object put static-assets/images/logo.png --file ./logo.png
# 批量同步本地目录到 R2(将 dist/ 目录发布到 R2)
wrangler r2 object put static-assets/ --file dist/ --recursive
# 查看存储桶内容
wrangler r2 object list static-assets/ Nginx 层透明重写到 R2 CDN
# R2 存储桶公开访问策略(在 Dashboard → R2 → 存储桶 → Settings → Public access 设置)
# 开启 "Allow Public Access" 后,文件可通过 cdn.yourdomain.com/文件名 直接访问
# ── 配合 Nginx 将静态资源重写到 R2 CDN ───────────────────────────────────────
# 网站源码中静态资源仍使用相对路径,Nginx 层做透明重写
# 修改 /etc/nginx/conf.d/yourdomain.conf:
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?)$ {
# 将静态资源请求重写到 R2 CDN
rewrite ^/(.*)$ https://cdn.yourdomain.com/$1 redirect;
# 或使用代理而非重定向(保持 URL 不变):
# proxy_pass https://cdn.yourdomain.com;
} 🌐 进阶:HTTP(S) 服务通过 CDN 前置
Cloudflare 橙云可以让用户先访问边缘节点,再由 Cloudflare 回源到 HTTP(S) 服务,从而隐藏公开 DNS 中的源站地址并提供缓存、TLS 与安全策略。但这不是“修复 IP”:Ping 和 SSH 不会因此恢复,普通 TCP / UDP 也不在标准 CDN 代理范围内;如果 Cloudflare 无法连接源站,访问仍会失败。
使用 CDN 前置的边界与前置条件:
仅适用于符合 Cloudflare 代理能力与服务条款的 HTTP(S) / WebSocket 场景: 1. 源站必须仍能从 Cloudflare 网络正常回源;CDN 不能修复宕机、服务未监听或回源被阻断。 2. 传输层与应用必须是 Cloudflare 支持的 HTTP(S) 兼容方式,例如 WebSocket;普通 SSH、任意 TCP / UDP 不会被橙云直接代理。 3. 端口必须使用 Cloudflare 支持的代理端口: HTTP 端口:80, 8080, 8880, 2052, 2082, 2086, 2095 HTTPS 端口:443, 2053, 2083, 2087, 2096, 8443 4. 域名、TLS、Host、路径和 WebSocket 设置必须在客户端、Cloudflare 与源站之间保持一致。 5. 管理入口与业务入口分离;SSH 仍需通过可达 IP、VPN、商家控制台或专门的接入产品管理。
上线前分别验证边缘访问、Cloudflare 回源、TLS 和业务路径,并保留不依赖公开业务域名的管理入口。实际延迟和吞吐取决于用户到边缘、边缘到源站及 Cloudflare 策略,应按目标地区和晚高峰复测。
📦 核心:缓存与绕过策略
合理的缓存策略是发挥 CDN 威力的关键。既要让静态资源被牢牢缓存,又要防止动态内容(如后台登录、用户购物车)被错误缓存。
缓存级别 (Caching Level)
面板位置: Caching → Configuration
- Standard (标准): 默认选项。当资源带有 Cache-Control 等 HTTP 头时才缓存。
- No Query String: 忽略 URL 中的查询参数进行缓存,提升命中率。
- Ignore Query String: 缓存所有静态内容,即使没有缓存头。
浏览器缓存 TTL
决定了资源在用户浏览器中缓存多长时间。设置较长时间(如 4 小时或 1 个月)可以极大减少重复加载。
必配:动态后台绕过缓存 (Bypass Cache)
如果您的网站是 WordPress,强烈建议利用 Page Rules 绕过后台缓存,否则会导致无法登录、无限循环或用户串号。
📋 新一代:Cache Rules 替代 Page Rules
Cloudflare 在 2024 年推出 Cache Rules 作为旧版 Page Rules 的替代品,配置更灵活、功能更强大。免费版提供 10 条 Cache Rules(Page Rules 只有 3 条),应该优先使用 Cache Rules 来管理缓存策略。
Page Rules(旧版)
- 免费版 3 条规则
- 功能混杂(缓存/重定向/安全全在一起)
- Cloudflare 不再主动推荐
- 未来可能下线
Cache Rules(新版)⭐
- 免费版 10 条规则
- 专注缓存相关设置,逻辑更清晰
- 支持正则表达式匹配
- 2024年推出,持续迭代中
# Cache Rules 在 Cloudflare 面板位置:
# Rules → Cache Rules → Create Rule
# ── 规则示例一:WordPress 后台强制绕过缓存 ───────────────────────────────────
# 规则名称:Bypass WordPress Admin
# 条件:URI Path contains /wp-admin
# OR Cookie contains wordpress_logged_in
# 动作:Cache Status = Bypass
# ── 规则示例二:静态资源长期缓存 ─────────────────────────────────────────────
# 规则名称:Cache Static Assets
# 条件:URI Path matches regex \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2)$
# 动作:Cache Status = Cache Everything
# Edge TTL = 1 month
# Browser TTL = 1 week
# ── 规则示例三:API 路径实时响应 ─────────────────────────────────────────────
# 规则名称:No Cache for API
# 条件:URI Path starts with /api/
# 动作:Cache Status = Bypass
# Disable Apps = true
# ── 通过 API 创建 Cache Rule(自动化部署场景)────────────────────────────────
# 需要先获取 Zone ID 和 API Token(API Token 需要 Cache Rules:Edit 权限)
curl -X POST "https://api.cloudflare.com/client/v4/zones/你的Zone_ID/rulesets/phases/http_request_cache_settings/entrypoint/rules" -H "Authorization: Bearer 你的API_Token" -H "Content-Type: application/json" -d '{
"action": "set_cache_settings",
"action_parameters": {
"cache": true,
"edge_ttl": { "mode": "override_origin", "default": 2592000 }
},
"expression": "(http.request.uri.path matches "\\.(jpg|png|css|js)$")",
"description": "Cache static assets for 30 days"
}' 🏠 核心:回源配置
回源配置定义了 CDN 如何与您的源站服务器通信,这里的设置错误是导致网站打不开的最大元凶。
SSL/TLS 加密模式
位于 "SSL/TLS" → "Overview" 页面:
| 模式 | 安全性 | 描述与适用场景 |
|---|---|---|
| Off | 不安全 | 不使用 SSL 加密。 不推荐使用。 |
| Flexible | 低 | 用户到 Cloudflare 加密,Cloudflare 到源站不加密。 仅当源站不支持 SSL 时使用,存在安全风险,极易引发重定向循环。 |
| Full | 中 | 全程加密,但 Cloudflare 不验证源站 SSL 证书的有效性。 源站有自签名证书时使用。 |
| Full (Strict) | 高 (推荐) | 全程加密,且 Cloudflare 会严格验证源站 SSL 证书。 源站已部署有效 SSL 证书(如 Let's Encrypt)。 |
始终在线 (Always Online)
在 "Caching" → "Configuration" 中开启。当您的源站意外宕机时,Cloudflare 会尽可能地从缓存中为用户提供网站的静态副本,提升可用性。
🛡️ 进阶:源站 IP 防护加固
开启 Cloudflare 代理不会自动消除历史 DNS、邮件或其他服务暴露的源站地址。对只应由 Cloudflare 回源的 Web 端口,可在确认控制台恢复通道后,仅放行 Cloudflare 当前公布的 IP 网段;同时定期同步网段变化并验证 IPv4、IPv6、健康检查和回滚,避免规则过期造成中断。
# ── 方法一:UFW 只允许 Cloudflare IP 段访问 80/443 ────────────────────────────
# 先清空现有 80/443 规则
ufw delete allow 80/tcp
ufw delete allow 443/tcp
# 添加 Cloudflare IPv4 IP 段(来源:https://www.cloudflare.com/ips-v4)
for ip in 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22; do
ufw allow from "$ip" to any port 80,443 proto tcp
done
# 添加 Cloudflare IPv6 IP 段
for ip in 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32; do
ufw allow from "$ip" to any port 80,443 proto tcp
done
ufw reload
echo "源站已只对 Cloudflare IP 开放 80/443"
# ── 方法二:Nginx 层拒绝非 CF 直连 ───────────────────────────────────────────
# 在 nginx.conf 的 server 块中添加:
# real_ip_header CF-Connecting-IP; # 获取真实用户 IP
# if ($http_cf_connecting_ip = "") {
# return 444; # 没有 CF-Connecting-IP 头 = 非 CF 请求,直接关闭连接
# }
# ── 方法三:定期自动更新 CF IP 白名单(推荐)─────────────────────────────────
# 创建更新脚本 /root/update-cf-ips.sh
# !/bin/bash
# curl -fsSL https://www.cloudflare.com/ips-v4 > /tmp/cf-ips-v4.txt
# curl -fsSL https://www.cloudflare.com/ips-v6 > /tmp/cf-ips-v6.txt
# # 然后用 ipset 或 iptables 批量更新规则
# crontab 每周一次:0 4 * * 1 /root/update-cf-ips.sh ⚠️ 注意: 配置 CF IP 白名单之前,请确认 Cloudflare Tunnel 或 SSH 访问不走 80/443 端口,否则可能锁死自己。SSH 通常在 22 端口,不受影响。如果您用 Tunnel 管理服务器,源站防火墙可以更激进——直接封死所有入站 80/443,只保留 Tunnel 出站连接。
🚀 进阶:国内优选 IP 提速
痛点: Cloudflare 免费版分配给中国大陆用户的泛播 IP,通常路由到了美国西海岸(如 San Jose),导致国内访问速度反而变慢,被戏称为"减速云"。
什么是优选 IP?
虽然默认 IP 绕路,但 Cloudflare 在全球拥有极多优质节点。高级玩家会通过测速脚本,扫描出当前网络环境下延迟最低、不丢包的 CF 节点 IP(如香港、日本节点),然后通过自定义 DNS 解析,将国内流量强制引导至这些优质 IP 上。
- 推荐工具:
CloudflareST(GitHub 搜索,XIU2 出品,Star 数最多)。 - 实施前提: 由于 Cloudflare 免费版强制要求使用 NS 接入,想要做优选 IP,通常需要利用第三方平台配合 SaaS 接入技术 (CNAME 接入) 来实现。配置相对复杂,适合爱折腾的极客。
CloudflareST 实战测速命令
# ── 安装 CloudflareST(Cloudflare IP 测速工具)────────────────────────────────
wget -N https://github.com/XIU2/CloudflareSpeedTest/releases/latest/download/CloudflareST_linux_amd64.tar.gz
tar -zxf CloudflareST_linux_amd64.tar.gz
chmod +x CloudflareST
# ── 基础测速(扫描默认 CF IP 库,找延迟最低的节点)───────────────────────────
./CloudflareST
# ── 高级测速(自定义参数,更精准)──────────────────────────────────────────
./CloudflareST -n 500 # 延迟测速线程数(默认200)
-t 4 # 延迟测速次数(默认4次取平均)
-tp 443 # 测速端口(默认443,HTTPS)
-url "https://cf.xiu2.xyz/url" # 自定义下载测速 URL
-tl 200 # 延迟上限(ms),超过不要
-sl 5 # 下载速度下限(MB/s),低于不要
-p 20 # 最终结果显示20个IP
# ── 结果说明 ─────────────────────────────────────────────────────────────────
# 结果保存在 result.csv,格式:IP地址,已发送,已接收,丢包率,平均延迟,下载速度
# 取第一行(最优IP),记录下来
# ── 指定 IP 段扫描(只扫香港/日本节点)──────────────────────────────────────
# 从 https://cf.xiu2.xyz/ip.txt 下载各地区 CF IP 段列表
# 指定只扫亚洲节点:
./CloudflareST -f hk_jp_ips.txt -p 10 ⚙️ 性能与安全
Cloudflare 免费提供了大量能一键开启的性能与安全增强功能。
自动压缩 (Auto Minify)
位于 "Speed" → "Optimization"。勾选 JavaScript、CSS、HTML 可以自动移除代码中不必要的字符,减小文件体积。
Brotli 压缩
位于 "Speed" → "Optimization"。开启 Brotli 可以提供比 Gzip 更高的压缩率,进一步加快加载速度。
DDoS 防护与 5 秒盾
当遭遇 CC 攻击时,开启 "Under Attack Mode",所有访客将经历 5 秒的人机验证,能拦截 99% 的僵尸网络。
防火墙规则 (WAF)
位于 "Security" → "WAF"。免费版提供 5 条自定义规则,您可以用来屏蔽恶意 IP 段或特定国家/地区的请求。
Early Hints(HTTP 103)
位于 "Speed" → "Optimization"。浏览器在收到 200 响应前就开始预加载关键资源,可将 LCP 指标提升 10-30%。
Turnstile(替代 reCAPTCHA)
Cloudflare 自家的无感人机验证服务,2022 年推出,无需用户完成图片点击,隐私友好,免费无限次使用,是 reCAPTCHA 的最佳替代品。
📈 性能监控
Cloudflare 强大的分析后台可以帮助您了解网站的流量、缓存和安全状况。
在 Cloudflare 仪表盘的 "Analytics & Logs" 页面,您可以查看:
- 流量分析: 总请求数、独立访客数、流量来源国家等。
- 性能分析: 缓存命中率 (Cache Hit Ratio) 是关键指标,命中率越高,说明 CDN 效果越好。目标 80% 以上。
- 安全分析: 被阻止的威胁数量、DDoS 攻击详情等。
- Web Analytics(免费): 无 Cookie 的隐私友好访客统计,可替代 Google Analytics,无需在页面插入追踪脚本。
🔧 故障排查
接入 CDN 后遇到问题?这里是一些常见的 Cloudflare 错误及其排查方向。
❌ 错误 521: Web server is down
含义: Cloudflare 无法连接到您的源站服务器。
排查: 1. 检查您的 VPS 服务器是否在线。 2. 检查服务器防火墙(如 ufw)是否屏蔽了 Cloudflare 的 IP 地址。 3. 如果刚配置了 CF IP 白名单,确认白名单 IP 段是最新的。
❌ 错误 525/526: SSL Handshake Failed
含义: 源站的 SSL 证书有问题。
排查: 1. 确保您的源站已经安装了有效的 SSL 证书。 2. 检查 Cloudflare 的 SSL/TLS 加密模式是否设置为"Full (Strict)",并且源站证书有效。 3. 如果证书刚续期,等待几分钟再试。
❌ 错误 524: A timeout occurred
含义: Cloudflare 连接到源站后,源站处理请求时间过长(超过 100 秒)未响应。
排查: 检查您的网站程序或数据库是否存在性能瓶颈,导致页面生成缓慢。
⚠️ 网站出现"重定向次数过多"
含义: 发生了 HTTP/HTTPS 循环重定向。
排查: 通常是因为 SSL/TLS 加密模式设置为"Flexible",而您的源站又强制将 HTTP 重定向到 HTTPS。请将模式更改为"Full"或"Full (Strict)"。
⚠️ Cloudflare Tunnel 连接中断
含义: cloudflared 守护进程与 Cloudflare 的连接丢失。
排查: 1. systemctl status cloudflared 检查服务状态。 2. journalctl -u cloudflared -n 50 查看最近日志找错误原因。 3. 确认 VPS 出站网络正常(curl https://cloudflare.com)。 4. 检查 config.yml 配置文件语法是否正确。
❓ 常见问题解答
接入 Cloudflare 后网站变更慢了,是什么原因?
这是"减速云"问题,Cloudflare 免费版将中国大陆用户的流量路由到美国节点,绕了一大圈反而变慢。解决方案按难度从低到高:① 检查 SSL 模式:先确认不是因为 Flexible 引发重定向循环导致加载多次;② 开启 Cloudflare 的 Speed 优化选项:Auto Minify + Brotli + Early Hints;③ 优化缓存命中率:用 CF-Cache-Status 响应头验证资源是否真的被缓存(HIT 才有效),静态资源 TTL 设长;④ 优选 IP(进阶):通过 CloudflareST 扫出延迟低的 CF 节点,配合 CNAME/SaaS 接入方案引导国内流量(见本文优选 IP 章节);⑤ 换方案:如果主要服务国内用户且域名已备案,国内 CDN(阿里云/腾讯云)的国内访问速度远优于 Cloudflare 免费版。
Cloudflare 会隐藏我的源站 IP 吗?隐藏后源站是否绝对安全?
开启橙色云朵代理后,DNS 解析返回的是 Cloudflare 的 IP,而非您的源站 IP,能有效隐藏真实 IP。但不是绝对安全,以下情况会泄露真实 IP:① 历史 DNS 记录:接入 CF 前 DNS 是裸 IP,攻击者可能已记录在案(SecurityTrails 等历史查询工具);② 邮件服务器 MX 记录:如果 MX 记录指向同一台机器的另一个子域名(未开代理),会暴露 IP;③ 直接连接测试:攻击者扫描 CF IP 段并对每个 IP 发 HTTP Host 头探测,可能碰到您的源站;④ SSL 证书泄露:老版本 Censys 搜索引擎收录了大量 SSL 证书与 IP 的对应关系。加固建议:按本文"源站 IP 防护加固"章节,在源站 Nginx/UFW 中只允许 Cloudflare 的 IP 段访问 80/443 端口,拒绝所有其他来源的直连。
网站更新了内容但 Cloudflare 还在显示旧缓存,如何强制刷新?
多种方法按场景选用:① Cloudflare 面板清除缓存:Caching → Configuration → Purge Cache → Purge Everything(清除全部缓存)或输入具体 URL 精准清除;② 开发者模式:Caching → Configuration → Development Mode,开启后 3 小时内所有请求直接回源,不走缓存,适合密集更新期间;③ 版本号/哈希后缀:更好的长期方案是在静态资源 URL 后加版本号(如 style.css?v=1.2),URL 变了自然绕过缓存;④ Cloudflare 插件自动清除:WordPress 安装 Cloudflare 官方插件,每次发布/更新文章时自动调用 API 清除相关页面缓存,无需手动操作;⑤ API 批量清除:curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" -H "Authorization: Bearer TOKEN" -d '{"purge_everything":true}' 可以集成到 CI/CD 部署流程中自动触发。
Cloudflare 免费版和 Pro 版的核心区别是什么?有必要升级吗?
对个人博客和中小网站来说,免费版已经非常够用。Pro($20/月)的主要提升:① WAF 规则数量:免费版 5 条自定义规则,Pro 是 20 条;② 图片优化:Polish(无损/有损图片压缩)和 Mirage(移动端图片懒加载);③ Page Rules 数量:免费版 3 条,Pro 是 20 条(但 Cache Rules 免费版已有 10 条,减少了升级必要性);④ 更快的 DDoS 缓解:Pro 的 5 秒盾响应更快;⑤ 更多分析数据:更长时间范围的历史数据。升级建议:日均 PV 超过 5 万、有频繁 DDoS 攻击,或需要精细的 WAF 规则时再考虑 Pro。Enterprise 版(自定义报价)才真正提供中国大陆优化路由节点。
申请 SSL 证书时(如 certbot)提示域名验证失败,是 Cloudflare 的问题吗?
Cloudflare 代理并不必然让 HTTP-01 失败,应先检查挑战路径是否被重定向、缓存、WAF 或源站规则干扰。可用 Certbot 的 Cloudflare DNS 插件配合最小权限 Token 自动完成 DNS-01;手动 DNS 模式通常不能无人值守续期。Cloudflare Origin CA 只受 Cloudflare 到源站链路信任,暂停代理或直连时浏览器可能报不受信任;证书仍有到期时间,而且 Cloudflare 当前不主动发送 Origin CA 到期通知,因此必须纳入证书清单、独立监控和轮换演练,并使用 Full (strict)。
Cloudflare 能防 DDoS,但攻击者直接打源站 IP 怎么办?
对传统回源,应在保留控制台恢复通道的前提下,只允许 Cloudflare 当前公布的网段访问 Web 端口,并建立网段更新、配置预演和回滚流程。不能仅凭 CF-Connecting-IP 是否存在判断来源:直连客户端可以伪造普通 HTTP 请求头,必须先在网络层确认请求来自可信代理,再恢复真实访客地址。Tunnel 可减少公网入站暴露,但仍需保护 Token、限制 cloudflared 到本机服务的权限、监控连接与保留故障回退;地址轮换前也要先清理 DNS、邮件和其他泄露路径。
Page Rules 只有 3 条(免费版),如何最大化利用?
免费版 3 条 Page Rules 要用在刀刃上。推荐优先级配置:① 第1条(最高优先):绕过后台缓存——*yourdomain.com/wp-admin* → Cache Level: Bypass,解决 WordPress 后台无法登录的问题;② 第2条:API/动态路径绕过——*yourdomain.com/api/* → Cache Level: Bypass + Disable Performance,确保 API 返回实时数据;③ 第3条:强制缓存静态资源——*yourdomain.com/wp-content/uploads/* → Cache Level: Cache Everything + Edge Cache TTL: 1 Month,把图片/附件等长期缓存在 CF 节点。更推荐的方式:如前所述,2024 年推出的 Cache Rules 免费版有 10 条规则,配置更灵活,优先使用 Cache Rules 完成缓存相关需求,把 Page Rules 留给重定向等其他场景。
Cloudflare Workers 是什么?免费版能用吗?
Cloudflare Workers 是边缘 JavaScript/Wasm 运行时,可用于请求改写、鉴权、A/B 分流和轻量 API。免费与付费计划的请求、CPU、子请求、存储及关联产品额度会调整,超限后的失败或计费方式也不同;上线前查看 当前定价和限制,并为付费计划设置 CPU 上限、预算与异常流量告警。不要把 Workers 当开放代理,也不要承诺“零冷启动”或整套架构永久零成本。
CDN 会影响 SEO 吗?搜索引擎能正常抓取 Cloudflare 后面的网站吗?
正面影响:CDN 让网站加载更快,而 Core Web Vitals(LCP/FID/CLS)是 Google 排名因素——网站越快,SEO 越好。Cloudflare 的 IP 质量比普通 VPS 高,也不容易被 Google 怀疑为垃圾站。注意事项:① 爬虫不会被 5 秒盾拦截:Googlebot/Bingbot 等主流搜索引擎已在 Cloudflare 白名单中,不会触发人机验证;② 缓存不影响抓取新鲜度:搜索引擎爬虫通常会携带 Cache-Control: no-cache 头,Cloudflare 会直接回源;③ WAF 别误封爬虫:如果 WAF 规则配置过激(如封所有机器人 UA),可能误伤 Googlebot——在 WAF 规则中明确放行 Google/Bing/Baidu 的爬虫 IP 段;④ 百度收录问题:百度爬虫 IP 来自中国大陆,部分 Cloudflare WAF 规则可能将其视为可疑流量,可在 Security → Bots 中确认百度爬虫不被拦截。
配置 CDN 完成后,下一步应该做什么?
CDN 接入只是网站交付和安全体系的一层,后续应继续验证回源、缓存、监控和故障切换:① 异地组网(第24篇):使用 Tailscale / ZeroTier 等私网连接管理多台服务器,不把管理端口直接暴露给公网——参见异地组网与虚拟局域网;② 代理服务器搭建(第25篇):了解各协议的传输边界,只有 HTTP(S) / WebSocket 兼容场景才评估 CDN 前置——参见代理服务器搭建;③ DNS 服务器搭建(第26篇):结合实际地区与隐私需求设计解析路径,而不是默认所有境外域名都走同一公共 DNS——参见DNS 服务器搭建。