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

在网站上线和运维过程中，很多站长、开发者都会接触到 Cloudflare。它既是 CDN 服务商，也是 DNS 托管平台，同时还提供安全防护、缓存加速、访问控制、WAF、防 DDoS、边缘计算等能力。对于服务器来说，接入 Cloudflare 并不是简单地“套一层 CDN”，它会对访问链路、真实 IP 获取、缓存策略、安全防护、日志分析、SSL 配置、源站压力等多个方面产生影响。

本文将系统讲解 Cloudflare 对服务器的影响，包括它带来的好处、可能产生的问题、服务器端需要做的配置，以及常见场景下的源码示例。

一、Cloudflare 的基本工作原理

在未接入 Cloudflare 之前，用户访问网站的大致流程是：

用户浏览器 -> DNS 解析 -> 服务器 IP -> 服务器响应

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

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

也就是说，用户并不会直接访问你的服务器 IP，而是先访问 Cloudflare 的边缘节点。Cloudflare 再根据规则决定是否直接返回缓存内容，或者回源请求你的服务器。

这意味着：

1. 用户看到的是 Cloudflare 的 IP，而不是源站服务器 IP；
2. 源站服务器看到的访问来源通常是 Cloudflare 节点 IP；
3. 静态资源可能由 Cloudflare 缓存，不一定每次都访问源站；
4. 攻击流量会先经过 Cloudflare，部分恶意请求可能被拦截；
5. SSL/TLS、HTTP/2、HTTP/3、压缩、缓存等行为会被 Cloudflare 参与处理。

二、Cloudflare 对服务器的正面影响

1. 降低源站服务器压力

Cloudflare 最大的价值之一是缓存静态资源。例如图片、CSS、JavaScript、字体文件、下载文件等，都可以缓存在 Cloudflare 的边缘节点上。

如果一个网站每天有大量用户访问，未接入 CDN 时，所有请求都会打到源站服务器。服务器不仅要处理动态请求，还要不断传输静态文件，占用 CPU、内存、磁盘 I/O 和带宽。

接入 Cloudflare 后，很多静态请求会直接由边缘节点返回：

用户请求图片 -> Cloudflare 有缓存 -> 直接返回

源站服务器不再需要重复处理这些请求，从而降低负载。

尤其是以下类型的网站，效果明显：

• 图片站；
• 博客站；
• 文档站；
• 下载站；
• 前后端分离项目；
• 海外访问较多的网站；
• 突发流量较大的活动页面。

2. 隐藏源站 IP，提高安全性

接入 Cloudflare 后，用户正常访问域名时解析到的是 Cloudflare 的 IP。如果服务器防火墙配置得当，只允许 Cloudflare IP 回源，那么攻击者就很难直接攻击源站服务器。

这对防御以下风险很有帮助：

• 直接扫描源站端口；
• 绕过 CDN 攻击真实服务器；
• DDoS 直接打源站 IP；
• 暴力破解后台；
• 恶意爬虫绕过 Cloudflare 规则；
• 针对服务器 IP 的漏洞扫描。

不过需要注意，Cloudflare 并不能自动让源站 IP 永久安全。如果源站 IP 曾经暴露过，或者服务器上还有其他域名未经过 Cloudflare，攻击者仍然可能找到真实 IP。

3. 提供 DDoS 和 Web 安全防护

Cloudflare 提供一定程度的 DDoS 防护能力。对于普通网站来说，免费版也能抵御不少常见攻击，例如：

• 简单的 HTTP Flood；
• 恶意爬虫；
• 高频请求；
• 常见漏洞扫描；
• 部分 CC 攻击；
• IP 黑名单访问。

Cloudflare 还提供 WAF、Bot Fight Mode、安全级别调整、JS Challenge、Turnstile 人机验证等功能。

对于服务器而言，这意味着很多异常请求在到达源站之前就会被拦截，从而减少服务器压力。

4. 改善全球访问速度

Cloudflare 在全球有大量边缘节点。当用户访问网站时，通常会被调度到距离较近的节点。对于海外用户访问，Cloudflare 往往能减少跨境网络波动带来的影响。

例如，一个源站服务器位于新加坡：

美国用户 -> Cloudflare 美国节点 -> Cloudflare 内部网络 -> 新加坡源站
欧洲用户 -> Cloudflare 欧洲节点 -> Cloudflare 内部网络 -> 新加坡源站
日本用户 -> Cloudflare 日本节点 -> Cloudflare 内部网络 -> 新加坡源站

如果资源已被缓存，用户甚至不需要访问新加坡源站，直接从就近节点获取内容。

5. 支持 HTTPS 和现代网络协议

Cloudflare 可以帮助网站快速启用 HTTPS，并支持：

