过去一周，我们发现（至少部分）CDN 仅缓存“200 OK”状态的 HTML 页面。这意味着，当发生大规模架构变更时，CDN 的作用不大，因为（出于 SEO 考虑）您的小型根服务器会处理大量的 301 重定向，或者（更有可能的是）会出现大量 404 错误，而 CDN 会认为没有页面，因为它没有缓存 200 状态的页面。最终导致 301 重定向服务失败。
这种情况的发生是有原因的—
—您当然可以理解 CDN 的要求包括仅缓 电话号码库 存已成功交付的页面，并与基础服务器检查每个错误状态（尤其是在部署期间，您希望 404 错误能够逐渐被捕获和修复，并且希望这些修复能够反映在 CDN 交付的版本中——例如，通过在 Google Analytics 中跟踪 404 错误页面来实现）。很容易看出这会演变成拒绝缓存任何非 200 状态页面，但这绝对不符合 SEO 的预期。
甚至比这更糟糕—
—因为当你查看主流框架内置的大多 类似用户报 告包含与 CRM 数据报告相同的数据： 数缓存解决方案时，你会发现其中大多数在缓存重定向方面设计也很差。每当对不存在的页面发出请求时，它不仅会错过缓存，而且通常会沿着堆栈一路向上级联，直到出现一个权威的“不，绝对不存在”（或“永久重定向到那里”）响应，这其中会涉及相当多的数据库查询。
你不可避免地会谈论从数据库驱动的 CMS 提供它们——虽然 Apache 可以快速处理硬编码重定向，但配置更改永远不是大规模架构变更的解决方案。在这些场景中，你至少需要基于规则的重定向（想到要在 Apache 配置中使用正则表达式来实现，我就不寒而栗）。
所以，虽然我们（目前）
还不需要指定一个能够处理数百万访问 阿拉伯联合酋长国电话号码 者访问不存在页面的系统（而这需要托管上述即将失效的子域名），但这还是引发了我们的思考。是否有人知道一种像缓存成功传送的 HTML 页面的系统一样有效地缓存非 200 状态代码页面的好方法？
与此同时，希望我们的故事能让您稍作思考，认识到需要做什么才能在通过框架和 CDN 交付的大型复杂系统上实现“将所有旧页面永久重定向到新页面”这一单行规范。