Azure-docs: Azure App Service Linux Container - Web Socket Handshake Error 503

@jlorek Thank you for your query and feedback, our team will further look into it and get back to you at the earliest.

We are experiencing the same issue.

Any updates on this one? Getting the same issue

Apologies for the delay! I completely understand it is a frustrating experience with this issue. I'm checking on this with our product engineering team and I will post back with an update soon.

Just as a side note, I have seen similar issues (WebSocket | error 503) fixed, by scaling-up to a higher App Service Plan.

@jlorek If you can share your app name where you are seeing the 503, I can help get to the bottom of this. Technically, Web sockets is supported for App Service Linux and the WebSocket-Extensions issue also should no longer be happening.

Is there anything more complex to try to repro this problem after deploying the default Blazor project app? I just tried to deploy a sample, and it loads for me fine. (https://blazerlinux.tuxedoase.p.azurewebsites.net/weatherforecast) But I admit I am not a app expert, so I might be missing something.

Thanks @JennyLawrance for your help and comments.
@LANSoftwareentwicklung, @ameyakarve, as Jenny requested, could you please share one of the WebApp name directly here or indirectly?

Default Blazor app works for us, if there are any additional/complex steps that you're configuring and want to share the repo and exact repro steps, please send an email to AzCommunity[at]Microsoft[dot]com referencing this thread, the WebApp name, and the Azure subscription ID, we will follow-up with you further.

Thanks for your patience and co-operation!

@JennyLawrance - The /weatherforecast API Endpoint is Part of the Blazor Client Side Default Project. It's not included in the Server Side Default Project, since it's not required due to the Server Side Application Architecture. Would you mind trying to reproduce with the Server Side Project Template dotnet new blazorserver?

@AjayKumar-MSFT - Sure, just head to https://peakseason.azurewebsites.net
As mentioned at the beginning, it's the Blazor Server Side Default Project Template deployed to an Azure App Service Linux Container (with WebSocket enabled) on a F1 App Service Plan.

I also created another sample without Containers, using App Service with Web App on Linux on a Net Core 3.1 Stack:
https://peakseason-code.azurewebsites.net

I tried the F1 and B1 Service Plan. Both resulting in the same issue - Web Socket Handshake Error 503.

@AjayKumar-MSFT - I sent you an e-mail with the app name and subscription id.

@jlorek, thanks for sharing the requested details.
@LANSoftwareentwicklung, Ack. We have received your email.

We're investigating and will get back to you soon.

@jlorek, can you clarify which URL is seeing the 503? I am able to access the app.

I was running into this same issue on a multi-container app service. When I encountered this error I was using an app service plan with the F1 tier (free). After reading through some of the recommendations I tried to switching to a b1 tier. After redeploying the multi-container app on the b1 tier the web socket is successfully connecting without the handshake error.

@JennyLawrance - Yes, you can access the app. But the underlying WebSocket connection cannot be established, because of a 503 error. To see this error, just open your browsers DevTools. Using Blazor there is a fallback mode implemented, when no WebSocket connection can be established. When not using Blazor and relying on WebSockets, your whole app may be broken due to this error.

@classifieds-dev - Tried the B1 without any success. But using the P1V2 service plan, the WebSocket connection works just fine for my project.

@jlorek , @classifieds-dev , Yes I have identified a code issue on our end which completely blocks web sockets on free SKU. I have opened a work item on our side to fix this.

As this issue is identified and a fix would be deployed. Also, the documentation will be refreshed to reflect the changes. We will now proceed to close this thread. If there are further questions regarding this matter, please tag us in your reply. We will gladly continue the discussion.

Thanks everyone for bringing this to our attention. We really appreciate your valuable feedback.

I'm seeing a 503 with a single-container F1 free tier app service. is this the same issue that's going to be fixed, or should i file a separate bug? oh, it looks like the free tier is going to be fixed...

Hello

All of those solutions did not work for me. Let me explain what I have:

I'm developing a solution with Twilio + Azure Cognitive Services (telephone based conversation, realtime, and using websockets)

From Twilio, when a call comes in, I send an initial POST request (Webhook) to my WebApp for Containers like this:
_https://my_azure_web_app.azurewebsites.net/twiml_

Inside server I have an end-point like this:

_class TwiML(tornado.web.RequestHandler):
def post(self):
response_str = './greetings.mp3'
response_str += ''
response_str += ''
self.finish(str(response_str))
def set_default_headers(self):
print("setting headers!!!")
self.set_header("Access-Control-Allow-Origin", "*")
self.set_header("Access-Control-Allow-Headers", "x-requested-with")
self.set_header("Sec-WebSocket-Extensions", "permessage-deflate")_

I can launch my app on localhost and into a container on localhost (i.e. I can open websockets from/to Twilio with no problem and get the websocket channel opened)

When I deploy the image into WebApp for Containers, and this container is running, I can receive the first part of the audio message (i.e. greetings). But, after that, I can not open the wss websocket connection (_wss://my_azure_web_app.azurewebsites.net.azurewebsites.net/socket_) and I always receive an error from Twilio like this:
Stream - WebSocket - Connection Broken Pipe

(I used the "EXPOSE 8080" into my Dockerfile and "WEBSITES_PORT = 8080" into my Configuration Settings WebApp)

The container is running:
2020-04-08 14:13:06.366 INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2020-04-08 14:13:06.882 INFO - Initiating warmup request to container my_azure_web_app_8_91af842a for site my_azure_web_app
2020-04-08 14:13:10.919 INFO - Container my_azure_web_app_8_91af842a for site my_azure_web_app initialized successfully and is ready to serve requests.

I can access to its url:
https://my_azure_web_app.azurewebsites.net/

I can connect to my websocket channel with Advanced Rest Client (Google)
"Connected to wss://my_azure_web_app.azurewebsites.net/socket"

I think everything is fine BUT when I try to open the "wss://my_azure_web_app.azurewebsites.net/socket" from Twilio, it is not possible

I tried everything with no success (both, tornado server and Azure ). So:

1. Web App for Containers
   1.1. CORS: empty (and also: Allowed Origins "*"). Both, without success.
   1.2. WebSockets enabled ("On")
   1.3. Scale Up Service Plan (P1V2)
2. Tornado server:
   2.1. Set headers "Access-Control-Allow-Origin", "*"
   2.2. Set header "Sec-WebSocket-Extensions", "permessage-deflate" (is it necessary yet?)

Finally, I do not have my app running deployed into Web App for Containers
I run out my ideas.

Anyone can tell new ways to try?

Thanks a lot in advance!

@lopejum, For a closer look, I have responded to your other GitHub thread. Thanks for the comment.

Why this issue is closed? As of today, it's still not working for the Free tier. Is there a reference, so we can watch it and be notified when the fix will be deployed to Azure?

I still have this issue for Blazor 3.1 and Linux App Service (B1). Can we please reopen or publish some clear recommendation on this one?

Like already stated in the first post, this problem seems well known but all issues get closed without providing any solution. Seems a bit strange. @AjayKumar-MSFT any infos about the progress on the fix?

Based on the feedback, we have updated this document with this - "Web Sockets are not currently supported for Linux apps on Free App Service Plans. We are working on removing this limitation and plan to support up to 5 web socket connections on Free App Service plans."

@JennyLawrance, Requesting your help and comments on this further.

@AjayKumar-MSFT: I am running into this issue using S1 App Service Plan, not the Free App Service Plan.

So it looks like the Web Sockets are not currently supported at all for Linux? Can you please clarify here? Thanks for help!

@JennyLawrance , @AjayKumar-MSFT: friendly reminder...

Just verified that a similar setup with WebSockets does work on a Windows App, but not on a Linux one. This is independent of what pricing tier is chosen.

There is probably multiple issues combined here:
Websockets not working for free is identified, and we will have a fix for it.

@thomaux , can you give me the app url you have setup (send email to jennylaw(at)microsoft(dot)com and we can investigate.

@AjayKumar-MSFT

Based on the feedback, we have updated this document with this - "Web Sockets are not currently supported for Linux apps on Free App Service Plans. We are working on removing this limitation and plan to support up to 5 web socket connections on Free App Service plans."

@JennyLawrance, Requesting your help and comments on this further.

Please, what does Free App Service Plans stand for? I have a student subscription with 100usd free credit and I'm running web sockets on B1 plan. Is this also counted as free plan? Websocket url is responding with 503.

WebSocket connection to 'ws://wsstestivo.azurewebsites.net/?encoding=text' failed: Error during WebSocket handshake: Unexpected response code: 503

Running this image: https://hub.docker.com/r/ksdn117/web-socket-test

Today, out of sudden my linux app service started working correctly with with web socket connection.
This is S1 App Service Plan, Blazor Server side application.

So, what's going on? Can you please shed some light? We didn't perform any deployments or settings changes recently.

@JennyLawrance Any update on this? I emailed you the app's URL

We started getting this issue last Friday randomly. All our App Service Plans are Linux.

Our clients were unable to establish a websocket connection to one of our services on a B3 App Service Plan. This service has been deployed for several months, and we never had any websocket connectivity issues (or any connectivity issues for that matter) with it.

I tried restarting the app service several times which did not work. Finally, after seeing this thread, I moved the app service from its original B3 App Service Plan to a different B1 App Service Plan we were using. This fixed the issue for us.

We then tried moving the app service back to the original B3 App Service Plan but the problem occurred again.

This is very confusing to us and we have sent a Support Ticket to Azure.

I don't think we have made any changes to the B3 App Service Plan or the affected App Service for a while.

Same error

failed: Error during WebSocket handshake: Unexpected response code: 503

App service plan: LinuxContainerAppServicePlan (P1v2: 1)

Same issue on Linux B1

Same issue using Linux B1, but it works when switched to Windows.

Switching Linux B1 → Linux B2 and then switching back helped

Apologies everyone for the late response and frustration with this issue. We had been discussion on this internally.
For anyone still experiencing this issue, could you please send an email with subject line 'Attn:Ajay' to AzCommunity[at]Microsoft[dot]com referencing this thread, WebApp name, and the Azure subscription ID, for a deeper investigation, we will follow-up on this further.

Thanks for your patience and co-operation!

Switch from free F1 plan to B2 worked. However, when switching back to F1 the error comes back. I'm not sure if websockets are not supported for the F1 plan.

My error: Error during WebSocket handshake: Unexpected response code: 503

Switch from free F1 plan to B2 worked. However, when switching back to F1 the error comes back. I'm not sure if websockets are not supported for the F1 plan.

My error: Error during WebSocket handshake: Unexpected response code: 503

@Sijoma, Thanks for the update. Yes, as mentioned in this document -“Web Sockets are not currently supported for Linux apps on Free App Service Plans. We are working on removing this limitation and plan to support up to 5 web socket connections on Free App Service plans.” - Our product team is working on it, but we do not have an ETA to share at this time.

They also do not work for paid plans (B1).

They also do not work for paid plans (B1).

Users with a similar issue, fixed it by switching the plan -B1 -> B2 -> B1, kindly see if this works for you. Having mentioned that, I'm discussing on this internally and will post back with more update.

Does this works on the Windows Free instance? Or are websockets out of scope for free instances?

Does this works on the Windows Free instance? Or are websockets out of scope for free instances?

We allow 5 websocket connections in FREE SKU in Windows.

I just want to add my experience in here. I had similar issues with web sockets not working on linux web apps.
For me it worked to upgrade to B2. Websockets did not work on F1 and B1 at all.

Had to upgrade to Linux B2 for it to work.

Same here, no luck with F1 or B1, when upgraded to B2 it has started to work immediately.

To me, Linux B2 worked as well. B1 and F1 does not.

On my multi-container web app websocket works but the error is still thrown. Using nginx, nodejs