什么可能导致应用在通过 CNAME 别名访问时过时?

Question

我有一个非常奇怪的情况，我的应用程序的陈旧版本仅在通过其 CNAME 别名访问时提供。

该应用程序是使用 Webpack 构建并托管在 Zeit NOW 上的静态节点应用程序。如果我使用直接 Zeit URL 访问它，我会得到最新版本和正确的 JS 资产：

https://nates-app.now.sh/index.html -> https://nates-app.now.sh/client/index.eb53e753.js (current)

在 AWS Route53 中，我设置了一个别名别名www.nates-app.comhttps://nates-app.now.sh别名。但是，将我的浏览器指向https://www.nates-app.com会导致过时的index.html。更奇怪的是，过时的索引.html页面要求过时的JS和CSS资产，这些资产也被成功返回：

https://www.nates-app.com/index.html -> https://www.nates-app.com/client/index.f64812dd.js (stale)

陈旧版本已超过 48 小时。

挖掘显示几乎相同的结果。dig nates-app.now.sh结果为以下答案部分：

;; ANSWER SECTION:
nates-app.now.sh.   60  IN  A   1.2.3.4
nates-app.now.sh.   60  IN  A   4.3.2.1

dig www.nates-app.com会产生相同的输出，只有ANSWER部分中显示一个(预期的(添加项 CNAME：

;; ANSWER SECTION:
www.nates-app.com.  300 IN  CNAME   https://nates-app.now.sh.
nates-app.now.sh.   60  IN  A   1.2.3.4
nates-app.now.sh.   60  IN  A   4.3.2.1

我没有将 AWS Cloudfront 或任何其他 CDN 用于静态资产。

我显然已经清除了浏览器的缓存，甚至关闭和打开了我的VPN。同事从不同的 ISP 访问互联网时会看到同样的事情。

那么，万维网中什么可以缓存我网站的HTML和随附资产的(非常(旧版本？

Answer 1

很奇怪，当我遇到类似的问题时，解决方案始终是刷新浏览器缓存或使用隐身模式。你还有同样的经历吗

Answer 2

有几件事：

Zeit 不支持将CNAME直接指向您的 Zeit 子域。您需要在Zeit仪表板中配置您的域，并设置验证文本记录并将您的CNAME分配给alias.zeit.co。alias.zeit.co服务器将您的CNAME路由到最新的部署。

也有可能，在 Zeit 的配置中，您的域名仍指向项目中较旧的部署。Zeit 不会自动将域名重新分配给新部署，除非您正在执行生产部署(即now --prod或已将其配置为将推送到 gitmaster分支视为生产部署。在仪表板中，单击"Projects"，然后单击项目的名称。如果未在最新部署中列出您的域，则可能是罪魁祸首。