多用户同账号登录Azure应用网关时会话值异常求助

我之前帮客户处理过几乎一模一样的场景，结合你的描述和Azure的架构特性，给你几个具体的排查方向：

1. 后端池改用FQDN而非IP地址 #

你提到的微软文档里的点确实是关键——当后端池用静态IP时，应用网关无法感知VMSS实例的动态变化（比如伸缩、重启后的IP变更），而且会话亲和性的绑定逻辑会变得模糊。建议把后端池改成VMSS的内部FQDN（格式一般是<你的VMSS名称>.<虚拟网络域名>.internal.cloudapp.net），这样应用网关能精准识别每个VM实例，确保会话被稳定路由到正确的后端节点。

2. 检查会话数据的存储隔离逻辑 #

既然会话值存在数据库里，要确认同一用户ID的不同设备会话是否有唯一标识区分。AWS环境下可能WAF或者LB隐式帮你做了部分隔离，但Azure的七层负载架构下，如果你的后端只靠用户ID来拉取会话数据，多个设备用同一ID登录时，必然会读取同一份数据导致串用。建议给每个会话生成唯一的session_id，和用户ID关联存储，前端请求时携带这个session_id，后端用用户ID + session_id的组合来查询对应会话值，从根源上隔离不同设备的会话。

3. 避免双重负载层的亲和性冲突 #

你当前的架构是App Gateway -> Public LB -> VMSS，两层负载的亲和性配置容易互相干扰：

• App Gateway的Cookie亲和性是基于它生成的ApplicationGatewayAffinity Cookie绑定到后端节点
• Public LB的会话持久性是基于源IP绑定到VM实例
  这种叠加可能导致App Gateway把请求转发到LB后，LB又把请求路由到了和之前不同的VM实例，打破会话绑定。如果业务允许，建议把App Gateway的后端池直接指向VMSS实例，绕过Public LB；如果必须保留LB，确保LB的会话持久性和App Gateway的亲和性逻辑匹配（不过LB只有源IP或无两种选项，所以更推荐直接让App Gateway对接VMSS）。

4. 验证应用网关的细节配置 #

• 确认后端HTTP设置里已开启Cookie-based亲和性，并且超时时间设置合理（不要过短导致会话提前失效）
• 检查是否开启了Connection draining，如果 draining时间过长，可能会把旧会话路由到正在下线的VM实例，引发数据异常

另外补充一点：AWS Classic LB是四层负载，Barracuda WAF做七层处理，和Azure App Gateway的纯七层负载逻辑差异很大，所以AWS上的配置不能直接照搬过来，得适配Azure的架构特性。

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