Application Gateway returns 502 for App Service backend by FQDN

Question

Application Gateway returns 502 for App Service backend by FQDN

Ievgen Kurinnyi 20

Problem

Azure Application Gateway returns 502 Bad Gateway for a custom domain routed to an Azure Web App (App Service). The Web App is reachable directly, but Application Gateway backend health for the App Service endpoint remains in error state when the backend is configured by FQDN.

Key symptoms

https://ecxportalpoc.ecxecx.com/ returns 502 Bad Gateway
Application Gateway backend health shows:
- The backend health status could not be retrieved...
Connection Troubleshoot reported:
- Local Error: DNSResolution

Confirmed working

Application Gateway frontend is reachable and presents the expected certificate:

subject: CN=ecxportalpoc.ecxecx.com

Public DNS for the custom domain now points to the Application Gateway public IP
Custom DNS server 1.0.0.68 in the VNet forwards unresolved Azure records to 168.63.129.16
DNS from a VM in the same VNet resolves both:
- the custom domain chain correctly
- the default Web App hostname to the correct IP
Direct backend test to App Service succeeds:

curl -Ik https://ecxsp06pwap04temp-cwhbcefqcrg9fnch.westus-01.azurewebsites.net/ -H 'Host: ecxportalpoc.ecxecx.com'

Response:

HTTP/1.1 200 OK

Direct TLS/SNI test to App Service also succeeds:

openssl s_client -connect ecxsp06pwap04temp-cwhbcefqcrg9fnch.westus-01.azurewebsites.net:443 -servername ecxportalpoc.ecxecx.com

Result:

subject=CN=ecxportalpoc.ecxecx.com
Verify return code: 0 (ok)

Configuration checks already done

Listener, backend pool, backend settings, health probe, and rule were reviewed and appear correct
Application Gateway was stopped and started after DNS correction
NSG and route table on the Application Gateway subnet were reviewed with no obvious issue found

Important observation

For test purposes, Application Gateway health works if the backend pool is configured with the direct App Service IP. This is not a valid production solution because App Service backend IP is not a stable target.

Request

Please help identify why Application Gateway cannot successfully resolve/probe/route to the App Service backend by FQDN in this configuration, even though:

DNS resolution works through the configured custom DNS path
Direct HTTPS and TLS/SNI tests to the App Service backend succeed
The same backend works when configured by IP only

Questions

Why does Application Gateway backend health fail for the App Service FQDN while direct backend tests succeed?
Is there any known issue or additional requirement for Application Gateway with App Service backend resolution through custom DNS forwarding to 168.63.129.16?
Is there any hidden NSG/UDR/control-plane dependency that can cause this exact health error and 502 behavior?

Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-21T00:17:19.3833333+00:00
Hi Ievgen Kurinnyi,

it looks like your Application Gateway is healthy up front but its health probe can’t turn your custom FQDN into the real App Service IP because DNS isn’t resolving the hidden *.azurewebsites.net hostname. Here’s the breakdown and how to fix it:

Why it fails by FQDN but works by IP:

When you point your backend pool at the App Service’s IP, you skip DNS entirely, so the probe succeeds.

When you use the FQDN (ecxportalpoc.ecxecx.com), Application Gateway asks your VNet DNS to resolve both that name and the underlying azurewebsites.net address. If your custom DNS server doesn’t forward azurewebsites.net queries to Azure’s resolver (168.63.129.16), the probe throws a DNSResolution error.

DNS‐forwarding gotcha : Application Gateway won’t automatically be fallback to 168.63.129.16 if your DNS can’t answer. You have two main options:

Create an Azure Private DNS Zone for ecxecx.com, add a CNAME from your custom domain → ecxsp06pwap04temp-…azurewebsites.net, and link the zone to your VNet.

Update your custom DNS server so it handles both your custom domain and forwards any *.azurewebsites.net queries to 168.63.129.16.

