如何在Azure APIM中阻止客户端发送Gzip压缩请求？

阿华AIGC实验室

2026-5-6

针对你遇到的Cloudflare拦截Gzip压缩POST请求的问题，把解决重心放在APIM里确实是最优选择——毕竟涉及多个移动端客户端，改APIM比挨个改客户端高效多了。我整理了几个可行的方法，帮你强制客户端不再发送Gzip压缩请求：

方案1：通过入站策略修改协商头，引导客户端放弃Gzip

APIM的入站策略可以直接干预请求头，我们可以检查客户端发送的Accept-Encoding头，如果包含gzip，就把它移除或者替换掉，同时在响应里返回明确的头信息，告知客户端我们不支持Gzip压缩，这样后续客户端就会调整请求方式。

具体的策略代码可以这么写：

<policies>
    <inbound>
        <!-- 移除Accept-Encoding中的gzip标识 -->
        <set-header name="Accept-Encoding" exists-action="override">
            <value>@{
                var acceptEncoding = context.Request.Headers.GetValueOrDefault("Accept-Encoding", "");
                return acceptEncoding.Replace("gzip", "").Trim(',', ' ');
            }</value>
        </set-header>
        <!-- 响应头明确告知不使用压缩 -->
        <set-header name="Content-Encoding" exists-action="override">
            <value></value>
        </set-header>
    </inbound>
    <backend>
        <forward-request />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

这个方法的好处是温和引导，不会直接中断客户端请求，还能逐步让客户端适配，不需要客户端做代码改动。

方案2：直接拦截Gzip请求，返回明确错误提示

如果希望快速纠正客户端的行为，可以在APIM里直接检查请求的Content-Encoding头，如果是gzip，就返回400错误，附带清晰的错误信息，让客户端开发人员立刻知道需要调整请求格式。

策略代码示例：

<policies>
    <inbound>
        <choose>
            <when condition="@(context.Request.Headers.GetValueOrDefault("Content-Encoding", "").Equals("gzip", StringComparison.OrdinalIgnoreCase))">
                <return-response>
                    <set-status code="400" reason="Bad Request" />
                    <set-body>@{
                        return "{\"error\": \"不支持Gzip压缩的请求体，请发送未压缩的内容\"}";
                    }</set-body>
                    <set-header name="Content-Type" exists-action="override">
                        <value>application/json</value>
                    </set-header>
                </return-response>
            </when>
        </choose>
    </inbound>
    <backend>
        <forward-request />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

这个方案适合需要快速推进修复的场景，错误信息明确，客户端开发能马上定位问题。

方案3：精准配置策略，只影响受影响的API

如果不是所有API都存在这个问题，你可以针对特定的API或产品单独配置上述策略。进入APIM的目标API编辑页面，在「设计」标签下的「策略」模块里添加规则，这样不会影响其他正常业务的API请求。

额外小建议

在正式环境应用策略之前，建议先在测试环境验证客户端的表现。有些客户端可能会忽略Accept-Encoding的修改，这时候可以结合方案2的强制拦截来推动调整。另外，如果条件允许，也可以和客户端开发团队沟通，在客户端层面直接关闭Gzip压缩请求，从源头解决问题——不过既然你优先考虑APIM层面，前面的方案应该能很好地解决你的问题。

内容的提问来源于stack exchange，提问作者Jean-Paul Smit