VPSKnow

CDN 加速配置指南

中高级
45分钟

将静态资源托管至全球 CDN 节点,利用智能缓存策略和回源配置,极大提升用户访问网站的速度和可用性。本指南以全球最流行的 Cloudflare 为例进行实战教学——从基础接入到 Tunnel 零端口暴露、R2 对象存储、新一代 Cache Rules,覆盖 2026 年最流行的 CF 玩法。

🌐 CDN 是什么 (CDN 原理)

CDN (Content Delivery Network),即内容分发网络。它是一个由分布在全球各地的服务器组成的网络,旨在更快、更可靠地将网站内容(如图片、CSS、JavaScript 文件)传送给用户。

工作原理

当未使用 CDN 时,所有用户都直接访问您位于单一地点的源站服务器。这会导致地理位置远的用户访问速度慢。

使用 CDN 后,CDN 会将您网站的静态内容缓存到其遍布全球的"边缘节点"(Edge Node)。当用户请求访问您的网站时:

  1. 用户的请求会被智能 DNS 解析到离他最近的 CDN 边缘节点。
  2. 如果该节点有缓存的内容,则直接返回给用户,实现秒开。
  3. 如果节点没有缓存(首次访问),它会向您的源站服务器请求内容,获取后再返回给用户,并同时在节点上缓存一份以备后续使用。

为何使用 CDN

为网站接入 CDN 能带来多方面的好处,是现代网站架构的标配。

🌍

全球加速

用户从最近的节点加载资源,极大降低延迟,提升访问速度。

🔋

高可用性

当源站服务器宕机时,CDN 缓存的资源仍可访问,提升网站在线率。

💰

节省成本

CDN 处理大部分请求,大幅减少源站服务器的带宽消耗和负载压力。

🛡️

安全防护

提供 DDoS 攻击缓解、WAF 等安全功能,保护源站服务器安全。

🏢 CDN 服务商选择

市面上有许多优秀的 CDN 服务商,选择哪家取决于您的预算、目标用户群体和功能需求。

⭐ 免费首选

Cloudflare

提供 CDN、DNS、托管证书以及 Workers、Pages、R2、Tunnel 等产品。各产品的免费计划、合理使用、协议和功能边界并不相同,应按当前文档与账户页面核对,而不是把整个平台理解为不限量免费服务。

国内厂商

如阿里云 CDN、腾讯云 CDN、又拍云等。主要用户在中国大陆时,应先核对域名备案、接入区域、计费和内容合规要求,再用目标省份与运营商的真实访问数据选择服务。

其他国际厂商

如 Bunny CDN、KeyCDN、Amazon CloudFront。通常提供按量计费和不同区域策略,但中国大陆访问表现会随用户运营商、源站位置和当前路由变化,不能用单一测速替代分地区验证。

🚀 Cloudflare 接入实战

下面我们将一步步演示如何将您的网站接入 Cloudflare 的免费 CDN 服务。

1

注册并添加站点

访问 Cloudflare 官网 注册账号,然后点击"添加站点",输入您的域名。

2

选择套餐

选择底部的 Free (免费) 套餐,然后点击继续。

3

检查 DNS 记录

Cloudflare 会自动扫描您现有的 DNS 记录。请确保指向您 VPS IP 地址的 A 记录(通常是根域名和 www)的"代理状态"已开启(即变成 橙色的云朵图标)。

4

修改域名服务器 (NS)

这是最关键的一步。Cloudflare 会提供两个新的 NS 地址。您需要登录您的域名注册商(如 GoDaddy, Namecheap),将您域名的默认 NS 服务器修改为 Cloudflare 提供的这两个地址。

提示: NS 记录在全球生效需要几分钟到几小时不等,请耐心等待。生效后,您会收到 Cloudflare 的确认邮件。

🕳️ Cloudflare Tunnel:出站连接与源站边界

传统 CDN 接入后,源站通常仍需接受 Cloudflare 回源连接。Cloudflare Tunnelcloudflared 主动建立到 Cloudflare 的出站连接,因此被发布的服务可以不开放公网入站端口。但 Tunnel 不会自动清除历史 DNS、邮件、其他服务或同机应用泄露的地址,也会引入 cloudflared、Cloudflare 控制面和出站网络依赖。

🔒

减少入站暴露

