YARP反向代理中WebSocket连接问题的分析与解决

在基于YARP（Yet Another Reverse Proxy）构建的反向代理系统中，开发人员可能会遇到WebSocket连接失败的问题。本文将深入分析这一问题的成因，并提供解决方案。

问题现象

在典型的开发环境中，我们可能会构建如下架构：

1. 前端使用Angular开发，运行在独立的开发服务器上
2. 中间层使用.NET API作为SPA宿主
3. 最外层使用YARP作为反向代理

当启用Angular的实时重载(live-reload)功能时，浏览器会尝试建立WebSocket连接（通常路径为/ng-cli-ws），但连接会失败，控制台显示"WebSocket connection failed"错误。

问题根源

经过深入排查，发现问题的根本原因在于中间层.NET API中配置的Spa防伪中间件（Antiforgery middleware）。该中间件默认会拦截所有请求并验证XSRF-TOKEN，但对于WebSocket升级请求（状态码101）这类特殊请求，中间件会静默拦截而不产生任何日志记录，导致开发者难以发现问题所在。

解决方案

针对这一问题，我们有以下几种解决方案：

1. 调整防伪中间件配置： 在.NET API中，可以配置防伪中间件排除WebSocket相关的路径：

   services.AddAntiforgery(options => 
   {
       options.Filter = context => !context.Request.Path.StartsWithSegments("/ng-cli-ws");
   });
   

2. 分离WebSocket路由： 将WebSocket相关的路由与普通API路由分开处理，确保WebSocket连接不受防伪验证影响。

3. 开发环境特殊处理： 仅在开发环境中禁用相关安全措施（需谨慎评估安全风险）：

   if (env.IsDevelopment())
   {
       services.AddAntiforgery(options => options.SuppressXFrameOptionsHeader = true);
   }
   

最佳实践建议

1. 日志记录：确保在开发环境中启用详细的请求日志记录，这有助于快速定位类似问题。

2. 环境区分：明确区分开发和生产环境的配置，开发环境可以适当放宽安全限制以方便调试。

3. 中间件顺序：注意中间件的执行顺序，确保WebSocket相关的中间件在安全相关中间件之前执行。

总结

YARP本身对WebSocket的支持是开箱即用的，不需要特殊配置。但在实际应用中，其他中间件可能会影响WebSocket的正常工作。遇到类似问题时，开发者应该：

• 检查中间件管道配置
• 启用详细日志
• 特别注意安全相关中间件的影响

通过合理的配置和问题排查方法，可以确保WebSocket在YARP反向代理架构中正常工作，为开发体验提供更好的支持。