Hi Fredle Coper,
From what you’ve described, the fact that connections drop every few minutes despite keep‑alive settings usually points to an idle timeout somewhere in the chain rather than the WebSocket protocol itself. IIS by default has limits on request timeouts, and if you’re using Application Request Routing (ARR) or a load balancer in front, each of those components can impose their own idle‑timeout values.
A good first step is to check the IIS site’s advanced settings for connection timeouts and ensure that WebSocket support is enabled with sufficient limits. If ARR is in play, review the proxy timeout settings, ARR often defaults to 2 minutes, which matches the behavior you’re seeing. Similarly, many load balancers (F5, Azure Front Door, etc.) have idle‑timeout values that need to be extended for long‑lived WebSocket sessions.
It’s also worth confirming that your keep‑alive pings are being sent frequently enough to reset those timers. Sometimes the application sends them at the protocol level but they don’t reach the proxy layer, so adjusting the interval can help. Capturing a network trace during the drop will show whether the reset is happening at IIS, ARR, or the load balancer.
I hope this gives you a clear path forward. If this explanation helps, please hit “accept answer”.
Jason.