越来越多人把网站接入 Cloudflare：原因、避坑与常用配置示例

发布人：慈云数据-客服中心发布时间：5小时前阅读量：3

Cloudflare 为什么越来越多人使用｜附配置文件

在过去几年里，Cloudflare 的存在感越来越强。无论是个人站长、独立开发者，还是中小企业、跨境电商、SaaS 服务团队，甚至一些大型互联网业务，都开始把 Cloudflare 作为网站基础设施的一部分。很多人最初接触 Cloudflare，可能只是为了“套一层 CDN”“隐藏源站 IP”“防止被攻击”，但真正用了一段时间后会发现，它已经不只是一个 CDN 服务，而是集 DNS、CDN、安全防护、边缘计算、访问控制、零信任网络、对象存储、图片优化等能力于一体的综合平台。

本文将系统梳理：为什么 Cloudflare 越来越多人使用，它到底解决了什么问题，适合哪些场景，以及在实际部署中常用的配置方式。文章后半部分会附上一些常见配置文件示例，包括 Nginx 源站配置、Cloudflare Origin 证书配置、真实 IP 获取配置、缓存规则建议等，方便直接参考。

一、Cloudflare 是什么？

Cloudflare 最早被大众熟知，是因为它提供 CDN 和 DNS 服务。用户只需要把域名 DNS 托管到 Cloudflare，然后开启代理模式，就可以让访问流量先经过 Cloudflare 的全球节点，再转发到自己的源站服务器。

简单来说，Cloudflare 站在用户和源站之间，扮演一个“前置网关”的角色：

用户浏览器 → Cloudflare 边缘节点 → 源站服务器

在这个过程中，Cloudflare 可以完成很多事情：

DNS 解析
CDN 缓存加速
HTTPS 证书管理
DDoS 防护
Web 应用防火墙
Bot 管理
页面规则与缓存规则
图片压缩与优化
访问控制
零信任认证
边缘函数计算
源站隐藏与保护

也就是说，它不只是让网站“访问快一点”，更重要的是让网站“更稳定、更安全、更容易维护”。

二、为什么 Cloudflare 越来越多人使用？

1. 免费套餐足够强大

Cloudflare 被广泛使用，一个非常重要的原因是：免费套餐已经足够好用。

很多 CDN 或安全服务虽然功能不错，但价格较高，门槛也不低。而 Cloudflare 的免费套餐就包含了很多实用能力，例如：

免费 DNS 托管
免费 CDN
免费 HTTPS
基础 DDoS 防护
基础防火墙规则
页面规则或缓存规则
全球 Anycast 网络
IPv6 支持
HTTP/2、HTTP/3 支持
Brotli 压缩

对于个人博客、文档站、开源项目官网、小型企业网站来说，这些功能已经能够覆盖大部分需求。

尤其是免费 HTTPS，极大降低了网站部署 SSL 证书的复杂度。过去很多站长需要自己申请证书、配置 Nginx、设置自动续期，而使用 Cloudflare 后，只要开启对应模式，就可以快速完成 HTTPS 部署。

2. DNS 解析速度快，稳定性高

Cloudflare 的 DNS 服务非常出名，其公共 DNS 1.1.1.1 也被很多用户使用。对于网站域名托管来说，Cloudflare DNS 的优势主要体现在：

全球节点多
解析速度快
稳定性较好
配置界面清晰
支持 API 自动化操作
免费支持 DNSSEC
支持灵活的代理模式切换

在实际运维中，DNS 的稳定性非常关键。一旦 DNS 解析出问题，网站即使源站正常也无法访问。Cloudflare 在 DNS 层面的可靠性，是很多人选择它的基础原因。

此外，Cloudflare DNS 管理界面比较直观。添加 A 记录、CNAME 记录、TXT 记录、MX 记录都很方便。对于需要配置邮件服务、第三方验证、GitHub Pages、Vercel、Netlify 等服务的用户来说，Cloudflare 的体验比较友好。

3. CDN 加速简单直接

使用 Cloudflare 的 CDN 不需要复杂接入流程。一般来说，只要将 DNS 记录的小云朵从灰色切换成橙色，就表示开启了 Cloudflare 代理和 CDN 功能。

开启后，静态资源如：

图片
CSS
JavaScript
字体文件
静态 HTML
下载文件

可以被 Cloudflare 缓存在边缘节点上。当用户再次访问时，资源可能直接由离用户更近的节点返回，而不必每次都回源请求服务器。

这对于个人服务器、海外 VPS、轻量云主机来说非常有价值。源站服务器带宽有限，如果所有访问都直接打到源站，不仅速度慢，还容易占满带宽。通过 Cloudflare 缓存静态资源，可以明显降低源站压力。

4. 隐藏源站 IP，提高安全性

