您好，我一直在与其他几个人合作，将我们旧的 vbulletin3 迁移到 discourse。现在是时候开始考虑迁移的其他方面了，其中之一就是我们有一个提供论坛服务的 Cloudflare 账户。
如果可能的话，我们希望保留它，因为我们的论坛有很多潜水用户（以及大约 1000 名活跃用户）。
我在这里找到的唯一一个有点信息的帖子是 2015 年的，所以我问是否有我可能错过的“官方”文档，其中说明了如何正确设置 Cloudflare 与 discourse。
其次，我想知道是否有可以遵循的流程来：
提前感谢 
如何托管？最简单的方法就是使用 DNS 模式。如果你想花额外的时间来获得非常小的收益，有一些关于这方面的帖子。大多数情况下，你会禁用那些会破坏 Discourse 的优化。如果你想减轻服务器的负载，那么像 Bunny.net 这样的 CDN 是最佳选择。
我认为统计数据和搜索应该可以正常工作。
暗示 Cloudflare 不是“真正的 CDN”可能有点短视？因为它确实是（而且远不止于此）是。也许您指的是“传统” CDN？
设置一个传统的 CDN 将花费更多的时间，但带来的好处却差不多。
说得有理！
而且 Cloudflare 可能更便宜，因为免费版本对许多人来说可能足够了。似乎总有一个活跃的话题，有人用 Cloudflare 搞坏了他们的网站，而让它正常工作的最简单方法似乎是关闭所有优化，这样只会增加延迟。
如果您能创建一个话题，描述如何配置 Cloudflare 以提供与传统 CDN 相同的优势，那将非常有帮助。也许这就像禁用 rocket loader 一样简单，但确切的设置方法似乎是一个不断变化的目标（因为他们会更改和改进他们的产品）。
抱歉，我不想引起关于哪个 CDN 最好的讨论等等。
我还没有获得更多信息，但据我所知，该论坛目前使用的是付费计划（所以我想不是免费选项），但即便如此，这也不是重点。
简单的问题 → 我需要做什么来设置 Cloudflare，使其不干扰 Discourse？
之后，我很乐意了解这是否是真正需要的东西（即，好处等）：slight_smile:
另外，如果有人能给我一个关于其他两个小问题的链接或什么，那就太好了：heart:
我将在下周在暂存环境中进行一些测试，所以一切都还没有定论！
如果您由 discourse.org 或其他任何方托管。在对 Cloudflare 进行任何操作之前，您应该与他们核实。通常，您只需创建一个指向其服务器的 DNS CNAME。Discourse.org 已经部署了 CDN，因此您无需担心。
谢谢 @pfaffman，它是自托管的。正如我所说，它用于当前的 vbulletin 论坛，该论坛将直接离线，并被 discourse 取代，后者将从同一域名响应。
这取决于您希望 Cloudflare 扮演什么角色（如果有的话）。
如果您只想将 Cloudflare 用作 DNS，请确保禁用论坛“a”记录的橙色云。
如果您实际上想让 Discourse 流量通过 Cloudflare 的网络传输，并且可以接受它增加的额外延迟，那么至少需要创建一个页面规则来为整个论坛域“禁用性能”。Cloudflare 的性能优化都不推荐，并且已知会破坏网站。
请注意，有一个 Cloudflare 模板需要添加到您的 app.yml 中，它会将 CF-Connecting-IP 作为客户端 IP 传递，这样您就不会看到所有人都源自其网络上的节点。
如果您不使用基于对象的存储，并且启用了橙色云，那么您可以为您的资源路径创建一个缓存规则。
谢谢 @Stephen。
Cloudflare（目前仍然是）用于避免实际网络服务器过载。
我最想知道的是，考虑到 Discourse 的实时更新特性（我猜是 websocket？我没查），这会不会与 Cloudflare 缓存等产生问题。所以我想知道是否有任何文档或有人有什么建议
我一无所知，这就是为什么我时不时感到迷茫，但听起来你正在寻找 PHP 的本质，但你却得到了 JavaScript 应用的本质，其中除了获取实际数据之外的所有事情都发生在用户的设备上。
这就是为什么（以及我有限的技能）我尝试将 Varnish 放在 Discourse 前面却惨败的原因。
当然，你可以从 CDN 提供静态资源，但仅此而已。
好的，Cloudflare 无法减少应用程序服务器负载。作为一个单页 JavaScript 应用，Discourse 确实没有从中受益。
情况更糟，因为将 Discourse 置于 Cloudflare 之后，浏览器中的应用程序和服务器之间的每次请求都会增加网络跃点，因此响应时间会略有增加。
您是保留服务器上的上传，还是使用 S3/类似 S3 的替代方案？
抱歉回复晚了。
我对 Discourse 的设计了解不多，但考虑到 Redis 已经管理了一些常用请求的缓存。这解释了“Cloudflare 并非真正需要”的原因。
那么，我的理解对吗？在 Discourse 安装前面放置 Cloudflare 基本没有好处，反而会因为网络跃点而减慢响应速度？
Cloudflare 仅用于 vbulletin3 安装的原因是请求量会压垮服务器，而且（我只是猜测）这可能是 vbulletin3 代码设计糟糕所致，因为托管它的虚拟机本身就有 4 核 8GB 内存，而数据库的虚拟机配置相同。
如今没有任何现代 Web 应用程序需要这么大的资源。
说到这个，有没有什么参考资料可以帮助我评估一个平均有约 1K 活跃用户和约 5-6K 潜水用户的 Discourse 安装需要多少硬件？
这并非完全正确。尤其是在首次加载时，Cloudflare 可以加快 JavaScript 静态资源的加载速度。而这正是 Google 用来判断您的网站性能是否足以避免搜索引擎处罚的因素之一。当您拥有一个吸引搜索引擎用户的营销型论坛时，其好处会更大；而当您拥有一个拥有活跃、回访用户群的论坛时，其弊端会更大。
没有，因为这真的取决于这些用户是否非常活跃，或者他们是否每天只访问一次。我见过一个由不到 50 人组成的群体，他们整天都在交换大型照片，并将 Discourse 用作聊天框，这让性能非常出色的硬件都难以承受；但我也见过一个拥有 10,000 人（他们每周只来发帖一次）和超过 3000 万 (!) 潜水用户的论坛，却运行在一个普通的 VPS 上。
感谢您的见解和信息 @RGJ，我想我只会继续关注，看看情况如何。希望它不需要与之前的软件相比大幅增加需求 