Failed healthchecks, http 50x errors in webapp container as afd origin (single instance origin groups)

Question

Failed healthchecks, http 50x errors in webapp container as afd origin (single instance origin groups)

WestCoastSolutionArch 21

I have an afd instance with two different origin groups (one to web app backend, and one to a file upload receiver server. The health checks are not functioning consistently, making me suspicious that there may be something else going on. When health checks are passing, endpoint is returning 50x errors (perhaps related to CORS, which appears to be configured for any origin, as needed by project requirements). As far as I can tell, and AI assist docs have indicated, things should be configured appropriately (yet my containers keep getting terminated, possibly contributing to the 50x http errors)

Prabhavathi Manchala 815 Reputation points Microsoft External Staff

2025-03-31T02:22:10.62+00:00
Hi WestCoastSolutionArch,

Health check failures are likely due to backend issues like resource exhaustion, timeouts, or crashes, causing Azure Front Door to mark the origin as unhealthy. This can lead to container terminations or failover to a backup origin. HTTP 50x errors are usually caused by server-side problems, such as crashes or slow responses. Misconfigured CORS settings and resource limitations in containers may also contribute to these errors.

Ensure the health check endpoint is correctly configured to return a success message and verify network connectivity to prevent intermittent issues causing health check failures. https://learn.microsoft.com/en-us/azure/frontdoor/health-probes#supported-http-methods-for-health-probes

Please check container or backend logs for errors, exceptions, or resource constraints (CPU, memory) causing 50x errors, and set up health monitoring with automatic restart or recovery on failure.

Please make sure your CORS configuration on the backend allows the necessary HTTP methods and headers, as misconfigurations can cause API requests to fail, even with the any origin setting.

Scale your backend services to handle heavy load and ensure AFD is properly balancing the load across instances.

Use tools like Fiddler or browser developer tools to inspect requests and responses, helping identify issues with the requests sent to your backend.

Kindly refer below document to troubleshoot the issue

https://learn.microsoft.com/en-us/azure/frontdoor/troubleshoot-issues#503-or-504-response-from-azure-front-door-after-a-few-seconds
Prabhavathi Manchala 815 Reputation points Microsoft External Staff

2025-04-01T05:00:15.6466667+00:00

Hi WestCoastSolutionArch,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
WestCoastSolutionArch 21 Reputation points

2025-04-01T05:57:33.3933333+00:00

Ack, sorry about that... no notification email about a reply, glad I came and checked.

I am currently, since my dotnet API's origin's route is something like /a/b/c, attempting to add a specific handler for OPTIONS for that route (thinking maybe the default AddCors isn't applying to my controller routes). Strange that it isn't a problem locally (with the API vs the uploading remote app on different ports on localhost, which I would think trigger CORS). Perhaps that will address your noted healthcheck issue/concern.

I've noticed my browser is sending a whole host of headers beyond the simple. Is there a way in afd premium to remove all headers except those critical to the backend API for CORS before handing it off?

Currently running only a single instance of origins in my (two) groups (one for www content, the other an endpoint to receive file uploads. So, no balancing across istances

The MS docs certainly give the impression it should "just work", but that has most definitely not been my experience thus far with Azure Front Door Premium...

https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/troubleshoot-cross-origin-resources#wildcard-or-single-origin-scenarios

I am hoping you're right about the healthchecks failing causing requests to not be passed through (that would confirm what I am seeing logged on the back end, nothing except the app service checks are showing up).

WestCoastSolutionArch 21

After enabling "Microsoft.AspNetCore.Routing"``: "Debug" in my webapp/origin's appsettings.json, I now see in my webapp's "Deployment Center", "Logs" tab...

2025-04-01T12:12:25.6399643Z dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1001]
2025-04-01T12:12:25.6399998Z       1 candidate(s) found for the request path '/onsite/report/healthcheck'
2025-04-01T12:12:25.6400029Z dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]
2025-04-01T12:12:25.6400068Z       Endpoint 'SuperReportsServer.Controllers.ReportsServerController.HealthCheck (SuperReportsServer)' with route pattern 'onsite/report/healthcheck' is valid for the request path '/onsite/report/healthcheck'
2025-04-01T12:12:25.6400091Z dbug: Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware[1]
2025-04-01T12:12:25.6400117Z       Request matched endpoint 'SuperReportsServer.Controllers.ReportsServerController.HealthCheck (SuperReportsServer)'
2025-04-01T12:12:25.6400141Z info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
2025-04-01T12:12:25.6400168Z       Executing endpoint 'SuperReportsServer.Controllers.ReportsServerController.HealthCheck (SuperReportsServer)'
2025-04-01T12:12:25.6400190Z info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
2025-04-01T12:12:25.6400246Z       Executed endpoint

This means the webapp's own health checks appear to be working ok (which the Azure Portal UI's overview shows "100.00% (Healthy 1 / Degraded 0)").However, if I hit the Azure Front Door FQDN/endpoint with the healthcheck route/path addedto the request, I receive an error 504. My webapp is in a VNET with endpoints connecting from the afd to the webapp (eg: no public access to the webapp directly). I do have a jumpbox that I can ssh into and retrieve logs via az cli from peered webapp containers.

