Azure WebApp中Https中间件并发负载测试时出现NullReferenceException

你的自定义HTTPS强制中间件在Azure Web App并发测试中触发NullReferenceException，核心原因是Azure Web App的反向代理环境特性以及自定义中间件未覆盖这类边缘场景，导致后续MVC组件访问HttpContext.Items时遇到未初始化的状态。本地Kestrel环境无问题是因为请求直接到达服务器，上下文生命周期管理和状态初始化逻辑与Azure的反向代理场景完全不同。

具体解决方案 #

1. 替换为官方HTTPS中间件（最推荐） #

ASP.NET Core提供的官方中间件已经经过严格测试，完全覆盖Azure环境、并发场景等边缘情况，不需要自行实现：

// 在Startup.cs的Configure方法中，确保在UseMvc之前注册
// 方式一：自动将HTTP请求重定向到HTTPS（遵循HTTP最佳实践）
app.UseHttpsRedirection();

// 方式二：如果你需要直接返回403而非重定向，可使用官方风格的极简实现
app.Use(async (context, next) =>
{
    if (!context.Request.IsHttps && !env.IsDevelopment())
    {
        context.Response.StatusCode = (int)HttpStatusCode.Forbidden;
        await context.Response.WriteAsync("Only secure HTTPS connections permitted.");
        return;
    }
    await next();
});

2. 配置ForwardedHeaders中间件（关键） #

Azure Web App的反向代理会将原始请求的协议（HTTPS）放在X-Forwarded-Proto头中，ASP.NET Core默认不会读取这个头，导致context.Request.IsHttps判断错误，并发场景下会引发上下文状态异常。必须在Startup中添加以下配置：

// 在ConfigureServices中配置选项
services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
    // 允许Azure内部反向代理IP段，避免安全风险
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.0/8"));
    options.KnownProxies.Add(IPAddress.Parse("192.168.0.0/16"));
    options.KnownProxies.Add(IPAddress.Parse("172.16.0.0/12"));
});

// 在Configure方法的最开头注册该中间件（必须早于其他业务中间件）
app.UseForwardedHeaders();

这个配置让ASP.NET Core正确识别来自Azure反向代理的HTTPS请求，确保IsHttps判断准确，同时避免上下文状态异常。

3. 检查中间件注册顺序 #

确保HTTPS校验中间件（自定义或官方）注册在路由、MVC、认证等业务中间件之前，保证所有请求先完成HTTPS校验，避免后续组件处理无效的HTTP请求。

为什么你的自定义中间件会出问题？ #

你的代码逻辑本身没有语法错误，但Azure并发场景下，反向代理环境的上下文状态初始化逻辑与本地不同，官方中间件内置了这类场景的处理逻辑，包括并发下的上下文安全访问，而你的自定义实现未覆盖这些细节。

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