很多人使用 Cloudflare 的另一个核心原因，是为了隐藏源站真实 IP。

如果网站直接暴露源站 IP，攻击者可以绕过域名，直接攻击服务器。例如：

http://源站IP

或者对源站 IP 发起端口扫描、CC 攻击、DDoS 攻击等。开启 Cloudflare 代理后，用户看到的是 Cloudflare 的节点 IP，而不是源站真实 IP。

当然，仅仅开启 Cloudflare 并不能百分百隐藏源站。因为源站 IP 可能通过历史 DNS 记录、邮件头、错误配置、其他子域名泄露。因此更稳妥的做法是：

源站防火墙只允许 Cloudflare IP 访问 80/443
不要让未代理子域名指向同一源站
邮件服务与 Web 服务分离
使用 Cloudflare Origin Certificate
关闭不必要端口
定期检查 DNS 泄露记录

只要配置合理，Cloudflare 可以显著提升源站安全性。

5. DDoS 与恶意流量防护

Cloudflare 以抗 DDoS 能力闻名。对于很多普通网站来说，即使不是大型攻击，频繁的恶意请求、扫描器、爬虫、爆破登录、接口刷请求，也会导致服务器资源被大量消耗。

Cloudflare 可以在边缘节点层面拦截一部分异常流量，例如：

大规模 DDoS 流量
常见漏洞扫描
异常 User-Agent
特定国家或地区访问
高频请求
恶意 Bot
SQL 注入尝试
XSS 攻击尝试

通过 WAF 规则、安全级别、速率限制、Bot Fight Mode、JS Challenge 等能力，可以让很多恶意请求还没到达源站就被拦下。

对于 WordPress、Typecho、Discuz、论坛、登录后台等容易被扫描和爆破的系统，Cloudflare 的防护价值尤其明显。

6. HTTPS 配置更简单

网站启用 HTTPS 已经是基本要求。不仅浏览器会对 HTTP 网站标记“不安全”，搜索引擎也更倾向于收录和推荐 HTTPS 网站。

Cloudflare 提供多种 SSL/TLS 模式：

Off
Flexible
Full
Full Strict

其中比较推荐的是：

Full (strict)

这个模式要求：

用户 → Cloudflare：HTTPS
Cloudflare → 源站：HTTPS，并验证源站证书

也就是说，访问链路两端都是加密的，更安全。

Cloudflare 还提供 Origin Certificate，可以生成源站专用证书。该证书只被 Cloudflare 信任，适合源站与 Cloudflare 之间通信使用。它的有效期可以设置较长，部署起来也比较方便。

7. 全球网络和 Anycast 优势

Cloudflare 拥有覆盖全球的网络节点，并使用 Anycast 技术，让用户自动连接到较近或较优的节点。

对于跨区域访问的网站来说，这一点很重要。例如：

国内用户访问海外服务器
海外用户访问亚洲服务器
全球用户访问同一个 SaaS 服务
跨境电商网站
面向海外的博客或文档站

虽然 Cloudflare 免费版在不同地区的表现会因网络环境而变化，但整体上，它能为很多网站提供比裸连源站更好的访问体验，尤其对静态资源和可缓存页面效果明显。

8. 规则系统灵活，可玩性强

Cloudflare 的规则系统越来越强大。过去常用的是 Page Rules，现在逐渐被 Cache Rules、Redirect Rules、Origin Rules、Transform Rules 等更细分的规则替代。

你可以用规则实现：

指定路径强制缓存
后台路径禁止缓存
API 路径绕过缓存
某些路径跳转到新地址
给特定国家访客设置挑战
修改请求头
设置源站端口
针对静态资源设置长缓存
对 WordPress 登录页面增强防护

例如，一个博客站可以设置：