Host header & probe settings: Make sure your HTTP probe uses the correct Host header. In your Backend HTTP settings, you can:

Pick the hostname from the backend target (so it sends the azurewebsites.net name)

Or explicitly override the Host header to the default *.azurewebsites.net hostname This ensures SNI, and certificate validation align.

NSG/UDR or other hidden dependencies: There’s no secret NSG, UDR or control-plane requirement here beyond allowing outbound DNS and HTTPS. The only blocker is the DNS lookup itself.

Once you fix DNS resolution for *.azurewebsites.net, your backend health should turn green, and the 502 errors will go away.

Reference docs:

Troubleshoot Bad Gateway errors - Azure Application Gateway - Azure | Microsoft Learn

Troubleshoot backend health issues in Azure Application Gateway - Azure | Microsoft Learn

Azure Private DNS: Secure DNS for Virtual Networks | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-23T16:56:50.0033333+00:00

Hi Ievgen Kurinnyi,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ievgen Kurinnyi 20 Reputation points

2026-03-23T18:10:18.7266667+00:00
Thank you for the guidance.

We rechecked our DNS path and would like to clarify which exact DNS requirement is still missing in our configuration.

What we have already verified

Public DNS for the custom hostname points to the Application Gateway public IP

Our custom DNS server:

12.0.0.68

resolves the App Service default hostname correctly.

Our custom DNS server already forwards unresolved Azure records, and App Service hostname resolution succeeds through that path.

Direct backend HTTPS and TLS/SNI tests to App Service succeed:

Direct HTTPS with host header for the custom domain returns HTTP/1.1 200 OK

Direct TLS/SNI test returns a valid certificate for the custom domain

Application Gateway frontend is reachable and presents the expected certificate for the custom domain.

Main question

Please confirm whether Azure requires split-horizon DNS for the custom hostname in this scenario, for example:

public DNS:

ecxportalpoc.ecxecx.com -> 20.245.193.154 (Application Gateway public IP)

private/VNet DNS:

ecxportalpoc.ecxecx.com -> CNAME -> ecxsp06pwap04temp-cwhbcefqcrg9fnch.westus-01.azurewebsites.net

If this is required, please explain why Application Gateway cannot work with the following already configured model:

backend pool target:

App Service default hostname

backend host header / probe host:

custom hostname

public DNS for the custom hostname:

Application Gateway public IP

Please clarify which of the following is actually required

A conditional forwarder specifically for azurewebsites.net

An Azure Private DNS zone for the custom domain

Both of the above

Additional note

From our current testing, App Service default hostname resolution through our custom DNS path already works, so we want to understand what additional dependency is still missing from the Application Gateway perspective.
Ievgen Kurinnyi 20 Reputation points

2026-03-23T21:47:36.8733333+00:00

I have just double checked that our custom DNS server is configured with the correct DNS forwarder, and we can successfully resolve Azure hostnames from one of the VMs in the same VNet using that custom DNS server.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-23T22:14:52.6766667+00:00
Ievgen Kurinnyi,

The issue you’re seeing is caused by how Application Gateway resolves the backend FQDN inside the VNet, not by a missing general DNS forwarder. Your current DNS path already resolves *.azurewebsites.net correctly, so the core DNS forwarding is fine.

For this setup, the cleanest and most supported pattern is:

Keep the backend pool member as the App Service default hostname (e.g., ecxsp06pwap04temp-...azurewebsites.net).

Configure the Host header and probe host as your custom domain (ecxportalpoc.ecxecx.com).

Leave public DNS pointing ecxportalpoc.ecxecx.com to the Application Gateway public IP.

This avoids any split‑horizon complexity because Application Gateway resolves the backend to the App Service IP, while the App Service itself sees the correct host header and certificate.

If you later want to use the custom domain FQDN directly as the backend pool member, you’ll need an internal DNS path (such as an Azure Private DNS zone) that maps ecxportalpoc.ecxecx.com to the App Service FQDN inside the VNet, rather than letting it resolve back to the Application Gateway’s public IP.

