Cloudflare 为什么突然火了｜附配置文件

如果你最近刷技术社区、博客圈、独立开发者群，应该会明显感觉到一个现象：Cloudflare 的存在感越来越强。

以前提到 Cloudflare，很多人的第一反应可能只是：

“一个免费的 CDN。”

“可以隐藏源站 IP。”

“能防 DDoS。”

“网站套个小云朵。”

但现在，Cloudflare 已经不只是 CDN 了。它逐渐变成了一套覆盖 域名解析、CDN、安全防护、无服务器计算、对象存储、内网穿透、零信任访问、边缘网络应用部署 的综合平台。

对于个人站长、独立开发者、小团队，甚至企业来说，Cloudflare 的吸引力正在快速上升。

这篇文章就聊聊：Cloudflare 为什么突然火了？它到底解决了什么问题？以及常见服务应该如何配置。

一、Cloudflare 到底是什么？

Cloudflare 最早被大众熟知，主要是因为它提供了免费的 CDN 和 DNS 服务。

简单来说，Cloudflare 站在用户和你的服务器之间：

用户浏览器
   ↓
Cloudflare 边缘节点
   ↓
你的源站服务器

用户访问你的网站时，请求会先进入 Cloudflare 全球边缘网络。Cloudflare 会根据配置决定：

• 是否直接返回缓存内容；
• 是否拦截恶意请求；
• 是否进行 HTTPS 处理；
• 是否转发到源站服务器；
• 是否执行 Worker 脚本；
• 是否走 Zero Trust 规则；
• 是否通过 Tunnel 访问内网服务。

这也是为什么 Cloudflare 不只是一个 CDN，而更像一个“互联网入口控制层”。

二、为什么 Cloudflare 最近突然火了？

1. 免费额度足够慷慨

Cloudflare 最吸引人的地方之一，就是它的免费套餐真的能用。

对于大多数个人网站、小型项目、博客、API 测试服务来说，免费套餐已经覆盖了大量常用需求：

• 免费 DNS；
• 免费 CDN；
• 免费 HTTPS 证书；
• 免费 DDoS 基础防护；
• 免费防火墙规则；
• 免费 Page Rules 或 Rules；
• 免费 Workers 调用额度；
• 免费 Pages 静态站点托管；
• 免费 Tunnel；
• 免费 Zero Trust 基础功能；
• 免费 R2 一定额度。

这对于个人开发者非常友好。

以前，如果你想部署一个带 HTTPS 的网站，可能要经历：

1. 买服务器；
2. 配置 Nginx；
3. 申请证书；
4. 配置自动续期；
5. 配 CDN；
6. 配防火墙；
7. 防止源站暴露；
8. 处理攻击流量；
9. 配静态资源缓存。

现在 Cloudflare 可以帮你解决其中很大一部分。

2. 域名解析体验非常好

Cloudflare 的 DNS 服务非常稳定，解析速度也不错。很多人最开始使用 Cloudflare，就是因为它的 DNS 面板简单、清晰、可靠。

常见记录类型都支持：

• A；
• AAAA；
• CNAME；
• TXT；
• MX；
• SRV；
• CAA；
• NS。

并且 Cloudflare 的 DNS 记录旁边有一个非常经典的小云朵：

• 灰色云朵：只做 DNS 解析；
• 橙色云朵：开启 Cloudflare 代理。

开启橙色云朵后，用户请求就会经过 Cloudflare，源站 IP 不会直接暴露给用户。

这对于个人站长来说非常有用。

3. HTTPS 配置简单

Cloudflare 可以自动给你的域名签发边缘证书。你只需要把域名托管到 Cloudflare，然后开启 SSL/TLS，就可以很方便地使用 HTTPS。

常见 SSL 模式包括：

最推荐的是：

SSL/TLS 模式：Full (strict)

因为 Flexible 模式容易导致重定向循环、安全性不足等问题。

4. Cloudflare Tunnel 让内网穿透变简单

Cloudflare Tunnel 是最近非常火的功能之一。