被发布服务可不开放公网入站端口,但主机、凭据、应用和隧道进程仍需加固。

🌍

无需公网 IP

家宽、NAT VPS、内网服务器都能通过 Tunnel 对外提供服务,无需公网 IP。

📋

核对计划限制

可用功能、协议、访问控制和计划限制以当前官方文档及账户页面为准。

安装 cloudflared

cloudflared 安装与创建 Tunnel
# ── 方法一:在 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
# 文件路径:~/.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

注册为系统服务并启动

systemd 服务管理
# 将 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 上线前成本检查

存储
GB-month 与类型
写入/列举
A 类操作
读取
B 类操作
取回
按存储类型核对
生命周期
最短期限与删除
预算
告警与用量复核

创建存储桶与上传文件

R2 + Wrangler CLI
# ── 通过 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,应使用 Cache Rules 绕过后台与登录路径,避免登录状态、管理页面或动态内容被错误缓存。

1. 打开 Rules -> Overview -> Cache Rules 2. 新建规则:WordPress admin bypass 3. 匹配后台与登录路径: starts_with(http.request.uri.path, "/wp-admin/") or http.request.uri.path eq "/wp-login.php" 4. Cache eligibility 选择 Bypass cache 5. 部署后用未登录窗口验证后台、登录和前台页面

📋 新一代:Cache Rules 替代 Page Rules

Cloudflare 当前建议新配置使用 Cache Rules、Redirect Rules、Configuration Rules 等现代 Rules 功能。旧 Page Rules 仍可能存在于历史站点中,但不同动作需要迁移到对应的新规则类型;新旧规则的匹配顺序与覆盖关系也不同,不能只把旧配置原样照搬。

Page Rules(旧版)

  • 历史站点可能仍在使用
  • 缓存、重定向与安全动作混在同一规则
  • 第一条匹配规则生效
  • 新配置不再作为首选

Cache Rules(新版)⭐

  • 规则额度按当前计划核对
  • 缓存动作与其他规则类型分离
  • 多条匹配规则可以叠加
  • 支持表达式与 Trace 排查
Cache Rules 配置示例(面板操作 + API)
# 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 + Nginx 双层防护配置
# ── 方法一: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 出站连接。

🧭 中国大陆访问边界与验证

Cloudflare 的公网服务使用泛播网络,但中国大陆用户的实际路径仍受运营商、地区、时段、源站位置与产品计划影响。海外测速站快,不代表中国电信、联通、移动的真实用户也快;同一个城市在晚高峰和白天也可能得出相反结论。

上线前至少做四组验证

  • 分网络: 至少覆盖目标用户常见的中国电信、联通、移动,不能只测自己的宽带。
  • 分时段: 对比工作日白天与晚高峰,记录 DNS、TCP/TLS、首字节和完整页面加载时间。
  • 分对象: 分别验证首页、动态接口、大文件和静态资源,并查看 CF-Cache-Status,避免把源站慢误判为 CDN 慢。
  • 保留基线: 在同一时间窗口对照直连源站或另一家 CDN;变更 DNS 前保存 TTL、证书和回退方案。

不要把第三方“优选 IP”或共享 CNAME 当成长期生产方案。它可能改变证书、Host、缓存隔离、故障归属和服务条款边界,也无法保证后续路由不变。主要服务中国大陆且满足备案条件时,优先比较合规的境内 CDN;无法备案时,应把跨境链路波动写进容量和可用性预期。

⚙️ 性能与安全

Cloudflare 提供多种性能与安全能力,但可用功能、规则额度和界面位置会随计划与产品更新变化。启用前应在当前账户中核对,并用真实流量验证收益和误拦截。

自动压缩 (Auto Minify)

位于 "Speed" → "Optimization"。勾选 JavaScript、CSS、HTML 可以自动移除代码中不必要的字符,减小文件体积。

Brotli 压缩

位于 "Speed" → "Optimization"。开启 Brotli 可以提供比 Gzip 更高的压缩率,进一步加快加载速度。

DDoS 防护与 5 秒盾

遭遇明显的应用层攻击时,可临时启用 Under Attack Mode 触发托管质询。它可能影响正常访客、API 和自动化客户端,应先确认攻击范围并在缓解后关闭。

防火墙规则 (WAF)

