Azure Web应用部署槽交换后流量未完全切换至生产环境

针对你遇到的四个Web App在槽交换后数小时仍有15%流量流向staging槽的情况，我整理了几个常见的排查方向，你可以逐一验证：

1. 确认槽交换的完整性与流量路由配置 #

• 先检查槽交换是否完全完成：在Azure门户的Web App「部署槽」页面，查看交换历史记录，确认交换过程没有报错或中断。
• 验证流量权重分配：在部署槽页面查看每个槽的流量权重，确保生产槽设置为100%，staging槽为0%。如果使用CLI命令交换，可以执行以下命令确认权重配置是否正确：

  az webapp show --name <你的应用名> --resource-group <资源组名> --query "slots[].{name:name, trafficWeight:trafficWeight}"
  

• 注意：如果交换时额外添加了--no-swap参数（仅交换配置不交换流量），会导致流量路由不更新，不过你使用的默认命令应该不会出现这个问题，但还是可以排查确认。

2. 检查粘性会话（ARR Affinity）的影响 #

如果你的Web App开启了ARR Affinity（会话粘性），之前已经与staging槽建立连接的用户会保持会话关联，直到他们的会话自然过期（默认超时通常为20-30分钟，具体取决于你的配置）。这部分流量属于正常现象，等会话过期后就会自动切换到生产槽。

• 你可以在Web App的「配置」>「常规设置」中查看ARR Affinity是否开启，如果不需要粘性会话，临时关闭它来验证流量是否恢复正常。

3. 排查自定义域名与DNS配置 #

• 确认自定义域名是否仅绑定到生产槽：如果staging槽也绑定了同一个自定义域名，用户直接访问该域名可能会绕过流量路由规则直接进入staging槽。你需要确保自定义域名只绑定到生产槽，staging槽使用默认的<应用名>-staging.azurewebsites.net域名。
• 检查DNS缓存：部分用户的本地DNS可能缓存了旧的解析记录，导致他们仍访问staging槽的IP。不过Azure槽交换是通过负载均衡器调整流量路由，而非交换IP，所以这个情况较少见，但可以让用户执行ipconfig /flushdns刷新DNS缓存来测试。

4. 分析流量来源与应用日志 #

• 启用Application Insights或查看Web App的访问日志，定位这15%流量的来源：
  • 如果请求的Host头是staging槽的域名，说明是直接访问staging的流量（比如测试人员、爬虫或误操作）；
  • 如果Host头是生产域名但流量流向staging，那大概率是流量路由配置未同步；
  • 另外，检查是否有健康检查流量：如果配置了针对staging槽的健康检查端点，Azure的健康检查服务会持续发送请求到staging，这部分属于正常运维流量，不算用户流量。

5. 排除持续部署的意外触发 #

检查staging槽的部署历史，确认交换完成后没有因master分支的新推送触发自动部署。如果有意外部署，可能导致staging槽的代码更新，但流量路由未调整，不过这种情况通常不会持续数小时。

内容的提问来源于stack exchange，提问作者Saqib