WebSockets and SignalR
Real-time connections are supported out of the box; what to check when clients disconnect.
WebSockets, and with them ASP.NET Core SignalR and Blazor Server, work on every website — Free and Premium. There is nothing to enable in the Control Panel and no special server configuration is needed.
What is supported
| Free | Premium | |
|---|---|---|
WebSockets (wss://) and SignalR |
Yes | Yes |
| Blazor Server | Yes | Yes |
| Connection to Azure SignalR Service | Yes | Yes |
| Limit on the number or duration of connections | No fixed limit | No fixed limit |
| AlwaysRunning application pool | No | On request |
| Redis backplane, Centrifugo or other separate real-time servers | No | No |
There is no fixed limit on how many WebSocket connections a website can keep open or how long one connection can last. The practical limit is the CPU and memory of your plan: every open connection costs memory, and the server restarts an application that exceeds its memory limit.
Before you start
Enable HTTPS
WebSocket connections from a browser run over
wss://, which needs a working certificate. Enable HTTPS for the domain first — see Enable HTTPS with Let's Encrypt.Use the standard configuration
In an ASP.NET Core application nothing beyond the usual
app.MapHub<MyHub>("/hub")is required. Keep the default transports; SignalR falls back to Server-Sent Events or long polling by itself when a client cannot use WebSockets.Keep connections alive
Use the default SignalR keep-alive (15 seconds) or a slightly longer value, for example
KeepAliveInterval = 30 swithClientTimeoutInterval = 60 s. Keep-alive frames prevent mobile networks and proxies from closing a connection they consider idle.
Frequent disconnections
If clients drop at random, look at the website first — the cause is almost always a restart of the application:
- Memory limit. Open Resources and Logs in the Control Panel. If the application reaches its memory limit, the server restarts it and every connection is closed. Lower the memory usage or increase the memory. Switching the website to 64-bit on the Scripting page helps applications that hold many connections.
- Idle timeout. After 3 hours without any HTTP request the application is stopped. Active WebSocket traffic normally keeps it alive; for an application that must stay up regardless of traffic, ask for AlwaysRunning (Premium).
- Deployments and configuration changes restart the application as well — see Application keeps restarting.
Connections that close after exactly the same time (for example 120 seconds) with a clean close code are ended by one of the two applications, not by the server — typically a timer, a CancellationToken or a client reconnect logic. There is no proxy in front of your website and the IIS connection timeout does not apply to WebSockets.
Scaling to many users
A single website keeps all connections in one process. For a few hundred concurrent users this is fine; for thousands of simultaneous connections — an exam with 1 000 students at the same moment, a live auction — use Azure SignalR Service. Your application only keeps a connection to Azure, which handles the clients. Outbound connections to Azure SignalR are not restricted.
We do not provide Redis or another backplane, and separate real-time servers (Centrifugo, Socket.IO servers running as their own process) cannot be installed on shared hosting.