We are experiencing an issue with our Azure Application Gateway setup and need your assistance. Below are the details:

Question

We are experiencing an issue with our Azure Application Gateway setup and need your assistance. Below are the details:

Dilip Shukal 0

Environment:

Frontend Web App: Frontendwebapp

API Web App: apiwebapp

Application Gateway: appgw1

Listener: Public, path-based routing configured

Paths: / → Frontend, /graphql → API

Issue:

The Web Apps are accessible internally (within local network)

Public access is not working

Backend health in Application Gateway shows healthy for both Web Apps

Steps already performed:

Configured backend pools with correct Web App FQDNs

Enabled “Pick host name from backend target” in HTTP settings

Configured path-based routing for / and /graphql

Verified DNS pointing to Application Gateway public IP

Request:

Assistance in enabling public access for the above Web Apps via Application Gateway

Validation of configuration to ensure routing works correctly for both paths

Dilip Shukal 0 Reputation points

2025-10-15T04:53:18.07+00:00

Hi Microsoft Support Team,

We are experiencing an issue with our Azure Application Gateway setup and require your assistance. Below are the details of our environment and the issue:

Environment Details:

Web Apps:

Frontend Web App: Accessible publicly via https://frontend/error

API Web App: Accessible internally via https://frontend/graphql

Application Gateway Configuration:

Backend Pools:

Backend Pool 1 → Frontend Web App

Backend Pool 2 → API Web App

Backend Settings:

Frontend: Port 80, custom probe enabled

API: Port 443, custom probe enabled

Listener: Single listener on port 443 with public IP

Routing Rule: Path-based routing configured

/* → Frontend backend

/graphql → API backend

Health Probes:

Frontend: HTTP probe, path /, host and port from backend setting

API: HTTPS probe, path /graphql, host and port from backend setting

Issue Observed:

Frontend works fine publicly: https://frontend/error

API works internally: https://frontend/graphql

Public access to API: https://frontend/graphql results in 403 Forbidden

Observed behavior: When accessing the API URL (internal or external), it redirects to the default Azure domain (e.g., frontend.azurewebsites.net).

What We Have Tried:

Verified backend health – all backends are healthy

Checked path-based routing and backend settings

Request: Please advise on why the API web app is redirecting to its default domain when accessed via Application Gateway and how we can resolve this issue to allow public access through our frontend domain (https://frontend/graphql).

Let us know if you need any additional configuration details or screenshots.
Jeevan Shanigarapu 2,460 Reputation points Microsoft External Staff Moderator

2025-10-15T15:51:48.8633333+00:00

Hello @Dilip Shukal,

This issue usually happens because of a Host header mismatch. Azure App Service checks every incoming request’s Host header to make sure it matches the configured custom domain. If it doesn’t match, the service may either redirect the request to its default *.azurewebsites.net domain or block it entirely.

To fix the issue, kindly go through the above shared comment.

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

1 answer

Your answer

Dilip Shukal 0 Reputation points

2025-10-15T04:53:18.07+00:00

Hi Microsoft Support Team,

We are experiencing an issue with our Azure Application Gateway setup and require your assistance. Below are the details of our environment and the issue:

Environment Details:

Web Apps:

Frontend Web App: Accessible publicly via https://frontend/error

API Web App: Accessible internally via https://frontend/graphql

Application Gateway Configuration:

Backend Pools:

Backend Pool 1 → Frontend Web App

Backend Pool 2 → API Web App

Backend Settings:

Frontend: Port 80, custom probe enabled

API: Port 443, custom probe enabled

Listener: Single listener on port 443 with public IP

Routing Rule: Path-based routing configured

/* → Frontend backend

/graphql → API backend

Health Probes:

Frontend: HTTP probe, path /, host and port from backend setting

API: HTTPS probe, path /graphql, host and port from backend setting

Issue Observed:

Frontend works fine publicly: https://frontend/error

API works internally: https://frontend/graphql

Public access to API: https://frontend/graphql results in 403 Forbidden

Observed behavior: When accessing the API URL (internal or external), it redirects to the default Azure domain (e.g., frontend.azurewebsites.net).

What We Have Tried:

Verified backend health – all backends are healthy

Checked path-based routing and backend settings

Request: Please advise on why the API web app is redirecting to its default domain when accessed via Application Gateway and how we can resolve this issue to allow public access through our frontend domain (https://frontend/graphql).

Let us know if you need any additional configuration details or screenshots.
Jeevan Shanigarapu 2,460 Reputation points Microsoft External Staff Moderator

2025-10-15T15:51:48.8633333+00:00

Hello @Dilip Shukal,

This issue usually happens because of a Host header mismatch. Azure App Service checks every incoming request’s Host header to make sure it matches the configured custom domain. If it doesn’t match, the service may either redirect the request to its default *.azurewebsites.net domain or block it entirely.

To fix the issue, kindly go through the above shared comment.

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

Answer 1

Hello @Dilip Shukal,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand your question about the Azure Application Gateway setup for your webapps. You’re asking for our assistance in enabling public access for the specified Web Apps via the Application Gateway and confirming that the routing works correctly for both paths.

From your description, the Application Gateway and backend setup appear correct, as both Web Apps are marked as Healthy. This indicates the gateway is communicating with the backends without issues. The problem with public access likely stems from the listener, DNS, or network settings.Here are a few important checks to consider:

Reasons for This issue: Even if the backends are functioning properly, public access might still fail for the following reasons:

The listener is either missing or incorrectly configured, such as an HTTP/HTTPS mismatch or a missing SSL certificate.
The DNS is not resolving the Application Gateway’s public IP as expected.
The Network Security Group (NSG) or a User Defined Route (UDR) is blocking inbound traffic.
HTTPS-only is enabled on the Web App, but the gateway does not have SSL configured correctly.

Suggested Checks:

Listener & SSL

Make sure your Public Listener is assigned to the correct frontend public IP address.
If you're using HTTPS, ensure a valid SSL certificate is uploaded and bound.
Turn on SNI (Server Name Indication) if your Web Apps are configured with custom domains.

Routing Rules

/ → points to the Frontend Web App backend pool.
/graphql → points to the API Web App backend pool.

HTTP Settings

“Pick host name from backend target” (already done).
If the backend uses HTTPS, make sure “Use well-known CA certificate” is enabled or upload the backend’s root certificate.

DNS validation process:

Verify that your custom domain points to the Application Gateway public IP.
Access the site directly via the public IP to check for any DNS-related problems.
curl -I http://<AppGW-Public-IP>

Network Security

The NSG on the Application Gateway subnet should permit inbound traffic on ports 80 and 443.
Confirm that no UDR is restricting outbound internet access.

6. HTTPS Redirect

• If your Web Apps require HTTPS-only, set up an HTTP-to-HTTPS redirect rule on the Application Gateway.

7.Web Application Firewall Rules:

Review the WAF logs to confirm that requests to /graphql are not being blocked. If the rules are too strict, this may cause 403 errors.

Typical Mistakes to Avoid:

Missing SSL binding on the listener.
Custom domain not using SNI.
DNS changes not fully propagated yet.

For more information refer the below links:

Tutorial: Create an application gateway with URL path-based routing rules using Azure portal | Microsoft Learn

Troubleshoot backend health issues in Azure Application Gateway | Microsoft Learn

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

Please do not forget to "Accept the answer” and “up-vote it” wherever the information provided helps you, this can be beneficial to other community members__.__ It would be greatly appreciated and helpful to others.

Share via

We are experiencing an issue with our Azure Application Gateway setup and need your assistance. Below are the details:

1 answer

Your answer