好吧，这确实很奇怪，我甚至不知道该如何正确描述它。有一位客户抱怨我们网站上的某个特定页面无法正常工作，我们的一位内部技术人员也能够重现该问题。网站的大部分功能都运行良好。它部署在 Azure 应用服务上。
我检查了与技术人员完全相同的页面，结果一切正常。除了身份验证 cookie 之外，整个请求完全相同。当我运行请求时，我得到了 200 OK，但技术人员和客户得到了 404 NOT FOUND。
这个问题是在我们今天早上在 Azure App Service 上进行 VIP 交换后才出现的（我是新手）。我今天早上将服务更新部署到临时部署交换，几分钟后进行了 VIP 交换。我认为客户和技术人员在 VIP 交换期间都打开了浏览器并处于活动状态。
我进行了一些故障排除，以下是我发现的问题。我可以使用 Fiddler 捕获对我来说运行正常的网页的精确跟踪。然后，我可以从收到 404 错误的技术人员的请求中复制一个值，然后我突然也可以重现 404 错误。区别在于一个 cookie：
Cookie: ARRAffinity=blahblahblahblah;
我的基本理解是，这是识别用户正在连接到哪个服务器的关键，以便他们与负载平衡集（2 个服务器）中的特定实例建立关联。我们能够通过让技术人员和客户删除浏览器中的所有 cookie 来解决这个问题，但即使注销并重新登录也无法解决问题。
为什么“过时的”亲和力密钥会导致某个特定页面出现随机 404 错误？是否有可能某些用户的请求实际上被定向到旧的暂存部署站点，即使他们访问的是连接到生产部署站点的 URL？
答案1
这里有两件事：
- 会话亲和性。正如你可能读到的在本文中，您现在可以删除 Web 应用程序内的会话亲和性，如果这值得您的使用案例（例如，您处理 Web 应用程序之外的会话，或者您没有会话特定的信息）。
- 404 错误有点奇怪。它可能来自错误的部署，因此您可能需要在新的插槽上重新进行完整部署并再次交换。如果仍然有错误，请查看网站本身，看看是否没有任何“有状态”代码可以为您提供特定行为。
请让我们知道最后发生了什么。