Azure APIM rate-limit-by-key异常：触发限制时返回非预期响应

问题现象 #

直接在rate-limit-by-key策略的counter-key中使用@(context.Request.IpAddress)或@(context.Request.IpAddress.ToString())时，触发限流偶尔返回500 Internal Server Error或401 Unauthorized，而非预期的429 Too Many Requests；但先通过set-variable将context.Request.IpAddress存入变量，再从变量取值时，能稳定返回预期的429响应。

可能原因分析 #

• 上下文初始化时机差异：rate-limit-by-key的表达式执行时机可能早于context.Request.IpAddress的完全初始化，直接调用时可能获取到空值或无效对象，引发内部错误（500），甚至触发前置认证策略的异常（401）；而set-variable通常在更早的策略阶段执行，此时IP地址已完成解析，存入变量后取值更稳定。
• 类型转换隐式异常：context.Request.IpAddress是IPAddress类型，直接在策略表达式中使用时，某些边缘场景（如代理转发的IP解析延迟）可能导致隐式类型转换失败，使计数器键值异常，触发非预期响应；变量存储的是快照值，APIM内部会做更稳定的类型处理。
• 上下文状态一致性问题：直接使用context.Request.IpAddress时，后续策略可能修改请求属性，导致计数器逻辑异常；变量存储的是固定快照，避免了上下文状态变化的影响。

解决思路 #

• 沿用变量中转方案：既然set-variable的方式能稳定工作，继续采用该方案，确保计数器键值的稳定性。
• 添加空值校验逻辑：若要直接使用context.Request.IpAddress，需在表达式中增加空值判断，避免IP未解析完成导致的异常，示例：

  <rate-limit-by-key calls="1" renewal-period="2" counter-key="@(context.Request.IpAddress?.ToString() ?? "unknown-ip")" increment-condition="@(context.Response.StatusCode == 200)" />
  

• 调整策略执行顺序：确保rate-limit-by-key策略的执行位置在context.Request.IpAddress能正确获取的阶段（如避免在inbound阶段最早期执行，此时IP可能尚未被APIM完全解析）。
• 启用APIM日志排查：开启APIM的Backend、Gateway等详细日志类别，查看触发500/401时的具体错误信息，定位是IP解析失败、计数器逻辑异常还是其他策略冲突导致的问题。

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