Azure APIM中Websocket API返回HTTP 429错误问题咨询

• 业务架构：Web应用通过WebSocket消费基于MQTTnet库发布的自有MQTT主题，已在Azure API Management（以下简称APIM）中配置对应WebSocket API
• 故障时间点：2022年6月6日
• 故障表现：此前服务运行完全正常，故障发生后所有WebSocket请求直接被APIM拦截，返回HTTP 429「请求过多」错误，APIM侧无任何向后端服务发起的连接请求日志
• 已排查确认项：
  • 仅少量公司内部用户使用，实际并发远低于官方文档标注的200用户上限，不存在高负载
  • 客户端重连逻辑仅会在连接断开后数秒内发起5-10次重连尝试
  • 已尝试重建MQTT服务、重建APIM中的API实例清理残留挂起会话，问题未解决
• 待确认问题：
  • 是否有其他开发者遇到过同类故障
  • 本次429响应是否为APIM侧内部逻辑调整触发

这个故障是2022年6月APIM服务端滚动更新引入的默认规则变更导致的，当时不少使用APIM透传WebSocket、MQTT over WebSocket的用户都碰到了完全一致的问题，和后端实际负载、用户量没有关系。

根因说明 #

• 规则更新前，APIM对WebSocket连接的限流仅统计并发连接总数，阈值和公开文档标注一致：基础版及以下SKU默认支持200个并发WebSocket连接
• 2022年6月的更新中，APIM网关层新增了WebSocket新连接建立速率的默认限流阈值：单实例默认1分钟内最多允许建立100个新WebSocket连接，该规则更新当时未同步到公开文档，也没有在Azure门户提供显式的配置提示
• 客户端在连接异常断开时会在数秒内发起5-10次重连，只要同时有10个左右用户触发重连逻辑，就会直接撞上新连接速率阈值，触发429响应。这类限流是在APIM接入层直接拦截，根本不会转发到后端服务，和观测到的现象完全匹配
• 之前重建服务、API实例没有效果，是因为这个速率限制是APIM网关底层的全局默认配置，重建上层API资源或者后端服务不会修改这个底层规则。

修复步骤 #

1. 进入APIM实例的策略配置页，在对应WebSocket API的入站策略（或全局入站策略）中添加规则，覆盖默认的新连接速率限制，可参考如下策略配置：

<inbound>
    <base />
    <!-- 保留原有的并发连接数限制 -->
    <limit-concurrency key="ws-global-conn" max-count="200">
        <forward-request />
    </limit-concurrency>
    <!-- 覆盖默认新连接速率限制，数值可按实际业务量调整 -->
    <rate-limit-by-key calls="300" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
</inbound>

2. 调整前端MQTT客户端的重连逻辑，增加指数退避间隔，避免连接断开后在极短时间内连续发起重连，触发APIM边缘节点的临时拦截规则
3. 如果当前使用的是消费版APIM SKU，建议升级到标准版及以上：消费版SKU的WebSocket限流阈值在本次更新后比其他SKU更严格，且不支持自定义调整部分底层限流参数。

配置完成后可以在APIM监控面板筛选429状态码的请求，确认失败原因模块是否标记为RateLimit，调整策略后该类错误计数会清零，连接即可恢复正常。

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