Cloudflare 降本实战：缓存、WAF、源站防护与配置模板一次讲清

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

Cloudflare 如何降低成本｜附配置文件

在中小型网站、SaaS 项目、跨境电商、内容站、API 服务以及个人博客的运维过程中，成本往往不是单一来源造成的。很多团队一开始关注的是服务器价格，但真正上线后才发现，带宽费用、DDoS 防护费用、对象存储流量费用、CDN 回源费用、日志分析费用、图片处理费用、API 峰值扩容费用，都会不断推高整体支出。

Cloudflare 的价值不只是“加速网站”，更重要的是它可以通过缓存、安全防护、边缘网络、访问控制、图片优化、DNS 托管等能力，把原本需要自己购买或自建的基础设施成本压下来。合理配置 Cloudflare 后，很多网站可以显著减少源站压力、降低带宽消耗、减少服务器规格需求，甚至避免额外购买昂贵的安全防护服务。

本文将从实际运维角度说明：Cloudflare 如何帮助降低成本，以及如何通过配置文件和规则模板快速落地。

一、成本主要花在哪里？

在分析 Cloudflare 的降本方案之前，先要看清楚网站或应用的成本结构。常见成本主要包括以下几类：

成本类型	说明	是否可通过 Cloudflare 优化
服务器成本	CPU、内存、磁盘、实例规格	可以
带宽成本	云服务器公网流量、峰值带宽	可以
安全防护成本	DDoS、CC、防火墙、Bot 防护	可以
CDN 成本	静态资源分发、跨地区访问优化	可以
回源成本	CDN 到源站的数据传输	可以
图片处理成本	图片压缩、格式转换、缩放	可以
运维成本	监控、规则维护、故障处理	部分可以
DNS 服务成本	高可用 DNS、全球解析	可以

很多项目刚上线时会直接把所有请求打到源站，例如：

用户 -> 源站服务器

这种架构简单，但问题明显：

所有静态资源都由源站输出；
突发访问会直接压垮服务器；
海外访问延迟高；
遇到恶意请求时，源站暴露在公网；
带宽和 CPU 成本持续升高。

接入 Cloudflare 后，请求链路变成：

用户 -> Cloudflare 边缘节点 -> 源站服务器

如果配置得当，大量请求会直接在 Cloudflare 边缘节点命中缓存，不再访问源站。这样源站只处理真正需要动态计算的请求，从而降低服务器压力和带宽费用。

二、Cloudflare 降低成本的核心方式

1. 缓存静态资源，减少源站流量

这是最直接的降本方式。

网站中的 CSS、JS、图片、字体、视频封面、下载文件等资源，通常不需要每次都从源站返回。如果这些文件能够缓存在 Cloudflare 边缘节点，用户访问时就可以直接由 Cloudflare 返回。

例如：

第一次访问：
用户 -> Cloudflare -> 源站

之后访问：
用户 -> Cloudflare 缓存

这样可以减少：

源站公网流量；
源站磁盘读取；
Nginx/Apache 请求压力；
应用服务器负载；
云服务器升级需求。

如果是 WordPress、Hexo、Hugo、Next.js 静态页面、文档站、图片站，缓存收益通常非常明显。

2. 使用 Cache Rules 精准缓存页面

很多人只缓存静态文件，却忽略了 HTML 页面也可以缓存。对于博客、新闻页、商品详情页、文档页等更新频率不高的页面，可以设置边缘缓存。

例如：

