Cloudflare 接入后，服务器压力、真实 IP 与缓存配置会发生什么？附实用源码

发布人：慈云数据-客服中心发布时间：1 天前阅读量：4

Cloudflare 对服务器有什么影响｜附源码

在现代网站架构中，Cloudflare 几乎已经成为许多站长、开发者和企业的“标配”。无论是个人博客、SaaS 平台，还是跨境电商网站，经常都会看到网站接入 Cloudflare 的身影。

Cloudflare 的核心定位并不是一台传统意义上的服务器，而是位于用户与源站服务器之间的一层网络服务平台。它通常承担 CDN 加速、DNS 解析、DDoS 防护、WAF 防火墙、缓存优化、HTTPS 证书、Bot 管理 等功能。

那么问题来了：Cloudflare 对服务器到底有什么影响？它是减轻服务器压力，还是会带来额外问题？接入 Cloudflare 后，服务器应该如何配置？

本文将从原理、优点、潜在影响、配置建议以及源码示例等角度，系统分析 Cloudflare 对服务器的影响。

一、Cloudflare 在网站架构中的位置

在没有接入 Cloudflare 之前，用户访问网站的流程通常是：

用户浏览器 → DNS 解析 → 源站服务器 → 返回网页内容

接入 Cloudflare 后，访问流程会变成：

用户浏览器 → Cloudflare 边缘节点 → 源站服务器 → Cloudflare → 用户浏览器

也就是说，Cloudflare 位于用户和源站服务器之间，充当了一个“反向代理”的角色。

当用户访问你的域名时，请求会先到达 Cloudflare 的边缘节点。Cloudflare 会根据缓存规则、安全规则、页面规则、SSL 设置等，决定是否直接返回缓存内容，还是继续回源访问你的服务器。

因此，Cloudflare 对服务器的影响主要体现在以下几个方面：

改变真实访问来源 IP；
减少部分静态资源请求；
提供攻击流量过滤；
改变 HTTPS 连接方式；
增加一层代理链路；
影响日志、限流、鉴权等业务逻辑；
改变缓存策略和响应头行为。

二、Cloudflare 对服务器的积极影响

1. 减轻源站服务器压力

Cloudflare 最明显的作用之一就是缓存静态资源，例如：

图片；
CSS；
JavaScript；
字体文件；
视频片段；
静态 HTML；
下载文件。

如果缓存命中，用户请求不会到达你的源站服务器，而是直接由 Cloudflare 边缘节点返回。

例如：

用户请求 logo.png
↓
Cloudflare 判断已有缓存
↓
直接返回 logo.png
↓
源站服务器完全没有收到请求

这对服务器的好处非常明显：

减少带宽消耗；
减少 Nginx/Apache 请求压力；
降低磁盘 I/O；
降低 CPU 消耗；
提高高并发场景下的稳定性。

对于小型 VPS 来说，Cloudflare 的缓存能力尤其有价值。一台配置较低的服务器，如果直接承受大量图片、CSS、JS 请求，可能很快就会出现带宽打满或负载升高的问题。而接入 Cloudflare 后，大部分静态资源可以由边缘节点承担。

2. 提升全球访问速度

Cloudflare 在全球有大量边缘节点。用户访问网站时，通常会被调度到距离自己较近的 Cloudflare 节点。

例如：

美国用户 → 美国 Cloudflare 节点
欧洲用户 → 欧洲 Cloudflare 节点
亚洲用户 → 亚洲 Cloudflare 节点

如果静态资源已经缓存在对应地区的节点上，用户可以直接从本地或邻近节点获取资源，访问速度明显提升。

即使请求需要回源，Cloudflare 在一些情况下也可以通过自身网络优化链路，改善跨区域访问质量。

对于以下类型网站尤其有用：

跨境电商；
海外博客；
SaaS 服务；
文档站；
图片资源站；
开源项目官网；
面向全球用户的 API 服务。

3. 隐藏源站真实 IP

接入 Cloudflare 后，普通用户访问域名时看到的是 Cloudflare 的 IP，而不是源站服务器真实 IP。

这可以在一定程度上保护源站：

攻击者 → 只能看到 Cloudflare IP
攻击流量 → 先到 Cloudflare
源站 IP → 不直接暴露

如果源站 IP 没有泄露，并且服务器防火墙只允许 Cloudflare IP 访问，那么攻击者就很难绕过 Cloudflare 直接攻击你的服务器。

不过需要注意：
Cloudflare 不能自动保证源站 IP 永远不泄露。