它可以让你在没有公网 IP、没有开放端口的情况下，把本地服务暴露到公网域名上。

传统做法可能需要：

• 公网服务器；
• 反向代理；
• frp；
• ngrok；
• 防火墙放行端口；
• 配置 TLS；
• 处理源站 IP 暴露。

而 Cloudflare Tunnel 的方式是：

本地服务
   ↓
cloudflared 主动连接 Cloudflare
   ↓
Cloudflare 边缘网络
   ↓
用户访问域名

关键点在于：连接是由内网机器主动发起到 Cloudflare 的，不需要外部主动访问你的内网机器。

这对于家庭服务器、NAS、Homelab、开发测试环境非常有吸引力。

例如：

• 在家里部署一个博客；
• 暴露本地 Git 服务；
• 暴露 Home Assistant；
• 暴露 Jellyfin；
• 暴露本地 API；
• 暴露开发中的 Web 项目；
• 暴露内网面板但配合 Zero Trust 限制访问。

5. Workers 让边缘函数开发变得简单

Cloudflare Workers 是运行在 Cloudflare 边缘节点上的 Serverless 平台。

它允许你写 JavaScript / TypeScript 代码，在离用户更近的位置处理请求。

比如你可以用 Workers 做：

• API 代理；
• 请求鉴权；
• URL 重写；
• 简单后端服务；
• A/B 测试；
• 图片代理；
• 短链接；
• 边缘缓存控制；
• 反爬逻辑；
• 简单 SSR；
• Webhook 转发。

一个最简单的 Worker：

export default {
  async fetch(request, env, ctx) {
    return new Response("Hello from Cloudflare Workers!");
  }
}

这种部署方式不需要你维护服务器，也不需要考虑传统意义上的运维问题。

对于独立开发者来说，这非常有吸引力。

6. Pages 让静态网站部署变得极其简单

Cloudflare Pages 类似 Vercel、Netlify，可以用来部署静态网站和前端项目。

它支持：

• GitHub / GitLab 自动部署；
• 自定义域名；
• HTTPS；
• 预览环境；
• 构建命令；
• 环境变量；
• Pages Functions；
• 与 Workers 集成。

你可以部署：

• VuePress；
• VitePress；
• Hexo；
• Hugo；
• Astro；
• Next.js 部分场景；
• Nuxt 部分场景；
• React / Vue / Svelte 前端项目。

对于技术博客来说，Cloudflare Pages 是一个非常不错的选择。

7. R2 对象存储没有出口流量费

Cloudflare R2 也是很多人关注 Cloudflare 的原因之一。

传统对象存储的成本，除了存储费用外，比较让人头疼的是 出口流量费。如果图片、附件、视频等资源访问量增加，流量成本可能会明显上升。

R2 的一个重要卖点是：

没有出口流量费。

这对于图床、资源站、静态资源分发、小型文件服务非常有吸引力。

当然，R2 也不是完全免费无限使用，它仍然有存储和请求额度限制。但对于很多个人项目来说，它的成本结构更容易接受。

8. Zero Trust 让访问控制更现代

Cloudflare Zero Trust 可以给你的内部服务加一层身份验证。

例如你通过 Tunnel 暴露了一个内网后台：

admin.example.com

你不希望任何人都能打开这个地址，那么可以用 Zero Trust 配置访问策略：

• 只有指定邮箱可以访问；
• 只有某个 GitHub 组织成员可以访问；
• 只有通过 Google 登录的人可以访问；
• 只有特定国家或地区可以访问；
• 只有安装 WARP 客户端的设备可以访问；
• 需要一次性验证码。

这比单纯依赖 Nginx Basic Auth 或 IP 白名单更灵活。

三、Cloudflare 适合哪些人？

Cloudflare 特别适合以下几类用户。

1. 个人站长

如果你有博客、文档站、资源站、导航站，Cloudflare 可以帮你解决：

• HTTPS；
• CDN；
• DNS；
• 缓存；
• 基础防护；
• 源站隐藏。

2. 独立开发者

如果你经常做小产品、API 服务、SaaS 原型，Cloudflare Workers、Pages、R2、D1 都可以帮助你快速上线。

