Cloudflare 企业级实战方案｜附源码

在企业级互联网架构中，性能、安全、稳定性、可观测性、成本控制往往是相互制约的几个核心目标。随着业务全球化、攻击复杂化以及用户访问链路多样化，传统只依赖源站机房、单一 CDN 或普通负载均衡的架构，已经很难满足现代企业对高可用和高安全的要求。

Cloudflare 作为全球领先的边缘网络平台，不仅提供 CDN 加速能力，还覆盖了 DNS、WAF、DDoS 防护、Zero Trust、Workers 边缘计算、R2 对象存储、Pages、Load Balancing、Bot Management、Access、Tunnel 等多种企业级能力。合理使用 Cloudflare，可以将企业应用从“单点源站架构”升级为“全球边缘安全架构”。

本文将从企业真实落地角度，给出一套较完整的 Cloudflare 企业级实战方案，并附带可参考源码，帮助团队快速搭建一个具备安全防护、缓存加速、灰度发布、边缘鉴权、API 防护和日志分析能力的现代化架构。

一、企业为什么需要 Cloudflare

很多企业最初接触 Cloudflare，是从 DNS 托管或 CDN 开始的。但在企业级场景中，Cloudflare 的价值远不止“加速静态资源”。

企业业务通常面临以下问题：

1. 全球访问延迟高
   用户分布在不同国家和地区，如果所有请求都回源到单一机房，会导致访问延迟明显增加。

2. DDoS 和恶意流量风险高
   电商、金融、SaaS、游戏、内容平台都可能遭遇 HTTP Flood、CC 攻击、爬虫滥刷、撞库等安全威胁。

3. 源站暴露风险大
   如果源站 IP 被攻击者发现，即使前面配置了 CDN，也可能被绕过直接攻击。

4. API 接口缺少精细化保护
   常规网关可以做限流，但面对全球恶意流量、自动化脚本和复杂 Bot，防护成本较高。

5. 发布流程缺少边缘控制能力
   企业希望支持灰度发布、A/B 测试、区域路由、请求改写、缓存规则动态控制。

6. 统一身份认证和内网访问困难
   远程办公、供应商接入、内部系统暴露公网等场景，需要 Zero Trust 架构支撑。

Cloudflare 的核心优势是：
把大量安全、性能和流量治理能力下沉到离用户最近的边缘节点上执行。

这意味着恶意请求在到达源站之前就可以被清洗，缓存资源可以在全球边缘节点直接返回，业务逻辑也可以通过 Workers 在边缘完成。

二、整体架构设计

本文推荐的企业级 Cloudflare 架构如下：

用户 / 客户端
    |
    v
Cloudflare DNS
    |
    v
Cloudflare Edge Network
    |
    |-- WAF / DDoS Protection
    |-- Bot Management
    |-- Rate Limiting
    |-- Cache Rules
    |-- Workers 边缘逻辑
    |-- Access / Zero Trust
    |-- Load Balancing
    |
    v
企业源站集群
    |
    |-- Web 服务
    |-- API 网关
    |-- 对象存储
    |-- 数据库
    |-- 日志系统

推荐将系统拆分为以下几个层次：

三、DNS 与源站保护方案

1. 域名接入 Cloudflare

企业首先需要将域名 DNS 托管到 Cloudflare。一般流程如下：

1. 在 Cloudflare 创建 Zone；
2. 添加 DNS 记录；
3. 将域名注册商处的 NS 修改为 Cloudflare 提供的 NS；
4. 等待解析生效；
5. 对需要保护的记录开启代理，即橙色云朵。

例如：

需要注意的是，源站真实 IP 不应直接暴露在公共 DNS 中。如果业务必须保留源站直连域名，建议仅用于内网或加白访问。

2. 限制源站只允许 Cloudflare 回源

为了防止攻击者绕过 Cloudflare 直接访问源站，企业应在源站防火墙或 Nginx 层只允许 Cloudflare IP 访问。

Cloudflare 官方会维护 IP 段列表：

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

Nginx 示例配置如下：

# cloudflare_allow.conf

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;