/wp-admin/*       不缓存，开启高安全等级
/wp-login.php     不缓存，开启挑战
/*.css            缓存 30 天
/*.js             缓存 30 天
/*.png            缓存 30 天
/api/*            不缓存

这种灵活性让 Cloudflare 不只是 CDN，而更像一个可视化边缘网关。

三、Cloudflare 适合哪些人使用？

Cloudflare 适合很多类型的网站和项目。

1. 个人博客

个人博客通常使用 WordPress、Hexo、Hugo、Typecho、Halo 等系统。Cloudflare 可以帮助博客实现：

免费 HTTPS
静态资源加速
防止恶意扫描
减少源站带宽压力
隐藏源站 IP
缓存文章页面

对于静态博客，Cloudflare 的效果会更明显，因为页面基本都可以缓存。

2. 中小企业官网

企业官网通常访问量不一定非常大，但对稳定性和形象要求较高。Cloudflare 可以帮助企业官网提升访问速度，并提供基础安全防护。

尤其是一些面向海外客户的企业官网，如果服务器部署在香港、新加坡、日本、美国等地区，通过 Cloudflare 可以改善全球访问体验。

3. SaaS 和 API 服务

对于 SaaS 服务来说，Cloudflare 可以承担边缘防护和访问控制功能。不过需要注意，API 服务不能盲目缓存，应根据接口类型设置规则。

适合使用 Cloudflare 的能力包括：

WAF
Rate Limiting
Bot 管理
Access 访问控制
Workers 边缘逻辑
日志分析
SSL/TLS 管理

4. 开源项目与文档站

很多开源项目官网、文档站、下载页都使用 Cloudflare。原因很简单：成本低、配置快、静态资源缓存效果好。

如果文档站部署在 GitHub Pages、Vercel、Netlify、Cloudflare Pages 上，配合 Cloudflare DNS 会非常方便。

四、使用 Cloudflare 时需要注意什么？

Cloudflare 很强，但并不是“开了就万事大吉”。实际使用中有几个注意点。

1. 不要长期使用 Flexible SSL

Flexible SSL 的模式是：

用户 → Cloudflare：HTTPS
Cloudflare → 源站：HTTP

这种方式虽然容易配置，但 Cloudflare 到源站之间不是加密连接。如果源站和 Cloudflare 之间链路存在安全风险，就可能被监听或篡改。

更推荐使用：

Full (strict)

并在源站部署有效证书。

2. 不要错误缓存动态页面

如果网站有登录态、购物车、用户中心、后台管理页面，就不能随便开启“缓存所有内容”。否则可能出现：

用户 A 看到用户 B 的页面
登录状态异常
后台页面被缓存
表单提交异常
API 数据延迟

因此，缓存规则一定要区分静态资源、公开页面、动态接口和后台路径。

3. 源站仍然需要安全加固

Cloudflare 可以拦截很多攻击，但源站自身仍要做好安全配置，例如：

系统及时更新
关闭不必要端口
SSH 禁止密码登录
使用防火墙
数据库不暴露公网
定期备份
Web 程序保持更新
设置强密码和双因素认证

Cloudflare 是防线之一，不是唯一防线。

4. 国内访问体验不一定稳定

如果主要用户在中国大陆，需要注意 Cloudflare 免费版在国内的访问表现可能不稳定。由于网络环境复杂，部分地区访问 Cloudflare 节点可能会出现延迟较高、丢包或连接不稳定的情况。

如果是面向国内用户的商业项目，可能需要考虑国内备案 CDN、对象存储加速、或其他合规方案。如果是面向海外用户，Cloudflare 通常更适合。

五、推荐的 Cloudflare 基础设置

下面给出一套比较通用的 Cloudflare 设置建议。

1. DNS 设置

常见记录如下：

example.com      A       1.2.3.4       Proxied
www              CNAME   example.com   Proxied
api              A       1.2.3.4       Proxied
mail             A       5.6.7.8       DNS only

说明：

网站相关记录建议开启代理，也就是橙色云朵。
邮件相关记录通常不要开启代理，应保持 DNS only。
如果 mail.example.com 指向邮件服务器，不建议经过 Cloudflare 代理。

2. SSL/TLS 设置

推荐设置：

SSL/TLS encryption mode: Full (strict)
Always Use HTTPS: On
Automatic HTTPS Rewrites: On
Minimum TLS Version: TLS 1.2
TLS 1.3: On

如果源站还没有证书，可以在 Cloudflare 后台生成 Origin Certificate，然后部署到服务器。

3. 缓存设置

推荐策略：

Caching Level: Standard
Browser Cache TTL: 1 month
Always Online: 可按需开启
Development Mode: 调试时开启，平时关闭

对于静态资源，可以设置更长缓存；对于后台和 API，需要绕过缓存。

4. 安全设置

建议：

Security Level: Medium
Bot Fight Mode: On
Browser Integrity Check: On
WAF Managed Rules: On

如果遭遇攻击，可以临时开启：

Under Attack Mode

不过该模式会给访问者增加挑战验证，不适合长期打开。

六、附：Nginx 源站配置文件示例

以下示例适合 Cloudflare + Nginx + HTTPS 源站。假设域名为 example.com，网站目录为 /var/www/example.com。

1. Nginx HTTPS 配置

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html index.htm index.php;

    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff|woff2|ttf|eot)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        try_files $uri =404;
    }

    location ~ /\. {
        deny all;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

2. WordPress 站点 Nginx 配置示例

如果你使用 WordPress，可以参考下面配置：

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.php index.html index.htm;

    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;

    client_max_body_size 64m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param HTTPS on;
    }

    location ~* \.(css|js|jpg|jpeg|png|gif|webp|svg|ico|woff|woff2|ttf|eot)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        try_files $uri =404;
    }

    location = /wp-login.php {
        limit_req zone=login burst=5 nodelay;

        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param HTTPS on;
    }

    location ~ /\. {
        deny all;
    }

    access_log /var/log/nginx/wordpress.access.log;
    error_log  /var/log/nginx/wordpress.error.log;
}

如果使用了 limit_req，还需要在 Nginx 主配置中的 http 段加入：

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

七、附：获取 Cloudflare 真实访客 IP 配置

开启 Cloudflare 后，源站看到的访问 IP 默认可能是 Cloudflare 节点 IP，而不是用户真实 IP。因此需要在 Nginx 中配置真实 IP。

1. Nginx real_ip 配置

创建文件：

sudo nano /etc/nginx/conf.d/cloudflare-real-ip.conf

写入以下内容：

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

然后测试并重载 Nginx：

sudo nginx -t
sudo systemctl reload nginx

注意：Cloudflare IP 段可能会更新，建议定期查看官方列表。

八、附：只允许 Cloudflare 访问源站

为了避免攻击者绕过 Cloudflare 直接访问源站，可以在服务器防火墙中只允许 Cloudflare IP 访问 80 和 443。

1. UFW 示例

先允许 SSH，避免把自己锁在服务器外：

sudo ufw allow 22/tcp

允许 Cloudflare IPv4：

sudo ufw allow from 173.245.48.0/20 to any port 80,443 proto tcp
sudo ufw allow from 103.21.244.0/22 to any port 80,443 proto tcp
sudo ufw allow from 103.22.200.0/22 to any port 80,443 proto tcp
sudo ufw allow from 103.31.4.0/22 to any port 80,443 proto tcp
sudo ufw allow from 141.101.64.0/18 to any port 80,443 proto tcp
sudo ufw allow from 108.162.192.0/18 to any port 80,443 proto tcp
sudo ufw allow from 190.93.240.0/20 to any port 80,443 proto tcp
sudo ufw allow from 188.114.96.0/20 to any port 80,443 proto tcp
sudo ufw allow from 197.234.240.0/22 to any port 80,443 proto tcp
sudo ufw allow from 198.41.128.0/17 to any port 80,443 proto tcp
sudo ufw allow from 162.158.0.0/15 to any port 80,443 proto tcp
sudo ufw allow from 104.16.0.0/13 to any port 80,443 proto tcp
sudo ufw allow from 104.24.0.0/14 to any port 80,443 proto tcp
sudo ufw allow from 172.64.0.0/13 to any port 80,443 proto tcp
sudo ufw allow from 131.0.72.0/22 to any port 80,443 proto tcp

设置默认拒绝入站：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status

如果你使用 IPv6，也需要同步放行 Cloudflare IPv6 段。

九、附：Cloudflare 缓存规则建议

下面是一套常见的缓存策略思路。

1. 静态资源缓存

匹配路径：

*.example.com/*.css
*.example.com/*.js
*.example.com/*.jpg
*.example.com/*.jpeg
*.example.com/*.png
*.example.com/*.gif
*.example.com/*.webp
*.example.com/*.svg
*.example.com/*.woff2

建议动作：

Cache eligibility: Eligible for cache
Edge TTL: 30 days
Browser TTL: 30 days

2. API 不缓存

匹配路径：

example.com/api/*

建议动作：

Cache eligibility: Bypass cache

3. WordPress 后台不缓存

匹配路径：

example.com/wp-admin/*
example.com/wp-login.php

建议动作：

Cache eligibility: Bypass cache
Security level: High

4. HTML 页面缓存

如果是静态博客，可以缓存 HTML：

example.com/*

建议动作：

Cache eligibility: Eligible for cache
Edge TTL: 1 hour 或 1 day
Browser TTL: Respect origin

如果是 WordPress 等动态站点，不建议全站缓存 HTML，除非你清楚如何绕过登录用户、评论用户和后台页面。

十、附：Cloudflare Workers 简单重定向示例

Cloudflare Workers 可以在边缘节点执行 JavaScript，用来做重定向、鉴权、改写请求、灰度发布等。

下面是一个简单的 HTTP 跳转示例：

export default {
  async fetch(request) {
    const url = new URL(request.url)

    if (url.pathname === "/old-page") {
      return Response.redirect("https://example.com/new-page", 301)
    }

    return fetch(request)
  }
}

也可以实现强制跳转到 www：

export default {
  async fetch(request) {
    const url = new URL(request.url)

    if (url.hostname === "example.com") {
      url.hostname = "www.example.com"
      return Response.redirect(url.toString(), 301)
    }

    return fetch(request)
  }
}

不过对于普通重定向，优先使用 Cloudflare Redirect Rules 即可，不一定非要使用 Workers。