源站 IP 可能通过以下方式暴露：

历史 DNS 记录；
邮件服务器记录；
子域名未接入代理；
服务器主动对外请求；
GitHub 配置泄露；
错误的 SSL 证书信息；
其他服务端口暴露。

因此，如果你希望真正隐藏源站 IP，仅仅开启 Cloudflare 小橙云是不够的，还需要配合服务器防火墙策略。

4. 防御 DDoS 和恶意流量

Cloudflare 的另一个重要作用是安全防护。它可以在边缘层处理大量异常流量，例如：

SYN Flood；
UDP Flood；
HTTP Flood；
CC 攻击；
恶意爬虫；
简单扫描器；
高频请求；
部分漏洞探测。

对于源站服务器来说，这意味着：

攻击流量不一定会到达源站；
部分恶意请求会被 Cloudflare 拦截；
源站负载下降；
服务器可用性提高。

Cloudflare 还提供 WAF 规则，可以拦截常见 Web 攻击，例如：

SQL 注入；
XSS；
路径穿越；
命令注入；
WordPress 常见攻击；
PHP 探测请求；
敏感路径访问。

当然，Cloudflare 并不能替代服务器自身安全防护。服务器仍然需要：

及时更新系统；
关闭无用端口；
配置 SSH 安全；
部署应用层鉴权；
做好日志审计；
备份重要数据。

5. 简化 HTTPS 配置

Cloudflare 可以为域名提供免费的 SSL/TLS 证书。用户访问 Cloudflare 时，可以使用 HTTPS。

常见 SSL 模式包括：

模式	用户到 Cloudflare	Cloudflare 到源站	说明
Off	HTTP	HTTP	不推荐
Flexible	HTTPS	HTTP	不推荐用于生产
Full	HTTPS	HTTPS	可用
Full Strict	HTTPS	HTTPS 且验证证书	推荐

建议使用：

Full (strict)

也就是：

用户浏览器 HTTPS → Cloudflare HTTPS → 源站服务器 HTTPS

这样可以保证整条链路都加密，避免出现中间链路明文传输的问题。

三、Cloudflare 对服务器的潜在负面影响

虽然 Cloudflare 有很多优点，但它不是“无脑开启就一定更好”。如果配置不当，也会给服务器和业务带来一些问题。

1. 服务器日志中的 IP 变成 Cloudflare IP

接入 Cloudflare 后，源站服务器收到的请求来源 IP 通常是 Cloudflare 节点 IP，而不是用户真实 IP。

例如 Nginx 日志可能变成：

172.70.214.32 - - [01/Jan/2026:10:00:00 +0800] "GET / HTTP/1.1" 200

这会影响：

用户真实 IP 统计；
安全审计；
登录风控；
访问限流；
地理位置判断；
黑名单系统；
日志分析；
业务鉴权。

Cloudflare 会通过请求头传递真实 IP，例如：

CF-Connecting-IP: 203.0.113.10
X-Forwarded-For: 203.0.113.10

服务器需要正确读取这些请求头，才能恢复真实用户 IP。

2. IP 限流可能失效或误伤

如果应用程序直接使用连接 IP 进行限流，例如：

每个 IP 每分钟最多请求 60 次

接入 Cloudflare 后，应用看到的 IP 可能都是 Cloudflare 节点 IP。结果可能出现两种问题：

第一，所有用户被识别成同一个 IP 段，导致正常用户被误伤。

第二，攻击者隐藏在 Cloudflare 后面，如果程序没有读取真实 IP，就无法进行准确限流。

因此，接入 Cloudflare 后，必须修改限流逻辑，优先读取：

CF-Connecting-IP

但要注意，不能无条件信任客户端传来的请求头。只有当请求确实来自 Cloudflare IP 段时，才应该信任 CF-Connecting-IP。

3. 缓存配置错误可能导致内容异常

Cloudflare 的缓存机制虽然强大，但如果配置不当，可能造成严重问题。

常见错误包括：

登录后的页面被缓存；
用户个人信息页面被缓存；
后台管理页面被缓存；
API 响应被错误缓存；
购物车页面被缓存；
支付回调被缓存；
动态 HTML 被长期缓存。

例如，如果一个用户登录后访问 /profile，Cloudflare 错误缓存了该页面，另一个用户可能看到前一个用户的信息。这是非常严重的安全事故。

因此，动态页面需要明确禁止缓存：

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

对于静态资源，可以设置较长缓存：

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

4. HTTPS 模式错误导致重定向循环

