Cloudflare 免费 CDN 实战：DNS 接入、SSL、缓存与防 CC 一次配好 - 主机测评网

不少站长把 VPS 买回来、把网站跑起来之后，注意力就全放在了内容上，却忽略了一个很现实的问题：源站 IP 从一开始就暴露在公网上。别人扫到你的 IP，就能绕过一切防护直接打源站；带宽被刷、CPU 被打满、数据库连接被占死，网站该挂还是挂。Cloudflare 的免费套餐，恰好能把这几个最要命的问题一次性解决掉：隐藏源站 IP、缓存静态资源、免费 SSL、以及一层基础但够用的 CC 防护。

这篇文章不堆概念，按真实部署顺序走一遍：从添加站点、切换 NS，到 DNS 橙云开关、SSL 模式选择、缓存规则、安全规则，最后处理「回源真实 IP」这个九成新手都会踩的坑。照着做完，一套能长期稳定运行的免费 CDN 方案就搭好了。

一、免费版能给你什么，不能给你什么

先把预期摆正。Cloudflare 免费版对我们这种个人站、测评站、小型业务站来说，核心价值有四条：

隐藏源站 IP：域名解析到 Cloudflare 节点，源站 IP 不再直接暴露；
静态资源缓存：图片、CSS、JS 走边缘节点，源站带宽和响应时间都能降下来；
免费 SSL：Universal SSL 自动签发，浏览器到 Cloudflare 这一段全程 HTTPS；
基础防护：WAF 自定义规则、速率限制、Bot Fight Mode，挡掉大部分脚本小子和采集器；
全球 Anycast 解析：DNS 生效快，解析线路也比普通免费 DNS 稳。

它不能给你的同样要说清楚：免费版没有 SLA 保证，节点质量看地区，中国大陆访问走的是国际线路，速度不一定比直连快，甚至可能更慢；免费套餐的 WAF 规则条数、速率限制规则条数都很有限，具体额度以后台实际显示为准；大文件、视频这类流量也不适合硬塞给 CDN。所以正确的心态是：用 Cloudflare 做隐藏源站、缓存静态资源、兜底防护，而不是指望它把大陆访问速度也一起优化了。

二、接入第一步：添加站点并切换 NS

登录 Cloudflare 控制台，点击 Add a site，输入裸域名（例如 fvps.cn），不要带 www，也不要带 http://；
套餐选 Free 就够了，后面需要再升级；
系统会自动扫描现有的 DNS 记录，这一步一定要逐条核对，尤其是 MX 邮件记录和 TXT 验证记录；
拿到分配给你的两个 NS 地址，通常是 xxx.ns.cloudflare.com 和 yyy.ns.cloudflare.com；
到域名注册商后台，把域名的 DNS 服务器改成这两个地址，原来的 NS 记录删掉。

切换之前，如果原解析商支持，先把 TTL 调到最低（比如 300 秒），万一出问题能快速切回去。改完 NS 后用命令验证是否已经生效：

dig NS fvps.cn +short
dig +trace fvps.cn | tail -20

正常情况下几十分钟内生效，最长不超过 24 小时。这段时间里不要反复改来改去，否则只会延长生效时间。

三、DNS 记录怎么配：橙云不是随便开的

NS 生效后，进 DNS 面板逐条配置。一个典型的建站配置是：

A 记录：名称 @，内容填源站 IPv4 地址，开启橙云（Proxied）；
CNAME 记录：名称 www，内容填 fvps.cn，开启橙云；
MX 记录：邮件服务，必须保持灰云（DNS only），橙云会导致邮件收发异常；
TXT 记录：SPF、DKIM、各类验证记录，一律灰云；
面板、API、SSH 等子域名：建议灰云，或者干脆不要解析到同一台机器，避免后台入口被打。

几个容易忽略的细节：

第一，橙云只代理特定端口，常规的 80、443、8080、8443、2052、2053 等端口才会走 CDN，像 8888、888 这种面板端口即便开了橙云也不会被代理，访问会直接落到源站，等于没隐藏。

第二，开了橙云之后，源站的防火墙必须放行 Cloudflare 的 IP 段，否则会出现大面积 522。Cloudflare 会定期更新 IP 列表，最稳妥的做法是用官方接口拉取并生成放行规则：

curl -s https://www.cloudflare.com/ips-v4
curl -s https://www.cloudflare.com/ips-v6

把结果写到脚本里，配合 iptables 或 ufw 定时更新。如果源站直接全量放行 80/443，又叠加了「只允许 Cloudflare IP 访问」的策略，那 CDN 才算真正闭环。

四、SSL 模式：Flexible 是最常见的坑

这是新手最容易配错、也最容易导致网站出问题的地方。Cloudflare 的 SSL/TLS 模式有三种：

Flexible：Cloudflare 到源站走 HTTP。源站如果配置了强制 HTTPS 跳转，就会形成无限重定向循环（ERR_TOO_MANY_REDIRECTS）；而且这一段明文传输，等于只锁了前门；
Full：Cloudflare 到源站走 HTTPS，但不校验证书。能用，但不防中间人；
Full (Strict)：Cloudflare 到源站走 HTTPS 并校验证书，源站必须持有有效证书，这是唯一推荐的模式。

正确顺序是：先在源站用 Let's Encrypt 或商业证书把 HTTPS 配好，确认 https://源站IP 能正常访问且证书有效，再把 Cloudflare 切到 Full (Strict)。同时建议开启：

Always Use HTTPS：把 http 请求 301 到 https；
Automatic HTTPS Rewrites：自动修掉页面里的混合内容；
Minimum TLS Version 设为 TLS 1.2；
HSTS 建议先用较短的 max-age 观察，确认全站 HTTPS 没问题后再逐步加长，不要一上来就设一年。

