如何在 Netcup 上配置 Cloudflare（Full Strict 严格 SSL、真实访客 IP 还原与源站 mTLS 防火墙锁定）

如果您的域名注册在 Netcup 旗下（包括 Netcup Webhosting 虚拟主机套餐附带的 .de 包含域名），请先登录 Netcup 客户控制面板（customercontrolpanel.de，简称 CCP）→ Domains → 选择对应域名 → Name Server（域名服务器），将模式切换为 Own name servers（自定义域名服务器），并填入 Cloudflare 为您分配的两个权威 NS 地址（例如 ada.ns.cloudflare.com 与 bob.ns.cloudflare.com）。由于 Netcup 的 AS197540 核心骨干路由器在德国法兰克福 DE-CIX 与奥地利维也纳 VIX 交换中心同 Cloudflare 建立了高带宽直连对等互联（Peering），Cloudflare 欧洲边缘节点回源至 Netcup 纽伦堡与维也纳机房的 RTT 延迟通常低于 2 毫秒。

重要 DNSSEC 安全提示：如果您的域名此前在 Netcup 默认 DNS（root-dns.netcup.net）上开启过 DNSSEC 签名，在修改 Nameserver 之前，请务必先在 CCP 面板中关闭 DNSSEC 并等待约 15 至 30 分钟让注册局（如 .de 域名的管理机构 DENIC）移除旧的 DS 委派签名记录。如果在旧 DS 记录尚未从顶级域注册局清除时就直接把 NS 切往 Cloudflare，全球启用了 DNSSEC 严格校验的公共递归解析器（如 1.1.1.1 与 8.8.8.8）会判定签名链断裂并对您的域名直接返回 SERVFAIL 错误。待域名在 Cloudflare 正式激活后，再从 Cloudflare 后台重新开启 DNSSEC 并将新生成的 DS 参数填回 CCP 面板即可。

在 Cloudflare DNS 面板中添加源站记录时，建议同时为您网站的根域名（@）和 www 子域名添加指向 Netcup 服务器 IPv4 地址的 A 记录以及指向 Netcup /64 子网主地址的 AAAA 记录，并将两者的代理状态均设为 已代理（Proxied / 橙色云朵）。Cloudflare 边缘节点具备天然的 IPv4/IPv6 双栈协议转换能力：无论终端访客使用的是纯 IPv6 移动网络还是传统 IPv4 宽带，Cloudflare 都能在边缘就近终结连接并通过最优路径回源。

最后，请妥善隔离非 Web 协议的解析记录。Cloudflare 默认的橙色云朵反向代理仅转发标准 HTTP/HTTPS Web 端口（如 80、443、8443、2053 等），不会转发 TCP 22（SSH）、465/587（SMTP）或 5432（PostgreSQL）端口的原始流量。如果您习惯通过域名连接 SSH，请按照下方清单单独创建一条关闭代理（灰色云朵）的子域名记录：

• ▪ IPv4 主记录：类型选择 A，名称填 @（以及 www），内容填您的 Netcup IPv4 /32 公网地址（如 203.0.113.10），代理状态开启 已代理（Proxied / 橙色云朵）。
• ▪ IPv6 主记录：类型选择 AAAA，名称填 @（以及 www），内容填您 Netcup /64 子网中的主 IPv6 地址（如 2a03:4000:60:1234::1），代理状态同样开启 已代理（Proxied / 橙色云朵）。
• ▪ SSH 管理连接专用避让规则：由于 Cloudflare 免费版的橙色云朵 HTTP 代理默认仅转发 80/443 等 Web 端口而不转发 22 端口的 SSH 流量，日常连接 SSH 请直接使用服务器的原始 IPv4/IPv6 地址，或者单独添加一条关闭代理（仅限 DNS / 灰色云朵）的 ssh.example.com 子域名记录。

进入 Cloudflare 仪表盘的 SSL/TLS → 概述（Overview），将加密模式强制锁定为 完全（严格）— Full (Strict)。切勿将生产站点留在 Flexible（灵活） 模式：在 Flexible 模式下，虽然访客浏览器到 Cloudflare 边缘节点之间显示为 HTTPS 绿锁，但 Cloudflare 边缘节点到您德国/奥地利 Netcup 服务器之间的跨国回源链路却是通过 80 端口以明文 HTTP 裸奔传输的！更糟糕的是，Flexible 模式始终向源站发送 X-Forwarded-Proto: http，一旦您的源站 Nginx 或 WordPress 开启了强制 HTTPS 跳转，就会立刻陷入无限 301 Moved Permanently 重定向死循环（ERR_TOO_MANY_REDIRECTS）。

在 Full (Strict) 模式下，Cloudflare 边缘节点不仅会使用 TLS 1.3 加密回源连接，还会严格校验您 Netcup 服务器 443 端口出示的 SSL 证书是否由受信任的公共 CA（如 Let’s Encrypt）签发、是否在有效期内且 SAN 域名完全匹配。如果您的网站流量 100% 经过 Cloudflare 代理，您还可以在 SSL/TLS → 源服务器（Origin Server）→ 创建证书 中免费生成一张长达 15 年有效期的 Cloudflare Origin CA 源站专用证书部署在 Nginx 上，从而省去每 90 天续期一次 ACME 证书的维护工作。

