.NET 6 Web API中Gzip响应压缩失效及自定义中间件异常求助

一、官方ResponseCompression中间件失效问题排查 #

你的基础配置逻辑正确，但部署在IIS环境下，压缩失效通常由以下几个原因导致：

1. IIS压缩设置冲突 #

IIS自带动态压缩、静态压缩功能，若IIS已启用对应压缩规则，可能会直接接管压缩逻辑，导致.NET中间件失效。

• 解决：在IIS管理器中找到目标站点，进入「压缩」功能，暂时禁用动态压缩后测试；或调整.NET中间件注册顺序，确保其优先处理请求。

2. 中间件顺序错误 #

UseResponseCompression必须在路由、端点映射中间件之前注册，且在UseStaticFiles之后（若使用静态文件）。正确示例：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    // 必须在UseRouting之前注册
    app.UseResponseCompression();

    app.UseRouting();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

3. 未显式配置压缩提供者（部分场景需要） #

.NET 6默认包含Gzip压缩提供者，但部分环境下需显式声明确保生效：

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.EnableForHttps = true;
        options.Providers.Add<GzipCompressionProvider>();
        // 补充需要压缩的MIME类型，默认已包含text/*、application/json等
        options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[] { "application/xml" });
    });

    // 配置压缩级别
    services.Configure<GzipCompressionProviderOptions>(options =>
    {
        options.Level = CompressionLevel.Optimal;
    });
}

4. 响应未满足压缩条件 #

• 默认仅对大小超过200字节、MIME类型在默认列表内的响应进行压缩，若API返回特殊类型，需手动添加到options.MimeTypes。
• 若响应过小（如小于200字节），压缩收益极低，中间件会自动跳过压缩。

二、自定义Gzip中间件“cannot access closed stream”异常修复 #

你的自定义中间件存在流处理逻辑错误，导致异常触发：

1. 核心问题分析 #

• 调用await _next(context)后，后续中间件可能已关闭原始响应流originalBodyStream，导致后续无法写入。
• 未正确处理GZipStream的刷新与释放，且未移除原Content-Length头（压缩后响应长度已变化）。
• 检查响应头自定义字段的逻辑不符合HTTP压缩规范，应检查请求头Accept-Encoding。

2. 修复后的中间件代码 #

public class ConditionalCompressionMiddleware
{
    private readonly RequestDelegate _next;
    public ConditionalCompressionMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        var request = context.Request;
        var response = context.Response;

        // 检查请求头是否支持gzip压缩
        var acceptEncoding = request.Headers.AcceptEncoding.ToString();
        if (!string.IsNullOrEmpty(acceptEncoding) && acceptEncoding.Contains("gzip", StringComparison.OrdinalIgnoreCase))
        {
            var originalBodyStream = response.Body;
            using var memoryStream = new MemoryStream();
            response.Body = memoryStream;

            try
            {
                // 执行后续中间件，将响应写入内存流
                await _next(context);

                // 仅对成功状态码的响应进行压缩
                if (response.StatusCode >= 200 && response.StatusCode < 300)
                {
                    memoryStream.Position = 0;
                    // 更新响应头
                    response.Headers.ContentEncoding = "gzip";
                    response.Headers.Remove("Content-Length");

                    // 使用await using自动管理GZipStream生命周期，确保刷新与释放
                    await using var compressedStream = new GZipStream(originalBodyStream, CompressionLevel.Optimal);
                    await memoryStream.CopyToAsync(compressedStream);
                    await compressedStream.FlushAsync();
                }
                else
                {
                    // 非成功响应直接转发原始内容
                    memoryStream.Position = 0;
                    await memoryStream.CopyToAsync(originalBodyStream);
                }
            }
            finally
            {
                // 确保原始响应流始终被恢复
                response.Body = originalBodyStream;
            }
        }
        else
        {
            await _next(context);
        }
    }
}

3. 关键修复点 #

• 改为检查请求头Accept-Encoding，符合HTTP压缩规范流程。
• 使用try-finally确保原始响应流始终被恢复，避免流泄漏。
• 用await using自动管理GZipStream，确保流被正确刷新和释放。
• 移除原Content-Length头，压缩后长度由服务器自动处理。
• 仅对成功状态码的响应进行压缩，避免无效处理错误响应。

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