Websocket Connection Error (was working a day ago)

Question

Websocket Connection Error (was working a day ago)

David Dong 20

I have been running an Azure Web App (Windows) successfully for months with websockets on and yesterday I started receiving Websocket connection error 403s, which prevents my app from starting (it uses Streamlit).

What I've tried:

Turning off and on websockets
different combinations with affinity cookies on/off
different certificate options

I do not have this issue on a similar web app hosted on linux, which defaults to websockets on. Any help would be appreciated!

Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-05-02T04:34:15.71+00:00

Hi @David Dong,

It seems like your Streamlit app hosted on an Azure Web App suddenly started showing a 403 error when trying to establish a WebSocket connection, even though it was working fine just the day before. A 403 error usually means the server is denying access, this often points to permission or configuration issues.

First, check that WebSockets are still enabled in the Azure portal for your Web App. Sometimes these settings don't stick or might get reset without warning.

Since 403 errors are often related to permissions, double-check that your app has the necessary access and isn't being blocked by a firewall or network restrictions.

Given that the same setup works on a Linux Web App but not on a Windows one, it’s a good idea to compare both environments. Look for any configuration differences, especially around CORS. You may need to explicitly allow WebSocket connections from the domains you're using.

If your app enforces HTTPS, make sure your WebSocket connections use wss:// (secure) instead of ws:// (insecure), or they might get blocked.

It’s also worth testing your app on a different network, sometimes corporate networks block WebSocket traffic. Switching to a home or mobile network can help confirm that. And don't forget to disable browser extensions like ad blockers during testing, just in case they’re interfering with the connection.

Finally, check your app logs for any specific errors or warnings. They can often give more detailed clues about why the connection is being refused.

References:
Error: "Web socket is closed or could not be opened"
ASP.NET SignalR application is not working in Azure cloud service

Hope this information is helpful, let me know if you have any further queries.
Suresh Chikkam 2,135 Reputation points Microsoft External Staff Moderator

2025-05-05T09:41:13.85+00:00

Hi David Dong,

Since the app is running on a Windows-based App Service, one possible area to check is how the web.config file is behaving. Sometimes, even automatically generated entries in that file can affect WebSocket connections something that wouldn’t apply on a Linux-based app. If Streamlit or the deployment setup modifies the configuration during publishing, it could be worth reviewing the final output to rule that out.

Another thing to consider is how session affinity (ARR) is being handled. I understand you have tried different combinations already, but sometimes the underlying platform behavior differs subtly between Windows and Linux, especially when it comes to how sticky sessions are maintained.

If there is any kind of gateway or reverse proxy in front of the app like Azure Front Door or Application Gateway, it’s worth confirming that WebSocket-specific headers like Connection: Upgrade and Upgrade: websocket aren’t being stripped or altered. These headers are essential for the WebSocket handshake to go through properly. Microsoft has some guidance on WebSocket transport behavior in this article.

Also, if there were any recent updates to the custom domain or TLS/SSL settings, it might be a good idea to double-check that the WebSocket requests are still going through as wss:// and that nothing is failing silently during the handshake due to a domain mismatch or certificate issue.

To get more detail, you could try streaming the app logs using az webapp log tail, or open the Kudu console at https://<your-app-name>.scm.azurewebsites.net. Sometimes you’ll find more revealing information there that doesn’t show up in the default log output.

Please feel free to drop a comment here if the issue still persists, we would be happy to take another look with you. Hope it gets sorted soon.
Suresh Chikkam 2,135 Reputation points Microsoft External Staff Moderator

2025-05-05T10:51:55.65+00:00
Hi David Dong,

When checking logs, we also noticed this error:

“Error in getJarvisToken. Error is BrowserAuthError: popup_window_error: Error opening popup window. This can happen if you are using IE or if popups are blocked in the browser. Details: BrowserAuthError: empty_window_error: window.open returned null or undefined window object.”

This tells that a popup-based auth flow is failing likely due to browser restrictions or blocked popups. If your app relies on a JavaScript-based authentication mechanism (like MSAL.js), Use the redirect-based auth flow (loginRedirect) instead of loginPopup, especially for mobile or embedded scenarios.

Add error handling to detect popup_window_error and fallback to redirect if needed.

msalInstance.loginPopup(loginRequest).catch(error => { if (error.errorCode === "popup_window_error" || error.errorCode === "empty_window_error") { return msalInstance.loginRedirect(loginRequest); } });
David Dong 20 Reputation points

2025-05-05T13:20:01.78+00:00

The issue resolved after 3 days without any new action on my part. It might have been my VPN provider or something upstream in Azure. Thank you all for looking into this!

Accepted answer

0 additional answers

Your answer

Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-05-02T04:34:15.71+00:00

Hi @David Dong,

It seems like your Streamlit app hosted on an Azure Web App suddenly started showing a 403 error when trying to establish a WebSocket connection, even though it was working fine just the day before. A 403 error usually means the server is denying access, this often points to permission or configuration issues.

First, check that WebSockets are still enabled in the Azure portal for your Web App. Sometimes these settings don't stick or might get reset without warning.