在站点配置中引用：

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

    include /etc/nginx/cloudflare_allow.conf;

    location / {
        proxy_pass http://backend_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $http_cf_connecting_ip;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

其中 CF-Connecting-IP 是 Cloudflare 传递的真实客户端 IP，企业日志系统应优先使用该字段。

四、SSL/TLS 企业配置

Cloudflare SSL/TLS 模式一般有以下几种：

企业级环境建议使用：

SSL/TLS Mode: Full (Strict)
Minimum TLS Version: TLS 1.2 或 TLS 1.3
Always Use HTTPS: 开启
Automatic HTTPS Rewrites: 开启
HSTS: 谨慎开启，确认所有子域都支持 HTTPS 后再开启

源站证书可以使用：

1. 公共 CA 证书，例如 Let's Encrypt；
2. Cloudflare Origin Certificate；
3. 企业自有 CA 证书。

如果使用 Cloudflare Origin Certificate，可以在源站 Nginx 中配置：

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

    ssl_certificate /etc/nginx/ssl/origin.pem;
    ssl_certificate_key /etc/nginx/ssl/origin.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend_api;
    }
}

五、缓存策略设计

缓存策略是 Cloudflare 实战中的重点。错误的缓存策略可能导致用户看到过期页面、接口数据混乱，甚至隐私泄露。

1. 推荐缓存分层

企业可将资源分为三类：

2. 静态资源缓存规则

对于带版本号的静态资源，例如：

/static/app.8f31a9.js
/static/style.91ab20.css

可以设置较长缓存：

Cache Everything: false
Edge Cache TTL: 30 days
Browser Cache TTL: 30 days

源站响应头建议：

Cache-Control: public, max-age=2592000, immutable

3. API 不缓存

对于 API：

