来自Azure AppService的GET请求返回自身将返回502 Bad Gateway错误

Question

I have an Azure AppService/Website that when it receives a request, part of servicing it involves making another GET request back to itself. This is part of an HMAC workflow. When I run it on localhost it works fine with no errors. There is something about the Azure environment that is causing the error. The website is not publicly available unfortunately.

using (HttpClient httpClient = new HttpClient())
{
   ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

   apiResponse = await httpClient.GetAsync(apiBaseAddress + "api/Survey/GetApiKey/" + appId);
   entity = await apiResponse.Content.ReadAsAsync<ClientApiRegistrationEntity>();
}

The URL being passed to GetAsync() is correct. The URL has a https scheme in Azure; locally it is just http. If I copy/paste the URL into a browser on my machine the request goes through. If I make the request on the Kudu debug console I get the 502. I have confirmed that the DNS is resolving correctly in the AppService. For what it is worth, the invoke-webrequest call in Kudu returns a web page with the title: "502 - Web server received an invalid response while acting as a gateway or proxy server.".

Any ideas? Suggestions?

Answer 1

Just to highlight, the standard/native Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.

The only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet. However, applications may create a socket which can listen for connections from within the sandbox. For example, two processes within the same app may communicate with one another via TCP sockets; connection attempts incoming from outside the sandbox, albeit they be on the same machine, will fail. Using a custom Windows container in App Service lets you make OS changes that your app needs, so it's easy to migrate on-premises app that requires custom OS and software configuration. See sandbox page .

Based on your requirement, you may checkout these document to start-off:

Run a custom Linux container in Azure App Service & Run a custom Windows container in Azure (Preview)

502 bad gateway errors won't be visible in the IIS logs as they're returned by the frontend servers, which forwards the requests to the worker hosting the app and there are many reasons why the frontend can return this error, but typically, 502 errors are caused by the application level issues, among them:

• requests taking a long time

• application using high memory/CPU

• application crashing due to an exception

You may always follow the document Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable ( https://docs.microsoft.com/en-us/azure/app-service/troubleshoot-http-502-http-503 )" in Azure App Service for identifying the issue.

Answer 2

I stumbled on this fix. I was comparing application gateways between dev and prod and I noticed an inbound port rule called "DenyAllInbound" sitting on port 4096. I pulled that out and everything started working again. I'm not sure how that rule got there in the first place. It looks like a 502 is a generic "something is wrong" message from Azure.

FWIW, I found the "DenyAllInbound" rule by using the "Connection troubleshoot" link under Monitoring for the application gateway.