Webflow CMS Behind CloudFront：在同一域名上提供动态和静态页面
Source: Dev.to
（请提供您希望翻译的正文内容，我将为您翻译成简体中文。）
介绍
在 AWS 上部署前端的常见方式是使用 S3、CloudFront 和 Route 53。这种方案简单且成本低廉，许多团队可以多年使用这种配置。
团队最终将一些面向公众的页面（例如首页或博客）迁移到 Webflow 之类的 CMS 也非常普遍。这种转变通常出于以下实际原因：
- 市场人员可以在无需工程师介入的情况下发布内容。
- SEO 工作流变得更容易。
- 设计迭代速度更快。
当你想要同时实现以下两点时，挑战就出现了：
company.com和/blogs→ 由 Webflow 管理- 其他所有页面（尤其是像
/dashboard/*这样的动态页面） → 仍保留在 S3 上
所有内容必须位于 同一域名 下，且不能使用重定向或子域名。
问题：流量路由
在本文中，我将逐步讲解在部署期间如何解决此问题。该方法可以让您：
- 将 CloudFront 保持为唯一入口点。
- 在同一根域名下提供 Webflow 页面和基于 S3 的页面。
- 在 不永久将流量从 CloudFront 重定向 的情况下处理 Webflow 域名验证。
该设置在生产环境中可靠运行，并避免了其他地方未明确记录的多个陷阱。
高级解决方案
我们不尝试将路由逻辑迁入 Webflow（这可能需要企业计划），也不引入新的代理层，而是：
- 保持 CloudFront 作为唯一的边缘节点。
- 将 Webflow 和 S3 视为源站。
- 使用 基于路径的行为 来决定每个请求的去向。
请求流程（运行时）
Route53 → CloudFront
├── /dashboard/* → S3
└── /* → Webflow从浏览器的角度来看，一切仍然来自 company.com。没有重定向、没有子域名，也看不出 Webflow 管理的页面与 S3 支持的页面之间的边界。
为什么会出现 502 Bad Gateway
将 Webflow 作为 CloudFront 的源站是直接的：创建一个指向您在 Webflow 上托管站点的自定义源，就像为 ALB 或任何外部服务创建源站一样。
如果您 仅仅 做了这一步，您很可能会在指向 Webflow 的路径上遇到 502 Bad Gateway。原因在于 Webflow 在允许发布之前需要进行域名所有权验证。
Webflow 的验证流程
- TXT 记录 – 证明所有权。
- A 记录或 CNAME – 将流量直接指向 Webflow。
当 Webflow 是流量的最终目的地时，这种方式可以正常工作。在我们的架构中，DNS 必须指向 CloudFront，而不是 Webflow，导致出现不匹配：
| 需求 | Webflow | CloudFront |
|---|---|---|
| 所有权验证 | TXT 记录（必需） | – |
| 流量路由 | A/CNAME → Webflow | A/CNAME → CloudFront |
Webflow 的 UI 将两个关注点混在一起：
- 控制平面 – 验证（TXT 记录）。
- 数据平面 – 实际的流量路由（A/CNAME）。
Webflow 建议 TXT 记录 和 A/CNAME 必须持续指向 Webflow，但 只有 TXT 记录是持续验证所必需的。
实际解决方案
- 初始步骤 – 将 TXT、A 和 CNAME 记录指向 Webflow，以便验证成功。
- 验证后 – 保留 TXT 记录 并且 将 A/CNAME 记录指回 CloudFront。
- 现在 CloudFront 可以安全地将流量转发到 Webflow 作为源站。
Source: …
步骤实施
注意： 请 不要 在任何阶段删除或绕过 CloudFront。根域名（
company.com）和www（如果使用）必须始终解析到 CloudFront。
1. 在 CloudFront 中创建自定义源
| 设置 | 值 |
|---|---|
| 源域名 | your-site.webflow.io |
| 协议策略 | HTTPS only |
| 源请求头 | 无需 |
2. 配置行为
| 行为 | 路径模式 | 源 | 缓存策略 | 源请求策略 |
|---|---|---|---|---|
默认 (*) | * | Webflow | CachingDisabled（推荐用于 CMS） | AllViewer（或等效） |
| 特定 | /dashboard/* | S3 | 按您现有的设置 | 按您现有的设置 |
顺序很重要——更具体的路径（
/dashboard/*）必须 位于 默认 (*) 行为 上方。
3. 设置 Webflow
- 在 Webflow UI 中添加您的自定义域名（
company.com）。
4. 在 Route 53 中添加 DNS 记录（初始阶段）
| 记录类型 | 名称 | 值 | 用途 |
|---|---|---|---|
| TXT | _webflow | Webflow 提供的验证字符串 | 所有权验证（永久保留） |
| A（根域） | @ | Webflow IP(s) | 临时 – 用于验证 |
| CNAME（www） | www | cdn.webflow.com | 临时 – 用于验证 |
等待 Webflow 将域名显示为 已验证 且 已发布。
5. 将 DNS 切回 CloudFront（验证后）
| 记录类型 | 名称 | 值 |
|---|---|---|
| A（根域） | @ | CloudFront 分配的 别名（或 CloudFront 域名） |
| CNAME（www） | www | 同样的 CloudFront 别名 |
| TXT | _webflow | 保持不变 |
此时：
- DNS 将流量路由到 CloudFront。
- Webflow 仍保持验证状态并可发布。
6. 在 Webflow 中发布站点
- 将自定义域名设为 默认。
- 点击 Publish（发布）。
无需进一步的 DNS 更改。
结果
| 路径模式 | 来源 |
|---|---|
/* | Webflow |
/restaurants/* (or any other dynamic path) | S3 |
所有内容均在 相同域名 (company.com) 下提供，无重定向且无子域名。
关键洞察
- CloudFront 保持单一边缘。
- Webflow 只需验证域名一次；之后它可以作为 CloudFront 后面的源。
这个简单的思维模型消除了额外代理层的需求，并利用了许多团队已在生产中使用的架构。
处理路由并将请求转发至 Webflow
在 DNS 恢复指向 CloudFront 后，您可能仍会在 Webflow UI 中看到 “需要更新” 等警告。这些警告是无害的，只要域名已经完成验证并已发布即可。
采用这种模式，您可以灵活地混合静态资源、动态前端以及像 Webflow 这样的托管平台，同时仍保留 CloudFront。
这就是实际可行的架构。
感谢阅读。
与我联系
- LinkedIn: [Your LinkedIn Profile]
- YouTube: [Your YouTube Channel] – 订阅获取更多有价值的内容。
欢迎在评论区分享你的想法！