在 Security / WAF 相关页面配置托管或自定义规则。规则数量和能力按当前计划核对;先用日志观察匹配,再逐步阻断,避免误伤登录、回调和搜索抓取。

Early Hints(HTTP 103)

Early Hints 可让浏览器更早发现关键资源,但是否改善 LCP 取决于页面依赖和浏览器支持。开启后用真实用户数据或同条件实验验证,不预设固定提升幅度。

Turnstile(替代 reCAPTCHA)

Turnstile 可为登录、注册和表单加入挑战机制,交互方式通常比传统图片挑战轻量。接入时仍要验证服务端令牌、超时与失败回退,并按当前产品条款核对适用范围。

📈 性能监控

Cloudflare 强大的分析后台可以帮助您了解网站的流量、缓存和安全状况。

在 Cloudflare 仪表盘的 "Analytics & Logs" 页面,您可以查看:

  • 流量分析: 总请求数、独立访客数、流量来源国家等。
  • 性能分析: 缓存命中率要按资源类型拆分。动态页面、登录请求和个性化接口本就应绕过缓存,不适合设统一的 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 后网站变更慢了,是什么原因?

不要先假设只有一个原因。按顺序检查:① SSL 与重定向:排除 Flexible 引发的循环;② 缓存状态:用 CF-Cache-Status 区分未缓存、过期和命中,动态内容不要强行缓存;③ 源站与对象:分别测 DNS、连接、首字节、静态资源和动态接口;④ 地区与时段:在目标运营商和晚高峰复测,并与变更前基线对照;⑤ 重新选型:主要服务中国大陆且满足备案条件时,比较合规的境内 CDN;否则为跨境波动保留容量和回退方案。

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/月,按月支付 $25/月,主要增加图片优化、更多安全与性能能力。WAF、规则、分析保留期和附加产品额度会调整,不应依赖教程中的固定数字做购买决定。升级前先列出确实需要的功能,再核对 Cloudflare 当前计划对比;业务关键站点还要评估支持、SLA、预算和回退需求。

申请 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 要立即迁移吗?

不要在没有验证的情况下直接删除。先按 官方迁移表把缓存、重定向、配置和 Origin 动作分别迁移到对应的现代 Rules;使用测试域名或低风险路径验证命中顺序、缓存响应头与重定向,再停用旧规则。Cache Rules 可以叠加匹配,且与 Page Rules 的执行逻辑不同,迁移时必须逐条验收并保留回退记录。

Cloudflare Workers 是什么?免费版能用吗?

Cloudflare Workers 是边缘 JavaScript/Wasm 运行时,可用于请求改写、鉴权、A/B 分流和轻量 API。免费与付费计划的请求、CPU、子请求、存储及关联产品额度会调整,超限后的失败或计费方式也不同;上线前查看 当前定价和限制,并为付费计划设置 CPU 上限、预算与异常流量告警。不要把 Workers 当开放代理,也不要承诺“零冷启动”或整套架构永久零成本。

CDN 会影响 SEO 吗?搜索引擎能正常抓取 Cloudflare 后面的网站吗?

CDN 可能改善加载性能,但不会自动提升排名。当前 Core Web Vitals 关注 LCP、INP 与 CLS;应同时用真实用户数据和 PageSpeed Insights 验证,而不是只看缓存命中。还要检查:① WAF、Bot 管理或质询是否误拦搜索引擎;② 缓存是否让页面、状态码、canonical 或 robots 规则长期过期;③ 源站不可达时是否持续返回旧内容;④ 回源与边缘响应是否保持正确的 HTTP 状态。上线后应结合搜索引擎站长工具、Cloudflare 日志和实际抓取测试复核。

配置 CDN 完成后,下一步应该做什么?

CDN 接入只是网站交付和安全体系的一层,后续应继续验证回源、缓存、监控和故障切换:① 异地组网(第24篇):使用 Tailscale / ZeroTier 等私网连接管理多台服务器,不把管理端口直接暴露给公网——参见异地组网与虚拟局域网;② 代理服务器搭建(第25篇):了解各协议的传输边界,只有 HTTP(S) / WebSocket 兼容场景才评估 CDN 前置——参见代理服务器搭建;③ DNS 服务器搭建(第26篇):结合实际地区与隐私需求设计解析路径,而不是默认所有境外域名都走同一公共 DNS——参见DNS 服务器搭建