源站 Nginx 这边保留 80 端口做跳转，证书用 certbot 自动续期，不要再依赖 Cloudflare 的 Flexible 来「假装」有证书，那是最脆弱的方案。

五、缓存规则：让静态资源真正命中边缘节点

很多人开了 Cloudflare 就以为缓存自动生效，实际上默认只缓存一批常见静态后缀，而且受源站响应头影响。真正的优化要落到 Cache Rules 上，建议按路径区分：

图片、CSS、JS、字体目录（如 /static/、/wp-content/uploads/）：Edge TTL 设 1 个月，Browser TTL 设 1 天到 7 天；
HTML 首页和文章页：可以短缓存，比如 10 到 30 分钟，兼顾更新和命中；
后台、登录、购物车、结算、用户中心：一律 Bypass Cache，例如 /wp-admin/*、/login、/cart/*；
带登录态 Cookie 的请求：设置绕过规则，避免把用户 A 的页面缓存给用户 B。

配置完用命令行验证命中情况：

curl -I https://fvps.cn/static/logo.png | grep -i cf-cache-status

返回 HIT 说明命中，MISS 是首次回源，DYNAMIC 说明这条请求没走缓存规则，BYPASS 则是被规则主动跳过。如果一直是 DYNAMIC，优先检查源站是否发了 Cache-Control: no-store 或 Set-Cookie，这两个头会让 Cloudflare 直接放弃缓存。

另外，不要给整站无脑开 Cache Everything。动态页面、带用户信息的页面被缓存，轻则显示错乱，重则泄露数据。改动规则后记得 Purge 一次缓存，否则旧内容还会挂在边缘节点上。

六、防 CC 与基础安全设置

免费版的防护不算强，但用对了足以挡掉绝大多数低级攻击。建议按这个顺序开：

Security Level 平时设 Medium，被刷时临时调 High，不要长期挂 High，会误伤正常用户和搜索引擎；
Bot Fight Mode 打开，能挡掉一批已知的恶意爬虫；
WAF 自定义规则：拦截空 UA、拦截明显异常的路径扫描，比如对 /wp-login.php、/xmlrpc.php 的非正常请求；
Rate Limiting：对登录、搜索、评论接口做频率限制，例如同一 IP 10 秒内超过 30 次请求就阻断 1 分钟，这是防 CC 最有效的一招；
Under Attack Mode 是最后手段，开启后所有访客要过 5 秒验证，非必要不要开。

规则要一条条加，每加一条观察一段时间日志，确认没有误杀再继续。免费版规则条数有限，优先保护登录、搜索、评论这三个最容易被刷的入口。

七、最容易翻车的一步：回源真实 IP

这一节如果跳过，前面的防护基本白做。开了 CDN 之后，源站 Nginx 日志里记录的全是 Cloudflare 节点的 IP，你的 fail2ban、宝塔防火墙、自建限流全部会失效——因为它们看到的永远是同一个「大客户」，真凶藏在 CF-Connecting-IP 请求头里。

更危险的是，有人一怒之下把这些 Cloudflare IP 全封了，结果全站 522，因为所有回源请求都被自己拒之门外。

正确做法是在 Nginx 里启用 realip 模块，把 Cloudflare 的 IP 段设为可信来源，并从请求头取真实 IP：

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 172.64.0.0/13;
real_ip_header CF-Connecting-IP;

完整 IP 段从官方接口获取，建议写成脚本每周更新一次配置并 reload Nginx，避免 Cloudflare 调整网段后失效。配置生效后，日志里看到的才是访客真实 IP，fail2ban 和限流才有意义。

再进一步，可以开启 Cloudflare 的 Authenticated Origin Pulls（源站证书校验），让源站只接受携带 Cloudflare 客户端证书的回源请求。这样即使别人扫到了你的源站 IP，也没法直接访问，CDN 才算是真正把源站藏住了。

八、常见报错对照排查

521：源站拒绝连接。先看 Nginx 是否在跑、端口是否监听、防火墙是否放行了 Cloudflare IP；
522：连接超时。多半是源站防火墙把 Cloudflare 节点拦了，或者安全组没放行；
524：回源超过 100 秒。检查慢查询、外部 API 阻塞，必要时上页面缓存；
525 / 526：SSL 握手失败或证书无效。检查源站证书是否过期、证书链是否完整、SSL 模式是否设成了 Full (Strict)；
重定向循环：典型是 Flexible 模式叠加源站强制 HTTPS，改成 Full (Strict) 即可；
缓存不生效：看源站响应头里的 Cache-Control 和 Set-Cookie，再确认 Cache Rules 的路径匹配是否写对。

九、上线顺序清单

备份现有 DNS 记录，调低 TTL；
添加站点，核对记录后用灰云先接入，确认解析正常；
源站装好证书，验证 HTTPS 直连可用；
切换 NS，等生效；
开启橙云，SSL 切 Full (Strict)；
配置 Cache Rules 与 Bypass 规则；
按需开启安全等级、Bot Fight Mode、WAF 与速率限制；
配置 realip 与源站 IP 白名单，开启 Authenticated Origin Pulls；
观察一周日志，按误杀情况微调规则。

整套流程走完，花的时间并不长，但收益很直接：源站 IP 藏住了，静态资源不再消耗源站带宽，证书和 HTTPS 不用自己操心，常见的扫描和 CC 也能挡住大半。Cloudflare 免费版不是万能药，但对于大多数个人站长来说，它是投入产出比最高的一层基础设施，值得认真配一次。