如何将网站连接到 Cloudflare

如何将网站连接到 Cloudflare

Cloudflare 可以以两种非常不同的方式位于网站前面。您可以将整个域名迁移到 Cloudflare 的 DNS 和代理，或者您可以保持狭窄的设置并一次只启用一个功能。这个选择会改变步骤、风险和回滚计划。

从这里开始。一个有几页的营销网站与一个邮件繁重的公司域名有不同的需求，而一个已经支持企业网站的域名需要比全新启动的域名更仔细的记录处理。如果您还在考虑网站安全，Cloudflare 通常会因这个原因首先进入讨论。

1. 决定您是否需要完全的 DNS 控制或仅需要一个 Cloudflare 功能

Cloudflare 不是一个单一的开关。它可以管理 DNS、代理网络流量、缓存内容、过滤请求，并在访客和您的源服务器之间进行中介。如果您只想要一个功能，例如 DNS 管理或安全层，您仍然应该理解域名的名称服务器通常是 Cloudflare 接管控制的地方。

对于一个简单的宣传网站，完全控制通常是可以的。对于一个包含邮件路由、验证服务和多个子域的设置，决策就更加明确。例如，私有网络基础设施可能需要某些主机名保持在代理路径之外，而网页可以毫无问题地通过 Cloudflare。

问一个实际的问题：第一天必须保持工作的是什么？如果答案包括电子邮件、API 回调或支付流程，那么您不仅仅是在“将网站连接到 Cloudflare”；您正在改变域名的解析方式。这个区别很重要。

一个简单的规则是：不要猜测。如果网站依赖于任何外部服务，请在触碰名称服务器之前列出它。这个列表将成为您的安全网。

2. 在更改名称服务器之前审计您当前的域设置

在您移动任何内容之前，请检查当前 DNS 的管理位置。注册商和 DNS 主机并不总是同一家公司，这种不匹配会导致可避免的错误。查找当前的名称服务器，然后检查那里存在的区域记录。

您需要全面了解：网站的 A 和 AAAA 记录、子域的 CNAME 记录、邮件的 MX 记录、验证的 TXT 记录，以及任何第三方工具使用的特殊记录。缺少 TXT 记录可能会破坏登录流程。错误的 MX 记录可能会停止邮件。

不要依赖记忆。一个已经上线多年的域名可能包含由不同的人在不同时间添加的记录，其中一些可能不再在其他地方有文档。如果网站所有者无法解释某个记录，那就是一个保留它的理由，直到你知道它的作用。

这也是列出重定向和旧主机名的时刻。如果流量仍然到达旧子域名，请现在记录下来。一个在源头有效的重定向，如果主机名没有被复制到Cloudflare，可能会在后期失效。

在注册商账户外保留一份当前区域的副本。一个纯文本文件就足够了。电子表格也可以。关键是恢复。

3. 创建 Cloudflare 网站并导入现有的 DNS 记录

审核后，将域名添加到Cloudflare。Cloudflare将扫描现有的DNS记录并尝试将它们导入其区域。该扫描节省时间，但并不能保证所有内容都干净地转移过来。

逐行审核导入的记录。可能会缺少某个记录，子域名可能会重复，或者某个值可能已经过时。第一次检查关注准确性，而不是速度。如果你看到一个应该指向你的网络服务器的主机名，但现在指向其他地方，请在你接触注册商之前修复它。

两个小检查可以捕捉到许多错误。首先，将导入的记录与您的审核列表进行比较。其次，确认顶级域和常见的“www”主机名都解析到正确的位置。这些是用户首先会遇到的记录。

如果您管理一个表现得像一个 企业网站, 密切关注子域名。一个支持门户、一个预发布主机名和一个文件主机通常与主站点并排存在，缺少一个记录就可能导致难以诊断的故障。

一个实用的附注：Cloudflare 的导入很有帮助，但这并不是跳过您自己审查的借口。扫描是一个起点。您的审核是最终检查。

4. 选择哪些记录应保持代理状态，哪些应保持仅 DNS

Cloudflare 为您提供了许多记录的选择。橙色云表示流量通过 Cloudflare 的代理。灰色云表示仅 DNS。这个选择并不是外观上的，它改变了请求的传输方式。

公共网站的网络流量通常是通过代理的。邮件记录不是。验证记录也不是。一些提供 API 或专用工具的子域名也应该保持仅 DNS，除非您仔细测试了完整路径。如果您想要一个快速的规则，可以代理网站，保持非网络服务不变，除非您有理由更改它们。

一个常见的错误是因为看起来整洁而代理所有内容。但它不会保持整洁太久。代理后的 MX 记录将失败。验证主机名可能会停止被其他服务识别。文件传输端点可能会表现得很奇怪，因为它从未打算通过网络代理传输。

从功能的角度考虑，而不是外观。网站可以为了性能和安全性而被代理。邮件通常应该保持仅 DNS。如果您的设置包括跟踪像素、Webhook 端点或第三方验证主机，请分别测试每一个。