很多人接入 Cloudflare 后会遇到：

ERR_TOO_MANY_REDIRECTS

常见原因是 Cloudflare 使用了 Flexible SSL 模式。

流程如下：

用户 HTTPS 访问 Cloudflare
Cloudflare 使用 HTTP 访问源站
源站发现是 HTTP，请求跳转到 HTTPS
Cloudflare 再次用 HTTP 访问源站
源站继续跳转
最终形成死循环

解决方案是：

Cloudflare SSL 模式改为 Full 或 Full Strict；
源站部署有效 HTTPS 证书；
Nginx/Apache 正确识别代理协议头；
避免重复强制跳转。

生产环境强烈建议不要使用 Flexible。

5. 增加一层代理延迟

理论上，Cloudflare 会增加一层中转：

用户 → Cloudflare → 源站

如果缓存命中，速度通常更快；
如果不缓存，并且 Cloudflare 节点到源站链路不理想，可能反而增加延迟。

例如，源站在中国香港，用户也在香港，但被调度到了较远节点，或者网络链路绕路，就可能出现延迟升高。

因此，Cloudflare 对性能的影响不是绝对的，需要结合：

用户分布；
源站位置；
缓存命中率；
DNS 调度；
网络质量；
业务类型。

对于动态 API 服务，Cloudflare 的加速效果可能不如静态网站明显。

四、服务器接入 Cloudflare 后的推荐配置

1. 防火墙只允许 Cloudflare IP 访问 HTTP/HTTPS

如果源站真实 IP 已经隐藏，建议服务器防火墙只允许 Cloudflare IP 访问 80 和 443 端口。

这样即使攻击者知道服务器 IP，也无法直接绕过 Cloudflare 访问网站。

基本思路：

允许 Cloudflare IP → 访问 80/443
拒绝其他 IP → 访问 80/443
保留 SSH 管理端口 → 仅允许自己的固定 IP

2. Nginx 恢复真实用户 IP

Nginx 可以使用 real_ip_header 配置恢复真实 IP。

示例：

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;

配置后，Nginx 日志中的 $remote_addr 就可以变成真实用户 IP。

3. 应用程序正确获取真实 IP

在应用层，也可以通过 CF-Connecting-IP 获取用户 IP。但必须注意安全：
只有请求来自可信代理时，才信任该请求头。

如果不做校验，攻击者可以伪造请求头：

CF-Connecting-IP: 1.2.3.4

然后绕过限流、风控或黑名单。

五、源码示例：Node.js 获取 Cloudflare 真实 IP

下面是一个 Express 示例，用于在接入 Cloudflare 后安全获取用户真实 IP。

1. 安装依赖

npm init -y
npm install express ipaddr.js

2. app.js 源码

const express = require('express');
const ipaddr = require('ipaddr.js');

const app = express();

/**
 * Cloudflare 官方 IPv4 CIDR
 * 注意：生产环境建议定期从 Cloudflare 官方接口同步
 */
const cloudflareCIDRs = [
  '173.245.48.0/20',
  '103.21.244.0/22',
  '103.22.200.0/22',
  '103.31.4.0/22',
  '141.101.64.0/18',
  '108.162.192.0/18',
  '190.93.240.0/20',
  '188.114.96.0/20',
  '197.234.240.0/22',
  '198.41.128.0/17',
  '162.158.0.0/15',
  '104.16.0.0/13',
  '104.24.0.0/14',
  '172.64.0.0/13',
  '131.0.72.0/22'
];

function isIpInCidr(ip, cidr) {
  try {
    const addr = ipaddr.parse(ip);
    const [range, bits] = cidr.split('/');
    const rangeAddr = ipaddr.parse(range);
    return addr.match(rangeAddr, parseInt(bits, 10));
  } catch (e) {
    return false;
  }
}

function isCloudflareIp(ip) {
  return cloudflareCIDRs.some(cidr => isIpInCidr(ip, cidr));
}

function getClientIp(req) {
  let remoteIp = req.socket.remoteAddress || '';

  // 处理 IPv4 映射 IPv6 的情况，例如 ::ffff:192.0.2.1
  if (remoteIp.startsWith('::ffff:')) {
    remoteIp = remoteIp.replace('::ffff:', '');
  }

  const cfConnectingIp = req.headers['cf-connecting-ip'];

  if (cfConnectingIp && isCloudflareIp(remoteIp)) {
    return cfConnectingIp;
  }

  return remoteIp;
}

app.use((req, res, next) => {
  req.realIp = getClientIp(req);
  next();
});