/api/*
/auth/*
/payment/*

建议设置：

Cache Level: Bypass

源站响应头：

Cache-Control: no-store, no-cache, must-revalidate

4. HTML 页面短缓存

对于文章详情页、营销页：

Cache-Control: public, max-age=60

如果业务支持主动刷新缓存，可以通过 Cloudflare API 做 Purge。

六、使用 Cloudflare Workers 实现边缘鉴权

Cloudflare Workers 可以在边缘节点运行 JavaScript/TypeScript 逻辑，非常适合做轻量鉴权、请求改写、灰度发布、缓存控制等。

下面给出一个企业常用的 Workers 示例：
对 API 请求进行 Token 校验，校验通过后转发到源站，否则返回 401。

1. Workers 鉴权源码

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // 只保护 /api/private 路径
    if (url.pathname.startsWith("/api/private")) {
      const token = request.headers.get("Authorization");

      if (!token || !token.startsWith("Bearer ")) {
        return jsonResponse(
          {
            code: 401,
            message: "Missing Authorization token"
          },
          401
        );
      }

      const rawToken = token.replace("Bearer ", "").trim();

      const valid = await verifyToken(rawToken, env.API_SECRET);

      if (!valid) {
        return jsonResponse(
          {
            code: 401,
            message: "Invalid token"
          },
          401
        );
      }
    }

    // 添加边缘标识头，便于源站日志分析
    const newHeaders = new Headers(request.headers);
    newHeaders.set("X-Edge-Auth", "passed");
    newHeaders.set("X-Edge-Provider", "cloudflare-workers");

    const newRequest = new Request(request, {
      headers: newHeaders
    });

    return fetch(newRequest);
  }
};

async function verifyToken(token, secret) {
  // 示例：实际企业场景可替换为 JWT 校验、HMAC 校验或远程 introspection
  return token === secret;
}

function jsonResponse(data, status = 200) {
  return new Response(JSON.stringify(data), {
    status,
    headers: {
      "Content-Type": "application/json; charset=utf-8"
    }
  });
}

2. wrangler 配置

name = "enterprise-edge-auth"
main = "src/index.js"
compatibility_date = "2024-06-01"

[vars]
API_SECRET = "change-this-secret"

生产环境不建议将密钥直接写在 wrangler.toml 中，应使用：

wrangler secret put API_SECRET

七、使用 Workers 实现灰度发布

企业发布新版本时，通常希望只让部分用户进入新版本系统。例如按照用户 ID、Cookie、Header 或地区灰度。

下面是一个基于 Cookie 的灰度发布示例。

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    if (!url.pathname.startsWith("/")) {
      return fetch(request);
    }

    const cookie = request.headers.get("Cookie") || "";
    const isBetaUser = cookie.includes("beta_user=true");

    let targetHost;

    if (isBetaUser) {
      targetHost = env.BETA_ORIGIN;
    } else {
      targetHost = env.STABLE_ORIGIN;
    }

    url.hostname = targetHost;

    const newRequest = new Request(url.toString(), request);

    return fetch(newRequest);
  }
};

wrangler.toml 示例：

name = "enterprise-gray-release"
main = "src/index.js"
compatibility_date = "2024-06-01"

[vars]
STABLE_ORIGIN = "stable-origin.example.com"
BETA_ORIGIN = "beta-origin.example.com"

也可以按照百分比灰度：

function shouldGoBeta(request, percent = 10) {
  const ip = request.headers.get("CF-Connecting-IP") || "0.0.0.0";
  let hash = 0;

  for (let i = 0; i < ip.length; i++) {
    hash = (hash << 5) - hash + ip.charCodeAt(i);
    hash |= 0;
  }

  const bucket = Math.abs(hash) % 100;
  return bucket < percent;
}

这种方式可以确保同一个 IP 大概率稳定命中同一个版本，避免用户在新旧系统之间频繁跳转。

八、API 限流与防刷策略

企业 API 面临的主要风险包括：

1. 暴力破解；
2. 短信验证码滥刷；
3. 登录撞库；
4. 抢购接口刷单；
5. 爬虫批量采集；
6. 高频扫描漏洞。

Cloudflare 提供多种方式应对：

1. 登录接口限流规则

例如：

路径：/api/login
条件：同一 IP 1 分钟超过 10 次
动作：Managed Challenge 或 Block

2. 验证码接口限流规则

路径：/api/sms/send
条件：同一 IP 5 分钟超过 3 次
动作：JS Challenge 或 Block

3. Workers 自定义限流源码

如果需要更灵活的限流策略，可以结合 Workers KV 实现简单限流。

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    if (url.pathname.startsWith("/api")) {
      const ip = request.headers.get("CF-Connecting-IP") || "unknown";
      const key = `rate:${ip}:${url.pathname}`;

      const current = await env.RATE_LIMIT_KV.get(key);
      const count = current ? parseInt(current, 10) : 0;

      if (count >= 60) {
        return new Response(
          JSON.stringify({
            code: 429,
            message: "Too many requests"
          }),
          {
            status: 429,
            headers: {
              "Content-Type": "application/json; charset=utf-8"
            }
          }
        );
      }

      await env.RATE_LIMIT_KV.put(key, String(count + 1), {
        expirationTtl: 60
      });
    }

    return fetch(request);
  }
};

wrangler.toml：

name = "enterprise-rate-limit"
main = "src/index.js"
compatibility_date = "2024-06-01"

[[kv_namespaces]]
binding = "RATE_LIMIT_KV"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

需要说明的是，Workers KV 是最终一致性存储，不适合强一致计数。如果是严格限流，建议使用 Cloudflare Rate Limiting、Durable Objects 或企业 API 网关。

九、使用 Cloudflare Tunnel 隐藏源站

Cloudflare Tunnel 可以让企业源站不暴露公网 IP，通过一个出站连接将内部服务安全连接到 Cloudflare。

适用场景：

1. 内部管理后台；
2. Jenkins、Grafana、Kibana；
3. 私有 API；
4. 测试环境；
5. 不希望暴露公网端口的业务服务。

1. 安装 cloudflared

Linux 示例：

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 \
  -o /usr/local/bin/cloudflared

chmod +x /usr/local/bin/cloudflared

cloudflared version

2. 登录 Cloudflare

cloudflared tunnel login

3. 创建 Tunnel

cloudflared tunnel create enterprise-api-tunnel

4. 配置 tunnel

创建配置文件：

tunnel: enterprise-api-tunnel
credentials-file: /root/.cloudflared/enterprise-api-tunnel.json

ingress:
  - hostname: api.example.com
    service: http://localhost:8080
  - hostname: admin.example.com
    service: http://localhost:9000
  - service: http_status:404

运行：

cloudflared tunnel run enterprise-api-tunnel

将其注册为系统服务：

cloudflared service install
systemctl enable cloudflared
systemctl start cloudflared

使用 Tunnel 后，源站可以关闭公网入站端口，只保留服务器主动出站访问 Cloudflare，大幅降低被直接攻击风险。

十、Zero Trust 访问控制

对于企业后台系统，不建议仅依赖账号密码暴露在公网。Cloudflare Access 可以实现基于身份的访问控制。

例如对 admin.example.com 设置访问策略：

允许访问：
- 企业邮箱域名：@example.com
- 指定用户：admin@example.com
- 指定部门：Engineering
- 指定身份提供商：Google Workspace / Azure AD / Okta

访问流程：

1. 用户访问 admin.example.com；
2. Cloudflare Access 拦截请求；
3. 用户跳转到企业身份提供商登录；
4. 登录成功后，Cloudflare 签发访问令牌；
5. 请求才会进入后端服务。

这样即使后台系统本身存在弱口令风险，攻击者也无法直接访问登录页面。

十一、WAF 规则实战

Cloudflare WAF 是企业安全防护的核心模块。企业通常需要结合托管规则和自定义规则。

1. 开启托管规则

建议开启：

Cloudflare Managed Ruleset
OWASP Core Ruleset
Cloudflare Specials

对于业务复杂的网站，应先使用 Simulate 或 Log 模式观察误报，再逐步切换到 Block。

2. 自定义拦截规则

拦截敏感路径

URI Path contains "/.git"
URI Path contains "/.env"
URI Path contains "/wp-admin" 且业务不是 WordPress
URI Path contains "/phpmyadmin"

动作：Block。

拦截异常 User-Agent

User-Agent contains "sqlmap"
User-Agent contains "nikto"
User-Agent contains "masscan"
User-Agent contains "acunetix"

动作：Block。

限制后台访问地区

Hostname equals "admin.example.com"
AND Country not in ["CN", "SG"]

动作：Block 或 Managed Challenge。

保护 API

Hostname equals "api.example.com"
AND URI Path starts with "/api/"
AND Request Method not in ["GET", "POST", "OPTIONS"]

动作：Block。

十二、Turnstile 防机器人方案

Cloudflare Turnstile 是一种无感或低干扰的人机验证方案，可用于替代传统图形验证码。

适合放在：

1. 登录页面；
2. 注册页面；
3. 找回密码；
4. 评论提交；
5. 表单提交；
6. 短信验证码发送前。

1. 前端代码

  
  
  


  

    
    

    

    

    登录
  

2. Node.js 后端校验源码

import express from "express";
import fetch from "node-fetch";

const app = express();

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

const TURNSTILE_SECRET = process.env.TURNSTILE_SECRET;

app.post("/api/login", async (req, res) => {
  const token = req.body["cf-turnstile-response"];

  if (!token) {
    return res.status(400).json({
      code: 400,
      message: "Missing Turnstile token"
    });
  }

  const verifyResult = await verifyTurnstile(token, req.ip);

  if (!verifyResult.success) {
    return res.status(403).json({
      code: 403,
      message: "Turnstile verification failed"
    });
  }

  // TODO: 继续执行账号密码校验
  return res.json({
    code: 0,
    message: "Login success"
  });
});

async function verifyTurnstile(token, ip) {
  const formData = new URLSearchParams();

  formData.append("secret", TURNSTILE_SECRET);
  formData.append("response", token);
  formData.append("remoteip", ip);

  const response = await fetch(
    "https://challenges.cloudflare.com/turnstile/v0/siteverify",
    {
      method: "POST",
      body: formData
    }
  );

  return response.json();
}

app.listen(3000, () => {
  console.log("Server listening on port 3000");
});

十三、日志与可观测性

企业使用 Cloudflare 后，必须建立日志闭环，否则安全事件、缓存命中率、攻击来源和性能瓶颈都难以及时发现。

推荐关注以下指标：

Cloudflare Enterprise 可使用 Logpush 将日志推送到：

1. Amazon S3；
2. Google Cloud Storage；
3. Azure Blob；
4. Splunk；
5. Datadog；
6. Elasticsearch；
7. 企业自建日志平台。

如果是自建分析平台，可以将 Cloudflare 日志写入 ClickHouse，然后使用 Grafana 做可视化。

十四、缓存刷新自动化源码

企业发布新版本时，通常需要自动刷新指定 URL 或全部缓存。下面给出 Cloudflare API 刷新缓存脚本。

1. Node.js Purge Cache 脚本

import fetch from "node-fetch";

const CF_API_TOKEN = process.env.CF_API_TOKEN;
const CF_ZONE_ID = process.env.CF_ZONE_ID;

async function purgeFiles(files) {
  const response = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/purge_cache`,
    {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${CF_API_TOKEN}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        files
      })
    }
  );

  const data = await response.json();

  if (!data.success) {
    console.error("Purge failed:", JSON.stringify(data, null, 2));
    process.exit(1);
  }

  console.log("Purge success:", data);
}

purgeFiles([
  "https://www.example.com/",
  "https://www.example.com/static/app.js"
]);

2. 清空全部缓存

async function purgeEverything() {
  const response = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/purge_cache`,
    {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${CF_API_TOKEN}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        purge_everything: true
      })
    }
  );

  const data = await response.json();
  console.log(data);
}

生产环境不建议频繁使用 purge_everything，因为这会导致大量请求同时回源，可能造成源站压力骤增。

十五、CI/CD 集成方案

企业可以将 Cloudflare 缓存刷新、Workers 部署、Pages 发布纳入 CI/CD 流程。

以 GitHub Actions 为例：

name: Deploy Workers

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Deploy Cloudflare Worker
        run: npx wrangler deploy
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

如果需要发布后刷新缓存：

      - name: Purge Cloudflare Cache
        run: node scripts/purge-cache.js
        env:
          CF_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
          CF_ZONE_ID: ${{ secrets.CF_ZONE_ID }}

这样可以让边缘逻辑发布与业务版本发布保持一致，降低人为操作风险。

十六、企业落地最佳实践

1. 不要把所有内容都设置为 Cache Everything

很多团队为了追求缓存命中率，会错误地将全站设置为 Cache Everything。对于登录态页面、用户中心、订单页、支付页，这可能导致严重的数据泄露风险。正确方式是分路径、分资源类型设置缓存。

2. 源站必须隐藏

开启 Cloudflare 代理不代表源站安全。如果攻击者知道源站 IP，仍可绕过 Cloudflare。企业应通过防火墙、Tunnel 或安全组限制源站访问来源。

3. WAF 先观察后阻断

初次开启 WAF 托管规则时，不建议直接全部 Block。应先进入日志模式，观察误报路径和业务影响，再逐步收紧。

4. API 防护要分层

API 防护不应只依赖单一限流。推荐组合：

Cloudflare WAF
+ Rate Limiting
+ Bot Management
+ Turnstile
+ API Gateway
+ 业务风控

5. 建立应急开关

企业应提前准备：

1. 缓存全部绕过规则；
2. WAF 临时放行规则；
3. 源站备用线路；
4. Workers 回滚版本；
5. DNS 降级方案；
6. 黑名单快速封禁脚本。

6. 权限最小化

Cloudflare API Token 应按用途拆分，例如：

不要在 CI/CD 中使用全局 API Key。

十七、推荐企业实施路径

对于已经有线上业务的企业，可以按以下阶段逐步实施：

第一阶段：基础接入

1. DNS 托管到 Cloudflare；
2. 开启代理；
3. 配置 Full Strict SSL；
4. 设置基础缓存；
5. 限制源站只允许 Cloudflare IP。

第二阶段：安全加固

1. 开启 WAF 托管规则；
2. 配置敏感路径拦截；
3. 登录、验证码接口限流；
4. 后台系统接入 Access；
5. 使用 Turnstile 替代验证码。

第三阶段：边缘治理

1. 使用 Workers 做灰度发布；
2. 使用 Workers 做边缘鉴权；
3. 针对静态资源和页面精细化缓存；
4. API 接入更严格的安全策略；
5. 缓存刷新接入 CI/CD。

第四阶段：可观测与自动化

1. 启用 Logpush；
2. 接入 SIEM 或日志平台；
3. 建立 WAF 命中告警；
4. 建立源站异常告警；
5. 自动化封禁高危 IP 或 ASN。

十八、总结

Cloudflare 在企业级架构中的价值，不仅是 CDN 加速，更是一个覆盖全球边缘网络、安全防护、身份访问、边缘计算和流量治理的平台。

一套成熟的 Cloudflare 企业级方案，应至少包含：

1. DNS 托管与源站隐藏；
2. Full Strict HTTPS 加密链路；
3. 静态资源和页面缓存策略；
4. WAF、Rate Limiting、Bot 防护；
5. Workers 边缘鉴权与灰度发布；
6. Tunnel 与 Zero Trust 内网访问保护；
7. Turnstile 人机验证；
8. 日志分析与自动化运维；
9. CI/CD 集成与缓存刷新自动化。

企业在落地过程中，不应一味追求复杂配置，而应围绕业务风险和访问特点分阶段推进。对于多数企业来说，先解决源站暴露、HTTPS、缓存、WAF 和后台访问控制，就已经能显著提升安全性和稳定性。随后再引入 Workers、Tunnel、Logpush、API Shield 等高级能力，逐步构建真正的全球边缘安全架构。

Cloudflare 的最佳实践并不是“打开所有功能”，而是根据业务特点制定规则、持续观测效果、不断调优策略。只有将 Cloudflare 与企业自身的研发、运维、安全和发布流程结合起来，才能真正发挥其企业级价值。