I see the dotnet 8 official containers use port 8080, is that a problem with Azure Front Door Premium (it seems to work with port 80 and a wildcard route to that particular origin group).

x-azure-ref: 20250401T120523Z-186b855ff67f442mhC1NYCx1m00000000bv0000000001cv0

Rohith Vinnakota 3,835 Reputation points Microsoft External Staff

2025-04-01T21:54:10.96+00:00
Hello @WestCoastSolutionArch,
For further investigation, could you please share the following information:

Let me know which error you are encountering when accessing the front door URL,and also share a screenshot of the error.

Also, try to check the front access logs when encountering the 5xx error to see what client status is being given.

Could you please try accessing the backend web app URL directly and inform me if it is working or not?

If it is not working, the issue might be from the backend. You need to check why the backend is behaving this way.

You can also collect the tracking reference ID (x-azure-ref) from the access logs when encountering the 5xx error. Use this reference ID (x-azure-ref) to check the logs in your Azure portal.
Please refer to the following document for collecting the logs: Troubleshoot Azure Front Door common issues | Microsoft Learn

Also, please let me know how you are using the 8080 port in the AFD (How are you configuring 8080?)

Similar case: https://learn.microsoft.com/en-us/answers/questions/1487952/configure-port-8080-on-azure-frontdoor-site
WestCoastSolutionArch 21 Reputation points

2025-04-02T04:12:15.13+00:00
Hello Rohith,

Thank you for this feedback. A little more info/feedback on my part first...

Regarding accessing my webapp directly, it is in a private vnet. I could try curl'ing the private DNS endpoint within the vnet my ubuntu peer vm?

Port 8080...

My research thus far lead me to believe this may be the culprit. In additional to your very helpful QA link (to answer my next question as to which port the origin should route to), I found the following documentation (finally)...

"By default, App Service assumes your custom container listens on port 80. If your container listens to a different port, set the WEBSITES_PORT app setting in your App Service app."
https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?tabs=debian&pivots=container-linux#configure-port-number

Currently my project is rebuilding/deploying with changes in light of this info. I suspect it will at least help narrow the scope of the disconnect and will let you know how it goes.

PS: An example of a failed (HTTP504) healthcheck request to my endpoint (via afd)...

x-azure-ref: 20250402T041248Z-17cccd5449b4wvd9hC1EWRkczn00000014n000000000bpax

WestCoastSolutionArch 21

Hmm... I'm still seeing the following in the deployment logs. I am going to give it a bit and see if perhaps not all code/configuration has finished fully deploying...

2025-04-02T04:23:28.7152719Z Starting container: {redacted}.
2025-04-02T04:23:28.7347110Z Starting watchers and probes. 
2025-04-02T04:23:28.7349092Z Starting metrics collection. 
2025-04-02T04:23:28.7350028Z Container is running. 
2025-04-02T04:23:28.7500411Z Container start method finished after 1044 ms. 2025-04-02T04:23:29.8558212Z Site startup probe succeeded after 1.1039983 seconds. 2025-04-02T04:23:29.8567561Z Site started. 
2025-04-02T04:23:49.8688823Z Container is terminating. Grace period: 5 seconds. 2025-04-02T04:23:49.8706465Z Stop and delete container. Retry count = 0 2025-04-02T04:23:49.8707023Z Stopping container: {redacted}.
2025-04-02T04:23:50.9486194Z Deleting container: {redacted}. Retry count = 0 
2025-04-02T04:23:51.6612741Z Container spec TerminationMessagePolicy path 2025-04-02T04:23:51.6616194Z Container is terminated. Total time elapsed: 1792 ms.

Here is a devtools screenshot of the attempt to request the healthcheck endpoint...

User's image

WestCoastSolutionArch 21 Reputation points

2025-04-02T12:18:33.2066667+00:00
Regarding "accessing my webapp directly", trying curl from another host in the vnet works for both apps/routes/origin-groups behind my afd instance...

$ curl https://app1-randomstring.westus-01.azurewebsites.net -I HTTP/1.1 200 OK

$ curl https://app2-randomstring.westus-01.azurewebsites.net/onsite/report/healthcheck -I HTTP/1.1 200 OK