app.get('/', (req, res) => {
  res.json({
    message: 'Hello Cloudflare',
    realIp: req.realIp,
    remoteAddress: req.socket.remoteAddress,
    cfConnectingIp: req.headers['cf-connecting-ip'] || null
  });
});

app.listen(3000, () => {
  console.log('Server is running at http://localhost:3000');
});

运行：

node app.js

访问后返回示例：

{
  "message": "Hello Cloudflare",
  "realIp": "203.0.113.10",
  "remoteAddress": "172.70.214.32",
  "cfConnectingIp": "203.0.113.10"
}

六、源码示例：Nginx 自动同步 Cloudflare IP

Cloudflare 的 IP 段可能会更新，因此建议定期同步。

下面是一个 Shell 脚本，用于自动生成 Nginx 的 Cloudflare real IP 配置。

1. sync-cloudflare-ip.sh

#!/bin/bash

set -e

CONF_PATH="/etc/nginx/conf.d/cloudflare-realip.conf"
TMP_FILE="/tmp/cloudflare-realip.conf"

echo "# Auto generated Cloudflare real IP config" > "$TMP_FILE"
echo "# Generated at: $(date)" >> "$TMP_FILE"
echo "" >> "$TMP_FILE"

echo "real_ip_header CF-Connecting-IP;" >> "$TMP_FILE"
echo "" >> "$TMP_FILE"

curl -s https://www.cloudflare.com/ips-v4 | while read ip; do
  echo "set_real_ip_from $ip;" >> "$TMP_FILE"
done

curl -s https://www.cloudflare.com/ips-v6 | while read ip; do
  echo "set_real_ip_from $ip;" >> "$TMP_FILE"
done

nginx -t

cp "$TMP_FILE" "$CONF_PATH"

nginx -t
systemctl reload nginx

echo "Cloudflare real IP config updated successfully."

2. 使用方式

chmod +x sync-cloudflare-ip.sh
sudo ./sync-cloudflare-ip.sh

3. 添加定时任务

sudo crontab -e

加入：

0 3 * * 1 /path/to/sync-cloudflare-ip.sh >/var/log/sync-cloudflare-ip.log 2>&1

表示每周一凌晨 3 点自动同步一次。

七、源码示例：iptables 只允许 Cloudflare 访问 80/443

下面示例适用于 Linux 服务器，用于限制只有 Cloudflare IP 可以访问网站端口。

注意：执行防火墙规则前，请务必确认 SSH 端口已经放行，否则可能导致无法连接服务器。

allow-cloudflare.sh

#!/bin/bash

set -e

# 修改为你的 SSH 端口
SSH_PORT=22

# 清空旧规则，生产环境请谨慎
iptables -F

# 默认策略
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# 允许本地回环
iptables -A INPUT -i lo -j ACCEPT

# 允许已建立连接
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 允许 SSH
iptables -A INPUT -p tcp --dport "$SSH_PORT" -j ACCEPT

# 允许 Cloudflare IPv4 访问 80/443
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  iptables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT
  iptables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

# 如果需要 IPv6，请额外配置 ip6tables
echo "Rules applied. Only Cloudflare can access HTTP/HTTPS."

如果服务器使用 ufw，也可以写成：

#!/bin/bash

ufw --force reset

ufw default deny incoming
ufw default allow outgoing

ufw allow 22/tcp

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow from "$ip" to any port 80 proto tcp
  ufw allow from "$ip" to any port 443 proto tcp
done

for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  ufw allow from "$ip" to any port 80 proto tcp
  ufw allow from "$ip" to any port 443 proto tcp
done

ufw --force enable

ufw status numbered

八、Cloudflare 缓存策略建议

对于不同类型资源，可以采用不同缓存策略。

1. 静态资源

例如：

/assets/app.css
/assets/app.js
/images/logo.png
/fonts/font.woff2

推荐响应头：

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

前提是文件名带版本号或哈希，例如：

app.8f3a1c.js
style.2b9c0d.css

这样可以长期缓存，并通过文件名变化更新资源。

2. 动态页面

例如：

/user/profile
/admin
/order/list
/cart

推荐响应头：

Cache-Control: no-store

避免用户数据被缓存。

3. API 接口

对于 API，需要根据业务判断。

用户相关接口：

Cache-Control: no-store

公开数据接口：

Cache-Control: public, max-age=60

例如新闻列表、商品列表、公开配置等，可以短时间缓存，降低服务器压力。

