We have enabled SignalR on our ASP.NET Core 5.0 web project running on an Azure Web App (Windows App Service Plan). Our SignalR client is an Angular client using the @microsoft/signalr NPM package (version 5.0.11).

We have a hub located at /api/hub/notification.

Everything works as expected for most of our clients, the web socket connection is established and we can call methods from client to server and vice versa.

For a few of our clients, we see a massive amount of requests to POST /api/hub/notification/negotiate and POST /api/hub/notification within a short period of time (multiple requests per minute per client). It seems like that those clients switch to long polling instead of using web sockets since we see the POST /api/hub/notification requests.

We have the suspicion that the affected clients could maybe sit behind a proxy or a firewall which forbids the web sockets and therefore the connection switches to long polling in the first place.

The following screenshot shows requests to the hub endpoints for one single user within a short period of time. The list is very long since this pattern repeats as long as the user has opened our website. We see two strange things:

1. The client repeatedly calls /negotiate twice every 15 seconds.
2. The call to POST /notification?id=<connectionId> takes exactly 15 seconds and the following call with the same connection ID returns a 404 response. Then the pattern repeats and /negotiate is called again.

For testing purposes, we enabled only long polling in our client. This works for us as expected too. Unfortunately, we currently don't have access to the browsers or the network of the users where this behavior occurs, so it is hard for us to reproduce the issue.

Some more notes:

1. We currently have just one single instance of the Web App running.
2. We use the Redis backplane for a scale-out scenario in future.
3. The ARR affinity cookie is enabled and Web Sockets in the Azure Web App are enabled too.
4. The Web App instance doesn't suffer from high CPU usage or high memory usage.
5. We didn't change any SignalR options except of adding the Redis backplane. We just use services.AddSignalR().AddStackExchangeRedis(...) and endpoints.MapHub<NotificationHub>("/api/hub/notification").
6. The website runs on HTTPS.

• What could cause these repeated calls to /negotiate and the 404 returns from the hub endpoint?
• How can we further debug the issue without having access to the clients where this issue occurs?

Update

We now implemented a custom logger for the @microsoft/signalr package which we use in the configureLogger() overload. This logger logs into our Application Insights which allows us to track the client side logs of those clients where our issue occurs.

The following screenshot shows a short snippet of the log entries for one single client.

We see that the WebSocket connection fails (Failed to start the transport "WebSockets" ...) and the fallback transport ServerSentEvents is used. We see the log The HttpConnection connected successfully, but after pretty exactly 15 seconds after selecting the ServerSentEvents transport, a handshake request is sent which fails with the message from the server Server returned handshake error: Handshake was canceled. After that some more consequential errors occur and the connection gets closed. After that, the connection gets established again and everything starts from new, a new handshare error occurs after those 15 seconds and so on.

Why does it take so long for the client to send the handshake request? It seems like those 15 seconds are the problem, since this is too long for the server and the server cancels the connection due to a timeout.

We still think that this has maybe something to to with the client's network (Proxy, Firewall, etc.).

Fiddler

We used Fiddler to block the WebSockets for testing. As expected, the fallback mechanism starts and ServerSentEvents is used as transport. Opposed to the logs we see from our issue, the handshake request is sent immediately and not after 15 seconds. Then everything works as expected.