Azure Traffic Manager 浏览器缓存问题

Question

Azure Traffic Manager 浏览器缓存问题

google-chromeazurecachingdnsazure-traffic-manager

6

在Azure的流量管理器中，我正在测试两个故障转移URL: 流量管理器配置了两个不同的端点（failover1.mysite.com和failover2.mysite.com），然而，我的本地浏览器（例如Chrome）似乎在自己缓存DNS记录并重定向到它认为仍然是目标，而不是让Azure Traffic Manager重新路由。在新的浏览器或无痕浏览会话中尝试该请求将导致请求到达正确的站点。但对于现有的会话，故障转移更新未被注册，仍然命中我们试图重定向流量的站点。有没有人有相关经验？

- Rohan

你有没有找到任何解决方案？？ :P 我也遇到了完全相同的问题 :/ - A.J Alhorr

我们遇到了类似的问题，即CORS请求绑定到“down”站点并忽略“up”端点。无论刷新、清除缓存还是新建选项卡都无法解决它。实际上，在它转到“up”端点之前，我们必须关闭所有Chrome实例。这几乎就像无限期地缓存文件响应一样。其他浏览器没有出现同样的情况。 - Jaans

2个回答

1

当我处理Azure Traffic Manager或AWS CloudFront时，我遇到了同样的问题。

DNS记录与其TTL值相关联。这不是Azure Traffic Manager的问题，而是TTL值让DNS客户端缓存IP地址。

如何检查DNS的TTL值：

如果您使用Windows操作系统，请执行以下步骤：

https://support.rackspace.com/how-to/nslookup-checking-dns-records-on-windows/

如果您使用的是Linux，请按照此处详细说明操作。

https://www.cyberciti.biz/faq/howto-use-dig-to-find-dns-time-to-live-ttl-values/

希望有所帮助。

- Kannaiyan

谢谢，我很感激每个客户端设备都可以清除缓存或配置，但这在许多方面都是违背初衷的。客户现在卡在一个因为浏览器/操作系统缓存而现在已经无法访问的网站上，并且我们无法联系数以百计的未知网络访客来引导他们进行 DNS 清理过程。 - Rohan

TTL是在您的DNS服务器记录中配置的，而不是在客户机上配置的。客户端将尊重在您的DNS服务器中配置的TTL。看起来您误解了TTL是在客户机/浏览器中配置的。 - Kannaiyan

TTL在流量管理器中配置为10秒，但客户端没有遵守。 - Rohan

您可以使用上述链接验证TTL。如果您刚刚更改并等待其传播，则旧的TTL可能仍然有效。 - Kannaiyan

1

旧/默认TTL为300秒。自从测试开始2天以来，这段时间已经过去了多次，不管怎样，还是很感激的。 - Rohan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matt · Accepted Answer

从微软的负载均衡服务概述中得知：

Traffic Manager是基于DNS的流量负载均衡器[...]，它仅在域级别进行负载平衡。因此，由于DNS缓存和系统不遵守DNS TTL等常见挑战，它无法像Front Door那样快速故障转移。

使用Front Door，您可以根据规则和/或后端本身的健康状况将请求路由到不同的后端，因此它不会出现您描述的问题。