For more details, you can refer to the official docs:

Configure Application Gateway with an App Service backend

Troubleshoot backend health issues in Application Gateway

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ievgen Kurinnyi 20 Reputation points

2026-03-24T19:49:22.42+00:00
Thank you. This helps clarify the expected design.

I confirm that our current configuration already matches the supported pattern you described:

Backend pool member = App Service default hostname

Backend host header / probe host = custom domain

Public DNS for the custom domain = Application Gateway public IP

I also confirmed:

our custom DNS server resolves the App Service default hostname correctly from a VM in the same VNet

direct HTTPS and TLS/SNI tests to the App Service backend succeed

Application Gateway still returns 502 and backend health remains in error state when using the backend FQDN

for testing only, health works when the backend pool uses the direct App Service IP

Given that our current configuration already matches the supported pattern, please advise what exact next diagnostic step you recommend. Specifically, could you please clarify:

Do you see any mismatch between our current configuration and the supported pattern you described?

What exact Application Gateway diagnostic logs or backend health details should we capture next to identify why FQDN backend resolution/probing still fails?

Is there any known limitation or issue with Application Gateway using a custom DNS server to resolve an App Service backend by FQDN in this configuration?

If you believe DNS is still the root cause, please specify which exact hostname is failing to resolve from the Application Gateway perspective, because the App Service default hostname already resolves correctly through our VNet DNS path.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-25T00:12:03.1566667+00:00
Thank you for confirming the details. You’re right that your current configuration already matches the supported pattern:

Backend pool member = App Service default hostname

Backend host header / probe host = custom domain

Public DNS for the custom domain = Application Gateway public IP

So there is no documented configuration mismatch; the fact that health works when you use the App Service IP proves the backend is reachable. The remaining issue is almost certainly around how Application Gateway itself resolves the App Service FQDN, not how a VM in the same VNet resolves it.

Check:

To narrow this down, I recommend focusing on three concrete diagnostic steps:

Application Gateway backend‑health logs

Enable ApplicationGatewayBackendHealth diagnostics on the gateway and send them to Log Analytics or Storage.

Filter for your backend pool and look at:

The BackendServer value (this is the exact FQDN AG is trying to resolve).

The HealthStatusDetail field; if it mentions DNSResolution or similar, that confirms AG cannot resolve the backend FQDN on its own.

DNS behavior from AG’s perspective

Even though a VM in the same VNet can resolve the App Service FQDN, Application Gateway uses the VNet’s DNS servers independently and may have a different path or cache.

Confirm that:

The VNet DNS server list includes your custom DNS server (12.0.0.68).

The custom DNS server forwards *.azurewebsites.net to 168.63.129.16 without returning NXDOMAIN or timeouts.

If you changed DNS settings recently, stop and start (or fully redeploy) the Application Gateway so it picks up the updated DNS configuration; Azure docs note that DNS changes sometimes require this.

Exact backend‑pool and HTTP‑settings configuration

Double‑check that the backend pool member is only the App Service FQDN (not the custom domain or any alias).

In the backend HTTP settings:

Set the Host name to ecxportalpoc.ecxecx.com (or let it pick the host name from the backend).

Ensure the probe host header is also ecxportalpoc.ecxecx.com.

If you’re using a custom probe, verify it sends the same host header.

Is DNS still the root cause?

If the logs show that AG is failing to resolve the exact App Service FQDN (e.g., ecxsp06pwap04temp-...azurewebsites.net), then the issue is that AG is not resolving that name the same way the VM does. This can happen if:

AG hits a different DNS server or a cached negative result.

Your custom DNS server is not consistently forwarding *.azurewebsites.net to 168.63.129.16.

