YARP反向代理中非200状态码响应丢失问题解析

问题背景

在使用YARP(Yet Another Reverse Proxy)构建中转服务时，开发人员遇到了一个典型的问题：当目标服务器返回非2xx状态码(如400)时，客户端却收到了500错误响应，而代理日志中显示确实接收到了目标服务器的400响应。这种现象会导致客户端无法获取原始的错误信息，给问题排查带来困难。

问题现象分析

该问题出现在一个多租户系统中，系统需要根据请求动态决定是否将请求中转其他区域的服务器。具体表现为：

1. 当目标服务器返回200状态码时，中转工作正常，客户端能正确接收响应
2. 当目标服务器返回400等非2xx状态码时，中转日志显示接收到了正确的状态码，但客户端却收到500错误
3. 系统使用了请求缓冲中间件，并在自定义异常过滤器中进行请求转发

根本原因

问题的核心在于ASP.NET Core的异常处理机制。在自定义异常过滤器OnExceptionAsync中，虽然开发人员正确调用了中转服务进行请求转发，但遗漏了一个关键设置：没有明确告知MVC框架该异常已被处理。

具体来说，缺少了以下代码：

context.ExceptionHandled = true;

由于这个遗漏，MVC框架在异常过滤器执行完毕后，仍然认为这是一个未处理的异常，于是继续执行默认的异常处理流程，最终返回了500错误响应，覆盖了中转返回的原始状态码。

解决方案

修复方法很简单，只需在异常过滤器中明确标记异常为已处理状态：

public override async Task OnExceptionAsync(ExceptionContext context)
{
    if (context.Exception is TenantMigratedException tenantMigratedException)
    {
        context.HttpContext.Request.Body.Position = 0;
        await _forwardingService.ForwardRequestAsync(context.HttpContext, tenantMigratedException.Region);
        context.ExceptionHandled = true; // 关键修复
        return;
    }
    // 其他异常处理...
}

技术要点

1. 异常过滤器执行流程：在ASP.NET Core中，异常过滤器执行后，框架会检查ExceptionHandled属性，如果为false，将继续执行默认异常处理。

2. 请求缓冲与转发：在使用请求缓冲中间件时，需要注意重置请求体的位置(Position = 0)，确保中转能正确读取请求内容。

3. YARP中转行为：YARP本身能正确转发各种状态码的响应，问题出在更高层的异常处理机制覆盖了这些响应。

最佳实践建议

1. 在使用异常过滤器进行请求转发时，始终记得设置ExceptionHandled = true
2. 对于请求转发场景，建议添加详细的日志记录，包括原始响应状态码和内容
3. 考虑使用专门的中间件而不是异常过滤器来处理请求转发，可以避免这类问题
4. 在开发阶段，可以添加诊断中间件来验证响应是否被意外修改

总结

这个问题展示了框架各层之间交互时可能出现的不明显问题。通过理解ASP.NET Core的异常处理机制和YARP的工作方式，我们能够快速定位并解决这类中转响应被覆盖的问题。关键在于认识到异常过滤器只是异常处理管道的一部分，需要明确告知框架异常是否已被完全处理。