• TLS 1.2 / TLS 1.3；
• HTTP/2；
• HTTP/3；
• Brotli 压缩；
• HSTS；
• 自动 HTTPS 重写；
• 边缘证书管理。

对于服务器来说，部分 TLS 连接压力会被 Cloudflare 承担。如果使用 Full 或 Full Strict 模式，Cloudflare 与源站之间仍然通过 HTTPS 通信。

推荐配置为：

SSL/TLS 模式：Full (strict)

不推荐长期使用：

Flexible

因为 Flexible 模式是：

用户 -> HTTPS -> Cloudflare -> HTTP -> 源站

这可能导致安全性下降，也容易引起重定向循环。

三、Cloudflare 对服务器的负面影响和注意事项

1. 服务器看到的客户端 IP 变成 Cloudflare IP

这是接入 Cloudflare 后最常见的问题。

未接入时，Nginx 或应用程序获取的客户端 IP 是用户真实 IP。接入后，源站看到的是 Cloudflare 节点 IP。例如日志中可能出现：

172.68.23.10
104.21.88.123
188.114.96.3

这些并不是用户真实 IP，而是 Cloudflare 的代理 IP。

Cloudflare 会通过 HTTP 请求头传递真实 IP，常见字段包括：

CF-Connecting-IP
X-Forwarded-For
True-Client-IP

其中免费版常用的是：

CF-Connecting-IP

因此服务器需要正确配置，否则会影响：

• 用户 IP 统计；
• 登录风控；
• 限流策略；
• 日志分析；
• 评论 IP 记录；
• 后台安全审计；
• 地区识别；
• 反作弊判断。

2. 缓存可能导致内容更新不及时

Cloudflare 会缓存静态资源。如果缓存规则设置不当，可能出现：

• CSS 更新后用户仍然看到旧样式；
• JS 文件更新后功能异常；
• 图片替换后仍显示旧图；
• API 被错误缓存；
• 用户登录页面缓存导致安全问题；
• 后台页面被缓存。

因此动态接口、登录页面、后台管理、用户中心等页面通常不应该被缓存。

推荐策略：

静态资源：缓存
API 接口：不缓存
后台路径：不缓存
HTML 页面：根据业务决定

常见路径示例：