九、Cloudflare 对不同类型服务器的影响

1. 对静态网站服务器

影响通常非常正面。

静态网站接入 Cloudflare 后：

访问速度提升明显；
源站压力大幅降低；
带宽成本下降；
抗攻击能力增强；
HTTPS 配置更方便。

如果网站主要由 HTML、CSS、JS、图片组成，Cloudflare 是非常适合的。

2. 对 WordPress 服务器

Cloudflare 对 WordPress 也很有帮助，但需要注意缓存规则。

WordPress 常见优化方向：

缓存静态资源；
登录页面加强防护；
后台路径限制访问；
XML-RPC 接口限制；
配合页面缓存插件；
避免缓存登录用户页面；
对 /wp-admin 设置绕过缓存。

推荐规则：

/wp-admin/*        Bypass Cache
/wp-login.php      Security Challenge
/xmlrpc.php        Block or Challenge
/wp-content/*      Cache Static

3. 对 API 服务器

对 API 服务器的影响更复杂。

优点：

可防御部分恶意请求；
可做速率限制；
可隐藏源站；
可提供 TLS；
可缓存公开 API。

风险：

增加代理层；
真实 IP 需要正确处理；
WebSocket、长连接需额外关注；
缓存配置错误可能影响数据实时性；
某些请求头可能被修改或增加。

如果 API 对延迟极其敏感，需要实际压测后决定是否全量接入。

十、接入 Cloudflare 后的排查思路

当网站接入 Cloudflare 后出现异常，可以按以下顺序排查：

1. 检查 DNS 状态

确认域名是否开启代理：

橙色云朵：流量经过 Cloudflare
灰色云朵：仅 DNS 解析，不代理

2. 检查 SSL 模式

3. 检查源站是否能正常访问

可以通过修改本地 hosts 或直接访问源站 IP 测试。

也可以使用：

curl -I https://your-domain.com

查看响应头：

Server: cloudflare
CF-Cache-Status: HIT

4. 检查缓存状态

Cloudflare 常见缓存状态：

状态	含义
HIT	命中缓存
MISS	未命中缓存
BYPASS	绕过缓存
EXPIRED	缓存过期
DYNAMIC	动态内容未缓存

示例命令：

curl -I https://example.com/assets/app.js

5. 检查真实 IP

查看 Nginx 日志：

tail -f /var/log/nginx/access.log

如果仍然都是 Cloudflare IP，说明 real IP 配置未生效。

十一、Cloudflare 使用建议总结

接入 Cloudflare 后，建议重点做好以下几件事：

使用 Full Strict SSL 模式，避免 Flexible；
源站部署 HTTPS 证书；
Nginx 配置 real IP，恢复用户真实 IP；
应用层只信任来自 Cloudflare 的真实 IP 头；
防火墙限制 80/443 只允许 Cloudflare 访问；
静态资源设置长期缓存；
动态页面和用户页面禁止缓存；
定期同步 Cloudflare IP 段；
关注缓存命中率和源站负载变化；
不要把 Cloudflare 当作唯一安全措施。

十二、结论

Cloudflare 对服务器的影响总体是积极的。它可以显著降低源站压力、提升全球访问速度、隐藏服务器真实 IP、缓解 DDoS 攻击，并简化 HTTPS 部署。

但与此同时，Cloudflare 也会改变服务器接收到的请求特征。接入后，服务器看到的访问来源不再是用户真实 IP，而是 Cloudflare 节点 IP；缓存策略如果配置错误，可能导致动态内容异常；SSL 模式配置不当，可能引发重定向循环；防火墙和日志系统也需要相应调整。

因此，正确的使用方式不是简单地“打开小橙云”，而是配合服务器做完整配置：

Cloudflare 负责边缘加速和防护
Nginx 负责真实 IP 识别和反向代理
应用程序负责业务鉴权与安全判断
防火墙负责保护源站入口
缓存策略负责平衡性能和数据安全

如果配置得当，Cloudflare 可以让服务器更轻、更快、更安全；如果配置不当，它也可能让日志、限流、缓存和 HTTPS 出现一系列问题。

对于大多数网站来说，Cloudflare 是非常值得接入的基础设施服务，但前提是：理解它对服务器的影响，并按照正确方式进行配置。

文章标签： Cloudflare 服务器配置真实IP 缓存策略

上一篇：Cloudflare 会让服务器更快更安全吗？跨境电商独立站必看指南

下一篇：Cloudflare 接入后，服务器到底会发生哪些变化？配置与源码一次讲清

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们