499 status code returned from container app

Question

499 status code returned from container app

Aya Taha 20

I have a container app that receives requests through Azure front endpoint

below are my current settings:
-the container app has ingress enabled and accepts traffic from anywhere
-the container app environment is linked to VNet
-NAT gateway is linked to the same VNet

I have the following issues:
1- I got HTTP status code 499 randomly although the service average response time is a few seconds
2- I see HTTP requests in logs instead of https although the endpoint is configured to use https only and forwarding requests to https only

and these issues didn't exist when the same endpoint was connected to Azure app service instead of Azure container app

Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-09T12:58:43.6433333+00:00

@Aya Taha ,

Thanks for reaching out.

What we’re seeing here likely comes down to differences in how Azure App Service and Azure Container Apps handle things like ingress, HTTPS forwarding, and networking behind the scenes.

App Service handles a lot of this automatically — like always forwarding traffic over HTTPS and managing cold starts and networking gracefully. Container Apps, on the other hand, gives us more flexibility but also requires us to explicitly configure things like backend HTTPS, timeout settings, and warm-up strategies.

So the 499 responses you're seeing could be related to slight delays (like cold starts or SNAT port limits in the NAT Gateway), and the HTTP logs might be because Front Door is terminating HTTPS and forwarding as HTTP unless we’ve told it to do otherwise.
Aya Taha 20 Reputation points

2025-04-09T14:34:17.92+00:00

in FrontDoor endpoint route:
accepted protocols is HTTPs Only
Redirect all traffic to use HTTPS is checked
Forwarding protocol is HTTPs only

in the container app ingress:
Insecure connections Allow is not checked

so what are the missing settings to receive https requests by the container app?
Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-10T12:21:40.8666667+00:00
@Aya Taha ,

To help isolate where the issue might be coming from, could you please confirm the following:

If you bypass Azure Front Door and access the Container App directly (using its default .azurecontainerapps.io domain), does everything work as expected — especially with HTTPS?

If authentication is enabled (e.g., Azure AD, social login, etc.), could you please verify that the redirect URIs are correctly configured to use HTTPS instead of HTTP? Sometimes misconfigured redirect URIs can lead to HTTPS being downgraded or logged incorrectly.

These will help us pinpoint whether the behavior is caused by Front Door, the app, or some intermediate configuration.
Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-11T10:50:53.77+00:00

@Aya Taha ,

Just following up to see if you had a chance to review my previous message.
Aya Taha 20 Reputation points

2025-04-13T08:26:59.11+00:00

1-when the front door is bypassed, I still see the request with HTTP in logs

2-authentication is used but without redirection, ResourceOwnerPasswordCredentials is used - the authorization micro-service is deployed to another container app with internal ingress
Ryan Hill 30,181 Reputation points Microsoft Employee

2025-04-14T19:48:43.5933333+00:00

@Aya Taha please respond the private message.
LeelaRajeshSayana-MSFT 17,521 Reputation points

2025-04-16T22:52:14.8533333+00:00

@Aya Taha apologies for the delay in getting back to you. Looking at the response codes returned from the Application gateway, 499 error indicates - the connection is closed by the Client. You could see this response code in instances where the client request that is sent to application gateways using v2 sku is closed before the server finished responding. This error can be observed in 2 scenarios. The first scenario is when a large response is returned to the client and the client might have closed or refreshed the application before the server finished sending a large response. The second scenario is when the time-out on the client side is low and doesn't wait long enough to receive the response from server. In this case it's better to increase the time-out on the client. Refer the documentation - HTTP response codes for more information on this.

Please try to increase the client application time-out settings and see if that helps.

Your answer

Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-09T12:58:43.6433333+00:00

@Aya Taha ,

Thanks for reaching out.

What we’re seeing here likely comes down to differences in how Azure App Service and Azure Container Apps handle things like ingress, HTTPS forwarding, and networking behind the scenes.

App Service handles a lot of this automatically — like always forwarding traffic over HTTPS and managing cold starts and networking gracefully. Container Apps, on the other hand, gives us more flexibility but also requires us to explicitly configure things like backend HTTPS, timeout settings, and warm-up strategies.

So the 499 responses you're seeing could be related to slight delays (like cold starts or SNAT port limits in the NAT Gateway), and the HTTP logs might be because Front Door is terminating HTTPS and forwarding as HTTP unless we’ve told it to do otherwise.
Aya Taha 20 Reputation points

2025-04-09T14:34:17.92+00:00

in FrontDoor endpoint route:
accepted protocols is HTTPs Only
Redirect all traffic to use HTTPS is checked
Forwarding protocol is HTTPs only

in the container app ingress:
Insecure connections Allow is not checked

so what are the missing settings to receive https requests by the container app?
Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-10T12:21:40.8666667+00:00

@Aya Taha ,

To help isolate where the issue might be coming from, could you please confirm the following:

If you bypass Azure Front Door and access the Container App directly (using its default .azurecontainerapps.io domain), does everything work as expected — especially with HTTPS?

If authentication is enabled (e.g., Azure AD, social login, etc.), could you please verify that the redirect URIs are correctly configured to use HTTPS instead of HTTP? Sometimes misconfigured redirect URIs can lead to HTTPS being downgraded or logged incorrectly.

These will help us pinpoint whether the behavior is caused by Front Door, the app, or some intermediate configuration.
Khadeer Ali 4,710 Reputation points Microsoft External Staff

2025-04-11T10:50:53.77+00:00

@Aya Taha ,

Just following up to see if you had a chance to review my previous message.
Aya Taha 20 Reputation points

2025-04-13T08:26:59.11+00:00

1-when the front door is bypassed, I still see the request with HTTP in logs

2-authentication is used but without redirection, ResourceOwnerPasswordCredentials is used - the authorization micro-service is deployed to another container app with internal ingress
Ryan Hill 30,181 Reputation points Microsoft Employee

2025-04-14T19:48:43.5933333+00:00

@Aya Taha please respond the private message.
LeelaRajeshSayana-MSFT 17,521 Reputation points

2025-04-16T22:52:14.8533333+00:00

@Aya Taha apologies for the delay in getting back to you. Looking at the response codes returned from the Application gateway, 499 error indicates - the connection is closed by the Client. You could see this response code in instances where the client request that is sent to application gateways using v2 sku is closed before the server finished responding. This error can be observed in 2 scenarios. The first scenario is when a large response is returned to the client and the client might have closed or refreshed the application before the server finished sending a large response. The second scenario is when the time-out on the client side is low and doesn't wait long enough to receive the response from server. In this case it's better to increase the time-out on the client. Refer the documentation - HTTP response codes for more information on this.

Please try to increase the client application time-out settings and see if that helps.

Share via

499 status code returned from container app

Your answer