Azure速率限制策略针对指定订阅未按预期生效问题排查

你的配置逻辑方向是对的，但指定订阅仍被限流，主要有以下几个可能原因及对应解决方法：

1. 条件判断未正确匹配 #

APIM中订阅名称区分大小写，如果实际订阅名称和配置的someName/otherName大小写不一致，会导致<when>条件不触发，进而进入<otherwise>执行限流。

验证方法 #

在<when>块中添加<trace>策略，输出当前订阅名称确认匹配情况：

<choose>
    <when condition="@(context.Subscription.Name=="someName")">
        <trace source="SubscriptionCheck" severity="information" message="匹配到订阅: @(context.Subscription.Name)" />
    </when>
    <when condition="@(context.Subscription.Name=="otherName")">
        <trace source="SubscriptionCheck" severity="information" message="匹配到订阅: @(context.Subscription.Name)" />
    </when>
    <otherwise>
        <rate-limit calls="50" renewal-period="300" remaining-calls-variable-name="remainingCallsPerSubscription" />
    </otherwise>
</choose>

之后通过APIM跟踪日志查看输出，确认订阅名称是否和配置一致。

2. 消费模式的平台默认限流 #

消费层（Consumption Model）的APIM有平台级默认速率限制（比如单订阅每分钟1000次调用、单API每秒100次调用等），这个限制是平台强制的，无法通过自定义策略绕过。你看到的限流可能不是自己配置的50次/300秒，而是平台默认限制触发的。

区分方法 #

查看限流错误信息：

• 自定义策略触发的限流：错误信息会包含你配置的remainingCallsPerSubscription变量相关内容
• 平台默认限流：错误信息会显示类似Rate limit is exceeded. Try again in X seconds.的提示

3. 策略位置或其他限流规则冲突 #

如果入站策略中，在这个<choose>块之后还有其他<rate-limit>或<rate-limit-by-key>策略，那么即使<choose>跳过了自定义限流，后续的限流规则依然会生效。

解决方法 #

检查整个入站策略的执行顺序，确保所有限流规则都被包含在<choose>逻辑中，或移除不必要的重复限流配置。

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