3. Homelab 玩家

如果你有 NAS、家庭服务器、小主机、软路由，Cloudflare Tunnel 可以让你很方便地远程访问服务。

4. 小团队

小团队可以利用 Zero Trust、Access、Tunnel、Gateway 做访问控制和安全接入，减少公网暴露面。

5. 前端开发者

Cloudflare Pages 对前端项目非常友好。你可以直接连接 GitHub 仓库，push 后自动构建部署。

四、Cloudflare 的常见使用场景

场景一：给网站套 CDN

这是最基础的用法。

步骤大致如下：

1. 注册 Cloudflare；
2. 添加域名；
3. 修改域名 NS 到 Cloudflare；
4. 添加 DNS 记录；
5. 开启橙色云朵代理；
6. 设置 SSL/TLS 为 Full Strict；
7. 配置缓存规则和安全规则。

适用于：

• WordPress；
• Typecho；
• Halo；
• 静态博客；
• 自建论坛；
• 后台管理系统。

场景二：通过 Tunnel 暴露本地服务

假设你本地有一个服务：

http://localhost:8080

想通过下面的域名访问：

app.example.com

可以使用 Cloudflare Tunnel。

场景三：用 Workers 做 API 代理

比如你想把请求：

https://api.example.com/github

代理到：

https://api.github.com

可以用 Workers 写一个简单代理，并在边缘节点完成请求转发。

场景四：用 Pages 部署博客

例如你用 VitePress 写博客，只需要把代码推到 GitHub，然后在 Cloudflare Pages 中选择仓库，设置构建命令即可。

常见配置：

Build command: npm run build
Build output directory: .vitepress/dist

五、Cloudflare 配置文件示例

下面给出几个常见配置文件，方便参考。

1. cloudflared Tunnel 配置文件

适用于把本地服务通过 Cloudflare Tunnel 暴露到公网。

配置路径通常为：

~/.cloudflared/config.yml

示例：

tunnel: my-tunnel
credentials-file: /home/ubuntu/.cloudflared/my-tunnel.json

ingress:
  - hostname: app.example.com
    service: http://localhost:8080

  - hostname: api.example.com
    service: http://localhost:3000

  - hostname: nas.example.com
    service: http://192.168.1.10:5000

  - service: http_status:404

说明：

• tunnel：Tunnel 名称或 Tunnel ID；
• credentials-file：Tunnel 凭证文件路径；
• hostname：绑定的域名；
• service：本地或内网服务地址；
• 最后一条 http_status:404 是兜底规则，建议保留。

创建 Tunnel 的基本命令：

cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.example.com
cloudflared tunnel run my-tunnel

如果需要作为系统服务运行：

sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

2. Docker Compose 部署 cloudflared

如果你喜欢 Docker，可以使用下面的方式运行 Cloudflare Tunnel。

version: "3.8"

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --no-autoupdate run --token YOUR_TUNNEL_TOKEN

其中 YOUR_TUNNEL_TOKEN 可以在 Cloudflare Zero Trust 控制台中创建 Tunnel 后获得。

如果你需要把多个内网服务接入 Cloudflare，可以直接在 Cloudflare 控制台的 Tunnel 页面中添加 Public Hostname，也可以挂载本地配置文件。

带配置文件的版本：

version: "3.8"

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    volumes:
      - ./cloudflared:/etc/cloudflared
    command: tunnel --config /etc/cloudflared/config.yml run

目录结构：

project/
├── docker-compose.yml
└── cloudflared/
    ├── config.yml
    └── my-tunnel.json

3. Nginx 源站配置文件

如果你的网站源站仍然使用 Nginx，可以参考下面配置。

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

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

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

    ssl_certificate     /etc/ssl/certs/origin.pem;
    ssl_certificate_key /etc/ssl/private/origin.key;

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

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

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

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

这里建议使用 Cloudflare Origin Certificate，即源站证书。

Cloudflare 控制台路径：

SSL/TLS → Origin Server → Create Certificate

生成后把证书和私钥分别保存到：