Since 403 errors are often related to permissions, double-check that your app has the necessary access and isn't being blocked by a firewall or network restrictions.

Given that the same setup works on a Linux Web App but not on a Windows one, it’s a good idea to compare both environments. Look for any configuration differences, especially around CORS. You may need to explicitly allow WebSocket connections from the domains you're using.

If your app enforces HTTPS, make sure your WebSocket connections use wss:// (secure) instead of ws:// (insecure), or they might get blocked.

It’s also worth testing your app on a different network, sometimes corporate networks block WebSocket traffic. Switching to a home or mobile network can help confirm that. And don't forget to disable browser extensions like ad blockers during testing, just in case they’re interfering with the connection.

Finally, check your app logs for any specific errors or warnings. They can often give more detailed clues about why the connection is being refused.

References:
Error: "Web socket is closed or could not be opened"
ASP.NET SignalR application is not working in Azure cloud service

Hope this information is helpful, let me know if you have any further queries.
Suresh Chikkam 2,135 Reputation points Microsoft External Staff Moderator

2025-05-05T09:41:13.85+00:00

Hi David Dong,

Since the app is running on a Windows-based App Service, one possible area to check is how the web.config file is behaving. Sometimes, even automatically generated entries in that file can affect WebSocket connections something that wouldn’t apply on a Linux-based app. If Streamlit or the deployment setup modifies the configuration during publishing, it could be worth reviewing the final output to rule that out.

Another thing to consider is how session affinity (ARR) is being handled. I understand you have tried different combinations already, but sometimes the underlying platform behavior differs subtly between Windows and Linux, especially when it comes to how sticky sessions are maintained.

If there is any kind of gateway or reverse proxy in front of the app like Azure Front Door or Application Gateway, it’s worth confirming that WebSocket-specific headers like Connection: Upgrade and Upgrade: websocket aren’t being stripped or altered. These headers are essential for the WebSocket handshake to go through properly. Microsoft has some guidance on WebSocket transport behavior in this article.

Also, if there were any recent updates to the custom domain or TLS/SSL settings, it might be a good idea to double-check that the WebSocket requests are still going through as wss:// and that nothing is failing silently during the handshake due to a domain mismatch or certificate issue.

To get more detail, you could try streaming the app logs using az webapp log tail, or open the Kudu console at https://<your-app-name>.scm.azurewebsites.net. Sometimes you’ll find more revealing information there that doesn’t show up in the default log output.

Please feel free to drop a comment here if the issue still persists, we would be happy to take another look with you. Hope it gets sorted soon.
Suresh Chikkam 2,135 Reputation points Microsoft External Staff Moderator

2025-05-05T10:51:55.65+00:00

Hi David Dong,

When checking logs, we also noticed this error:

“Error in getJarvisToken. Error is BrowserAuthError: popup_window_error: Error opening popup window. This can happen if you are using IE or if popups are blocked in the browser. Details: BrowserAuthError: empty_window_error: window.open returned null or undefined window object.”

This tells that a popup-based auth flow is failing likely due to browser restrictions or blocked popups. If your app relies on a JavaScript-based authentication mechanism (like MSAL.js), Use the redirect-based auth flow (loginRedirect) instead of loginPopup, especially for mobile or embedded scenarios.

Add error handling to detect popup_window_error and fallback to redirect if needed.

msalInstance.loginPopup(loginRequest).catch(error => { if (error.errorCode === "popup_window_error" || error.errorCode === "empty_window_error") { return msalInstance.loginRedirect(loginRequest); } });
David Dong 20 Reputation points

2025-05-05T13:20:01.78+00:00

The issue resolved after 3 days without any new action on my part. It might have been my VPN provider or something upstream in Azure. Thank you all for looking into this!

Answer 1

Hi David Dong,

Thanks for the update, Glad to hear the issue resolved itself. these kinds of intermittent problems can be tricky, especially when they stem from VPN behavior or upstream network layers in Azure.

Posting this on behalf of David, just for the benefit of the community in case anyone else runs into a similar issue.

If you're experiencing WebSocket connection failures (such as 403 errors) on an Azure Web App—especially for apps like Streamlit that rely on WebSockets—and everything was working previously, here are a few things to check:

Make sure WebSockets are still enabled in the App Service configuration.

Ensure the app is using wss:// if HTTPS is enforced.

Review access restrictions, authentication settings, and custom domain mappings that might affect WebSocket headers or TLS.

If you're connected through a VPN or proxy, test the app outside that network—some VPNs interfere with WebSocket upgrades.

Also test in a clean browser session or incognito mode to rule out extensions or pop-up blockers.

In David’s case, the issue resolved itself after a few days, likely due to VPN interference or a transient issue upstream in Azure.

Hope this helps someone facing a similar issue.

Please do not forget to click "Accept the answer” and Yes wherever the information provided helps you, this can be beneficial to other community members.

User's image

If you have any other questions or still running into more issues, let me know in the "comments" and I would be happy to help you.

Share via

Websocket Connection Error (was working a day ago)

0 additional answers

Your answer