SignalR "Error during WebSocket handshake" sometimes

Question

My application is having issues accepting the handshake about half the time in my production environment. On my local machine and in my staging environment, which is the same as production, it works every time.

It is a .Net Core 2.1 app using aspnet-signalr/1.1.4

I am not configuring SignalR to use any specifics in my startup.s

app.UseSignalR(routes => { routes.MapHub<PortfolioHub>("/loadpagedetailsjob"); });

app.UseMvc(routes =>
{
    routes.MapRoute(
        name: "default",
        template: "{controller=Dashboard}/{action=Index}/{id?}");
});

my PortfolioHub is just a direct implementation of the Hub class

and in my page

var connection = new signalR.HubConnectionBuilder()
    .withUrl('/loadpagedetailsjob')
    .configureLogging(signalR.LogLevel.Information)
    .build();

connection.start().then(function () {
    connection.invoke("Subscribe");
});

It looks like it tries to negotiate web socket then long polling and both fail. But the requests return 200

Since it is only happening sometimes I am having issues resolving the issue. My only suspicion at this point is since my environment is in AWS behind a load balance that the negotiate requests are routed to different servers which might cause the issue?

Any help is appreciated.

@ChristophLütjen no it looks like it is disabled. And I found that my Staging environment only has 1 task instance while prod has 2. I updated staging to 2 instances and the problem arose. Now I am not a DevOps person and don't have control over our AWS instance. Do you know of any negatives for using Sticky Sessions, as I am going to need to convince someone to turn it on. — A. Hasemeyer
@ChristophLütjen that was the issue, I got it changed in AWS and all is right again. Thanks! — A. Hasemeyer
In general, sticky sessions will simply ensure that one client will use the same server for all requests - works, no problems. But... in general it's "not nice" if the app requires users to stay on one instance. There will be problems when deploying new versions and when scaling the cluster. — Christoph Lütjen
@ChristophLütjen please add your resolution as answer since it worked to the OP. — Kiril1512

Christoph Lütjen Christoph Lütjen · Accepted Answer · 2020-03-09T16:30:18

SignalR requires that one connection is always handled by the same server. The typical solution is to configure the load balancer to use sticky sessions. With sticky sessions enabled, the load balancer will route requests of the same user to the same backend server.

https://docs.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-3.1

SignalR "Error during WebSocket handshake" sometimes

1 Answers