/wp-admin/*
/admin/*
/api/*
/user/*
/login
/logout

3. 可能引入额外排查复杂度

接入 Cloudflare 后，当网站访问异常时，问题可能来自多个位置：

用户网络
Cloudflare 节点
Cloudflare 配置
DNS 配置
SSL 配置
缓存规则
防火墙规则
源站服务器
应用程序
数据库

例如常见错误：

这些错误不一定代表 Cloudflare 出问题，很多时候是源站防火墙、Nginx、证书、端口、安全组或程序响应太慢导致的。

4. 源站防火墙必须正确配置

如果服务器只允许 Cloudflare 回源访问，需要定期更新 Cloudflare IP 段。因为 Cloudflare 的节点 IP 可能调整。

Cloudflare 官方 IP 地址列表：

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

如果防火墙配置不完整，就可能导致部分地区用户访问失败。

5. WebSocket、上传、大文件下载需要额外注意

Cloudflare 支持 WebSocket，但某些功能和套餐会存在限制。对于大文件上传、视频流、长连接接口，也需要考虑 Cloudflare 的超时机制和大小限制。

例如：

• 请求处理时间太长，可能触发 524；
• 上传文件太大，可能受套餐限制；
• 长轮询接口可能不稳定；
• 实时通信需要确认 WebSocket 配置；
• 大文件下载可能不适合走 Cloudflare 免费版缓存。

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

1. Nginx 获取真实客户端 IP

如果使用 Nginx，需要配置 real_ip_header，让 Nginx 从 CF-Connecting-IP 获取真实用户 IP。

示例配置如下。

# /etc/nginx/conf.d/cloudflare-real-ip.conf

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

# Cloudflare IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

然后测试并重载 Nginx：

nginx -t
systemctl reload nginx

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

2. Nginx 日志格式示例

为了方便排查问题，可以记录 Cloudflare 相关请求头。

log_format cloudflare_log
    '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent" '
    'xff="$http_x_forwarded_for" '
    'cfip="$http_cf_connecting_ip" '
    'ray="$http_cf_ray" '
    'country="$http_cf_ipcountry"';

access_log /var/log/nginx/access.log cloudflare_log;

其中：

• CF-Connecting-IP：用户真实 IP；
• CF-Ray：Cloudflare 请求 ID，可用于排查；
• CF-IPCountry：Cloudflare 判断的访问国家或地区；
• X-Forwarded-For：代理链路 IP。

五、Node.js 获取真实 IP 源码

如果你的后端使用 Node.js + Express，可以通过以下方式获取用户真实 IP。

1. 基础版源码

const express = require('express');

const app = express();

function getClientIp(req) {
  const cfIp = req.headers['cf-connecting-ip'];
  const xForwardedFor = req.headers['x-forwarded-for'];

  if (cfIp) {
    return cfIp;
  }

  if (xForwardedFor) {
    return xForwardedFor.split(',')[0].trim();
  }

  return req.socket.remoteAddress;
}

app.get('/', (req, res) => {
  const ip = getClientIp(req);

  res.json({
    message: 'Hello Cloudflare',
    ip,
    headers: {
      cfConnectingIp: req.headers['cf-connecting-ip'],
      xForwardedFor: req.headers['x-forwarded-for'],
      cfRay: req.headers['cf-ray'],
      cfCountry: req.headers['cf-ipcountry']
    }
  });
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

2. 更安全的写法

需要注意的是，请求头可以被伪造。如果你的源站允许用户绕过 Cloudflare 直接访问，那么攻击者可以自己构造 CF-Connecting-IP 请求头。

因此，更安全的做法是：

1. 防火墙只允许 Cloudflare IP 访问源站；
2. 应用层只在请求来源是可信代理时，才信任 CF-Connecting-IP；
3. 不要直接暴露源站 IP。

以下是一个简单示例：

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

const app = express();

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 normalizeIp(ip) {
  if (!ip) return '';

  if (ip.startsWith('::ffff:')) {
    return ip.replace('::ffff:', '');
  }

  return ip;
}

function getClientIp(req) {
  const remoteIp = normalizeIp(req.socket.remoteAddress);

  if (isCloudflareIp(remoteIp) && req.headers['cf-connecting-ip']) {
    return req.headers['cf-connecting-ip'];
  }

  return remoteIp;
}

app.get('/ip', (req, res) => {
  const ip = getClientIp(req);

  res.json({
    ip,
    remoteAddress: req.socket.remoteAddress,
    cfConnectingIp: req.headers['cf-connecting-ip'] || null,
    trustedCloudflareProxy: isCloudflareIp(normalizeIp(req.socket.remoteAddress))
  });
});

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

安装依赖：

npm install express ipaddr.js

六、自动更新 Cloudflare IP 的 Shell 源码

如果你使用 Linux 服务器，并希望自动更新 Nginx 的 Cloudflare 真实 IP 配置，可以使用下面的脚本。

#!/bin/bash

set -e

CONF_PATH="/etc/nginx/conf.d/cloudflare-real-ip.conf"
TMP_PATH="/tmp/cloudflare-real-ip.conf"

echo "# Auto generated Cloudflare real IP config" > "$TMP_PATH"
echo "# Updated at: $(date '+%Y-%m-%d %H:%M:%S')" >> "$TMP_PATH"
echo "" >> "$TMP_PATH"

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

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

echo "" >> "$TMP_PATH"
echo "real_ip_header CF-Connecting-IP;" >> "$TMP_PATH"
echo "real_ip_recursive on;" >> "$TMP_PATH"

cp "$TMP_PATH" "$CONF_PATH"

nginx -t

systemctl reload nginx

echo "Cloudflare real IP config updated successfully."

保存为：

/usr/local/bin/update-cloudflare-real-ip.sh

赋予执行权限：

chmod +x /usr/local/bin/update-cloudflare-real-ip.sh

手动执行：

/usr/local/bin/update-cloudflare-real-ip.sh

添加定时任务：

crontab -e

加入：

0 3 * * 1 /usr/local/bin/update-cloudflare-real-ip.sh >/var/log/update-cloudflare-real-ip.log 2>&1

表示每周一凌晨 3 点自动更新一次。

七、使用 Cloudflare API 清理缓存源码

当网站发布新版本后，可能需要清理 Cloudflare 缓存。可以使用 Cloudflare API 实现自动化部署后清缓存。

1. 清理全部缓存

#!/bin/bash

CF_API_TOKEN="你的Cloudflare_API_Token"
CF_ZONE_ID="你的Zone_ID"

curl -X POST "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

2. 清理指定文件缓存

#!/bin/bash

CF_API_TOKEN="你的Cloudflare_API_Token"
CF_ZONE_ID="你的Zone_ID"

curl -X POST "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "files": [
      "https://example.com/static/app.css",
      "https://example.com/static/app.js",
      "https://example.com/logo.png"
    ]
  }'

实际项目中更推荐清理指定文件，而不是每次都清空全部缓存。因为清空全部缓存会导致大量请求重新回源，短时间内增加服务器压力。

八、Cloudflare 下的缓存规则建议

一个比较通用的缓存策略如下：

示例规则：

example.com/static/*
Cache Everything
Edge TTL: 1 month

example.com/api/*
Bypass Cache

example.com/admin/*
Bypass Cache

example.com/login*
Bypass Cache

对于前端项目，建议静态文件使用带 hash 的文件名，例如：

app.8f3a1c2.js
style.91deacf.css

这样可以安全设置长缓存。每次发布新版本时，文件名变化，用户自然会请求新文件。

九、源站服务器防护建议

接入 Cloudflare 后，不要以为服务器就绝对安全。推荐同时做好以下配置。

1. 只开放必要端口

常见端口：

80
443
22

如果 SSH 不需要公网访问，最好限制来源 IP，或者使用 VPN、堡垒机。

2. 限制 80/443 只允许 Cloudflare 访问

使用 ufw 示例：

ufw default deny incoming
ufw default allow outgoing

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

# 其他 Cloudflare IP 段也需要加入

ufw allow from 你的管理IP to any port 22

ufw enable

生产环境建议使用脚本自动拉取 Cloudflare IP 列表生成规则，避免手动维护遗漏。

3. 避免源站 IP 泄露

常见泄露方式包括：

• 历史 DNS 解析记录；
• 邮件服务器暴露同 IP；
• 子域名未接入 Cloudflare；
• 服务器主动请求第三方服务时暴露 IP；
• Git 仓库中提交了源站 IP；
• 旧域名仍然解析到源站；
• SSL 证书透明日志暴露其他域名；
• 直接访问 IP 能看到站点内容。

建议源站服务器直接访问 IP 时返回默认页面或拒绝访问。

Nginx 示例：

server {
    listen 80 default_server;
    listen 443 ssl default_server;

    server_name _;

    ssl_certificate /etc/nginx/ssl/default.crt;
    ssl_certificate_key /etc/nginx/ssl/default.key;

    return 444;
}

十、Cloudflare 常见问题排查

1. 出现 521 错误

可能原因：

• 源站 Nginx 没启动；
• 防火墙拒绝了 Cloudflare；
• 服务器端口未开放；
• 源站进程崩溃；
• 安全组配置错误。

排查命令：

systemctl status nginx
ss -lntp
curl -I http://127.0.0.1

2. 出现 522 错误

可能原因：

• 源站网络不通；
• 防火墙丢弃连接；
• 服务器负载过高；
• TCP 连接建立超时；
• 云服务商安全组限制。

排查命令：

ping 源站IP
traceroute 源站IP
top
free -m
journalctl -u nginx -n 100

3. 出现 524 错误

524 通常说明 Cloudflare 已经连上源站，但源站响应太慢。

常见原因：

• PHP、Node.js、Java 程序执行时间过长；
• 数据库慢查询；
• 大文件生成；
• 后台任务放在 HTTP 请求中执行；
• 接口没有超时控制。

优化建议：

• 长任务改成队列异步执行；
• 接口增加分页；
• 优化 SQL；
• 增加缓存；
• 使用对象存储处理大文件；
• 避免请求一直阻塞。

十一、接入 Cloudflare 的最佳实践总结

接入 Cloudflare 后，对服务器的影响可以总结为一句话：

Cloudflare 会让服务器从“直接面对用户”变成“面对 Cloudflare 代理节点”，从而改变访问来源、缓存行为、安全边界和故障排查方式。

推荐最佳实践如下：

1. SSL 使用 Full Strict 模式，源站也配置有效证书；
2. Nginx 配置真实 IP，否则日志和风控会失准；
3. 只允许 Cloudflare IP 回源，避免源站被直接攻击；
4. 动态接口和后台不要缓存，防止业务异常；
5. 静态资源使用 hash 文件名，配合长缓存；
6. 部署后按需清理缓存，不要频繁全量清理；
7. 监控源站负载和 Cloudflare 错误码；
8. 记录 CF-Ray 请求头，方便定位问题；
9. 隐藏源站 IP，避免绕过 Cloudflare；
10. 定期更新 Cloudflare IP 段，防止节点访问被误拦截。

结语

Cloudflare 对服务器既有积极影响，也有需要注意的副作用。它可以显著降低源站压力、提升全球访问速度、增强网站安全性，并帮助网站抵御大量恶意流量。但与此同时，它也改变了服务器获取用户 IP 的方式，引入了缓存一致性问题，并增加了故障排查链路。

对于个人博客、中小企业官网、SaaS 服务、跨境业务网站来说，Cloudflare 是非常实用的基础设施。但要真正用好它，不能只停留在“把 DNS 云朵点亮”这一步，还需要配合服务器端的 Nginx、应用程序、防火墙、缓存规则和部署流程进行完整配置。

只要按照本文中的配置和源码进行实践，就可以在享受 Cloudflare 加速与防护能力的同时，尽量减少它对服务器带来的负面影响。