Cloudflare 自定义主机名深度实战：从配置到排错全指南

前言

Cloudflare for SaaS (自定义主机名) 是一项强大的功能，它允许我们为客户的域名提供 SSL 和 CDN 服务，而无需将客户的域名 NS 托管到 Cloudflare。这个也是我们经常薅CF大善人的地方，尤其是现在可以针对于不同的自定义主机名采用不一样的源站了，这样就可以一个域名可以作为多个服务器的特定源站来使用。

但在实际使用中，其两种不同的源站配置模式——默认源站 和 自定义源站——常常是混淆和错误的根源。这个周末的下午踩了一下午的坑，总算搞定了。

我这边的情况是，用docker部署了服务，然后用 Nginx Proxy Manager 做反代，使用的是Let's Encrypt的证书，该证书通过域名解析获取，也就是哪怕我解析走也不怕它证书失效。现在想使用大善人的 Cloudflare for SaaS 来加速访问，但是又不想把域名NS服务器改过来，当然机制的小朋友肯定就知道了这还有啥玩法了。现实的情况是我用来做自定义主机名的域名源站已经配置了一个了，想着它反正现在支持自定义源站了就懒得再搞一个域名了。于是来测试使用，之前就用过所以过程很简单，但是后面一致提示出错，先是521，后面又是SSL handshake failed Error code 525。当然最终通过跟AI对话解决了问题，所以才又这篇水文。

本文旨在彻底厘清这两种模式的区别，并提供一套清晰的排错逻辑和解决方案，特别是针对最常见的 521 和 525 错误，以下核心内容来源于AI。

一、 两种核心模式：理解其工作原理是成功的一半

选择哪种模式，决定了你的网络架构和后续的维护方式。理解它们的本质区别至关重要。

1. 默认源站

• 工作模式：所有添加的自定义主机名（如 customer-a.com, customer-b.com）的流量，统一回源到同一个地址。这个地址在自定义主机名页面的顶部设置，我们称之为“回退源”。
• 请求流程：
  

• 核心特点：

  • 简单统一：配置简单，适合所有客户共享同一源站内容的场景。
  • 源站无证书要求：Cloudflare 到源站的连接是 HTTP，因此你的源站服务器不需要为 customer-b.com 等域名配置 SSL 证书。只需要为回退源（如 origin.saas.com）配置好 DNS 解析即可。

2. 自定义源站

• 工作模式：可以为每一个自定义主机名单独指定一个回源地址。
• 请求流程：
  

• 核心特点：

  • 灵活隔离：适合多租户环境，每个客户对应独立的服务器，或需要将不同子域名代理到不同后端服务的场景。
  • 源站必须有证书：Cloudflare 到源站的连接是 HTTPS。因此，你的源站服务器必须为你指定的自定义源地址（如 origin-b.saas.com）配置一个有效的 SSL 证书。

二、 核心踩坑实录：从 521 到 525 的排错之路

错误代码是 Cloudflare 给我们的最直接线索。我们的排错过程，就是一次从 521 到 525 的经典“破案”。

踩坑点 1：遭遇 Error 521: Web server is down

• 错误含义：Cloudflare 无法建立 TCP 连接到你的源站。

• 排错逻辑：这是一个网络层或服务器基础配置问题。从外到内，逐层排查。

  1. 源站服务是否存活？ -> curl 本地测试，确认 Web 服务正常运行。
  2. Cloudflare 能否访问到源站 IP 和端口？ -> 检查防火墙！ 这是最常见的原因。必须在源站服务器防火墙和云厂商安全组中，放行 Cloudflare 的所有 IP 范围对 80/443 端口的访问。
  3. 源站是否在正确监听？ -> netstat -tlnp 检查 80/443 端口是否由 Nginx (或 NPM) 进程监听，而不是被其他服务占用。
  4. Cloudflare 是否连接到正确的端口？ -> 确认 Cloudflare 只代理 80/443 端口。

踩坑点 2：解决 521 后，遭遇 Error 525: SSL handshake failed

• 错误含义：TCP 连接已建立，但在 SSL/TLS 握手阶段失败。这几乎只在使用“自定义源站”时出现。

• 排错逻辑：这是一个加密层配置问题。问题的核心在于 Cloudflare 不信任你的源站证书。

  1. 第一反应：检查 Cloudflare SSL/TLS 模式。

     • 临时测试：将模式从 “完全（严格）” 暂时降级为 “完全”。如果网站恢复，100% 是证书问题。
     • 根本原因：“完全（严格）”要求源站证书必须由公共信任的 CA 签发，且证书链完整。

  2. 第二反应：检查源站证书。

     • 证书是否存在？ -> 确认你的源站（如 NPM）确实为自定义源地址（如 origin-b.saas.com）申请了证书。
     • 证书是否有效？ -> 检查证书是否过期、域名是否匹配。

  3. 最终元凶：证书链不完整。

     • 问题：源站只提供了服务器证书，缺少了中间证书，导致 Cloudflare 无法验证其可信性。这是 Let's Encrypt 证书配置中最常见的坑。
     • 解决方案：在 NPM 中，为 origin-b.saas.com 重新申请 Let's Encrypt 证书，确保 NPM 自动配置了完整的证书链。

这里最终我的解决方案是在 Nginx Proxy Manager 使用子域名 origin-b.saas.com 创建了一个全新的站点，直接反代本地80端口，也就是毫无意义的内容。它不是要证书吗，于是我也懒得重新额外申请证书了，直接使用了大善人自己的源服务器证书，将其导入到NPM里就可以了。

三、 关键决策点与备忘清单

为了避免重蹈覆辙，请在配置时参考以下清单：

四、 总结

Cloudflare 自定义主机名功能极其强大，但它的灵活性也带来了配置的复杂性。

1. 模式选择是第一步：根据你的业务需求，清晰地在“默认源站”和“自定义源站”之间做出选择。这是所有后续配置的基础。
2. 错误代码是最佳向导：遇到问题时，不要慌张。5xx 错误代码是定位问题的金钥匙。521 看网络，525 看证书，这个逻辑屡试不爽。
3. 防火墙和证书是两大天坑：无数次的排错经验都指向这两个地方。在配置初期就妥善处理，能避免后续 90% 的麻烦。
4. 理解原理，而非死记硬背：理解了两种模式下数据流的差异，你就能从根本上理解为什么需要（或不需要）源站证书，为什么会出现 525 错误。