Web app HTTP 500 and 503 errors

Question

I recently published a new web app to Azure, but it's behaving strangely. Despite the default URL being https://mywebapp.azurewebsites.net, it always does a 301 redirect to https://mywebapp, which doesn't exist.

Apparently, AspNetCoreModuleV2 is raising 500 and 503 errors, but I have no other info on it. Why is it redirecting to https://mywebapp instead of the standard error page? Without any details, it is impossible to debug the issue.

Some things to note:

1. Remote debugging never hits any breakpoints.
2. In Program.Main(), I have enabled tracing but the trace log is always empty. Since commenting out the line "CreateHostBuilder(args).Build().Run()" makes no difference, I think it's safe to say this is never called.
3. The only error reported in other logs (including all App Service logs) in Kudu is a 404 error due to the redirect.
4. The app has no deployment slots, no custom domains, no custom DNS records, and no load balancing services.
5. In web.config, changing hostingModel from "inprocess" to "outofprocess" makes no difference.

Answer 1

Hi @kejiz23,

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue :

After deploying a new ASP.NET Core web app to Azure, the app was redirecting from https://mywebapp.azurewebsites.net to https://mywebapp, which doesn’t exist, causing 301 redirects and resulting in HTTP 500/503 errors. Remote debugging wasn’t working, and logs including stdout and trace logs were empty. Root-level (/) URLs were affected, though direct navigation to specific routes like /Account/SignIn or /Home worked fine.

Solution :

To resolve the issue, try adding the following middleware early in your Startup.Configure() method to help debug request behavior:

app.Use(async (context, next) => {

    Console.WriteLine($"Request URL: {context.Request.GetDisplayUrl()}");

    await next();

});

In this case, although no actual code change was ultimately responsible, deploying this logging change seemed to coincide with the issue resolving itself. It's possible that an Azure App Service environment refresh, cold start or configuration cache reset played a role.

After the redeployment, the root URL (/) started working correctly without redirecting.

Please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.

Answer 2

I found the problem. After commenting out all code in Startup.ConfigureServices() and Startup.Configure() that wasn't required for the app to function, I was able to get stdout logging working. However, there were still no errors occurring, and Program.Main() still wasn't firing.

Since I was all out of options, I decided to enter the URL for the sign-in page, https://mywebapp.azurewebsites.net/Account/SignIn, and it worked. But after signing in, it redirected back to https://mywebapp. Entering https://mywebapp.azurewebsites.net/Home took me to the home page, and I was able to navigate everywhere except for links with URL "/".

With remote debugging now working, I tried that but found nothing wrong, so I added this code in Startup.Configure() in an attempt to find out what was going on:

app.Use(async (context, next) => {

Console.WriteLine($"Request URL: {context.Request.GetDisplayUrl()}");

await next();

});

Shortly after publishing this change, the issue just went away. In the end, not a single line of code was changed for it to work.

What I don't understand is, why wasn't this happening locally? Was there an issue with "/" pointing to the subdomain? Your suggestions are welcome.