/blog/*
/docs/*
/products/*
/news/*

这些页面在短时间内内容不会频繁变化，可以设置 5 分钟、30 分钟、1 小时甚至更久的缓存时间。

需要注意的是，登录后台、购物车、用户中心、支付页面不应缓存，否则可能出现用户数据错乱或隐私风险。

3. 使用 WAF 和速率限制降低攻击成本

如果源站直接暴露，遇到爬虫、CC 攻击、恶意扫描、撞库请求时，服务器 CPU 和带宽很容易被打满。很多云厂商的 DDoS 高防、防火墙和安全产品价格不低。

Cloudflare 的 WAF、Bot 防护、速率限制、国家/地区访问控制，可以在边缘侧拦截大量无效请求。

典型可以拦截的请求包括：

高频扫描 /wp-admin、/phpmyadmin；
恶意访问 .env、config.php、backup.zip；
高频 API 调用；
非浏览器 User-Agent；
特定国家或地区的异常流量；
明显的 SQL 注入、XSS 探测请求。

拦截发生在 Cloudflare 边缘节点，请求不会进入源站，因此可以减少源站压力和安全成本。

4. 隐藏源站 IP，降低被直接攻击的概率

如果攻击者知道源站真实 IP，就可以绕过 Cloudflare 直接攻击服务器。正确做法是：

DNS 记录开启 Cloudflare 代理，即橙色云朵；
源站防火墙只允许 Cloudflare IP 访问 80/443；
SSH、数据库、管理面板不要暴露在公网；
后台管理路径增加访问控制。

这样外部访问只能先经过 Cloudflare，安全规则才有意义。

5. 图片优化减少流量费用

图片往往是网站流量的大头。尤其是电商、博客、图库、营销页，图片流量可能占总流量的 60% 以上。

Cloudflare 可以通过以下方式降低图片成本：

启用 Brotli 压缩；
启用 WebP/AVIF 图片优化；
使用 Polish、Mirage 或 Images；
对图片资源设置长缓存；
使用合适尺寸的缩略图；
避免原图直接暴露给用户。

即使不使用收费图片产品，只要把图片资源缓存好，也能明显降低源站流量。

6. 减少服务器规格需求

很多团队会因为“峰值访问”购买更高规格的服务器，例如平时只需要 2 核 4G，但为了应对活动或爬虫，升级到 4 核 8G 或更高。

Cloudflare 可以把大量静态请求、安全过滤、压缩传输放在边缘侧完成，源站只保留核心动态能力。这样可能不需要频繁升级服务器。

例如原本架构：

4 核 8G + 10Mbps 带宽

优化后可能变成：

2 核 4G + Cloudflare 缓存 + WAF + 源站防火墙

对于长期运行的项目，服务器规格降低带来的节省非常可观。

三、推荐的 Cloudflare 基础配置

下面给出一套适合大多数网站的基础配置思路。

1. DNS 配置建议

常见 DNS 记录如下：

A      example.com        你的源站 IP        Proxied
A      www.example.com    你的源站 IP        Proxied
CNAME  static             example.com       Proxied
CNAME  api                example.com       Proxied 或 DNS Only

建议：

网站主域名开启代理；
静态资源域名开启代理；
API 是否开启代理，需要结合业务判断；
邮件相关记录不要开启代理；
SSH、数据库、远程管理端口不要通过 Cloudflare 普通代理暴露。

2. SSL/TLS 配置建议

Cloudflare 后台建议设置：

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；
Let's Encrypt；
商业证书。

不建议长期使用 Flexible 模式，因为该模式下 Cloudflare 到源站之间不是 HTTPS，容易带来安全和重定向问题。

3. 缓存配置建议

推荐开启：

Brotli: On
Auto Minify CSS: On
Auto Minify JavaScript: On
Auto Minify HTML: 可按需开启
Browser Cache TTL: 1 month

静态资源建议设置较长缓存：

*.css
*.js
*.png
*.jpg
*.jpeg
*.gif
*.webp
*.avif
*.svg
*.woff
*.woff2
*.ttf
*.ico

如果资源文件名带 hash，例如：

app.8f3a1c.js
style.9a21de.css
logo.20240101.webp

可以放心设置更长缓存时间。

四、Cloudflare Cache Rules 配置示例

以下是适用于多数网站的缓存规则设计。

规则一：缓存静态资源

匹配表达式：

(http.request.uri.path matches "(?i)\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff|woff2|ttf|eot|mp4|webm|pdf)$")

配置建议：

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

作用：

减少源站静态资源流量；
提高页面加载速度；
降低服务器并发压力。

规则二：缓存公开页面

适合博客、文档站、内容站。

匹配表达式：

(http.request.uri.path starts_with "/blog/" or
 http.request.uri.path starts_with "/docs/" or
 http.request.uri.path starts_with "/news/")

配置建议：

Cache eligibility: Eligible for cache
Edge TTL: 1 hour
Browser TTL: 10 minutes

如果网站更新不频繁，可以把 Edge TTL 调整为 6 小时或 1 天。

规则三：不缓存后台和用户相关页面

匹配表达式：

(http.request.uri.path starts_with "/admin" or
 http.request.uri.path starts_with "/user" or
 http.request.uri.path starts_with "/account" or
 http.request.uri.path starts_with "/cart" or
 http.request.uri.path starts_with "/checkout" or
 http.request.uri.path starts_with "/api")

配置建议：

Cache eligibility: Bypass cache

作用：

避免登录信息被缓存；
避免购物车、订单、用户中心数据错误；
避免 API 返回被错误复用。

五、Nginx 源站配置文件示例

以下配置适用于源站在 Nginx 后面的常见网站。重点是设置缓存头、压缩、真实 IP 和安全响应头。

文件路径示例：/etc/nginx/conf.d/example.com.conf

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;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

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

    # 获取 Cloudflare 真实访客 IP
    real_ip_header CF-Connecting-IP;

    # Cloudflare 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;

    # 静态资源长缓存
    location ~* \.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff|woff2|ttf|eot)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000, immutable";
        access_log off;
        try_files $uri =404;
    }

    # HTML 页面短缓存
    location ~* \.(html)$ {
        expires 10m;
        add_header Cache-Control "public, max-age=600";
        try_files $uri =404;
    }

    # 禁止访问敏感文件
    location ~ /\.(env|git|svn|hg) {
        deny all;
    }

    location ~* /(composer\.json|composer\.lock|package\.json|yarn\.lock|pnpm-lock\.yaml)$ {
        deny all;
    }

    # 主站路由
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 安全响应头
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

如果你使用 WordPress、Laravel、ThinkPHP、Node.js、Next.js，需要根据实际后端路由调整 location / 规则。

六、源站防火墙配置：只允许 Cloudflare 访问

这是非常关键的一步。如果不限制源站 IP 访问，攻击者仍然可以绕过 Cloudflare 直接请求源站。

以下示例使用 ufw。

1. 默认拒绝入站

ufw default deny incoming
ufw default allow outgoing

2. 允许 SSH

建议只允许自己的固定 IP 登录 SSH：

ufw allow from 你的办公IP to any port 22 proto tcp

如果没有固定 IP，至少要更改默认 SSH 端口，并使用密钥登录。

3. 允许 Cloudflare 访问 80/443

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

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

4. 启用防火墙

ufw enable
ufw status verbose

Cloudflare IP 段可能更新，建议定期从官方页面同步。

七、WAF 规则配置示例

规则一：拦截敏感文件扫描

表达式：

(http.request.uri.path contains ".env" or
 http.request.uri.path contains ".git" or
 http.request.uri.path contains "config.php" or
 http.request.uri.path contains "phpinfo.php" or
 http.request.uri.path contains "backup" or
 http.request.uri.path contains "database.sql")

动作：

Block

规则二：保护后台登录入口

如果后台路径是 /admin，可以设置访问控制。

表达式：

(http.request.uri.path starts_with "/admin" and ip.geoip.country not in {"CN"})

动作：

Managed Challenge

如果后台只允许固定 IP 访问：

(http.request.uri.path starts_with "/admin" and ip.src ne 你的固定IP)

动作：

Block

规则三：拦截异常 User-Agent

表达式：

(http.user_agent contains "sqlmap" or
 http.user_agent contains "nikto" or
 http.user_agent contains "masscan" or
 http.user_agent contains "python-requests" or
 http.user_agent contains "Go-http-client")

动作：

Managed Challenge

注意：有些正常服务也可能使用 python-requests 或 Go-http-client，上线前应先观察日志，避免误伤。

八、API 降本与限流配置

API 服务通常最容易带来成本失控。比如某个接口被恶意刷取，数据库、缓存、应用服务器都会被拖慢。

建议：

对公开 API 设置速率限制；
对登录、注册、发送验证码接口重点保护；
对高成本接口增加鉴权；
对可缓存的 GET API 设置短缓存；
对 POST、支付、订单接口禁止缓存。

示例规则：

路径：/api/login
限制：每个 IP 每分钟 10 次
动作：Managed Challenge 或 Block

路径：/api/search
限制：每个 IP 每分钟 60 次
动作：Throttle

如果 API 返回公开数据，例如站点配置、文章列表、商品分类，可以缓存 30 秒到 5 分钟，这对高并发访问非常有帮助。

九、适合不同网站的降本策略

1. 个人博客 / 文档站

推荐配置：

静态资源缓存 30 天；
HTML 页面缓存 1 小时；
开启 Brotli；
开启 Always Use HTTPS；
后台路径加 WAF；
源站只允许 Cloudflare IP。

降本重点：减少服务器带宽与 CPU。

2. WordPress 网站

推荐配置：

/wp-admin/* 不缓存；
/wp-login.php 加挑战；
图片、CSS、JS 长缓存；
文章页可缓存；
安装缓存插件配合 Cloudflare；
禁止访问 XML-RPC，除非业务需要。

WAF 规则示例：

(http.request.uri.path eq "/xmlrpc.php")

动作：

Block

如果需要 Jetpack 或移动端发布文章，则不要直接封禁。

3. 电商网站

推荐配置：

商品详情页可短缓存；
分类页可短缓存；
购物车、结算、订单不缓存；
登录注册接口限流；
图片资源长缓存；
支付回调路径不要缓存。

电商网站要特别注意缓存边界，否则可能出现用户数据混乱。

4. SaaS 产品

推荐配置：

营销官网静态资源长缓存；
登录后控制台不缓存；
API 做速率限制；
管理后台限制地区或固定 IP；
高成本接口增加挑战或鉴权。

SaaS 降本核心是减少异常请求和爬虫流量对应用服务的影响。

十、上线前检查清单

在正式使用 Cloudflare 降本前，建议检查以下内容：

[ ] DNS 是否开启代理；
[ ] SSL 是否为 Full strict；
[ ] 源站证书是否有效；
[ ] 静态资源是否正确缓存；
[ ] 后台、用户中心、购物车是否绕过缓存；
[ ] API 是否设置限流；
[ ] WAF 是否有误伤；
[ ] 源站是否只允许 Cloudflare IP 访问；
[ ] 日志中是否能获取真实访客 IP；
[ ] 是否配置缓存清理流程；
[ ] 是否保留紧急回滚方案。

十一、如何评估节省效果？

可以从以下几个指标观察：

Cache Hit Ratio
缓存命中率越高，说明越多请求由 Cloudflare 直接返回。
源站带宽变化
对比接入前后的云服务器出站流量。
源站 CPU 和内存变化
静态资源减少回源后，CPU 通常会下降。
请求数量变化
查看 Nginx 日志中真实到达源站的请求是否减少。
安全事件数量
查看 Cloudflare WAF 拦截了多少扫描和攻击。
服务器规格是否可降低
如果源站长期资源占用下降，可以考虑降配。

十二、总结

Cloudflare 降低成本的核心并不是简单“套一层 CDN”，而是通过缓存、安全、访问控制、压缩、源站保护等能力，把大量无效请求和静态请求挡在边缘网络上。

一套合理的 Cloudflare 降本方案至少应包括：

静态资源长缓存；
公开页面短缓存；
用户相关页面绕过缓存；
WAF 拦截恶意扫描；
API 限流；
源站只允许 Cloudflare IP；
SSL 使用 Full strict；
定期分析缓存命中率和源站流量。

对于内容站、博客、文档站、电商站和 SaaS 官网来说，Cloudflare 配置得当后，往往可以减少源站带宽、降低服务器规格、减少安全防护开销，同时提升访问速度和稳定性。

真正有效的降本，不是盲目压缩服务器预算，而是把请求分层处理：能缓存的交给边缘节点，能拦截的在边缘拦截，必须动态处理的才交给源站。这样既能省钱，也能让系统更加稳定。

文章标签： Cloudflare 成本优化缓存 WAF

上一篇：把账单打下来：Cloudflare 降本实战与 Workers 源码示例

下一篇：2026年Cloudflare实战加固指南：从隐藏源站到API与后台防护

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们

Cloudflare 降本实战：缓存、WAF、源站防护与配置模板一次讲清

Cloudflare 如何降低成本｜附配置文件

一、成本主要花在哪里？

二、Cloudflare 降低成本的核心方式

1. 缓存静态资源，减少源站流量

2. 使用 Cache Rules 精准缓存页面

3. 使用 WAF 和速率限制降低攻击成本

4. 隐藏源站 IP，降低被直接攻击的概率

5. 图片优化减少流量费用

6. 减少服务器规格需求

三、推荐的 Cloudflare 基础配置

1. DNS 配置建议

2. SSL/TLS 配置建议

3. 缓存配置建议

四、Cloudflare Cache Rules 配置示例

规则一：缓存静态资源

规则二：缓存公开页面

规则三：不缓存后台和用户相关页面

五、Nginx 源站配置文件示例

六、源站防火墙配置：只允许 Cloudflare 访问

1. 默认拒绝入站

2. 允许 SSH

3. 允许 Cloudflare 访问 80/443

4. 启用防火墙

七、WAF 规则配置示例

规则一：拦截敏感文件扫描

规则二：保护后台登录入口

规则三：拦截异常 User-Agent

八、API 降本与限流配置

九、适合不同网站的降本策略

1. 个人博客 / 文档站

2. WordPress 网站

3. 电商网站

4. SaaS 产品

十、上线前检查清单

十一、如何评估节省效果？

十二、总结