/etc/ssl/certs/origin.pem
/etc/ssl/private/origin.key

然后把 SSL/TLS 模式设置为：

Full (strict)

4. 只允许 Cloudflare IP 访问源站

为了防止攻击者绕过 Cloudflare 直接访问源站，可以在服务器防火墙或 Nginx 中只允许 Cloudflare IP。

Nginx 示例：

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;

real_ip_header CF-Connecting-IP;

如果要直接拒绝非 Cloudflare 请求，可以结合防火墙实现。以 UFW 为例：

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow ssh
sudo ufw allow from 173.245.48.0/20 to any port 80
sudo ufw allow from 173.245.48.0/20 to any port 443

sudo ufw enable

不过实际使用时要把 Cloudflare 官方完整 IP 段都加入规则。Cloudflare IP 列表地址：

https://www.cloudflare.com/ips/

注意：如果你是通过 Tunnel 暴露服务，通常不需要开放 80/443 到公网。

5. Wrangler 配置文件

如果你使用 Cloudflare Workers，通常会用到 Wrangler。

wrangler.toml 示例：

name = "my-worker"
main = "src/index.js"
compatibility_date = "2024-06-01"

routes = [
  { pattern = "api.example.com/*", zone_name = "example.com" }
]

[vars]
APP_ENV = "production"
API_BASE = "https://backend.example.com"

Worker 示例代码：

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

    if (url.pathname === "/health") {
      return Response.json({
        status: "ok",
        env: env.APP_ENV
      })
    }

    const target = env.API_BASE + url.pathname + url.search

    const newRequest = new Request(target, {
      method: request.method,
      headers: request.headers,
      body: request.body,
      redirect: "follow"
    })

    return fetch(newRequest)
  }
}

部署命令：

npm install -g wrangler
wrangler login
wrangler deploy

6. Cloudflare Pages 配置示例

以 VitePress 为例，Cloudflare Pages 中可以这样配置：

Framework preset: None
Build command: npm run docs:build
Build output directory: docs/.vitepress/dist
Root directory: /

package.json 示例：

{
  "scripts": {
    "docs:dev": "vitepress dev docs",
    "docs:build": "vitepress build docs",
    "docs:preview": "vitepress preview docs"
  },
  "devDependencies": {
    "vitepress": "^1.0.0"
  }
}

如果是 Vite 项目：

Build command: npm run build
Build output directory: dist

如果是 Hugo：

Build command: hugo
Build output directory: public

六、Cloudflare 使用时的注意事项

Cloudflare 虽然好用，但并不是万能的。使用时也要注意一些问题。

1. 不要盲目开启所有功能

很多人一看到 Cloudflare 面板里有很多开关，就全部打开：

• Auto Minify；
• Rocket Loader；
• Brotli；
• Always Use HTTPS；
• Cache Everything；
• WAF；
• Bot Fight Mode。

但并不是所有功能都适合所有网站。

例如：

• Rocket Loader 可能影响前端 JS 执行；
• Cache Everything 可能导致动态页面被缓存；
• 过度防护可能误伤正常用户；
• Flexible SSL 可能导致重定向循环。

建议一个一个开启，并观察效果。

2. SSL 尽量使用 Full Strict

如果源站支持 HTTPS，建议使用：

Full (strict)

并配置 Cloudflare Origin Certificate 或 Let’s Encrypt 证书。

不要长期使用 Flexible 模式，因为它只保证用户到 Cloudflare 的连接是 HTTPS，而 Cloudflare 到源站仍然可能是 HTTP。

3. 后台和管理接口不要裸奔

即使套了 Cloudflare，也不代表后台绝对安全。

例如：

/admin
/wp-admin
/api/private
/dashboard

这些路径建议额外加保护：

• Zero Trust Access；
• 登录验证；
• IP 白名单；
• MFA；
• 强密码；
• 限速规则；
• WAF 规则。

4. 注意缓存规则

如果缓存配置不当，可能会出现：

• 登录后页面被缓存；
• 用户 A 看到用户 B 的信息；
• API 返回旧数据；
• 后台页面异常；
• 表单提交失败。