I appear to have the healthchecks resolved and the containers stable. I am able to route/browse to first app/origin via the front door (and custom domain), but unable to still to the second app/route (though it works "directly" as shown above). Attemping to do so still results in a 504 error (x-azure-ref: 20250402T121615Z-17cccd5449bvj9xqhC1EWRh59s00000015h000000000cukq)

Thanks for your help with this, it is bizarre to me.
ChaitanyaNaykodi-MSFT 27,366 Reputation points Microsoft Employee

2025-04-02T20:07:30.46+00:00
@WestCoastSolutionArch

Thank you for getting back here and sharing the Ref ID.

Based on the Ref-id I can see there is a OriginTimeout error observed here.

Based on the error can you try following the troubleshooting steps in the document here if not already done so

Configure the Origin response timeout for Azure Front Door. You can increase the default timeout to up to 4 minutes (240 seconds).

If increasing the timeout doesn't resolve the issue, use a tool like Fiddler or your browser's developer tool to check if the client is sending byte range requests with Accept-Encoding headers. Using this option leads to the origin responding with different content lengths. If the client is sending byte range requests with Accept-Encoding headers, you have two options. The first option is to disable compression on the origin or Azure Front Door. The second option is to create a rules set rule to remove Accept-Encoding from the request for byte range requests.

As we proceed with troubleshooting this issue, can you please share the requested details below?

I understand your backend web apps are deployed in a Vnet, can you please share a rough network diagram of your set-up here? I just want to make sure if there are no NSG or any connectivity issue here.

For the request which gives 504 error, can you please check is there is any error observed in the backend web app logs for the same request. If it helps Azure Front Door Appends the these headers to each request.

Thank you!
WestCoastSolutionArch 21 Reputation points

2025-04-02T21:35:54.5666667+00:00