然而，仅仅配置单向 TLS 证书还不足以保护源站隐身。由于全网 IPv4 地址空间有限，像 Censys 与 Shodan 这样的安全测绘引擎每天都在全网扫描 443 端口的 TLS 证书，一旦扫描器发现您的 Netcup IP 返回了包含 example.com 域名的服务端证书，您的真实源站 IP 就会被公开记录在案。攻击者随后只需构造 curl --resolve example.com:443:203.0.113.10 请求，即可绕过 Cloudflare WAF 防火墙直接向您的 Netcup 服务器发起 CC 攻击或漏洞注入。

为了从密码学层面封堵直接扫 IP 绕过 WAF 的路径，我们强烈建议在 Nginx 中启用 Authenticated Origin Pulls（经过身份验证的源站拉取，即双向 mTLS 认证）。启用 ssl_verify_client on; 并加载 Cloudflare 官方客户端根证书（authenticated_origin_pull_ca.pem）后，任何未在 TLS 握手阶段出示合法 Cloudflare 边缘节点客户端证书的直接 IP 请求都会被 Nginx 在内核态/SSL 层直接拒绝。同时，建议在 Cloudflare 后台开启 Smart Tiered Cache（智能分层缓存），让全球边缘节点统一通过邻近法兰克福或维也纳的上层核心节点（Upper-Tier PoP）回源，将源站回源请求量再降低 60% 以上：

# 下载 Cloudflare 官方维护的 Authenticated Origin Pull 客户端根 CA 证书
sudo mkdir -p /etc/nginx/certs
sudo curl -fsSL https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem \
  -o /etc/nginx/certs/cloudflare-origin-pull-ca.pem

# 在您的 /etc/nginx/sites-available/example.com.conf 配置文件的 server { listen 443 ssl; ... } 块中加入：
# ssl_client_certificate /etc/nginx/certs/cloudflare-origin-pull-ca.pem;
# ssl_verify_client on;

sudo nginx -t && sudo systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

当流量经过 Cloudflare 橙色云朵代理后，由于 Cloudflare 在三层/四层充当了反向代理，到达您 Netcup 网卡的每一个 TCP 数据包的源 IP 地址都会变成 Cloudflare 边缘节点的 IP（如 172.64.0.0/13、104.16.0.0/12 或 2606:4700::/32）。在默认配置下，Nginx 的内置变量 $remote_addr 直接取自 TCP 套接字的对端地址，这会导致您的 /var/log/nginx/access.log 访问日志里记录的全是 Cloudflare 法兰克福或维也纳节点的 IP。

如果不修正这一行为，一旦您在服务器上启用了 Nginx limit_req_zone $binary_remote_addr 速率限制或 Fail2ban 日志监控监狱，就会引发严重的生产事故：只要有一名恶意攻击者触发了登录限流或密码爆破阈值，Nginx 或 UFW 就会把当前回源的 Cloudflare 边缘节点 IP 当作攻击源直接封禁——瞬间导致成千上万经过同一个 Cloudflare 机房节点访问您网站的正常用户全部出现 522 Connection Timed Out 断网！

切勿通过在后端 PHP 或 Node.js 代码中直接无条件信任 $_SERVER['HTTP_CF_CONNECTING_IP'] 或 X-Forwarded-For 请求头来解决此问题，因为任何绕过 CDN 直连源站的攻击者都可以轻易通过 curl -H "CF-Connecting-IP: 1.2.3.4" 伪造任意 IP。正确的做法是利用 Nginx 原生编译的 ngx_http_realip_module 模块：通过 set_real_ip_from 显式列出 Cloudflare 官方公布的所有 IPv4 与 IPv6 网段，并配合 real_ip_header CF-Connecting-IP;，指示 Nginx 仅在底层 TCP 连接确实来自受信任的 Cloudflare 边缘网段时，才将 $remote_addr 与 $binary_remote_addr 覆写为 CF-Connecting-IP 头中的真实客户端地址。

下方自动化脚本中配置的 real_ip_recursive on; 参数在处理多级代理链路时尤为关键：当请求依次经过 Cloudflare 边缘节点与您宿主机内部的网关容器时，开启递归解析会让 Nginx 从右向左依次剥离所有位于 set_real_ip_from 授信列表中的代理服务器地址，最终精准提取出最左侧第一个非授信代理的真实客户端公网 IP。请在服务器上部署并运行该脚本：

cat << 'EOF' | sudo tee /usr/local/sbin/update-cloudflare-realip.sh
#!/usr/bin/env bash
set -euo pipefail

CONF_FILE="/etc/nginx/conf.d/cloudflare-realip.conf"
TMP_FILE="$(mktemp)"

echo "# 自动生成的 Cloudflare RealIP 授信网段配置 ($(date -u +%Y-%m-%dT%H:%M:%SZ))" > "${TMP_FILE}"

for ip in $(curl -fsSL https://www.cloudflare.com/ips-v4); do
  echo "set_real_ip_from ${ip};" >> "${TMP_FILE}"
done

for ip6 in $(curl -fsSL https://www.cloudflare.com/ips-v6); do
  echo "set_real_ip_from ${ip6};" >> "${TMP_FILE}"
done

echo "real_ip_header CF-Connecting-IP;" >> "${TMP_FILE}"
echo "real_ip_recursive on;" >> "${TMP_FILE}"

mv "${TMP_FILE}" "${CONF_FILE}"
chmod 0644 "${CONF_FILE}"
nginx -t && systemctl reload nginx
EOF

sudo chmod +x /usr/local/sbin/update-cloudflare-realip.sh
sudo /usr/local/sbin/update-cloudflare-realip.sh

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful