ASP.NET Core首次错误时错误处理方法未触发，后续正常、超时后复现

听起来你遇到的这个问题挺棘手的——首次请求（或会话超时后的首次请求）出现错误时，UseStatusCodePagesWithReExecute完全没反应，后续请求却正常，甚至换UseStatusCodePagesWithRedirects也一样。结合你提到的会话超时关联现象，我来分享几个排查方向和解决方案：

1. 先检查中间件的注册顺序（最常见原因） #

ASP.NET Core的中间件管道是严格按顺序执行的，如果UseStatusCodePagesWithReExecute的位置不对，前面的中间件可能直接返回了响应，根本没给它触发的机会。

正确的顺序应该是：

• 先注册异常处理中间件（UseExceptionHandler/UseDeveloperExceptionPage）
• 然后注册状态码页面中间件（UseStatusCodePagesWithReExecute）
• 再注册路由、认证、授权、静态文件等其他中间件

示例代码：

var app = builder.Build();

// 异常处理先上
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

// 状态码页面必须在Routing、Authorization之前！
app.UseStatusCodePagesWithReExecute("/Error/{0}");

// 后面才是其他中间件
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseSession(); // 如果用会话，需在路由之前注册
app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

如果之前把状态码页面放在了UseAuthorization之后，那首次401错误会被授权中间件直接返回响应，状态码页面根本没机会介入。

2. 排查认证中间件是否提前结束了响应 #

针对你提到的401初始错误，大概率是认证中间件（比如Cookie认证）在处理未授权请求时，直接结束了响应流程，没留给状态码页面中间件处理的空间。

以Cookie认证为例，默认情况下它会跳转登录页，而不是返回401状态码，或者直接调用了Response.CompleteAsync()提前终止响应。你可以自定义认证事件，让它只设置状态码，不提前结束：

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Events = new CookieAuthenticationEvents
        {
            OnRedirectToLogin = context =>
            {
                // 不要跳转，直接设置401状态码，交给状态码页面处理
                context.Response.StatusCode = StatusCodes.Status401Unauthorized;
                return Task.CompletedTask;
            }
        };
    });

这样授权中间件只会设置状态码，不会提前终止响应，状态码页面中间件就能正常触发了。

3. 检查错误页面是否依赖未初始化的会话/服务 #

你提到会话超时后首次请求会复现问题，那可能你的错误处理页面（比如/Error/{0}）依赖了HttpContext.Session，但首次请求时会话还没初始化，导致页面抛出异常，看起来像是状态码页面没触发。

解决办法：

• 如果错误页面不需要会话，直接移除相关代码
• 如果必须用会话，确保UseSession中间件在UseStatusCodePagesWithReExecute之前注册
• 在错误页面中添加会话是否存在的判断，避免抛出异常：

public IActionResult Error(int statusCode)
{
    if (HttpContext.Session.IsAvailable)
    {
        // 处理会话相关逻辑
    }
    // 其他错误处理代码
    return View();
}

4. 跟踪中间件管道的执行流程 #

如果以上方法都没解决，你可以添加一个自定义中间件，跟踪每个环节的响应状态码变化，看首次请求时哪个中间件提前拦截了响应：

app.Use(async (context, next) =>
{
    Console.WriteLine($"进入中间件：{context.Request.Path}，初始状态码：{context.Response.StatusCode}");
    await next();
    Console.WriteLine($"离开中间件：{context.Request.Path}，最终状态码：{context.Response.StatusCode}");
});

// 把这个中间件放在最前面，然后依次是异常处理、状态码页面等中间件

运行后查看控制台日志，就能清楚看到首次请求时，哪个环节修改了状态码或者提前结束了响应。

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