Certainly... regarding the timeout, my suspicion is that there is a disconnect between my dotnet 8 origin (which runs nonroot and can't do port 80, but exposes port 8080 instead) and the afd request coming in on port 80 (essentially, this Origin wont currently respond to any request on port 80, healthcheck or otherwise, but the webapp will).

I updated the Origin response timeout as indicated (from 30sec to 240sec). The other route/origin on that afd endpoint has a much heavier-weight start up and is working fine. This problematic one is very lightweight... but I certainly understand/appreciate ruling it out.

Regarding the Accept-Encoding headers, I do see that my browser is (force) sending that header. I added a rule to remove it and associated it with this path/route, we'll see. The same headers are sent by another browser in my dev environment, and the healthcheck endpoints return successfully. ....and we were all so assured that migrating to containers would fix the, "but it works in my environment" problem! lol

To answer your question about network diagram, it is based on the RWA pattern. A variation however, is rather than the two regions for redundancy, we have two different origin groups for two different origins/webapps, with a route to one specifically (the "/onsite/report/healthcheck" route), with all other traffic (Path: "/*") routed to the other (working) origin (serving our SPA/API).

Looking at the application/service logs, I do see requests from within the vnet, and healthchecks, being handled without issue. There doesn't appear to be any indication that requests from afd to origin are being received.

Is there anything more specifically needed to adapt afd/80 to dotnet8/8080? I added "WEBSITES_PORT" to the dotnet8 origin/webapp Environment variables (and the logs indicate that it is starting/listening on 8080... and curl commands in the vnet to the webapp directly on port 80 were successful).
WestCoastSolutionArch 21 Reputation points

2025-04-02T23:39:13.6266667+00:00
This is interesting, on host in vnet...

$ curl https://app2-randomstring.westus-01.azurewebsites.net/ -I HTTP/1.1 405 Method Not Allowed Date: Wed, 02 Apr 2025 23:22:19 GMT Server: Kestrel Allow: GET

Perhaps that is pointing to a healthcheck related (code/webapp) issue rather than port mapping (at least at this point)?

The "app2" webapp (dotnet 8) simply does...

app.MapGet("/", () => Results.Ok()); app.MapControllers();

...which I wouldn't expect to return a 405? Perhaps this is due to app.UseCors middleware being called before the MapGet? But UseCors includes HttpMethods.Get in the list of allowed methods with CORS related requests (so even if it were to apply, it specifically allows GET requests to the root path/route of the webapp, non afd).

It works locally without issue. Perhaps is CORS related, causing healthchecks to fail... but why would the other (longer) route/path to the same webapp work?
WestCoastSolutionArch 21 Reputation points

2025-04-04T03:43:56.8966667+00:00
Using the "Diagnose and solve problems" blade on my front door instance, I was lead to...

! Some container port settings were found from logs Exposed port by container Unknown Listening port by container 8080 Platform logs contain errors or warnings * Container {redacted} for site {app2} did not start within expected time limit.

Which would be consistent with webapp1 requests working via afd and vnet, while webapp2 (dotnet 8, port 8080) does not work via afd but does via vnet.

How is afd port 80 mapped to webapp port 8080? The documentation indicates that it is a "Default value is 80. Enter the value for the port that the origin supports for HTTP protocol.", but apparently that isn't the case?

Note, as a containerized webapp, it "only exposes/uses one port", and since I have afd forwarding all traffic as http, I left the default/unused HTTPS port unchanged.
KapilAnanth-MSFT 49,281 Reputation points Microsoft Employee

2025-04-11T04:08:12.42+00:00

@WestCoastSolutionArch ,

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil

1 answer

Your answer

Prabhavathi Manchala 815 Reputation points Microsoft External Staff

2025-03-31T02:22:10.62+00:00

Hi WestCoastSolutionArch,

Health check failures are likely due to backend issues like resource exhaustion, timeouts, or crashes, causing Azure Front Door to mark the origin as unhealthy. This can lead to container terminations or failover to a backup origin. HTTP 50x errors are usually caused by server-side problems, such as crashes or slow responses. Misconfigured CORS settings and resource limitations in containers may also contribute to these errors.

Ensure the health check endpoint is correctly configured to return a success message and verify network connectivity to prevent intermittent issues causing health check failures. https://learn.microsoft.com/en-us/azure/frontdoor/health-probes#supported-http-methods-for-health-probes

Please check container or backend logs for errors, exceptions, or resource constraints (CPU, memory) causing 50x errors, and set up health monitoring with automatic restart or recovery on failure.

Please make sure your CORS configuration on the backend allows the necessary HTTP methods and headers, as misconfigurations can cause API requests to fail, even with the any origin setting.

Scale your backend services to handle heavy load and ensure AFD is properly balancing the load across instances.

Use tools like Fiddler or browser developer tools to inspect requests and responses, helping identify issues with the requests sent to your backend.

Kindly refer below document to troubleshoot the issue

https://learn.microsoft.com/en-us/azure/frontdoor/troubleshoot-issues#503-or-504-response-from-azure-front-door-after-a-few-seconds
Prabhavathi Manchala 815 Reputation points Microsoft External Staff

2025-04-01T05:00:15.6466667+00:00

Hi WestCoastSolutionArch,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
WestCoastSolutionArch 21 Reputation points

2025-04-01T05:57:33.3933333+00:00

Ack, sorry about that... no notification email about a reply, glad I came and checked.

I am currently, since my dotnet API's origin's route is something like /a/b/c, attempting to add a specific handler for OPTIONS for that route (thinking maybe the default AddCors isn't applying to my controller routes). Strange that it isn't a problem locally (with the API vs the uploading remote app on different ports on localhost, which I would think trigger CORS). Perhaps that will address your noted healthcheck issue/concern.

I've noticed my browser is sending a whole host of headers beyond the simple. Is there a way in afd premium to remove all headers except those critical to the backend API for CORS before handing it off?

Currently running only a single instance of origins in my (two) groups (one for www content, the other an endpoint to receive file uploads. So, no balancing across istances

The MS docs certainly give the impression it should "just work", but that has most definitely not been my experience thus far with Azure Front Door Premium...

https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/troubleshoot-cross-origin-resources#wildcard-or-single-origin-scenarios

I am hoping you're right about the healthchecks failing causing requests to not be passed through (that would confirm what I am seeing logged on the back end, nothing except the app service checks are showing up).
Rohith Vinnakota 3,835 Reputation points Microsoft External Staff

2025-04-01T21:54:10.96+00:00

Hello @WestCoastSolutionArch,
For further investigation, could you please share the following information:

Let me know which error you are encountering when accessing the front door URL,and also share a screenshot of the error.

Also, try to check the front access logs when encountering the 5xx error to see what client status is being given.

Could you please try accessing the backend web app URL directly and inform me if it is working or not?

If it is not working, the issue might be from the backend. You need to check why the backend is behaving this way.

You can also collect the tracking reference ID (x-azure-ref) from the access logs when encountering the 5xx error. Use this reference ID (x-azure-ref) to check the logs in your Azure portal.
Please refer to the following document for collecting the logs: Troubleshoot Azure Front Door common issues | Microsoft Learn

Also, please let me know how you are using the 8080 port in the AFD (How are you configuring 8080?)

Similar case: https://learn.microsoft.com/en-us/answers/questions/1487952/configure-port-8080-on-azure-frontdoor-site
WestCoastSolutionArch 21 Reputation points

2025-04-02T04:12:15.13+00:00

Hello Rohith,

Thank you for this feedback. A little more info/feedback on my part first...

Regarding accessing my webapp directly, it is in a private vnet. I could try curl'ing the private DNS endpoint within the vnet my ubuntu peer vm?

Port 8080...

My research thus far lead me to believe this may be the culprit. In additional to your very helpful QA link (to answer my next question as to which port the origin should route to), I found the following documentation (finally)...

"By default, App Service assumes your custom container listens on port 80. If your container listens to a different port, set the WEBSITES_PORT app setting in your App Service app."
https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?tabs=debian&pivots=container-linux#configure-port-number

Currently my project is rebuilding/deploying with changes in light of this info. I suspect it will at least help narrow the scope of the disconnect and will let you know how it goes.

PS: An example of a failed (HTTP504) healthcheck request to my endpoint (via afd)...

x-azure-ref: 20250402T041248Z-17cccd5449b4wvd9hC1EWRkczn00000014n000000000bpax
WestCoastSolutionArch 21 Reputation points

2025-04-02T04:38:36.1733333+00:00

Hmm... I'm still seeing the following in the deployment logs. I am going to give it a bit and see if perhaps not all code/configuration has finished fully deploying...

2025-04-02T04:23:28.7152719Z Starting container: {redacted}. 2025-04-02T04:23:28.7347110Z Starting watchers and probes. 2025-04-02T04:23:28.7349092Z Starting metrics collection. 2025-04-02T04:23:28.7350028Z Container is running. 2025-04-02T04:23:28.7500411Z Container start method finished after 1044 ms. 2025-04-02T04:23:29.8558212Z Site startup probe succeeded after 1.1039983 seconds. 2025-04-02T04:23:29.8567561Z Site started. 2025-04-02T04:23:49.8688823Z Container is terminating. Grace period: 5 seconds. 2025-04-02T04:23:49.8706465Z Stop and delete container. Retry count = 0 2025-04-02T04:23:49.8707023Z Stopping container: {redacted}. 2025-04-02T04:23:50.9486194Z Deleting container: {redacted}. Retry count = 0 2025-04-02T04:23:51.6612741Z Container spec TerminationMessagePolicy path 2025-04-02T04:23:51.6616194Z Container is terminated. Total time elapsed: 1792 ms.

Here is a devtools screenshot of the attempt to request the healthcheck endpoint...
WestCoastSolutionArch 21 Reputation points

2025-04-02T12:18:33.2066667+00:00

Regarding "accessing my webapp directly", trying curl from another host in the vnet works for both apps/routes/origin-groups behind my afd instance...

$ curl https://app1-randomstring.westus-01.azurewebsites.net -I HTTP/1.1 200 OK

$ curl https://app2-randomstring.westus-01.azurewebsites.net/onsite/report/healthcheck -I HTTP/1.1 200 OK

I appear to have the healthchecks resolved and the containers stable. I am able to route/browse to first app/origin via the front door (and custom domain), but unable to still to the second app/route (though it works "directly" as shown above). Attemping to do so still results in a 504 error (x-azure-ref: 20250402T121615Z-17cccd5449bvj9xqhC1EWRh59s00000015h000000000cukq)

Thanks for your help with this, it is bizarre to me.
ChaitanyaNaykodi-MSFT 27,366 Reputation points Microsoft Employee

2025-04-02T20:07:30.46+00:00

@WestCoastSolutionArch

Thank you for getting back here and sharing the Ref ID.

Based on the Ref-id I can see there is a OriginTimeout error observed here.

Based on the error can you try following the troubleshooting steps in the document here if not already done so

Configure the Origin response timeout for Azure Front Door. You can increase the default timeout to up to 4 minutes (240 seconds).

If increasing the timeout doesn't resolve the issue, use a tool like Fiddler or your browser's developer tool to check if the client is sending byte range requests with Accept-Encoding headers. Using this option leads to the origin responding with different content lengths. If the client is sending byte range requests with Accept-Encoding headers, you have two options. The first option is to disable compression on the origin or Azure Front Door. The second option is to create a rules set rule to remove Accept-Encoding from the request for byte range requests.

As we proceed with troubleshooting this issue, can you please share the requested details below?

I understand your backend web apps are deployed in a Vnet, can you please share a rough network diagram of your set-up here? I just want to make sure if there are no NSG or any connectivity issue here.

For the request which gives 504 error, can you please check is there is any error observed in the backend web app logs for the same request. If it helps Azure Front Door Appends the these headers to each request.

Thank you!
WestCoastSolutionArch 21 Reputation points

2025-04-02T23:39:13.6266667+00:00

This is interesting, on host in vnet...

$ curl https://app2-randomstring.westus-01.azurewebsites.net/ -I HTTP/1.1 405 Method Not Allowed Date: Wed, 02 Apr 2025 23:22:19 GMT Server: Kestrel Allow: GET

Perhaps that is pointing to a healthcheck related (code/webapp) issue rather than port mapping (at least at this point)?

The "app2" webapp (dotnet 8) simply does...

app.MapGet("/", () => Results.Ok()); app.MapControllers();

...which I wouldn't expect to return a 405? Perhaps this is due to app.UseCors middleware being called before the MapGet? But UseCors includes HttpMethods.Get in the list of allowed methods with CORS related requests (so even if it were to apply, it specifically allows GET requests to the root path/route of the webapp, non afd).

It works locally without issue. Perhaps is CORS related, causing healthchecks to fail... but why would the other (longer) route/path to the same webapp work?
WestCoastSolutionArch 21 Reputation points

2025-04-04T03:43:56.8966667+00:00

Using the "Diagnose and solve problems" blade on my front door instance, I was lead to...

! Some container port settings were found from logs Exposed port by container Unknown Listening port by container 8080 Platform logs contain errors or warnings * Container {redacted} for site {app2} did not start within expected time limit.

Which would be consistent with webapp1 requests working via afd and vnet, while webapp2 (dotnet 8, port 8080) does not work via afd but does via vnet.

How is afd port 80 mapped to webapp port 8080? The documentation indicates that it is a "Default value is 80. Enter the value for the port that the origin supports for HTTP protocol.", but apparently that isn't the case?

Note, as a containerized webapp, it "only exposes/uses one port", and since I have afd forwarding all traffic as http, I left the default/unused HTTPS port unchanged.
KapilAnanth-MSFT 49,281 Reputation points Microsoft Employee

2025-04-11T04:08:12.42+00:00

@WestCoastSolutionArch ,

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil

Answer 1

KapilAnanth-MSFT 49,281 Microsoft Employee

Hi @WestCoastSolutionArch ,

Greetings.

From the conversation you had with ChaitanyaNaykodi-MSFT, I take it that

You have two applications, app1 and app2 - they are Azure App Service
You confirmed that app1 works, but not app2
You also mentioned that app2 has a Private EndPoint (PE)
Accessing the app2 from a VM in the VNET where the PE resides, gives you 200 responses.

Please let me know if this is incorrect.

My follow up questions would be,

Are you trying to
- route requests to a single endPoint to 2 different Origins, app1 and app2 via Path matching, i.e., single AFD endpoint with 2 routes ?
- or created 2 separate endPoints, each with it's own Origins app1 and app2 and own routes?
You mentioned you are using a Private EndPoint and you are able to access the App Service only via a VM in same VNET as the PE
- This is misleading.
- Note that a regular PE is not same as AFD Premium's PE. See : Connect AFD Premium to an App Service origin with Private Link
- If you haven't created a AFD PE, and your app2 is blocked for public access - this simply means AFD will not be able to access the app2 in any port.
I see you got 200 responses when you access app2 via VM.
- As mentioned by ChaitanyaNaykodi-MSFT, "curl" by default would use port 80 only. Also, if you specify "https" , it would use 443 only. Please run,

curl http://app2-randomstring.<region>.azurewebsites.net:8080/onsite/report/healthcheck -I

- Can you also run nslookup app2-randomstring.<region>.azurewebsites.net ? from this VM

Analysis:

AFAIK - your webapp is running in Port 80 only
I tried to curl your web app on
- Port 80 - Getting 403 (meaning network blocked me, but still I was able to get a response)
- Port 8080 - No response, timed out

As next steps,

From your screenshot, I do see that you have created a AFD Premium Private endPoint, so this should be fine.
For testing
- You can change the port to 80 in the Origin configuration.
- If this works, it simply means your application is running on Port 80 all along
In that case, you can refer to Configure port number to set the port to 8080

NOTE: If you have single endPoint and multiple routes, this is how it would look like,

User's image

Hope this helps.

Cheers,

Kapil

WestCoastSolutionArch 21 Reputation points

2025-04-04T12:28:16.75+00:00
Hello Kapil,

Doing my best cover your feedback/questions...

You have two applications, app1 and app2 - they are Azure App Service

Correct. Containers running as webapps

"app1" = dotnet 3.1, port 80

"app2" = dotnet 8, port 8080

You confirmed that app1 works, but not app2

app1 = works fully, correct

app2 = I can get a response from healthcheck routes via the vnet, but not when routed through/behind the afd (more details below)

You also mentioned that app2 has a Private EndPoint (PE)

Both apps, as per RWA design, have private endpoints to their respective vnet subnets (no?)

Accessing the app2 from a VM in the VNET where the PE resides, gives you 200 responses.

Correct

Are you trying to

route requests to a single endPoint to 2 different Origins, app1 and app2 via Path matching, i.e., single AFD endpoint with 2 routes ?

Correct

or created 2 separate endPoints, each with it's own Origins app1 and app2 and own routes?

The prior, one afd endpoint, two origins (routed by path)

You mentioned you are using a Private EndPoint and you are able to access the App Service only via a VM in same VNET as the PE

This is misleading.

I did not intend to conflate the use of the words "Private endpoint". In the RWA it appears each app had their own to the vnet subnet (and then one in for the afd to connect to the app origin via the private/Azure DNS).

Note that a regular PE is not same as AFD Premium's PE. See : Connect AFD Premium to an App Service origin with Private Link

Should it be an either/or scenario? In that case, how does something route from afd to origin not exposed publicly?

If you haven't created a AFD PE, and your app2 is blocked for public access - this simply means AFD will not be able to access the app2 in any port.

app2 also has its own afd private link (in addition to its own private link to vnet, and also with vnet integration)

I see you got 200 responses when you access app2 via VM.

As mentioned by ChaitanyaNaykodi-MSFT, "curl" by default would use port 80 only. Also, if you specify "https" , it would use 443 only. Please run...

Ah, yes a typo. Apologies for the confusion....

~$ curl http://app2.westus-01.azurewebsites.net/ -I HTTP/1.1 405 Method Not Allowed ~$ curl http://app2.westus-01.azurewebsites.net/onsite/report/healthcheck -I HTTP/1.1 200 OK ~$ curl http://app2.westus-01.azurewebsites.net:8080/ -I curl: (28) Failed to connect to app2.westus-01.azurewebsites.net port 8080 after 134007 ms: Connection timed out ~$ curl http://app2.westus-01.azurewebsites.net:8080/onsite/report/healthcheck -I curl: (28) Failed to connect to app2.westus-01.azurewebsites.net port 8080 after 134007 ms: Connection timed out

nslookup test results...

$ nslookup app2.westus-01.azurewebsites.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: app2.westus-01.azurewebsites.net canonical name = app2.westus-01.privatelink.azurewebsites.net. Name: app2.westus-01.privatelink.azurewebsites.net Address: 10.0.x.y

"You can change the port to 80 in the Origin configuration... If this works, it simply means your application is running on Port 80 all along"

That will be very bizarre as it conflicts with the EXPOSE statement in the container's dockerfile (again, dotnet 8 so it is 8080), as well as the setting I specified for the origin's Http port setting. How is it getting set to 80? This isnt a helpful developer experience or documentation that seems to be misleading... no?

"refer to Configure port number to set the port to 8080"

I do have "WEBSITES_PORT" set in app2's environment variables, and see in the Deployment Center logs that 8080 is the port app2 is listening on (as well as the specified port in the origin defined in the origin group)... part of why it is so peculiar that, via host in vnet, port 80 works while 8080 does not?

"...single endPoint and multiple routes..."

That matches what I have (single endpoint shown, two route listed, to their respective origin groups (app1 vs app2)

I'll try setting the Http port for the origin to 80 and see if that works (despite the documentation seemingly indicating otherwise).

Thanks for your help and feedback.
WestCoastSolutionArch 21 Reputation points

2025-04-04T12:49:45.91+00:00

PS: Setting the origin port to 80, now yields a blue screen with "404 Web Site not found" when trying to view https://app2...:80/onsite/report/healthcheck/ via afd/browser (whereas before, it was returning 504)

Not sure what this indicates. The system does claim there may be some caching going on that hasn't flushed out or reset just yet (uncertain how long after updating the origin it should then be applied).

PPS: Now the requests for app2's /onsite/report/heathcheck redirect me to the path for app1 (app1's "/", a SPA frontend). I think the previous 404 was due to a trailing "/" on "healthcheck" (typo)
KapilAnanth-MSFT 49,281 Reputation points Microsoft Employee

2025-04-04T13:14:14.7366667+00:00
@WestCoastSolutionArch - You're most welcome.

I understand, HTTP Port according to documentation should be 8080.

However, before troubleshooting that - I want to make sure that there is no issue from AFD side (i.e., AFD routing works)

Now to address your query, "Should it be an either/or scenario? In that case, how does something route from afd to origin not exposed publicly?"

It should be both for a tightened network security - Also, if you are locking your PaaS with a regular Private Endpoint, it only makes sense you leverage AFD Premium's Private EndPoint. Else, you will not be able to route from AFD to the PaaS via Public network.

The routing is handled by the platform, as the PaaS is first party

From your curl, it is evident that app2 is listening on Port 80.

One more thing I noticed is that "http://app2.westus-01.azurewebsites.net**/onsite/report/healthcheck**" works and "http://app2.westus-01.azurewebsites.net" doesn't

So make sure you either

Disable Health Probes at Origin Group

or you add the path /onsite/report/healthcheck in the Health probes section

And also verify if "HEAD" method is supported - if not, go for "GET"

Let us know what you see for AFD once you change the HTTP port to 80 in Origin config.

Additionally, you can leverage AFD Access log to understand what the Origin responded and what was the path sent to the origin (since you mentioned the use of path based routing).

Cheers,

Kapil
WestCoastSolutionArch 21 Reputation points

2025-04-04T18:08:41.68+00:00
Disable Health Probes at Origin Group

I thought this was not possible, as they were required to ensure the load can be routed/balanced, no? I'll gladly turn them off (since I have a single container in each origin/webapp group)

front door heath: (100% roughly since changing origin http port to 80)

app1: "100.00% (Healthy 1 / Degraded 0)"

app2: "100.00% (Healthy 1 / Degraded 0)"

or you add the path /onsite/report/healthcheck in the Health probes section

This is as I have had it configured (see afd/overall health checks above

Let us know what you see for AFD once you change the HTTP port to 80 in Origin config.

Verifying http port setting...
az afd origin show ` --resource-group {redacted}-infrastructure` --profile-name {redacted}-fd ` --origin-group-name {app2}-origins ` --origin-name {app2}-origin ` --query "httpPort" ` -o tsv
80

Verifying WEBSITES_PORT...
az webapp config appsettings list ` --resource-group {redacted}-a ` --name {app2} ` --query "[?name=='WEBSITES_PORT'].value" ` -o tsv
8080

This has been changed, requests for app2 (dotnet 8, "/onsite/report/healthcheck") routes result in a 404 error. Just purging afd cache in case that might help it route as expected now

Enabling access logs (I had been relying on az webapp log download... to get app logs)
WestCoastSolutionArch 21 Reputation points

2025-04-04T18:25:51.18+00:00

Re: Access Logs...

...the healthchecks are completing as expected, in the healthcheck system. As noted previously, trying to hit that origin via afd results in a 404 currently.
WestCoastSolutionArch 21 Reputation points

2025-04-04T20:40:58.4766667+00:00
Confirming WEBSITES_PORT "maps" webapp ("App Service") port 80 to image Dockerfile's EXPOSE statement... stackoverflow, this and past QA, and docs. Thank you!

Now to find out why https://{front door endpoint}/onsite/report/healthcheck, which routes to the following handler in app2...

[HttpHead] // optimized for health check [HttpGet] // This is for use with Azure Front Door Premium (afd) health check [Route("healthcheck")] [ProducesResponseType(StatusCodes.Status200OK)] public IActionResult HealthCheck() { return Ok(new { status = "Healthy", source = "ReportsServerController" }); }

...returns a 404? But not in vnet via webapp directly.

I'm waiting for some logging data to be captured to analyze.
WestCoastSolutionArch 21 Reputation points

2025-04-05T04:55:33.4033333+00:00
Digging through logs...

AzureDiagnostics | where httpStatusCode_s in (```404```)

I only see two 404 instances generated in the last 24hrs :-( (an odd thing to be disappointed about) that aren't relevant (given how many similar logged request succeeded I can only presume that these happened after an attempt to access resources after the logout button was hit). How else might I diagnose what is causing the 404 errors?
KapilAnanth-MSFT 49,281 Reputation points Microsoft Employee

2025-04-08T17:27:15.1+00:00
Thanks for the details @WestCoastSolutionArch .

Wrt Logs,

Are you sure you are seeing the "HttpStatusCode" from AccessLogs and not Health probe log

Can you please use the below query

AzureDiagnostics | where Category == "FrontDoorAccessLog"

and share the entire row (where there is a 404)

I would like to know if the 404 is from the AFD or from the Origin (App2).

NOTE :

As mentioned, Private EndPoint of a VNET is not same as Private EndPoint created by AFD Premium.

So comparing access via VM(private) and AFD (from public) is not the right approach.

Can you confirm if Approve Azure Front Door Premium private endpoint step has been done in the WebApp

Also, I see you are using health probes only,

Can you run

AzureDiagnostics | where Category == "FrontDoorHealthProbeLog"

And share the results.

Do you see constant 404 or any errors? (you can filter for app2 using the field "originName")

Cheers,

Kapil

Share via

Failed healthchecks, http 50x errors in webapp container as afd origin (single instance origin groups)

1 answer

Your answer