在云原生部署架构中，暂存（Staging）与生产（Production）环境的缓存隔离是防止配置错误导致数据泄露的关键防线。2026 年 3 月 30 日，Railway 发生的一起 CDN 缓存事故导致约 0.05% 的域名在 CDN 未启用状态下被错误缓存，认证用户的数据被意外提供给其他用户，持续约 52 分钟。这起事件的根本原因是配置变更流程缺乏足够的隔离验证机制。本文从工程实践角度出发，提供可落地的暂存 / 生产环境 CDN 缓存隔离配置清单与自动化检测方案。

缓存隔离的核心设计原则

暂存环境与生产环境的 CDN 缓存策略必须遵循「默认拒绝」原则。在 Railway 事故中，问题恰恰出在「默认缓存」行为上 —— 当工程师意外为已禁用 CDN 的域名开启缓存时，系统没有足够的防护机制来区分两类环境的差异化需求。暂存环境的流量通常来自内部测试人员或自动化测试脚本，其缓存策略应比生产环境更加保守，甚至在某些场景下完全禁用 CDN 缓存，以避免测试数据污染或意外数据泄露。

配置隔离的实现方式主要有三种：独立域名策略、Header 强制覆盖策略、以及环境变量驱动策略。独立域名策略是指为暂存环境分配独立的二级域名（如 staging.example.com），并在该域名对应的 CDN 配置中显式设置 Cache-Control: no-store, no-cache, must-revalidate；Header 强制覆盖策略是指在 CDN 层面通过 Edge Function 或配置规则，强制为特定环境的所有响应注入缓存控制头；环境变量驱动策略则是将缓存开关与部署环境变量绑定，确保配置变更必须经过环境切换流程。

暂存环境配置清单

针对暂存环境的 CDN 缓存配置，以下清单可直接应用于主流 CDN 服务商（包括 Cloudflare、Fastly、AWS CloudFront 等）。第一，域名层面必须设置「缓存模式」为「严格不缓存」或等效配置。以 Cloudflare 为例，应在 Page Rules 或 Cache Rules 中配置 Cache-Level: Bypass；以 AWS CloudFront 为例，应为该行为的 Viewer Request 事件添加函数，将所有请求的 CloudFront-Viewer-Country 头部与预定义的环境标识进行比对，若检测到暂存环境流量则直接返回 403 或重定向至生产环境。

第二，响应 Header 强制注入是第二道防线。在 CDN 配置中添加响应头覆盖规则：Cache-Control: no-store, no-cache, must-revalidate, private 和 Pragma: no-cache，确保即使上游应用未设置缓存头，CDN 也不会缓存任何响应。第三，Cookie 过滤规则应配置为「所有以 railway_session 或应用自定义前缀开头的 Cookie 都不参与缓存键计算」，这一措施直接针对 Railway 事故中「认证数据被缓存」的核心问题。

第四，缓存键（Cache Key）必须包含环境标识。无论是使用哪一代 CDN，均应在缓存键中强制加入环境变量（如 x-env: staging），确保暂存环境的缓存对象与生产环境物理隔离，避免缓存键冲突导致的意外数据泄露。第五，暂存环境的缓存大小应设置为零或极低阈值（如 1MB），并在达到阈值时自动触发清除策略。

生产环境配置清单

生产环境的配置清单则需要在安全与性能之间取得平衡。与暂存环境不同，生产环境的 CDN 缓存策略应默认开启，但必须通过严格的 Header 规则来控制哪些内容可以被缓存。第一，Cache-Control 头的默认值应设置为 max-age=3600, stale-while-revalidate=86400，允许 CDN 在源站不可用时最长提供一天的过期内容服务。第二，对于包含用户特定数据的路由（如 /api/user/*、/dashboard/*），必须在 CDN 层面配置「永不缓存」规则，匹配路径模式并强制设置 Cache-Control: private。

第三，认证相关的响应头过滤是防止数据泄露的关键。所有 Set-Cookie 响应头应在 CDN 层面自动剥离或标记为不参与缓存键计算，同时在缓存键中排除 Authorization 头部。第四，生产环境应启用「缓存分层」策略：静态资源（JS、CSS、图片）使用较长的缓存时间（如 max-age=31536000），并通过文件指纹（content hash）实现缓存更新；动态 API 响应则使用较短的缓存时间或完全不缓存。

第五，生产环境必须配置「缓存穿透告警」。当缓存命中率突然下降超过 20%，或缓存命中率异常升高（超过 99.5%）时，应触发告警。这两个极端情况都可能指示配置错误 —— 前者可能是缓存被意外禁用，后者则可能是本不应缓存的内容被缓存了。

自动化检测方案

配置清单只是起点，真正确保隔离有效的是持续运行的自动化检测机制。基于 Railway 事故的教训，建议部署以下三类自动化检测。

第一类是配置漂移检测。每小时执行一次 CDN 配置快照，并与基线配置进行比对。检测脚本应关注以下关键字段的变化：cache_mode、default_ttl、cache_key_includes、cookie_forwarding、header_overrides。一旦检测到任何变化，立即告警并暂停变更（如果部署流水线支持）。基线配置应存储在版本控制系统中，并在每次部署前自动校验。

第二类是运行时缓存行为验证。每 15 分钟从暂存环境和生产环境各发送一组测试请求，验证实际缓存行为。具体做法是：发送两个携带不同 Cookie 的 GET 请求到同一 URL，检查响应中是否包含相同的 Age 头（表示命中缓存）或不同的内容（表示未缓存）。如果暂存环境的响应包含 Age 头，说明缓存隔离失效；如果生产环境的 /api/user/profile 响应包含 Age 头，说明用户特定数据被错误缓存。检测脚本的告警阈值应设置为：暂存环境缓存命中率必须为 0%，生产环境用户数据路由缓存命中率必须为 0%。

第三类是异常流量模式检测。在 CDN 日志分析中部署异常检测规则，监控以下危险信号：来自同一 IP 地址的大批量不同 Cookie 请求（可能是在探测缓存隔离）、缓存命中率在短时间内剧烈波动、来自非生产域名的认证请求被成功服务。Railway 事故中「用户看到其他用户的页面」这一现象，正是异常流量检测可以捕捉到的典型模式。

监控与响应参数

为确保检测方案真正发挥作用，以下监控参数需要明确设置。缓存命中率告警阈值：生产环境正常范围为 70%–95%，低于 60% 或高于 98% 应触发 P2 级告警。响应时间异常阈值：缓存命中与未命中的响应时间差异应小于 50ms，若缓存响应反而更慢，说明缓存配置存在问题。配置变更审批流程：所有 CDN 配置变更必须经过至少一人审批，且变更窗口限制在非业务高峰期（建议 UTC 00:00–06:00）。

在响应层面，一旦检测到缓存隔离失效，应立即执行三步操作：回滚 CDN 配置至上一稳定版本（Railway 事故中用时 20 分钟）、触发全局缓存清除（Purge All）、向受影响用户发送通知。这三步应被编排为自动化剧本（runbook），确保在任何值班工程师都能在 5 分钟内完成完整响应。

Railway 事故的核心教训在于：缓存配置不是「一次设置终身受益」的静态配置，而是需要持续验证的动态风险点。通过本文提供的配置清单与检测方案，团队可以在 CDN 层面建立多层防护，将类似数据泄露风险控制在可接受范围内。配置隔离的最终目标，是让任何单点故障都不会导致认证数据跨越环境边界流动。

资料来源