必须保持纯 DNS 的流量通常是您最不希望中断的流量。在您点击橙色云太多次之前，请记住这句话。

5. 在您的注册商处更新域名的名称服务器

Cloudflare 将为该域分配两个名称服务器。您需要用这两个值替换注册商处的当前名称服务器。这是将 DNS 权限交给 Cloudflare 的步骤，因此请准确复制它们。

在注册商处，找到名称服务器部分并删除旧的配对。然后输入Cloudflare分配的配对。保存更改。

如果网站没有立即切换，不要惊慌。DNS更改并不是在同一个时钟上同步的。访客可能仍会在一段时间内访问旧路径，这很正常。如果旧的DNS主机在过渡期间仍然在线，您可以减少查找失败的风险。

这里有一句简短的话：要准确。名称服务器条目中的单个字符错误可能会导致委托无法正常工作。

此外，不要同时更改多个活动部分。如果您在一次操作中重命名记录、切换主机和编辑名称服务器，您会使故障排除变得比需要的更困难。

6. 确认域名在 Cloudflare 中处于活动状态并测试真实流量路径

在名称服务器更改后，Cloudflare应该显示该域为活动状态。如果没有，问题通常是以下三种情况之一：注册商更改未保存、名称服务器输入不正确，或者注册商仍然有缓存数据。在责怪源服务器之前，请检查这些。

然后测试真实路径，而不仅仅是主页。打开主域名、“www”版本、一个关键子页面和任何重要的子域名。如果网站有登录页面，也要测试一下。如果有文件下载或表单提交，也要测试这些操作。页面可以加载，而隐藏的端点可能是坏的。

这就是监控工具派上用场的地方。如果您使用网站分析和监控平台，请将切换后的第一次实时请求与正常模式进行比较。一个主机名上错误的突然增加通常是DNS记录或代理设置需要关注的第一个迹象。

使用第二个浏览器或私密窗口进行干净的测试。缓存数据可能隐藏问题。旧的登录会话也可能如此。

如果出现故障，请从域向外测试路径：DNS、边缘响应、源响应，然后是应用逻辑。这个顺序可以节省时间。

7. 为新连接设置第一个安全的 Cloudflare 选项

一旦域名激活，保持初始设置保守。选择与您的源实际支持的SSL/TLS模式相匹配的选项，不要猜测。如果源证书尚未准备好，浏览器可能会显示错误，或者Cloudflare可能会拒绝连接。这在上线当天是一个糟糕的意外。

基本安全设置应该是下一步。如果您已经关心网站安全，这就是Cloudflare开始在DNS之外提供帮助的地方。从明显的控制开始，然后再次测试网站。激进的调整可以等到您知道基线行为正确后再进行。

缓存行为也值得仔细关注。经常更改的页面不应与几乎不变的页面以相同方式对待。如果您不确定，首先保持默认行为，观察网站的响应，然后一次进行一个更改。

一个有用的习惯是将“现在安全”与“以后好”分开。现在安全包括正确获取SSL路径并确认网站仍然可以打开。以后好的包括在您有日志可读时调整缓存头或收紧规则。这个顺序可以防止自我造成的停机。

保持这个阶段小规模。小的更改更容易撤销。

8. 验证边缘案例：电子邮件、子域、重定向和混合内容问题

这是许多网站出错的地方。电子邮件通常依赖于应保持仅为DNS的DNS记录。验证MX记录仍然指向正确的邮件主机，并且SPF、DKIM或DMARC TXT记录被保留。如果邮件停止，网站可能看起来正常，而商业信息却消失了。

子域名值得拥有自己的检查清单。一个暂存主机名、一个图像主机和一个上传端点可能需要不同的处理。如果其中一个错误地被代理，您可能只会在那个单一主机名上看到奇怪的行为。这种类型的错误浪费时间，因为主页正常工作。

重定向也可能暴露错误。如果旧网站将访问者从一个主机名发送到另一个主机名，请在切换后再次测试该路径。曾经有效的重定向链现在可能指向一个从未添加到 Cloudflare 的主机名。单个缺失的记录可能会破坏整个路径。

混合内容问题出现在网站通过 HTTP 加载某些资源，而页面本身通过 HTTPS 提供时。浏览器不喜欢这种组合。图像可能会消失，脚本可能会失败，表单可能会停止提交。在应用程序级别修复源 URL，而不仅仅是在浏览器中。

如果您的域名支持一个 网站上线后的支持 工作流，请保持一份最脆弱主机的简短列表：邮件、暂存、上传、重定向和第三方验证。这五个领域通常是第一个工单出现的地方。

最后一个实用检查：尝试从您通常不使用的网络访问该网站。移动连接可能会暴露出缓存问题或您的办公室网络隐藏的 DNS 延迟。不同的路径揭示不同的问题。

如果您正在连接一个已经有严格操作要求的网站，请记录您所接触的每个 DNS 记录。不是以后，而是现在。