动态网站不要随便全站 Cache Everything。

比较稳妥的方式是：

• 静态资源长期缓存；
• HTML 短时间缓存或不缓存；
• API 不缓存；
• 后台不缓存。

示例规则：

/static/*
/assets/*
/images/*
/css/*
/js/*

这些路径适合缓存。

而下面这些路径通常不建议缓存：

/admin/*
/api/*
/user/*
/login
/logout

5. 关注合规和服务条款

Cloudflare 提供了很多免费资源，但并不意味着可以滥用。

例如：

• 大流量视频分发；
• 非网页类大文件分发；
• 违规代理服务；
• 恶意爬虫中转；
• 滥用 Workers；
• 绕过平台规则。

这些都有可能触发限制，甚至导致账号或域名受到影响。

七、推荐的一套个人网站配置

如果你只是想给个人博客或小型网站套 Cloudflare，可以参考下面这套配置。

DNS

A     example.com       1.2.3.4      Proxied
CNAME www               example.com  Proxied

SSL/TLS

Encryption mode: Full (strict)
Always Use HTTPS: On
Automatic HTTPS Rewrites: On
Minimum TLS Version: TLS 1.2

缓存

静态资源缓存：开启
HTML：默认或短缓存
API：不缓存
后台：不缓存

安全

WAF: 开启基础规则
Bot Fight Mode: 视情况开启
Rate Limiting: 对登录和 API 开启
Security Level: Medium

源站

只允许 Cloudflare IP 访问 80/443
SSH 更换默认端口或只允许固定 IP
源站启用 HTTPS
后台启用强密码和 MFA

Tunnel

如果没有公网 IP，或者不想开放端口：

使用 Cloudflare Tunnel
配合 Zero Trust Access
不要直接暴露敏感后台

八、Cloudflare 为什么值得关注？

总结一下，Cloudflare 之所以“突然火了”，不是因为它最近才出现，而是因为它的产品组合刚好击中了当前开发者的几个痛点：

1. 部署成本越来越重要
   个人开发者和小团队都希望低成本上线项目。

2. 安全问题越来越突出
   网站被扫、被打、被爆破已经很常见。

3. 公网 IP 越来越稀缺
   家庭宽带、校园网、部分云环境都不一定有公网 IP。

4. Serverless 和边缘计算越来越成熟
   轻量服务不一定非要买 VPS。

5. 独立开发者需要一站式平台
   DNS、CDN、存储、函数、部署、访问控制最好都能在一个平台解决。

6. 免费套餐降低了试错成本
   很多功能可以先免费用起来，再根据需要升级。

Cloudflare 最厉害的地方在于，它并不是单独提供某一个功能，而是把这些功能串成了一张网。

你可以从最简单的 DNS 开始，然后逐步用上：

• CDN；
• HTTPS；
• WAF；
• Tunnel；
• Zero Trust；
• Workers；
• Pages；
• R2；
• D1；
• KV。

最后，你会发现很多原本需要服务器、反向代理、安全网关、对象存储、访问控制系统才能完成的事情，现在可以在 Cloudflare 上用更轻量的方式实现。

九、结语

Cloudflare 的爆火，本质上不是偶然。

它满足了当下互联网项目的几个核心需求：

• 更低成本；
• 更快部署；
• 更强安全；
• 更少运维；
• 更灵活的边缘能力；
• 更适合个人开发者和小团队。

当然，Cloudflare 不是银弹。它不能替代所有后端服务，也不能解决所有性能和安全问题。但对于大多数网站、博客、工具站、小型 SaaS、Homelab 服务来说，Cloudflare 已经是一个非常值得掌握的基础设施平台。

如果你还只是把 Cloudflare 当作“免费 CDN”，那么现在可以重新认识它了。

它更像是一个站在互联网入口处的工具箱：
既能保护你的服务，也能加速你的访问；
既能部署前端，也能运行边缘函数；
既能隐藏源站，也能把内网服务安全地发布出来。

这就是 Cloudflare 为什么突然火了。