Fixing Blazor Server reconnects behind Azure Application Gateway (WebSocket issue)

Introduction:

Recently, I faced an interesting challenge while deploying a .NET Blazor Server application in an IIS Windows Server that sits behind an Azure Application Gateway. The app appeared to load fine at first, but after about 20 seconds, it would suddenly lose connection and attempt to reconnect. Each time, the browser displayed a warning stating that it had failed to connect via WebSockets and was switching to long polling instead. Most sources recommend increasing the Azure application gateway backend settings timeout, but I’m not comfortable with this approach. After conducting thorough troubleshooting, I discovered that although Azure Application Gateway already supports WebSockets, the IIS server hosting my app did not have the WebSocket Protocol feature enabled. Once I enabled it, the connection stabilized, and the issue was fully resolved.

Why Blazor Server needs WebSockets?

Blazor Server maintains a persistent, real-time connection between the browser and the server to push UI updates and receive events. SignalR is the underlying library that manages that connection. SignalR prefers WebSockets (low latency, full-duplex). When WebSockets are unavailable, SignalR falls back to Server-Sent Events or Long Polling, which is slower and can cause frequent reconnects if intermediate timeouts are short (for example, when a proxy or gateway has a relatively low backend timeout like 20 seconds).

When the browser logs the WebSocket failure + fallback message, it means SignalR couldn’t establish a WebSocket transport and fell back. That fallback can still work but is more fragile behind gateways and can trigger reconnect loops when the gateway backend idle/timeouts are short.

Reproducing the Issue

• Blazor Server app is served through Azure Application Gateway.
• Every 20 seconds, the client showed the reconnecting overlay (Attempting to reconnect to the server…).
• Browser console: Warning: Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection.
• Application Gateway backend HTTP settings had an idle timeout of 20 seconds.
  
  
  

Root cause

Azure Application Gateway supports WebSockets out of the box; however, the IIS Windows Server hosting the app did not have the WebSocket Protocolfeature enabled. Without that feature, IIS blocks or does not correctly upgrade connections to WebSockets, forcing SignalR to fall back to long polling. With the gateway’s 20s time,out the long-polling connection lifecycle caused repeated reconnects.

Step-by-step to diagnose

1. Check the browser console the warning about failing to connect via WebSockets is the primary clue.
2. Open network tab in devtools while loading the app and look for the SignalR negotiate/connect requests and their responses. Long Polling requests will show repeated HTTP calls.
3. Check Application Gateway: verify HTTP settings and the backend health probes. Note Backend HTTP settings, specifically the request timeout (if short, itcan cause reconnects during long-polling).
4. Check IIS server features: open Server Manager → Add Roles and Features → Web Server (IIS) → Application Development, and confirm WebSocket Protocol is installed.
5. Check IIS logs / Event Viewer for failed upgrade attempts (HTTP 101 upgrade events) or other errors.

Step-by-step: how to fix (Windows Server / IIS)

These steps assume you control the Windows server running IIS and can install features and edit the configuration.

Enable WebSocket Protocol

• Open Server Manager on the Windows Server.
• Select Add roles and features.
• Proceed to Server Roles → expand Web Server (IIS) → Web Server → Application Development.
• Check WebSocket Protocol and finish the wizard.
  
  
• Restart the server or at least restart IIS: iisreset.

Restart IIS and test

• Run iisreset or restart the App Pool for your site.
• Clear browser cache (or use an Incognito window) and load the app. Watch the console and network tab, SignalR should connect via WebSockets.

Application Gateway considerations

• WebSockets are supported by Azure Application Gateway by design; no extra toggle is normally required.
• However, backend HTTP settings include a request timeout / idle timeout. If your gateway is configured to close backend connections aggressively (for example 20 seconds), and the app falls back to long polling, frequent reconnects are likely. Consider increasing the backend timeout if your app cannot use WebSockets immediately.
• Confirm health probes and backend settings are correct and that SSL/TLS termination and header forwarding are configured as you expect.

If, after enabling the WebSocket protocol and confirming Application Gateway settings, you still see reconnects, check for intermediate proxies (corporate proxies, VPNs) that may block or disrupt WebSocket traffic, and validate TLS settings and header forwarding. If you want, I can provide a troubleshooting checklist tailored to your exact environment (IIS

Summary:

Through this article, we learned that when hosting a Blazor Server application behind Azure Application Gateway, maintaining a stable real-time connection depends heavily on proper WebSocket configuration. Although Azure Application Gateway supports WebSockets by default, the backend IIS server also requires the WebSocket Protocol feature to be enabled for the app to function smoothly. Without it, Blazor falls back to long polling, leading to frequent disconnections and reconnections, especially when the gateway has a short backend timeout setting. Once the WebSocket Protocol feature on the IIS server is enabled, the connection remains stable, and the application operates smoothly behind the gateway.

I hope you enjoyed reading this article and found it useful. Please share your thoughts or feedback in the comments. I’d love to hear from you!