从零搭建“私有版 Cloudflare”:边缘网关、WAF 与 CDN 生产落地实战
Cloudflare 私有化部署方案|生产环境实测
关键词:Cloudflare 私有化、CDN 私有部署、WAF、DDoS 防护、反向代理、边缘网关、生产环境实践、OpenResty、Nginx、Kubernetes、BGP、Anycast
一、为什么要做“Cloudflare 私有化部署”?
严格来说,Cloudflare 本身是一套全球化的云服务平台,并不提供传统意义上的“私有化部署包”。我们在生产环境中所说的“Cloudflare 私有化部署方案”,通常不是把 Cloudflare 原封不动搬到内网,而是在私有云、IDC、混合云或专有网络环境中,构建一套具备 Cloudflare 核心能力的边缘安全与流量治理平台。
Cloudflare 的核心价值主要体现在以下几个方面:
- DNS 解析与流量调度
- CDN 缓存加速
- DDoS 防护
- WAF Web 应用防火墙
- 反向代理与 TLS 终止
- Bot 管理与访问控制
- 零信任访问
- 日志分析与安全审计
- 全局负载均衡与健康检查
在公有云场景下,使用 Cloudflare 非常方便,域名接入后即可获得全球节点、WAF、缓存、证书、规则引擎等能力。但在以下场景中,企业往往希望建设私有化方案:
- 金融、政务、能源、运营商等行业对数据出境有严格要求;
- 核心业务必须运行在自有 IDC 或专有云环境;
- 业务访问群体集中在特定区域,全球 CDN 并非刚需;
- 需要对安全策略、日志、密钥、证书进行完全自主可控;
- 已经具备网络、安全、运维团队,希望降低长期 SaaS 成本;
- 内部系统、专线系统、工业互联网系统无法直接接入公网 SaaS。
因此,本文讨论的“Cloudflare 私有化部署”,本质上是一套面向生产环境的私有边缘网关平台建设方案,目标是尽可能复刻 Cloudflare 在边缘安全、缓存加速、流量治理方面的能力,并结合实际生产经验给出可落地的架构设计。
二、整体架构设计
在生产环境中,我们采用了分层架构,将平台拆分为以下几个层次:
用户 / 客户端
↓
DNS / GSLB / 智能解析
↓
边缘接入层 Edge Gateway
↓
安全防护层 WAF / Anti-DDoS / Bot Control
↓
缓存与加速层 CDN Cache
↓
负载均衡层 L7 / L4 Load Balancer
↓
业务服务层 Kubernetes / VM / Bare Metal
↓
日志分析 / 监控告警 / 审计平台
整个方案的核心是“边缘接入层”。它承担了类似 Cloudflare Proxy 的角色,所有外部流量先进入边缘节点,由边缘节点完成 TLS 终止、访问控制、缓存命中、WAF 检查、速率限制、路由转发等动作。
在实际部署中,我们将节点分为三类:
| 节点类型 | 主要职责 | 部署位置 |
|---|---|---|
| DNS / GSLB 节点 | 域名解析、智能调度、健康检查 | 公网 DNS 或私有 DNS |
| Edge Gateway 节点 | TLS 终止、WAF、缓存、限流、反代 | IDC 边界区、DMZ、云上 VPC |
| Origin 节点 | 真实业务服务 | Kubernetes、虚拟机、物理机 |
生产环境建议至少部署 2 个以上可用区,每个可用区至少 2 台边缘节点,以避免单点故障。对于关键业务,应结合 BGP、Anycast、专线或多运营商出口实现更高等级的容灾。
三、核心组件选型
1. 边缘代理:OpenResty / Nginx / Envoy
边缘代理是整个私有化方案的核心组件。我们在生产环境中主要使用 OpenResty 和 Nginx,部分微服务场景使用 Envoy。
OpenResty 的优势:
- 基于 Nginx,性能稳定;
- 支持 Lua 扩展,规则灵活;
- 可实现动态路由、动态限流、鉴权、灰度发布;
- 社区成熟,运维成本较低。
Envoy 的优势:
- 原生支持 xDS 动态配置;
- 对微服务、gRPC、服务网格友好;
- 可观测性能力强;
- 适合复杂东西向和南北向流量治理。
如果团队熟悉 Nginx,并且业务主要是 HTTP/HTTPS,OpenResty 是性价比很高的选择。如果业务大量使用 gRPC、HTTP/2、服务网格,则 Envoy 更适合作为核心网关。
2. WAF:ModSecurity / Coraza / 自研规则引擎
Cloudflare 的 WAF 能力非常强,私有化方案要完全复刻并不现实,但可以实现企业级基础防护。
常见选择包括:
- ModSecurity + OWASP CRS
- Coraza WAF
- Nginx Lua 自研规则
- 商业 WAF 设备或云 WAF 私有版
我们在生产环境中采用的是“基础规则 + 自定义规则 + 风险评分”的方式,而不是简单地一刀切拦截。
例如:
- SQL 注入检测;
- XSS 检测;
- 命令注入检测;
- 非法 User-Agent 拦截;
- 高频路径扫描识别;
- 后台路径保护;
- API 参数白名单校验;
- 地域/IP/ASN 访问控制。
需要注意的是,WAF 最容易出现的问题是误杀。因此上线策略建议分为三个阶段:
- 观察模式:只记录不拦截;
- 灰度拦截:对低风险业务先启用;
- 全量拦截:结合误报反馈持续优化。
3. 缓存加速:Nginx Cache / Varnish / ATS
CDN 的核心能力之一是缓存。私有化部署中,缓存层主要用于静态资源、半静态接口、图片、下载文件等场景。
可选组件:
| 组件 | 特点 |
|---|---|
| Nginx Cache | 简单稳定,适合中小规模 |
| Varnish | 缓存能力强,规则灵活 |
| Apache Traffic Server | 高性能,适合大规模 CDN 场景 |
| Squid | 历史悠久,但现代 Web 场景使用较少 |
我们在生产环境中选择 Nginx Cache,原因是架构简单、维护成本低,并且能够满足大多数业务需求。
常见缓存策略包括:
proxy_cache_path /data/cache levels=1:2 keys_zone=edge_cache:10g max_size=500g inactive=7d use_temp_path=off;
location /static/ {
proxy_cache edge_cache;
proxy_cache_valid 200 301 302 30d;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating;
proxy_cache_lock on;
proxy_pass http://origin;
}
实际生产中,缓存策略不应只依赖路径,还要结合 Header、Cookie、Query String 和业务类型。例如:
- 登录态页面不得缓存;
- 带用户隐私数据的接口不得缓存;
- 图片、CSS、JS 可长缓存;
- API 接口可做短时间微缓存;
- 下载类文件可以开启 Range 支持;
- 缓存刷新需要接入发布系统或管理平台。
4. DDoS 防护:网络层 + 应用层组合
Cloudflare 的一个核心能力是抗 DDoS。私有化部署中,DDoS 防护是最难完全复刻的部分,因为它不仅依赖软件能力,更依赖带宽、清洗中心、运营商协同和全球节点容量。
生产环境建议采用组合方案:
- 运营商高防 / 云高防 / 清洗中心
- 边界防火墙 ACL
- L4 连接数限制
- L7 请求频率限制
- 验证码 / JS Challenge
- 黑白名单机制
- 异常行为自动封禁
在 OpenResty 中可以通过 Lua 实现限流,例如基于 IP、URI、Host、Token 等维度进行限制:
-- 示例:基于 IP 的简单限流逻辑
local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("limit_req_store", 10, 20)
local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if not delay then
ngx.status = 429
ngx.say("Too Many Requests")
return ngx.exit(429)
end
不过需要强调,边缘节点自身不是无限抗打的。如果攻击流量已经打满入口带宽,应用层限流再精细也没有意义。因此,对于公网关键业务,必须配置上游高防或运营商清洗能力。
四、生产部署拓扑
我们在生产环境中采用了如下部署模型:
┌────────────────────┐
│ 用户访问 │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ DNS / GSLB 调度 │
└─────────┬──────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ Edge Node A │ │ Edge Node B │ │ Edge Node C │
│ Nginx/WAF/CDN │ │ Nginx/WAF/CDN │ │ Nginx/WAF/CDN │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
└─────────────┬───────┴─────────────┬───────┘
│ │
┌───────▼───────┐ ┌───────▼───────┐
│ Origin Group 1 │ │ Origin Group 2 │
│ Kubernetes │ │ VM / BareMetal │
└───────────────┘ └───────────────┘
每个 Edge Node 包含以下模块:
- Nginx / OpenResty;
- WAF 模块;
- Cache 模块;
- TLS 证书管理;
- 日志采集 Agent;
- 健康检查组件;
- 配置下发 Agent;
- 本地防火墙策略;
- Fail2ban 或自研封禁模块。
配置管理采用 GitOps 思路:所有站点配置、路由规则、缓存策略、WAF 策略都进入 Git 仓库,通过 CI/CD 进行校验和发布。这样可以避免人工直接登录服务器修改配置导致的不一致和不可追溯。
五、DNS 与流量调度设计
Cloudflare 的 DNS 和代理能力高度集成,私有化方案中需要单独设计 DNS 调度。
常用方案包括:
- 公网权威 DNS + 智能解析
- 自建 PowerDNS / Bind
- GSLB 设备
- 云厂商 DNS
- 内部 CoreDNS / Consul DNS
生产环境中,我们将公网域名托管在权威 DNS 服务上,通过智能解析将用户调度到不同边缘节点。调度依据包括:
- 运营商;
- 地域;
- 节点健康状态;
- 业务权重;
- 灰度比例;
- 线路质量;
- 故障切换策略。
对于内部系统,则使用私有 DNS,将域名解析到内网 Edge Gateway,实现内部系统也经过统一安全入口。
DNS TTL 不建议设置过长。一般生产环境可设置为 60 秒到 300 秒。如果业务对故障切换要求很高,可以结合健康检查和短 TTL 实现快速切换。
六、TLS 证书与加密策略
Cloudflare 的证书管理非常方便,而私有化方案中,证书管理必须重点设计。
证书来源可分为:
- 公网业务:Let’s Encrypt、DigiCert、GlobalSign 等;
- 内部业务:企业 CA、自建 CA;
- 专线业务:双方约定 CA 或双向 TLS。
生产环境中建议:
- 使用自动化证书申请和续期;
- 私钥不得明文分散存储;
- 证书变更要有审批和审计;
- 支持 TLS 1.2 和 TLS 1.3;
- 禁用不安全加密套件;
- 对核心 API 启用 mTLS;
- 证书即将过期前自动告警。
Nginx 中可配置较安全的 TLS 策略:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!3DES;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 10m;
对于多租户或多域名场景,可以使用 SNI 动态加载证书,避免每次新增域名都重载完整服务。
七、WAF 策略实测经验
在生产环境中,WAF 的核心不是“规则越多越好”,而是“规则准确、可观测、可回滚”。
我们上线 WAF 后观察到以下几类高频攻击:
/phpmyadmin、/wp-admin、/wp-login.php扫描;- SQL 注入探测,如
union select、sleep()、benchmark(); - XSS 探测,如
、onerror=; - 命令注入,如
;cat /etc/passwd; - 目录穿越,如
../../../../etc/passwd; - Log4Shell 探测;
- 异常 User-Agent 扫描器;
- 高频 404 路径爆破;
- API 暴力枚举。
我们的策略不是所有命中规则都立刻封禁,而是采用评分模型。例如:
| 行为 | 分值 |
|---|---|
| 命中 SQL 注入规则 | 40 |
| 命中 XSS 规则 | 30 |
| 访问敏感路径 | 20 |
| 高频 404 | 15 |
| 异常 User-Agent | 10 |
| 单 IP 高频请求 | 20 |
当单个 IP 在一定时间窗口内风险分超过阈值,则进入封禁或挑战流程。这样可以减少单条规则误报造成的业务影响。
八、日志、监控与可观测性
私有化方案能否稳定运行,关键在于可观测性。Cloudflare 控制台提供了大量分析能力,自建方案则需要自己完成日志与指标体系。
我们采集以下数据:
- 访问日志;
- WAF 命中日志;
- 缓存命中率;
- 请求耗时;
- 上游响应时间;
- HTTP 状态码分布;
- 入口带宽;
- QPS;
- TLS 握手失败数;
- 连接数;
- 节点 CPU、内存、磁盘、网卡;
- DNS 解析健康状态;
- 配置发布记录。
推荐技术栈:
| 类型 | 推荐组件 |
|---|---|
| 指标监控 | Prometheus + Grafana |
| 日志分析 | Elasticsearch / OpenSearch / Loki |
| 告警 | Alertmanager / 夜莺 / 自研平台 |
| 链路追踪 | Jaeger / Tempo |
| 安全审计 | SIEM / Wazuh |
生产中最有价值的几个指标是:
- 边缘节点 5xx 比例;
- Origin 响应时间;
- 缓存命中率;
- WAF 拦截量;
- 单 IP 请求突增;
- 出入口带宽;
- TLS 证书过期时间;
- 配置发布失败率。
如果只监控机器 CPU 和内存,无法真正发现边缘平台的问题。必须从“流量、业务、安全、配置”四个维度建立监控。
九、缓存实测效果
在我们的生产环境中,静态资源类业务接入私有 CDN 后,效果较明显。
上线前:
- 所有请求直达源站;
- 源站带宽压力较大;
- 图片和 JS/CSS 文件重复拉取;
- 高峰期源站响应时间抖动明显。
上线后:
- 静态资源缓存命中率稳定在 85% 以上;
- 图片类资源命中率可达到 90% 以上;
- 源站出口带宽下降约 50%~70%;
- 高频访问页面首屏加载速度明显改善;
- 源站 CPU 压力下降。
但也遇到了一些典型问题:
-
缓存污染
带用户参数的 URL 被误缓存,导致缓存碎片增多。 -
登录态误缓存风险
如果未正确处理 Cookie,可能导致敏感页面被缓存。 -
缓存刷新延迟
发布新版本后,部分用户仍访问旧资源。 -
Query String 过多
不同参数导致相同资源生成多个缓存副本。
解决方式包括:
- 对静态资源使用版本号文件名;
- 对 API 只做短时间微缓存;
- 明确禁止缓存带认证 Cookie 的请求;
- 缓存 Key 进行标准化;
- 接入发布系统自动刷新缓存;
- 对大文件开启分片缓存和 Range 支持。
十、安全访问控制与零信任能力
Cloudflare Access 提供了零信任访问能力。私有化方案中,可以通过以下方式实现类似能力:
- SSO 单点登录;
- OAuth2 / OIDC;
- LDAP / AD 集成;
- mTLS 双向认证;
- IP 白名单;
- 设备指纹;
- 动态验证码;
- 短期访问 Token;
- 审批流;
- 操作审计。
对于内部管理系统,我们不建议直接暴露公网,即使加了账号密码也不够。更合理的方式是:
用户访问
→ Edge Gateway
→ 身份认证
→ 权限判断
→ 安全策略检查
→ 反向代理到内部系统
例如,访问 Jenkins、Kibana、Grafana、数据库管理平台、堡垒机等系统时,都必须经过统一身份认证和访问审计。
生产中我们采用了“网关鉴权 + 后端系统二次鉴权”的方式。即使网关认证被绕过,后端系统仍需要独立登录,从而形成多层保护。
十一、配置发布与变更管理
边缘网关的配置变更风险非常高,因为它位于所有流量入口。一条错误规则可能导致全站不可访问。因此,生产环境必须建立严格的配置发布流程。
推荐流程如下:
- 配置提交到 Git;
- 自动进行语法检查;
- 自动进行规则冲突检查;
- 在测试节点发布;
- 执行健康检查;
- 灰度发布到部分边缘节点;
- 观察指标;
- 全量发布;
- 保留快速回滚能力。
Nginx 配置至少要执行:
nginx -t
OpenResty 配置至少要执行:
openresty -t
同时,需要对 WAF 规则、缓存规则、路由规则做自动化测试。例如:某个域名是否能正确路由,某条路径是否被误拦截,某类静态资源是否正确缓存。
我们在生产中遇到过一次由于正则规则过于宽泛导致 API 被误拦截的问题。后来所有规则上线前都必须经过测试样例验证,并且每条规则必须有明确的负责人和回滚方式。
十二、高可用与容灾设计
私有化部署最大的挑战之一是高可用。使用 Cloudflare 时,全球网络和节点容灾由 Cloudflare 负责;自建后,这些责任全部转移到企业自身。
建议至少做到:
- 单节点故障不影响业务;
- 单机房故障可切换;
- 单运营商线路故障可切换;
- 配置发布失败可回滚;
- 缓存节点故障不影响源站;
- DNS 可快速切换;
- 日志系统故障不影响流量转发;
- WAF 异常时可降级为仅代理模式。
边缘节点建议采用无状态或准无状态设计。缓存可以本地化,不要求强一致。配置通过统一平台下发。日志异步发送,避免日志系统异常拖垮网关。
健康检查需要分层:
- 节点存活检查;
- Nginx/OpenResty 进程检查;
- 端口连通性检查;
- 域名级 HTTP 检查;
- 回源链路检查;
- 业务接口检查。
十三、性能压测结果参考
在生产上线前,我们进行了多轮压测。以下数据仅作为参考,实际结果会受 CPU、网卡、磁盘、TLS 配置、WAF 规则复杂度、缓存命中率等影响。
测试环境:
- 8 核 CPU;
- 32GB 内存;
- NVMe SSD;
- 10Gbps 网卡;
- OpenResty;
- TLS 1.3;
- 开启基础 WAF;
- 开启静态缓存。
测试结果:
| 场景 | 单节点 QPS | 平均延迟 | 说明 |
|---|---|---|---|
| 静态缓存命中 | 5 万+ | 10ms 内 | 主要受网卡影响 |
| 简单反向代理 | 2 万~3 万 | 20ms~50ms | 与源站延迟相关 |
| 开启基础 WAF | 1.5 万~2.5 万 | 30ms~80ms | 规则复杂度影响明显 |
| 动态接口回源 | 取决于源站 | 50ms+ | 网关不是瓶颈 |
实测发现,WAF 规则越复杂,对性能影响越明显,尤其是大量正则匹配。因此应避免在所有请求上执行重型规则,可以按域名、路径、Content-Type 分层启用。
十四、成本分析
私有化部署并不一定比 Cloudflare 便宜。成本主要包括:
- 服务器成本;
- 带宽成本;
- 高防成本;
- 存储成本;
- 日志平台成本;
- 运维人员成本;
- 安全规则维护成本;
- 监控告警成本;
- 容灾演练成本。
如果企业业务规模较小,直接使用 Cloudflare 或其他云 CDN/WAF 通常更划算。如果企业有合规要求、流量规模较大、已有 IDC 资源和专业团队,私有化方案才更有价值。
从我们的生产经验看,私有化方案适合以下类型:
- 中大型企业;
- 强合规行业;
- 多云混合架构;
- 内外网统一入口;
- 对日志和密钥有强管控要求;
- 具备网络与安全运维团队。
十五、落地建议
如果要从零建设,建议分阶段推进,不要一开始就追求完整复刻 Cloudflare。
第一阶段:统一反向代理入口
目标:
- 域名统一接入;
- TLS 统一终止;
- 路由统一管理;
- 基础访问日志;
- 基础监控告警。
第二阶段:缓存和限流
目标:
- 静态资源缓存;
- API 微缓存;
- 单 IP 限流;
- 单 URI 限流;
- 上游熔断和重试。
第三阶段:WAF 和安全策略
目标:
- OWASP CRS;
- 自定义规则;
- 风险评分;
- 黑白名单;
- 安全日志分析。
第四阶段:高可用和自动化
目标:
- 多节点部署;
- DNS 健康切换;
- GitOps 配置发布;
- 自动证书管理;
- 灰度和回滚。
第五阶段:零信任和智能分析
目标:
- SSO;
- mTLS;
- 设备识别;
- Bot 管理;
- 行为分析;
- 自动封禁。
十六、总结
Cloudflare 私有化部署并不是简单安装某个软件,而是建设一套完整的边缘安全与流量治理体系。它涉及网络、DNS、TLS、反向代理、缓存、WAF、DDoS、防火墙、日志、监控、自动化发布、高可用和安全运营等多个方面。
从生产环境实测来看,私有化方案可以显著提升企业对流量入口的控制能力,尤其适合合规要求高、内部系统多、业务架构复杂的组织。通过 OpenResty、Nginx、Varnish、ModSecurity、Prometheus、Grafana、OpenSearch 等开源组件,可以构建出一套具备较强可用性的边缘网关平台。
但也必须认识到,自建方案无法完全替代 Cloudflare 的全球网络能力和超大规模 DDoS 清洗能力。对于公网大流量攻击,仍然需要运营商、高防服务或云清洗中心配合。
最终建议是:不要以“完全复制 Cloudflare”为目标,而应以“满足企业自身业务、合规和安全需求”为目标。 对于大多数企业,最佳实践往往是混合架构:公网大流量业务使用 Cloudflare 或云 CDN,高合规和内部业务使用私有化边缘网关,两者结合,才能在安全性、性能、成本和可控性之间取得平衡。