If the backend‑health logs show that AG is instead trying to resolve the custom domain as the backend (e.g., ecxportalpoc.ecxecx.com) and failing, then the root cause is that the backend pool is not actually pointing to the App Service FQDN, even though you think it is.

Next‑step

To move forward, I’d suggest:

Collect the ApplicationGatewayBackendHealth logs for your backend pool and share the BackendServer and HealthStatusDetail lines (with any sensitive names redacted).

Run a DNS test from a VM in the same VNet and subnet as the gateway:

nslookup ecxsp06pwap04temp-cwhbcefqcrg9fnch.westus-01.azurewebsites.net

Confirm it returns the App Service IP, not the AG IP.

This aligns with the official guidance on Application Gateway backend health troubleshooting and configuring Application Gateway with an App Service backend.

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-26T18:16:26.03+00:00

Hi Ievgen Kurinnyi,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 11,530 Reputation points Microsoft External Staff Moderator

2026-03-30T08:45:35.4566667+00:00

Hello Ievgen Kurinnyi

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

1 answer

Your answer

Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-23T16:56:50.0033333+00:00

Hi Ievgen Kurinnyi,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ievgen Kurinnyi 20 Reputation points

2026-03-23T18:10:18.7266667+00:00

Thank you for the guidance.

We rechecked our DNS path and would like to clarify which exact DNS requirement is still missing in our configuration.

What we have already verified

Public DNS for the custom hostname points to the Application Gateway public IP

Our custom DNS server:

12.0.0.68

resolves the App Service default hostname correctly.

Our custom DNS server already forwards unresolved Azure records, and App Service hostname resolution succeeds through that path.

Direct backend HTTPS and TLS/SNI tests to App Service succeed:

Direct HTTPS with host header for the custom domain returns HTTP/1.1 200 OK

Direct TLS/SNI test returns a valid certificate for the custom domain

Application Gateway frontend is reachable and presents the expected certificate for the custom domain.

Main question

Please confirm whether Azure requires split-horizon DNS for the custom hostname in this scenario, for example:

public DNS:

ecxportalpoc.ecxecx.com -> 20.245.193.154 (Application Gateway public IP)

private/VNet DNS:

ecxportalpoc.ecxecx.com -> CNAME -> ecxsp06pwap04temp-cwhbcefqcrg9fnch.westus-01.azurewebsites.net

If this is required, please explain why Application Gateway cannot work with the following already configured model:

backend pool target:

App Service default hostname

backend host header / probe host:

custom hostname

public DNS for the custom hostname:

Application Gateway public IP

Please clarify which of the following is actually required

A conditional forwarder specifically for azurewebsites.net

An Azure Private DNS zone for the custom domain

Both of the above

Additional note

From our current testing, App Service default hostname resolution through our custom DNS path already works, so we want to understand what additional dependency is still missing from the Application Gateway perspective.
Ievgen Kurinnyi 20 Reputation points

2026-03-23T21:47:36.8733333+00:00

I have just double checked that our custom DNS server is configured with the correct DNS forwarder, and we can successfully resolve Azure hostnames from one of the VMs in the same VNet using that custom DNS server.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-23T22:14:52.6766667+00:00

Ievgen Kurinnyi,

The issue you’re seeing is caused by how Application Gateway resolves the backend FQDN inside the VNet, not by a missing general DNS forwarder. Your current DNS path already resolves *.azurewebsites.net correctly, so the core DNS forwarding is fine.

For this setup, the cleanest and most supported pattern is:

Keep the backend pool member as the App Service default hostname (e.g., ecxsp06pwap04temp-...azurewebsites.net).

Configure the Host header and probe host as your custom domain (ecxportalpoc.ecxecx.com).

Leave public DNS pointing ecxportalpoc.ecxecx.com to the Application Gateway public IP.

This avoids any split‑horizon complexity because Application Gateway resolves the backend to the App Service IP, while the App Service itself sees the correct host header and certificate.

