Cloudflare 为什么成了站长和开发者的标配?从加速、防护到配置实战
Cloudflare 为什么越来越多人使用|附配置文件
在过去几年里,Cloudflare 的使用率明显提升。无论是个人博客、独立开发者项目,还是中小企业官网、SaaS 平台,甚至一些大型互联网业务,都能看到 Cloudflare 的身影。很多人最开始接触 Cloudflare,是因为它提供免费的 DNS 托管、CDN 加速和基础 DDoS 防护;但真正深入使用后会发现,Cloudflare 早已不只是一个“套 CDN”的工具,而是逐渐发展成了一套覆盖网络、安全、边缘计算、对象存储、零信任访问等能力的全球化平台。
本文将从实际使用角度出发,系统介绍 Cloudflare 为什么越来越受欢迎,它适合哪些场景,以及常见的配置方式。文末会附上一些可直接参考的配置文件,包括 cloudflared Tunnel、Nginx 获取真实 IP、Wrangler Workers 等配置示例。
一、Cloudflare 是什么?
Cloudflare 最初以 CDN 和网站安全服务起家。简单理解,它可以作为用户和你的服务器之间的一层“网络代理”。
当用户访问你的网站时,请求不会直接到达你的源站服务器,而是先进入 Cloudflare 的全球边缘节点。Cloudflare 会根据你的配置进行缓存、安全检查、流量清洗、协议优化,然后再决定是否回源访问你的服务器。
也就是说,Cloudflare 扮演了一个“前置网关”的角色。
它主要提供以下能力:
- DNS 托管
- CDN 内容分发
- DDoS 防护
- Web 应用防火墙 WAF
- SSL/TLS 证书管理
- 页面缓存与静态资源缓存
- 访问控制与 Zero Trust
- Cloudflare Tunnel 内网穿透
- Workers 边缘函数
- R2 对象存储
- Turnstile 人机验证
- Load Balancing 负载均衡
- Bot 管理
- API Shield 接口安全
对于个人站长来说,Cloudflare 可以提升访问速度、隐藏源站 IP、降低被攻击风险。对于企业来说,它可以减少安全和网络运维成本,并把很多原本复杂的基础设施能力托管到 Cloudflare 的全球网络中。
二、为什么越来越多人使用 Cloudflare?
1. 免费套餐已经足够强大
Cloudflare 最吸引人的地方之一,是免费套餐的可用性非常高。
很多云服务虽然也提供免费额度,但往往限制较多,或者只是短期试用。而 Cloudflare 的免费套餐长期可用,并且已经包含了许多基础但非常实用的功能:
- 免费 DNS 托管
- 免费 CDN
- 免费 Universal SSL 证书
- 基础 DDoS 防护
- 基础防火墙规则
- 页面规则或缓存规则
- Cloudflare Tunnel
- Workers 免费额度
- R2 免费额度
- Turnstile 免费人机验证
对于个人博客、开源项目官网、小型文档站、演示站点来说,免费套餐通常已经足够使用。即使后续业务增长,也可以平滑升级到 Pro、Business 或 Enterprise 套餐。
这种“低门槛进入,高上限扩展”的特点,是 Cloudflare 被大量采用的重要原因。
2. DNS 服务稳定且解析速度快
DNS 是网站访问的第一步。如果 DNS 服务不稳定,即使服务器本身没有问题,用户也可能无法访问网站。
Cloudflare 的 DNS 服务以速度快、稳定性好著称。它的权威 DNS 部署在全球 Anycast 网络上,用户通常会被路由到距离较近的节点,从而减少 DNS 查询延迟。
Cloudflare DNS 的优势包括:
- 全球 Anycast 网络
- 解析速度快
- 管理界面清晰
- 支持 API 自动化管理
- 支持 DNSSEC
- 支持 CNAME Flattening
- 支持批量导入 DNS 记录
对于经常迁移服务器、部署多环境、使用自动化运维的团队来说,Cloudflare DNS API 也非常方便。比如可以用脚本自动更新解析记录,实现动态 DNS、自动切换源站等功能。
3. CDN 加速简单易用
传统 CDN 接入通常需要配置加速域名、源站、缓存规则、HTTPS 证书,有时还需要复杂的备案或人工审核流程。而 Cloudflare 的接入方式比较简单:只要把域名 NS 服务器切换到 Cloudflare,就可以在 DNS 层面开启代理。
在 Cloudflare DNS 中,橙色云朵表示启用代理,灰色云朵表示仅 DNS 解析。启用代理后,访问流量会经过 Cloudflare 边缘节点。
Cloudflare CDN 对静态资源效果尤其明显,比如:
- 图片
- CSS
- JavaScript
- 字体文件
- 文档资源
- 静态 HTML
- 下载文件
对于静态站点,例如 Hugo、Hexo、VuePress、VitePress、Astro 生成的网站,Cloudflare 可以显著降低源站压力,并提升全球访问体验。
4. HTTPS 配置方便
过去给网站配置 HTTPS,需要购买证书、上传证书、配置 Nginx 或 Apache、设置自动续期。现在使用 Cloudflare 后,很多步骤都可以简化。
Cloudflare 提供 Universal SSL,可以为托管域名自动签发边缘证书。用户访问 Cloudflare 节点时使用 HTTPS,而 Cloudflare 到源站之间也可以配置不同的加密模式。
常见 SSL/TLS 模式包括:
| 模式 | 说明 | 是否推荐 |
|---|---|---|
| Off | 不启用 HTTPS | 不推荐 |
| Flexible | 用户到 Cloudflare 加密,Cloudflare 到源站不加密 | 不推荐 |
| Full | 用户到 Cloudflare 加密,Cloudflare 到源站也加密,但不严格校验证书 | 可用 |
| Full Strict | 全链路加密,并严格校验证书 | 推荐 |
一般建议使用 Full Strict。源站可以安装 Let’s Encrypt 证书,也可以使用 Cloudflare Origin Certificate。
5. 隐藏源站 IP,降低被攻击风险
如果用户直接访问源站 IP,那么攻击者也可以绕过 CDN 直接攻击服务器。使用 Cloudflare 代理后,正常访问流量会先进入 Cloudflare,源站 IP 不直接暴露在 DNS 解析结果中。
这可以降低以下风险:
- 直接 DDoS 源站
- 扫描服务器端口
- 绕过 WAF
- 绕过访问控制
- 针对源站进行暴力破解
当然,仅仅开启 Cloudflare 并不代表源站完全安全。更推荐的做法是:
- 源站防火墙只允许 Cloudflare IP 回源;
- 管理端口不要暴露公网;
- SSH 使用密钥登录并修改默认端口;
- 后台路径增加访问控制;
- 使用 Cloudflare Tunnel 彻底隐藏源站入口。
其中 Cloudflare Tunnel 是一个非常受欢迎的功能,后文会提供配置文件示例。
6. WAF 和安全规则易于配置
Cloudflare 提供 Web 应用防火墙,可以对常见攻击进行拦截,例如:
- SQL 注入
- XSS
- 路径穿越
- 恶意爬虫
- 频繁请求
- 可疑 User-Agent
- 非法国家或地区访问
- 后台暴力破解
对于没有专职安全团队的小公司来说,Cloudflare WAF 可以快速提供一层防护。即使是免费套餐,也能使用一些基础安全规则,例如根据路径、IP、国家、请求头、请求方法等条件进行阻断或挑战。
例如可以设置:
/admin路径只允许指定 IP 访问;- 对登录接口增加速率限制;
- 阻止特定国家或地区的访问;
- 拦截异常 User-Agent;
- 对敏感路径启用 Managed Challenge。
这些规则的配置门槛比自己搭建 WAF 要低很多。
7. Cloudflare Tunnel 让内网服务安全暴露
Cloudflare Tunnel 是近年来使用人数增长很快的功能之一。
传统部署网站时,需要服务器开放公网端口,比如 80、443,然后将域名解析到服务器 IP。但这样做会暴露源站地址,也需要处理防火墙、端口映射、SSL 等问题。
Cloudflare Tunnel 的思路不同:在源站服务器上运行 cloudflared 客户端,由客户端主动连接 Cloudflare。用户访问域名时,请求通过 Cloudflare 网络转发到这条隧道中,源站不需要暴露公网端口。
它适合以下场景:
- 家庭服务器
- NAS 服务
- 内网 Web 应用
- 本地开发环境
- 无公网 IP 的服务器
- 临时演示项目
- 企业内部工具
如果再结合 Cloudflare Zero Trust,还可以为内部服务增加登录认证、邮箱白名单、一次性验证码、身份提供商 SSO 等安全策略。
8. Workers 让边缘计算变得简单
Cloudflare Workers 是运行在 Cloudflare 边缘节点上的 JavaScript/TypeScript 运行环境。它可以在离用户更近的地方执行代码。
常见用途包括:
- API 代理
- 请求重写
- A/B 测试
- 鉴权逻辑
- 静态站点增强
- 边缘缓存控制
- 图片处理入口
- Webhook 转发
- 简单后端服务
相比传统服务器,Workers 的优势是:
- 全球分布式运行
- 冷启动很快
- 不需要维护服务器
- 支持按请求计费
- 可以搭配 KV、D1、R2、Durable Objects 使用
对于独立开发者来说,Workers 可以快速搭建轻量 API;对于企业来说,它可以作为边缘层逻辑处理平台,减少源站压力。
9. R2 对象存储没有出口流量费
Cloudflare R2 是兼容 S3 API 的对象存储服务。它最大的卖点之一是:没有传统意义上的出口流量费。
在许多云服务商中,对象存储本身价格不高,但外网下载流量费用可能很高。如果网站有大量图片、附件、安装包、视频切片等资源,出口流量费用会成为主要成本。
R2 适合存储:
- 图片资源
- 用户上传文件
- 软件安装包
- 静态网站资源
- 备份文件
- 日志归档
- AI 应用资源文件
如果搭配 Cloudflare CDN 使用,可以进一步降低回源请求,并提升全球访问体验。
10. Zero Trust 适合企业远程办公
Cloudflare Zero Trust 提供了一套替代传统 VPN 的方案。企业可以通过它保护内部应用,而不是直接暴露服务或依赖传统 VPN。
它可以实现:
- 用户身份认证
- 邮箱白名单
- SSO 登录
- 设备姿态检查
- 应用访问策略
- 内网资源访问
- DNS 过滤
- 安全网关
- 日志审计
对于远程办公团队,Zero Trust 的价值很明显:员工不需要连接复杂的 VPN,只要通过浏览器访问内部系统,并完成身份验证即可。
三、Cloudflare 适合哪些人使用?
Cloudflare 并不是只适合大型企业。实际上,它对很多用户群体都很友好。
1. 个人站长
如果你有个人博客、作品集网站、文档站,Cloudflare 可以帮你:
- 免费开启 HTTPS;
- 缓存静态资源;
- 降低服务器负载;
- 提升海外访问速度;
- 防止简单攻击;
- 管理 DNS 记录。
2. 独立开发者
如果你经常部署小项目,Cloudflare 可以提供:
- Workers 部署 API;
- Pages 部署前端;
- Tunnel 暴露本地服务;
- R2 存储静态文件;
- Turnstile 替代传统验证码;
- DNS API 自动化运维。
3. 中小企业
对于中小企业来说,Cloudflare 可以减少很多基础设施成本:
- 不必单独购买复杂 WAF;
- 不必维护全球 CDN;
- 不必自己处理 DDoS 清洗;
- 可以快速管理多个域名;
- 可以为后台系统增加访问控制;
- 可以通过 Zero Trust 管理内部应用。
4. 运维和安全团队
Cloudflare 对运维团队的价值在于统一入口和可观测性。很多网络和安全策略可以前置到 Cloudflare 层完成,例如:
- IP 访问控制;
- 防火墙规则;
- TLS 策略;
- 缓存策略;
- 速率限制;
- Bot 管理;
- 日志分析;
- 边缘重定向。
四、使用 Cloudflare 时需要注意什么?
虽然 Cloudflare 很强大,但并不是“无脑开启就完美”。实际使用时仍然有一些注意事项。
1. 不要使用 Flexible SSL
Flexible 模式下,用户到 Cloudflare 是 HTTPS,但 Cloudflare 到源站是 HTTP。这会导致源站链路不加密,也容易出现重定向循环、Cookie 安全属性异常等问题。
推荐使用:
SSL/TLS encryption mode: Full (strict)
2. 源站要限制访问来源
如果开启了 Cloudflare 代理,但源站仍然允许任何 IP 直接访问,那么攻击者只要知道源站 IP,仍然可以绕过 Cloudflare。
建议在服务器防火墙中只允许 Cloudflare IP 访问 80 和 443 端口。
3. 缓存规则要合理
并不是所有内容都适合缓存。比如:
- 登录页面
- 用户中心
- 购物车
- 支付页面
- 后台接口
- 带用户隐私的数据接口
这些内容如果错误缓存,可能导致严重问题。缓存规则应优先针对静态资源。
4. 注意真实 IP 获取
使用 Cloudflare 代理后,源站看到的访问 IP 通常是 Cloudflare 节点 IP,而不是用户真实 IP。需要在 Nginx、Apache 或应用中读取 CF-Connecting-IP 请求头,或者配置 real_ip 模块。
后文会给出 Nginx 配置示例。
5. 国内访问情况需要实测
Cloudflare 的全球网络很强,但对于中国大陆访问场景,需要根据实际线路、运营商、业务地区进行测试。某些情况下,国内用户访问 Cloudflare 代理后的域名可能并不一定比直连更快。
如果主要用户在中国大陆,可能需要结合国内 CDN、备案、分线路解析等方案综合考虑。
五、Cloudflare 常见 DNS 配置示例
以下是一个常见网站的 DNS 配置示例:
类型 名称 内容 代理状态
A @ 203.0.113.10 Proxied
A www 203.0.113.10 Proxied
CNAME static example.com Proxied
CNAME api example.com Proxied
MX @ mail.example.com DNS only
A mail 203.0.113.20 DNS only
TXT @ v=spf1 mx ~all DNS only
需要注意:
- 网站域名可以开启橙色云朵代理;
- 邮件相关记录通常不要开启代理;
MX指向的主机名应保持 DNS only;- 如果需要暴露真实服务器 IP 的服务,也不要开启代理;
- Cloudflare 代理主要支持 HTTP/HTTPS 等 Web 流量,并不是所有端口都支持。
六、Cloudflare Tunnel 配置文件示例
下面是一个典型的 cloudflared 配置示例。假设你有一个本地服务运行在 127.0.0.1:8080,希望通过 app.example.com 访问。
1. 创建隧道
cloudflared tunnel login
cloudflared tunnel create my-app
创建完成后,会生成一个隧道 ID,并在本地生成凭证文件。
2. 配置 config.yml
Linux 常见路径:
/etc/cloudflared/config.yml
配置内容:
tunnel: my-app
credentials-file: /etc/cloudflared/my-app.json
ingress:
- hostname: app.example.com
service: http://127.0.0.1:8080
- hostname: api.example.com
service: http://127.0.0.1:3000
- service: http_status:404
如果使用隧道 ID,也可以这样写:
tunnel: 12345678-abcd-1234-abcd-1234567890ab
credentials-file: /etc/cloudflared/12345678-abcd-1234-abcd-1234567890ab.json
ingress:
- hostname: app.example.com
service: http://localhost:8080
- service: http_status:404
3. 创建 DNS 路由
cloudflared tunnel route dns my-app app.example.com
cloudflared tunnel route dns my-app api.example.com
4. 安装为系统服务
cloudflared service install
systemctl enable cloudflared
systemctl start cloudflared
systemctl status cloudflared
这样,即使你的源站没有公网 IP,也可以通过 Cloudflare 安全访问内部服务。
七、Nginx 获取 Cloudflare 真实 IP 配置
开启 Cloudflare 代理后,Nginx 默认记录的是 Cloudflare 节点 IP。为了获取用户真实 IP,需要配置 real_ip_header。
示例配置如下:
# /etc/nginx/conf.d/cloudflare-real-ip.conf
real_ip_header CF-Connecting-IP;
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:
nginx -t
systemctl reload nginx
建议定期从 Cloudflare 官方更新 IP 段:
https://www.cloudflare.com/ips/
八、Nginx 源站安全配置示例
如果你希望源站只允许 Cloudflare 回源访问,可以在防火墙层面限制,也可以在 Nginx 层面做简单限制。
示例:
server {
listen 80;
server_name example.com www.example.com;
# 只允许 Cloudflare IP 段访问
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/13;
allow 104.24.0.0/14;
allow 172.64.0.0/13;
allow 131.0.72.0/22;
deny all;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
不过更推荐在系统防火墙或云服务器安全组中限制访问来源,这样可以在更早阶段拦截非 Cloudflare 流量。
九、Cloudflare Workers 配置示例
下面是一个简单的 Workers 项目配置,用于返回 JSON 响应。
1. wrangler.toml
name = "demo-worker"
main = "src/index.js"
compatibility_date = "2024-09-01"
routes = [
{ pattern = "worker.example.com/*", zone_name = "example.com" }
]
[vars]
ENVIRONMENT = "production"
2. src/index.js
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname === "/api/hello") {
return Response.json({
message: "Hello from Cloudflare Workers",
environment: env.ENVIRONMENT,
time: new Date().toISOString()
});
}
return new Response("Not Found", {
status: 404
});
}
};
3. 部署命令
npm install -g wrangler
wrangler login
wrangler deploy
这个示例适合用来快速搭建简单 API、边缘代理或请求处理逻辑。
十、Cloudflare 缓存规则建议
对于普通网站,可以考虑以下缓存策略:
1. 静态资源缓存
匹配路径:
*example.com/*.css
*example.com/*.js
*example.com/*.png
*example.com/*.jpg
*example.com/*.jpeg
*example.com/*.webp
*example.com/*.svg
*example.com/*.woff2
建议设置:
Cache eligibility: Eligible for cache
Edge TTL: 1 month
Browser TTL: 1 week
2. HTML 页面缓存
如果是纯静态博客,可以缓存 HTML:
example.com/*
建议设置:
Cache eligibility: Eligible for cache
Edge TTL: 1 hour 或 1 day
Browser TTL: 30 minutes
如果网站有登录态、用户中心或动态内容,不建议全站缓存 HTML。
3. 后台和 API 不缓存
匹配路径:
example.com/admin/*
example.com/api/*
建议设置:
Cache eligibility: Bypass cache
十一、常见防火墙规则示例
1. 保护后台路径
规则表达式:
(http.request.uri.path starts_with "/admin")
动作:
Managed Challenge
或者只允许指定 IP:
(http.request.uri.path starts_with "/admin") and not (ip.src in {203.0.113.100})
动作:
Block
2. 阻止异常 User-Agent
(http.user_agent contains "sqlmap") or
(http.user_agent contains "nikto") or
(http.user_agent contains "masscan")
动作:
Block
3. 限制特定国家访问
(ip.geoip.country in {"RU" "KP"})
动作:
Managed Challenge 或 Block
是否限制国家访问要根据业务情况决定,不建议盲目封锁。
十二、推荐的一套基础配置
如果是一个普通网站,我通常建议这样配置:
- DNS 托管到 Cloudflare;
- 网站主域名和
www开启代理; - SSL/TLS 设置为
Full Strict; - 开启 Always Use HTTPS;
- 开启 HTTP/2、HTTP/3;
- 静态资源设置缓存规则;
- 登录、后台、API 设置绕过缓存;
- Nginx 配置真实 IP;
- 源站防火墙只允许 Cloudflare IP;
- 后台路径增加 WAF 规则;
- 有内网服务时使用 Cloudflare Tunnel;
- 有轻量接口时考虑 Workers;
- 有文件存储需求时考虑 R2。
这套配置对大多数个人网站和中小型项目都比较实用。
十三、Cloudflare 的局限性
虽然 Cloudflare 很好用,但也要客观看待它的局限。
首先,Cloudflare 不是万能加速器。如果源站响应很慢、数据库查询很慢、应用代码性能差,仅靠 CDN 不能从根本上解决问题。
其次,对于动态接口,Cloudflare 只能优化网络层和部分边缘逻辑,不能完全替代后端性能优化。
第三,不同地区访问效果差异较大。尤其面向中国大陆用户时,需要结合实际测试决定是否全站使用 Cloudflare。
第四,配置不当可能引发问题。例如错误缓存用户页面、SSL 模式设置错误、真实 IP 未配置、源站未限制访问等,都可能带来安全或业务风险。
所以,Cloudflare 的正确使用方式不是“全部功能都打开”,而是根据业务场景合理配置。
十四、总结
Cloudflare 越来越多人使用,并不是偶然。它把 DNS、CDN、安全防护、边缘计算、对象存储、零信任访问等能力整合到一个平台中,让个人开发者和中小企业也能以较低成本使用全球化网络基础设施。
它的优势可以概括为:
- 入门成本低;
- 免费套餐实用;
- DNS 稳定快速;
- CDN 接入简单;
- HTTPS 配置方便;
- 安全防护能力强;
- Tunnel 能隐藏源站;
- Workers 适合边缘计算;
- R2 降低存储流量成本;
- Zero Trust 适合现代远程办公。
如果你只是运营一个普通网站,Cloudflare 可以帮你快速提升安全性和可用性;如果你是开发者,它可以成为你部署项目、暴露服务、运行边缘逻辑的重要工具;如果你是企业团队,它也可以作为网络安全和访问控制体系的一部分。
当然,Cloudflare 不是万能解决方案。真正稳定、安全、快速的网站,仍然需要良好的源站架构、合理的缓存策略、正确的安全配置和持续的监控维护。Cloudflare 更像是站在源站前面的一层强大基础设施,用得好,可以显著降低运维成本;用得不当,也可能带来缓存、安全和访问异常问题。
总体来说,Cloudflare 之所以越来越受欢迎,核心原因在于它把原本复杂、昂贵、需要专业团队维护的网络与安全能力,变成了普通用户也能轻松使用的服务。这正是它的价值所在。