Question

我有一个.NET Core 2.1 Web API（使用2.1.0-preview1-final）在本地使用SignalR 1.0.0-preview1-final正常工作。我在前端使用了一个包含"@aspnet/signalr": "1.0.0-preview1-final"的Angular应用程序，所以一切都匹配，当我在本地运行程序时，我有两个HTTP端点和Hub正常工作。

当我部署到我的虚拟服务器时，我有一个Nginx反向代理，它向其后面的所有应用程序发送请求。我正在使用Docker，当我们部署整个生态系统的v1.0时，我在其他项目中没有遇到任何问题。

我在这个特定场景中的差异有两个：

我使用AspNetIdentity拥有IdentityServer4，并且必须从Nginx配置中删除proxy_buffering off选项才能使其正常工作（https://andrewlock.net/fixing-nginx-upstream-sent-too-big-header-error-when-running-an-ingress-controller-in-kubernetes/之后）
我正在阅读你不应该这样做1）使用SignalR因为你可能遇到问题 - 不确定现在是不是这样。

我正在捕获API的日志，我可以看到，当我尝试连接到集线器时，我会回来：

info: Microsoft.AspNetCore.Cors.Infrastructure.CorsService[4]
      Policy execution successful.
info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[2]
      Successfully validated the token.
info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[1]
      Authorization was successful.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 7.4652ms 200 application/json

所以我认为这是正确的。现在在客户端（Angular app）：我看到了：

错误：无法启动连接。错误：找不到可用的传输。

但如果我检查一下回复：

{"connectionId":"nHzKKYtp0ITwlEntjqLprA","availableTransports":[{"transport":"WebSockets","transferFormats":["Text","Binary"]},{"transport":"ServerSentEvents","transferFormats":["Text"]},{"transport":"LongPolling","transferFormats":["Text","Binary"]}]}

更新

比较本地运行时的响应：

{"connectionId":"4ea7b1ea-8754-472b-baef-527073872d2a","availableTransports":["WebSockets","ServerSentEvents","LongPolling"]}

这意味着传输格式没有限制吗？不确定这是否相关...这很奇怪，这与此处发生的事情相同：SignalR no transport

------更新结束--------

所以我的问题是：

我是否破坏了SignalR连接，因为我设置了proxy_buffer？如果是这样，有没有办法让IS4和SignalR在同一个Nginx实例后面运行？ - 为了让事情变得更加困难，我正在使用一个使用docker-gen自动生成的Nginx模板。

如果我对Nginx的更改不应该破坏SignalR，为什么不建立连接？

谢谢！

UPDATE！发现问题!!!

我这样写是因为我觉得这对其他人有用。

我遇到的问题是我在客户端和API上都使用了preview1，但是当我创建Dockerfile时，我无法让FROM microsoft/dotnet:2.1.0-preview1-aspnetcore-runtime工作，所以我选择了使用preview2：FROM microsoft/dotnet:2.1.0-preview2-aspnetcore-runtime这就是问题所在。现在我迅速更改了客户端和API以使用SignalR的预览，我可以使连接工作。快乐的时光！希望这有用:)所以不仅客户端和API需要匹配，但实际的docker镜像也需要对齐。

Answer 1

我遇到的问题是我在客户端和API上都使用了preview1，但是在我创建Dockerfile的那天，我无法使用FROM microsoft/dotnet:2.1.0-preview1-aspnetcore-runtime，因为我遇到了元数据问题（取自错误）所以我选择使用preview2：FROM microsoft/dotnet:2.1.0-preview2-aspnetcore-runtime，这就是问题所在。现在我快速更改了客户端和API以使用SignalR的预览，我可以使连接正常工作。快乐的时光！希望这有用:)所以不仅客户端和API需要匹配，但实际的docker镜像也需要对齐。

因此，在创建图像时，请确保您已同步客户端版本，net Coresignalrversión以及Dockerfile的运行时版本

SignalR .NET Core 2.1无法在代理的docker容器

1 个答案: