ASP.NET 9 app trying to bind to localhost when running

Question

ASP.NET 9 app trying to bind to localhost when running

Andy Gill 21

I've got an app I haven't deployed to in a few months (https://devbackofficescheduler-staging.azurewebsites.net/) but I haven't made many changes if any. I've likely updated the framework and done so on the config of the web app, but I'm getting 502 and 503 errors. It runs fine locally but not when I publish to azure, to either of two slots. I'm not getting anything useful in the app log live stream:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"><HTML><HEAD><TITLE>Service Unavailable</TITLE><META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD><BODY><h2>Service Unavailable</h2><hr><p>HTTP Error 503. The service is unavailable.</p></BODY></HTML>

and when I run dotnet backofficescheduler.web.dll in the console I either get what seems to be a timeout error (failed to execute command after about a minute) or I get this exception: System.IO.IOException: Failed to bind to address http://127.0.0.1:5000: address already in use

I'm not sure if this looking for localhost port 5000 is a misconfiguration or just part of the usual azure process?

Anonymous

2025-06-12T21:19:49.8766667+00:00
Hi Andy Gill

The 502 and 503 errors typically indicate that the server isn't able to process the request, which can often happen due to misconfigurations or resource limitations on Azure.

Here are a few things you can check and try out:

Since you mentioned you've updated the framework and configuration, double-check your connection strings and app settings. Ensure they are correctly pointing to the right resources in Azure.

The error message you mentioned about failing to bind to http://127.0.0.1:5000 suggests that your application is trying to listen on a port that might already be in use. Azure doesn't usually allow apps to bind directly to localhost. Instead, ensure you're not trying to hardcode localhost in your app settings. It should be using environment variables provided by Azure for production settings.

If you haven't already, enable Application Insights in your app. It provides telemetry and more detailed error logging which can be invaluable in understanding what's going wrong when deployed on Azure.

Even though you mentioned not getting useful information in the app log live stream, try accessing the Azure portal and check the following:

Log Stream: Monitor this while restarting your app to see if any errors show up.

Diagnose and Solve Problems: This tool can provide insights on common issues.

If you're running on a lower tier service plan, consider scaling up temporarily to see if the issue resolves, which could indicate resource limitations.

If your app isn't designed to bind to localhost, ensure your web.config file doesn't specify Localhost bindings.

Ensure that the deployment slots are correctly set up and that the configurations for both production and staging slots have no discrepancies that could cause different behaviors.

If you have any further assistant, do let me know.
Andy Gill 21 Reputation points

2025-06-13T01:08:12.4033333+00:00
Thanks so much for the help @Anonymous @Siva Nair @Anonymous @Siva Nair @Siva Nair sorry, not sure which one to reply to. 'd have sworn I did watch the logs when I restarted, but maybe I didn't because I got an error page that makes me think that .NET somehow isn't installed, as silly as that is. I've verified that it is in the console so I know better, but this seems like it can't read the modules. My app, all its DLLs and the website are all set to .net 9.0. The

There's not a lot to my logs that might be looking for localhost.

I did find an event log XML file that again seems like .NET isn't installed; might you have some direction based on this? It looks like it thinks it needs .NET 7 and found 8, but it's got up through 9 installed and the app and site are both on 9

<configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\BackOfficeScheduler.Web.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>
Anonymous

2025-06-17T16:36:42.84+00:00
Hi @zephr

How are you deploying the app to Azure Web Apps - using Visual Studio, GitHub, Azure DevOps, or ZIP deployment? Also, are you deploying to a Windows or Linux App Service?

503 usually means the app failed to start (common when binding is incorrect)

502 may indicate the app crashed after startup.

Check stdout logs if enabled: they are stored at D:\home\site\wwwroot\logs\stdou

Azure App Service manages the port binding internally. Your app must listen on the port provided via the **PORT **environment variable, which is injected by the platform.

If your app hardcodes http://localhost:5000, it will fail because:

That port may not be available.

Azure expects the app to bind to *:{PORT}.

Ensure your .csproj has:
<TargetFramework>net9.0</TargetFramework>

Your answer

Anonymous

2025-06-12T21:19:49.8766667+00:00

Hi Andy Gill

The 502 and 503 errors typically indicate that the server isn't able to process the request, which can often happen due to misconfigurations or resource limitations on Azure.

Here are a few things you can check and try out:

Since you mentioned you've updated the framework and configuration, double-check your connection strings and app settings. Ensure they are correctly pointing to the right resources in Azure.

The error message you mentioned about failing to bind to http://127.0.0.1:5000 suggests that your application is trying to listen on a port that might already be in use. Azure doesn't usually allow apps to bind directly to localhost. Instead, ensure you're not trying to hardcode localhost in your app settings. It should be using environment variables provided by Azure for production settings.

If you haven't already, enable Application Insights in your app. It provides telemetry and more detailed error logging which can be invaluable in understanding what's going wrong when deployed on Azure.

Even though you mentioned not getting useful information in the app log live stream, try accessing the Azure portal and check the following:

Log Stream: Monitor this while restarting your app to see if any errors show up.

Diagnose and Solve Problems: This tool can provide insights on common issues.

If you're running on a lower tier service plan, consider scaling up temporarily to see if the issue resolves, which could indicate resource limitations.

If your app isn't designed to bind to localhost, ensure your web.config file doesn't specify Localhost bindings.

Ensure that the deployment slots are correctly set up and that the configurations for both production and staging slots have no discrepancies that could cause different behaviors.

If you have any further assistant, do let me know.
Andy Gill 21 Reputation points

2025-06-13T01:08:12.4033333+00:00

Thanks so much for the help @Anonymous @Siva Nair @Anonymous @Siva Nair @Siva Nair sorry, not sure which one to reply to. 'd have sworn I did watch the logs when I restarted, but maybe I didn't because I got an error page that makes me think that .NET somehow isn't installed, as silly as that is. I've verified that it is in the console so I know better, but this seems like it can't read the modules. My app, all its DLLs and the website are all set to .net 9.0. The

There's not a lot to my logs that might be looking for localhost.

I did find an event log XML file that again seems like .NET isn't installed; might you have some direction based on this? It looks like it thinks it needs .NET 7 and found 8, but it's got up through 9 installed and the app and site are both on 9

<configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\BackOfficeScheduler.Web.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>
Anonymous

2025-06-17T16:36:42.84+00:00

Hi @zephr

How are you deploying the app to Azure Web Apps - using Visual Studio, GitHub, Azure DevOps, or ZIP deployment? Also, are you deploying to a Windows or Linux App Service?

503 usually means the app failed to start (common when binding is incorrect)

502 may indicate the app crashed after startup.

Check stdout logs if enabled: they are stored at D:\home\site\wwwroot\logs\stdou

Azure App Service manages the port binding internally. Your app must listen on the port provided via the **PORT **environment variable, which is injected by the platform.

If your app hardcodes http://localhost:5000, it will fail because:

That port may not be available.

Azure expects the app to bind to *:{PORT}.

Ensure your .csproj has:
<TargetFramework>net9.0</TargetFramework>

Share via

ASP.NET 9 app trying to bind to localhost when running

Your answer