这个社区在使用 Cloudflare 的问题上有很多争论。有些人说它运行良好，没有任何问题，而另一些人则警告说，如果使用它，天就会塌下来。无论如何，这些信息大多已经过时，有的来自 2 年前，有的甚至来自近 10 年前。
就我个人而言，我在 2022 年使用 Cloudflare 和 Discourse 没有任何问题。
我正在对所有页面和 HTML/CSS/JS 进行完全最小化/缓存，并使用 Brotli 压缩。出于个人偏好，我只将 /admin 从 Cloudflare 的性能优化中排除。
我没有关闭 Rocket Loader，它默认是关闭的。我唯一做的其他更改是添加：
- "templates/cloudflare.template.yml"
到我的 app.yml 设置中，以恢复用户 IP。
值得一提的是，在我进行任何调整之前，网站就已经运行良好。
只要您认识到您所做的事情完全不受支持，那就没问题。
CloudFlare 会持续调整其优化，有时它们不会引起任何问题，但有时却会让网站瘫痪。对大多数人来说，网站在他们未采取任何行动的情况下就崩溃的想法是难以接受的。
如果您曾观看过重建过程，您就会知道 Discourse 内部已经进行了最小化处理。CloudFlare 对网站的最小化处理效果并不比它自身做得更好。您是否测量过启用 CloudFlare 前后的性能？
而且别忘了，一旦 JavaScript 应用程序加载到浏览器中，CloudFlare 实际上是在拖慢您的网站速度。现在，应用程序和服务器之间的每一份流量都必须经过 CloudFlare 网络，增加了网络跳数，从而增加了延迟。
但如果它对您有效，那就太好了。只是在寻求支持之前，请务必将其关闭，因为它是第一个（也是最有可能的）罪魁祸首。
我感觉围绕使用 Cloudflare 和 Discourse 的大部分（如果不是全部）担忧都源于多年前的问题。
在过去的十年里，Cloudflare 和 Discourse 都取得了长足的进步。
我在缓存问题方面拥有丰富的经验，确实，早期 Cloudflare 破坏了很多脚本，但它现在已经稳定了很多年了。
一些更激进的缓存工具确实会破坏东西，需要大量优化才能使其正常工作。这种普遍的情绪仍然存在。
但是，您确定 Cloudflare 不受 Discourse 支持的说法仍然准确吗？Discourse 本身就内置了处理 Cloudflare 的机制。
总之，我没有在 https://gtmetrix.com/ 上进行前后对比，但对我来说，这有点无关紧要，因为我使用 Cloudflare 有其他原因，不仅仅是为了速度，所以除非它导致速度显著（甚至明显）下降，否则我还是会使用它。
最后的想法：是的，任何时候使用 CDN/缓存/最小化/等工具，尤其是如果您经验不足，都可能导致问题。对于所有网站，无论其构建方式如何，都是如此。但是，Cloudflare 几乎肯定会破坏所有 Discourse 站点的想法，感觉像是过时的信息，需要停止传播。
CloudFlare 模板并不是新添加的，如果你花时间查看源代码，你会发现它的唯一目的是获取其 IP 地址范围并修改 nginx，以确保它将 CF-Connecting-IP 视为真实的客户端地址，因为橙色云提供的代理会隐藏真实地址。这不是什么新鲜事，它已经存在至少七年了。你可以使用 Cloudflare 来隐藏你的服务器位置，或者作为上传的廉价 CDN，但在这两种情况下，我们都建议你禁用所有性能功能，并使用页面规则为你的上传文件夹启用缓存。
通过 GTMetrix 进行测试能证明什么好处？我认为你对 Discourse 的工作原理有根本性的误解，才会引用它。Discourse 不是一个网站，它是一个 Javascript 应用程序。浏览网站不会向浏览器提供静态 HTML 页面。加载到你浏览器中的 Javascript 应用程序直接与服务器通信，这就是为什么某些页面元素在点击之间似乎不会重新加载的原因。该应用程序的响应速度仅取决于服务器资源以及客户端和服务器之间的延迟。CloudFlare 无法加快你的 Discourse 实例的速度，而它在这两个系统之间会增加延迟。
以上是基于多年的经验，而不是一种感觉。Discourse 仍然会定期出现与 Cloudflare 相关的问题。除了隐藏你的服务器 IP 和节省上传数据传输量之外，Cloudflare 无法加快 Discourse 站点的速度。
CloudFlare 模板并非新增功能，如果您花时间查看其源代码，就会发现其唯一目的是获取其 IP 范围并修改 nginx，以确保其将 CF-Connecting-IP 视为真实的客户端地址，因为橙色云提供的代理会隐藏该地址。这不是什么新鲜事，已经存在至少七年了。您可以利用 Cloudflare 来隐藏服务器的位置，或充当上传内容的廉价 CDN，但在这两种情况下，我们都建议您禁用所有性能功能，并使用页面规则为您的上传文件夹启用缓存。
好的，我的观点是，如果 Cloudflare 不受支持，他们就不会费心在第一位正式添加任何形式的支持。他们也不会有关于如何使用它的官方教程。诚然，在某些情况下，他们可能会建议不要使用它，因为 X、Y 和 Z，但这与某些东西完全不受支持是不同的。
通过 GTMetrix 进行测试有什么好处？我认为您对 Discourse 的工作原理有根本性的误解，才会引用它。Discourse 不是一个网站，它是一个 Javascript 应用程序。浏览网站不会向浏览器提供纯 HTML 页面。加载到您浏览器中的 Javascript 应用程序会直接与服务器通信，这就是为什么某些页面元素在点击之间似乎不会重新加载的原因。该应用程序的响应速度仅取决于服务器资源以及客户端和服务器之间的延迟。CloudFlare 无法加快您的 Discourse 实例，它位于两个系统之间会增加延迟。
是的，我明白 Discourse 不是一个网站。它是一个内容交付平台，与其他任何平台/软件/CMS 一样。当然，Cloudflare 无法影响任何服务器级别的操作，特别是对于 LAMP 设置。但是，最终，每个平台最终都必须交付所有客户端代码（HTML/CSS/JS）。当然，GTmetrix 无法扫描服务器端速度，但您仍然可以从您的设置的最终输出中了解一些信息。换句话说，用户体验内容的加载方式。
Cloudflare 实际上并没有像服务器端优化和更好的服务器资源那样显著地加快网站速度。在这方面我们完全同意。它的主要重点是优化 DNS。对于付费账户，有一些更高级的 CDN 功能，尤其是在图像方面，但我从未用过付费账户。我想知道是不是因为这些高级功能，人们才遇到了最多的麻烦并需要寻求帮助？
以上是基于多年的经验，而不是一种感觉。Discourse 仍然存在与 Cloudflare 相关的周期性问题。除了隐藏您的服务器 IP 和为上传节省少量数据传输外，Cloudflare 无法加快 Discourse 站点的速度。
该死。我就知道因为说了“感觉”会挨骂，但这只是一种比喻。我也是凭经验说话。
我不会质疑您作为官方 Discourse 社区的领导者，显然在 Discourse 方面拥有更丰富的经验，并且清楚地看到了 Cloudflare 造成的各种奇怪问题。
除了深入探讨 Cloudflare/Discourse 的所有细微差别之外，我仍然坚持我的主要观点，即 Cloudflare 根本不像这个论坛上的叙述所暗示的那样可怕。
话虽如此，我也理解管理社区的难处，显然不是每个人都是开发者，甚至不是技术爱好者。从这个意义上说，我可以理解，当人们认为 Discourse 坏了，而实际上只是 Cloudflare 或类似的东西时，被大量用户淹没会变得很烦人。
这就是重点。“不支持”并不意味着“不可能”，而是“祝你好运”。对于“有 bug”的常见回答是“关闭 Cloudflare 后还会出现吗？”
如果你确实想加快速度，请使用真正的 CDN - - 为你的 Discourse 启用 CDN
或者，你知道的，如果有人想要一个完全免费的选项，或者他们只是想使用 Cloudflare，他们当然可以。
你引用的是近十年前的建议。情况在变化。我真的很想看到一位官方开发者在 2022 年就此发表看法。我猜他会说，现在情况稳定多了，而且任何关于不要乱搞 JavaScript 的建议可能适用于所有 CDN，而不仅仅是 Cloudflare。
请不要标记团队成员，如果他们想发表意见，他们会自己做的。
???
我标记了 Discourse 的创建者。我们可以一整天都在争论 Discourse 在 2022 年相对于 Cloudflare 的地位，但除非我们直接听到他的说法，否则这更多的是猜测而不是确切的答案。
除非有人标记他，否则他怎么可能知道有人在征求他的意见以便他发表看法？
上周就有一个问题，与人们看到不该看到的广告有关，很明显是 Cloudflare 的问题。关闭它总是要做的第一件事。在这里获得支持的很多人都是完全的新手，让事情尽可能没有麻烦是目标。如果它对你有用，那就太好了。如果你想每周回复二十个或更多的帖子
但事实并非如此。如果你使用真正的 CDN Discourse 用户，它只用于应该由 CDN 提供服务的。
嘿 @JammyDodger，我认为是时候创建一个 Cloudflare FAQ 了（尽管这不是我第一次建议它）。你可以让 Jeff 和 Sam 发表看法。
事情是这样的。缓存/合并/最小化技术出了名地会破坏 JavaScript，无论使用的是什么软件或 CDN 组合。我见过十几种其他工具/服务都有这个常见问题。在处理新手时，仅仅是他们的浏览器缓存就够让人头疼的了。我以前管理过大型软件社区；我非常清楚同一个老问题会反复出现。
我想知道的是，这真的是 Cloudflare 特有的问题，还是所有优化工具都有的常见问题，它们会破坏 JavaScript，而仅仅因为 Cloudflare 的普及，这个问题就被错误地视为 Cloudflare 的问题。这个区别有意义吗？
无论如何，是的，我希望官方开发者能对此发表看法，并且一个最新的 FAQ 会非常有帮助。我收到了很多反对意见，但我并不是想制造麻烦。社区里对此有太多矛盾的说法，这让我感到沮丧；我只是想弄清楚在 2022 年的现状。
但是，如果我不能，如果我们不能，那也没关系。祝大家周末愉快。我现在要放过那匹可怜的 
了。
不，那不属实。我们非常频繁地遇到 Cloudflare 与 Discourse 结合使用时出现的问题。
根本没有“支持”这回事。但是，如果您不知道自己在做什么，它就会引起问题，即使您知道自己在做什么，也可能遇到意想不到的问题。
Cloudflare 的性能优势（如果有的话）会很小。Discourse 提供的大部分资源都经过良好压缩且是不可变的（即它们会被浏览器长时间缓存）。其他大部分内容是不可缓存的，因为它是个性化的应用程序数据。
话虽如此，Cloudflare 在 DDoS 防护方面可能非常有用。
这将会受到欢迎，因为我们有来自不同用户的各种意见 
我们为 Cloudflare 准备了一份常见问题解答，以及如何（不）为 Discourse 配置它的说明。这同样适用于自托管实例。
我不怀疑这一点，但我认为您错过了我试图弄清楚的区别。问题究竟是 Cloudflare 本身，还是这类优化工具很容易破坏 JS 这一事实？而大多数人碰巧因为 Cloudflare 的普及而使用它，从而产生了错误的混淆。
这就像将问题归咎于 Gmail 或 GoDaddy，而这些问题实际上是所有电子邮件或托管服务固有的。
即使您不同意，您也明白我的意思吗？
由于我们必须避免某些设置，并且元用户曾说过类似的话：
CloudFlare 能为你做的就是隐藏你的 IP 并充当你上传内容的 CDN。好处微乎其微。
和
Cloudflare 的性能优势（如果有的话）将很小。
对于“在未启用任何速度设置的情况下，与 Bunny CDN 或 Stackpath（或者任何“常规”CDN，我想）相比，Cloudflare 是否有任何优势？”这个问题，是否有明确而直接的答案？
我仍在犹豫是选择 Bunny（这将大大降低我目前的 CDN（Stackpath）成本），还是 Cloudflare（在我的情况下将是免费的，因为域名所有者可以将我的论坛添加到他的企业账户）。
另外，我无法理解的东西，因为我并不懂技术。
这不仅仅是破坏JS的问题。还包括代理和使80端口不可访问，破坏LetsEncrypt，以及一些服务缓存过多。
由于Cloudflare是这类“优化工具”中最大、最普及、最受欢迎且免费的，所以大多数讨论都围绕它展开。但你说得对，这类工具本身就存在问题。
是的，同意。
这类话题本质上有点危险，因为人们（尤其是“有问题”的目标群体）往往不太会仔细阅读。这就像在一个关于毒品或酒精滥用危险的话题中发帖，声称“不，伙计们，问题不仅仅是毒品和酒精，我使用毒品没有任何问题，别忘了，过度使用任何物质都是危险的”。（是的，我知道。每个比喻都有其局限性，但这是我能想到的最好的了）。
我们可以大声疾呼这些东西有多危险，但人们还是会照用不误。
这就是我们制作FAQ的原因 
新的常见问题解答指南听起来是个好主意。Communiteq 的链接不是很可靠。
在这个论坛上，有些人正在制定通用规则 Cache Level: Bypass, Disable Performance，但他们允许 Cloudflare 缓存图片或 CSS。我还没有看到官方回应，这是否可行……
与其说不要使用 Cloudflare，然后处理那些有问题的人，不如提前明确哪些应该做，哪些不应该做。这样以后只需快速链接到该帖子，就可以回答这些问题了。
这只是一个人的看法。
@RGJ — 谢谢！很多人可能看不到或不理解我区分的要点，或者它有什么区别，但对我来说，这带来了极大的清晰度。没有清晰度我会非常沮丧，因为没有最初的坚实基础，我就不知道该走哪条路来进一步专注于某个特定主题并获得更好的理解。
如果您有任何具体的评论，我很想听听。
关于缓存，我只能说它不是“好”或“不好”，更像是“一般般”：