If you later want to use the custom domain FQDN directly as the backend pool member, you’ll need an internal DNS path (such as an Azure Private DNS zone) that maps ecxportalpoc.ecxecx.com to the App Service FQDN inside the VNet, rather than letting it resolve back to the Application Gateway’s public IP.

For more details, you can refer to the official docs:

Configure Application Gateway with an App Service backend

Troubleshoot backend health issues in Application Gateway

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ievgen Kurinnyi 20 Reputation points

2026-03-24T19:49:22.42+00:00

Thank you. This helps clarify the expected design.

I confirm that our current configuration already matches the supported pattern you described:

Backend pool member = App Service default hostname

Backend host header / probe host = custom domain

Public DNS for the custom domain = Application Gateway public IP

I also confirmed:

our custom DNS server resolves the App Service default hostname correctly from a VM in the same VNet

direct HTTPS and TLS/SNI tests to the App Service backend succeed

Application Gateway still returns 502 and backend health remains in error state when using the backend FQDN

for testing only, health works when the backend pool uses the direct App Service IP

Given that our current configuration already matches the supported pattern, please advise what exact next diagnostic step you recommend. Specifically, could you please clarify:

Do you see any mismatch between our current configuration and the supported pattern you described?

What exact Application Gateway diagnostic logs or backend health details should we capture next to identify why FQDN backend resolution/probing still fails?

Is there any known limitation or issue with Application Gateway using a custom DNS server to resolve an App Service backend by FQDN in this configuration?

If you believe DNS is still the root cause, please specify which exact hostname is failing to resolve from the Application Gateway perspective, because the App Service default hostname already resolves correctly through our VNet DNS path.
Venkatesan S 6,115 Reputation points Microsoft External Staff Moderator

2026-03-26T18:16:26.03+00:00

Hi Ievgen Kurinnyi,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 11,530 Reputation points Microsoft External Staff Moderator

2026-03-30T08:45:35.4566667+00:00

Hello Ievgen Kurinnyi

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

Answer 1

Hello Ievgen Kurinnyi

Thanks for the reply!

After you configure an application gateway, one of the errors that you may see is Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server. This error may happen for the following main reasons:

NSG, UDR, or Custom DNS is blocking access to backend pool members.
Backend VMs or instances of virtual machine scale set aren't responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's backend pool isn't configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.

NOTE: Enable and inspect the BackendHealth diagnostics

Turn on the ApplicationGatewayBackendHealth diagnostic category (Log Analytics or Storage).
Look at the records for your App Service backend.
In Backend Server – this is the exact FQDN AG is trying to resolve
HealthStatusDetail – if it mentions “DNSResolution,” it means the gateway itself can’t resolve that name.

Verify DNS from the gateway’s perspective

- Make sure your AG’s subnet DNS servers list includes your custom DNS forwarder (12.0.0.68).
- Confirm that your forwarder is sending all *.azurewebsites.net queries to 168.63.129.16, not just the app’s default hostname.
- Redeploy the Application Gateway so it picks up any recent DNS changes.
If DNS is truly the blocker, pick one of these production-grade solutions: Option A – Conditional forwarder on your DNS server for azurewebsites.net → 168.63.129.16 Option B – Azure Private DNS zone for your custom domain (or for the App Service FQDN), linked to the VNet, with a CNAME to the *.azurewebsites.net name

Once AG can resolve the App Service default FQDN natively, the health probe will turn green and the 502s will disappear.

Microsoft docs: How to Troubleshoot Bad Gateway (502) error in Application Gateway

Hope that helps!

If you are still facing an issue, please share the required details in a private message so we can connect 1:1 to resolve your query.

Share via

Application Gateway returns 502 for App Service backend by FQDN

Problem

Key symptoms

Confirmed working

Configuration checks already done

Important observation

Request

Questions

What we have already verified

Main question

Please clarify which of the following is actually required

Additional note

1 answer

Your answer