Troubleshoot routing, redirect, and hostname issues in Azure Application Gateway

Summary

This article provides a step-by-step guide to diagnose and resolve routing, redirect, and hostname issues in Azure Application Gateway.

Routing, redirect, and hostname problems in Application Gateway typically have the following root causes:

• Path-based routing rules that lack a path entry for the requested URL and return "404" errors.
• Redirect loops that are caused by an HTTP-to-HTTPS redirect configuration that conflicts with a backend that also redirects.
• Rewrite rules that corrupt the Host header by appending a port number.
• Listener priority ordering that causes a lower-specificity listener to match before the intended listener.

Symptoms

You might encounter one or more of the following symptoms:

• HTTP 404 Not Found errors are returned by Application Gateway for an URL path that exists on the backend.
• Your browser shows ERR_TOO_MANY_REDIRECTS or the equivalent redirect loop error.
• Browser developer tools (such as the Network tab) show a repeating chain of 301and 302 redirects between HTTP and HTTPS.
• Back-end applications receive an incorrect Host header that have an unexpected appended port number (for example, contoso.com:443 instead of contoso.com).
• Back-end applications return the wrong content or an error because they receive a hostname that they don't recognize.
• Requests route to an unexpected back-end pool (the wrong site's served).
• Application Gateway returns 404 errors for some URL paths but 200 for others, despite all paths being valid on the backend.
• After you configure an HTTP-to-HTTPS redirect, the application becomes unreachable or loops indefinitely.
• A multi-site Application Gateway serves the wrong site's content for a specific hostname.

Prerequisites

• Permissions required: Network Contributor role on the Application Gateway resource group, or equivalent (Microsoft.Network/applicationGateways/read and write)
• Tools: Azure CLI 2.x, or an AI agent with Azure MCP access
• Required variables and examples of those variables, as shown in the following table

TIP: Each script that's provided in the following sections prompts you for the required values interactively. To open Cloud Shell and answer the prompts, select Try It. The values are cached for that session. Therefore, you enter them only one time. $FAILING_HOSTNAME and $FAILING_URL_PATH are derived from $FAILING_URL automatically. If the Log Analytics workspace ID is unknown, it can be discovered in Step 1b.

Diagnostic steps

Step 1a

Check which listener receives the client request, which routing rule processes it, and which back-end pool (or redirect) is the target. This check establishes the end-to-end request path for the failing URL.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway rule list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway http-listener list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json

Interpret the results

Map the $FAILING_URL to a listener by matching the hostname and port, and then follow the routing rule to the back-end pool or redirect configuration.

Step 1b

Check which Log Analytics workspace receives Application Gateway access logs.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az monitor diagnostic-settings list \
  --resource "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG/providers/Microsoft.Network/applicationGateways/$RESOURCE_NAME" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, workspaceId:workspaceId, logs:logs[?category=='ApplicationGatewayAccessLog'].enabled}" \
  --output json

Interpret the results

Enable Application Gateway access logging

If ApplicationGatewayAccessLog isn't enabled, turn it on before continuing. This action creates or updates a diagnostic setting that streams access logs to a Log Analytics workspace. It doesn't change how traffic is handled.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$WORKSPACE_RESOURCE_ID" ] && read -rp "Log Analytics workspace resource ID: " WORKSPACE_RESOURCE_ID

az monitor diagnostic-settings create \
  --name "appgw-access-logs" \
  --resource "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG/providers/Microsoft.Network/applicationGateways/$RESOURCE_NAME" \
  --subscription "$SUBSCRIPTION" \
  --workspace "$WORKSPACE_RESOURCE_ID" \
  --logs '[{"category":"ApplicationGatewayAccessLog","enabled":true}]'

Wait 5–10 minutes for logs to begin flowing, and then rerun the prior diagnostic-settings list command to verify ApplicationGatewayAccessLog is true.

Step 2a

Check whether the URL path map includes a rule for the path in $FAILING_URL. A missing path rule causes Application Gateway to route the request to the default back-end pool, which might return 404 errors if it isn't configured or points to the wrong application.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway url-path-map list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json

Interpret the results

Extract the URL path from $FAILING_URL (for example, /api/orders) and compare it against every paths entry in the path rules.

Step 2b

Check whether listener priorities cause a less-specific listener (for example, wildcard *.contoso.com) to match before a more specific one (for example, app.contoso.com), routing the request to the wrong back-end pool and rule.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "requestRoutingRules[].{name:name, priority:priority, ruleType:ruleType, listener:httpListener.id, backend:backendAddressPool.id, redirect:redirectConfiguration.id}" \
  --output json

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "httpListeners[].{name:name, hostName:hostName, hostNames:hostNames, protocol:protocol, port:frontendPort.id}" \
  --output json

Interpret the results

Sort rules by priority (a lower number equals a higher priority, which is evaluated first). Map each rule to its listener hostname.

Step 3

Check whether rewrite rule sets associated with the routing rule modify the Host header, inject redirect responses, or create conflicts with existing redirect configurations that cause loops.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway rewrite-rule set list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway redirect-config list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json

Interpret the results

The rewrite-rule set list command returns each rewrite rule as a set, and each set carries its rewriteRules[].actionSet.requestHeaderConfigurations. The Host header rows in the following table are inspected. To see the individual rules inside one set, rerun the step by using az network application-gateway rewrite-rule list --gateway-name "$RESOURCE_NAME" --resource-group "$RG" --subscription "$SUBSCRIPTION" --rule-set-name <set-name>.

Review each rewrite rule set for:

• Host header modifications that rewrite that set or modify Host in the request.
• URL rewrites that conflict with redirect configurations.
• Redirect configurations that can conflict with back-end behavior.

Step 4

Check whether the HTTP settings override the Host header that's sent to the backend, and what the back-end pool target fully qualified domain name (FQDN) actually is. If you enable pickHostNameFromBackendAddress, the backend receives the FQDN of the back-end target instead of the original client Host header. If you set hostName, the backend receives that static value. If you don't set either value, the original client Host header is passed through unchanged. A misconfiguration in this step can cause the backend to receive a hostname it doesn't recognize. This situation is especially true if you pass the original client Host to a multitenant platform as a service (PaaS) backend (such as Azure App Service, Azure Functions, and Azure API Management) that answers to only its own FQDN.

Run the following commands in Azure CLI:

The first command lists the HTTP settings (the Host header override behavior). The second command lists the back-end pool targets so that you can determine whether the backend is a multitenant PaaS service that requires its own FQDN. Both are read-only.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway http-settings list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, port:port, protocol:protocol, hostName:hostName, pickHostNameFromBackendAddress:pickHostNameFromBackendAddress, affinityCookieName:affinityCookieName, cookieBasedAffinity:cookieBasedAffinity}" \
  --output json

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway address-pool list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, backendAddresses:backendAddresses[].{fqdn:fqdn, ipAddress:ipAddress}}" \
  --output json

Classify the back-end target

From the second command, examine the fqdn of the back-end pool that serves $FAILING_URL (the pool that you identified in Step 1a). A backend is a multitenant PaaS service that requires its own FQDN in the Host header if the target fqdn ends in one of the following values:

• *.azurewebsites.net — App Service or Azure Functions.
• *.azurewebsites.windows.net — App Service (internal or regional form).
• *.azure-api.net — API Management.
• Any other PaaS backend that only answers to its own hostname (it rejects or returns a default page for any other Host header).

If the target is a plain VM or Virtual Machine Scale Sets IP address, an on-premises FQDN, or any host that's configured to answer for the client's hostname, it isn't a multitenant PaaS backend.

Interpret the results

Read the HTTP settings (first command) together with the prior backend target classification.

Step 5

Check the actual routing decisions that Application Gateway made for recent requests, such as which listener handled the request, which backend received it, and what HTTP status code was returned.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
# Derive the hostname and path from the failing URL (override by setting them first)
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"
FAILING_URL_PATH="${FAILING_URL_PATH:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://[^/]+##; s#\?.*##')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' | where requestUri_s contains '$FAILING_URL_PATH' or originalHost_s contains '$FAILING_HOSTNAME' | project TimeGenerated, httpStatus_d, requestUri_s, originalHost_s, host_s, serverRouted_s, listenerName_s, ruleName_s, httpMethod_s | order by TimeGenerated desc | take 50" \
  --timespan PT4H \
  --output json

Interpret the results

Before you use the following table, when httpStatus_d = 404 is populated with serverRouted_s, explicitly compare the Host header that was sent to the backend (host_s) against the backend's required FQDN (serverRouted_s. That value is the back-end pool target that you also saw in Step 4).

• The backend rejects the request because of the Host header if host_s isn't equivalent to the backend's required FQDN, and the backend is a multitenant PaaS service that requires its own FQDN (the PaaS classification from Step 4, such as *.azurewebsites.net, *.azurewebsites.windows.net, *.azure-api.net, or any backend that answers to only its own hostname). This condition is addressed in Resolution E, even though the back-end pool target is correct.
• The target is a pool or listener misconfiguration only if the back-end pool target (serverRouted_s) is, itself, the wrong application (a pool that points somewhere that the request shouldn't go). (Resolution A or Resolution D).

Evaluate the rows in order. The first matching row takes precedence.

Decision map

Use the following decision map table to determine the appropriate next steps based on your diagnostic results.

Resolution A

The URL path map doesn't include a path rule for the requested URL, so the request passes through to the default back-end pool. This default back-end pool might be empty, point to the wrong application, or return 404 error codes because it doesn't serve that path.

Common scenarios include:

• A new API endpoint (/api/v2/orders) was deployed, but the Application Gateway path map only has a /api/v1/* value.
• Path rules use exact paths (/api/orders), but clients request subpaths (/api/orders/123).
• Path rules were configured by using a different case (/API/Orders versus /api/orders).

Run the following commands in Azure CLI (as applicable):

1. Record the existing path rules and the default back-end pool for unmatched paths.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:   " RESOURCE_NAME
[ -z "$URL_PATH_MAP_NAME" ] && read -rp "URL Path Map Name:  " URL_PATH_MAP_NAME

az network application-gateway url-path-map show \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$URL_PATH_MAP_NAME" \
  --output json

2. Record:

• All existing paths entries and their associated back-end pools.
• The defaultBackendAddressPool where unmatched paths route.
• The $URL_PATH_MAP_NAME for use in the next step.

3. Add a new path rule for the missing path.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:      " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:       " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:     " RESOURCE_NAME
[ -z "$URL_PATH_MAP_NAME" ] && read -rp "URL Path Map Name:    " URL_PATH_MAP_NAME
[ -z "$NEW_RULE_NAME" ] && read -rp "New Path Rule Name:   " NEW_RULE_NAME
[ -z "$MISSING_PATH" ] && read -rp "Missing Path (e.g. /api/orders): " MISSING_PATH
[ -z "$TARGET_BACKEND_POOL" ] && read -rp "Target back-end pool:  " TARGET_BACKEND_POOL
[ -z "$TARGET_HTTP_SETTINGS" ] && read -rp "Target HTTP Settings: " TARGET_HTTP_SETTINGS

az network application-gateway url-path-map rule create \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --path-map-name "$URL_PATH_MAP_NAME" \
  --name "$NEW_RULE_NAME" \
  --paths "$MISSING_PATH" "$MISSING_PATH/*" \
  --address-pool "$TARGET_BACKEND_POOL" \
  --http-settings "$TARGET_HTTP_SETTINGS"

4. Rerun Step 2a to verify the new path rule appears. Then request $FAILING_URL. It should now return the expected response instead of 404 errors.

You can also verify in access logs.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_URL_PATH="${FAILING_URL_PATH:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://[^/]+##; s#\?.*##')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and requestUri_s contains '$FAILING_URL_PATH' | project TimeGenerated, httpStatus_d, serverRouted_s, ruleName_s | order by TimeGenerated desc | take 10" \
  --timespan PT1H \
  --output json

If the issue persists, go to Resolution D (listener priority) or check the backend application directly.

Resolution B

A redirect loop occurs when Application Gateway has an HTTP-to-HTTPS redirect configuration and the backend application also sends a redirect response (typically back to HTTP, or to a different URL that Application Gateway reintercepts). The result is an infinite loop: the HTTP-to-HTTPS (Application Gateway) backend responds with redirects to HTTP-to-HTTP-to-HTTPS (Application Gateway) and so on.

Common scenarios include:

• HTTP listener has a redirect rule to the HTTPS listener, but the backend is also configured to redirect HTTP-to-HTTPS (for example, web.config rewrite rules or HSTS redirect on the backend).
• A rewrite rule modifies the URL scheme to HTTPS while a redirect configuration also upgrades to HTTPS. Both instigate on the same request.
• The backend detects that X-Forwarded-Proto is http and sends a 301 value to the HTTPS URL, which Application Gateway then reintercepts on the HTTP listener.

Run the following commands in Azure CLI (as applicable):

1. Check the access logs for repeating patterns of 301 or 302 value responses that alternate between the HTTP and HTTPS listeners.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and originalHost_s contains '$FAILING_HOSTNAME' and httpStatus_d in (301, 302) | project TimeGenerated, httpStatus_d, requestUri_s, originalHost_s, listenerName_s, serverRouted_s, serverResponseLatency_d | order by TimeGenerated desc | take 20" \
  --timespan PT1H \
  --output json

Look for repeating patterns such as the following:

• Repeating httpStatus_d 301 or 302 value entries whose listenerName_s alternates between the HTTP listener and the HTTPS listener (the loop bounces between the two listeners).
• serverRouted_s populated only on the HTTPS listener (backend also returns a redirect).

2. Check the rewrite rule sets and redirect configurations associated with the routing rule for $FAILING_URL to see if both are trying to upgrade HTTP-to-HTTPS.

There are typically two scenarios. Choose the one that matches.

Option 1: Fix the backend redirect if the backend sends a Location: http://... header

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway rewrite-rule set create \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name XForwardedProtoRewrite

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME

az network application-gateway rewrite-rule create \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --rule-set-name XForwardedProtoRewrite \
  --name SetXForwardedProto \
  --request-headers "X-Forwarded-Proto=https" \
  --sequence 100

Then associate the rewrite rule set with the HTTPS listener's routing rule:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$HTTPS_RULE_NAME" ] && read -rp "HTTPS Routing Rule Name: " HTTPS_RULE_NAME

az network application-gateway rule update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$HTTPS_RULE_NAME" \
  --rewrite-rule-set XForwardedProtoRewrite

Option 2: Remove the duplicate HTTPS upgrade

Identify the conflicting rewrite rule from Step 3, then remove it:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$REWRITE_RULE_SET_NAME" ] && read -rp "Rewrite Rule Set Name:        " REWRITE_RULE_SET_NAME
[ -z "$CONFLICTING_REWRITE_RULE_NAME" ] && read -rp "Conflicting Rewrite Rule Name: " CONFLICTING_REWRITE_RULE_NAME

az network application-gateway rewrite-rule delete \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --rule-set-name "$REWRITE_RULE_SET_NAME" \
  --name "$CONFLICTING_REWRITE_RULE_NAME"

3. Clear the browser cache (redirect responses are often cached) and request $FAILING_URL.

The request should finish without a redirect loop.

Verify this result in access logs:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and originalHost_s contains '$FAILING_HOSTNAME' | project TimeGenerated, httpStatus_d, requestUri_s, listenerName_s, serverRouted_s | order by TimeGenerated desc | take 10" \
  --timespan PT1H \
  --output json

If the issue persists, go to Resolution C or file an Azure support request.

Resolution C

A rewrite rule modifies the Host request header by using a server variable that includes the port number. For example, {http_req_host} resolves to contoso.com:443. The backend application receives Host: contoso.com:443 instead of Host: contoso.com. This difference causes the backend application to return errors, wrong content, or reject the request.

Common scenarios include:

• A rewrite rule sets Host to {http_req_host}. This variable includes the port when the client sends it.
• A rewrite rule hardcodes Host to hostname:port format.
• A backend application (especially IIS or ASP.NET) uses the Host header for URL generation and produces broken links or redirects containing the port.

Run the following commands in Azure CLI (as applicable).

1. Locate the rewrite rule that sets RequestHeader: Host (Step 3).

Record:

• $REWRITE_RULE_SET_NAME, the rewrite rule set name.
• $REWRITE_RULE_NAME, the specific rewrite rule name.
• The current header value expression.

1. Update the rewrite rule to set the Host header to {var_host} instead of {http_req_host}.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$REWRITE_RULE_SET_NAME" ] && read -rp "Rewrite Rule Set Name: " REWRITE_RULE_SET_NAME
[ -z "$REWRITE_RULE_NAME" ] && read -rp "Rewrite Rule Name:     " REWRITE_RULE_NAME

az network application-gateway rewrite-rule update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --rule-set-name "$REWRITE_RULE_SET_NAME" \
  --name "$REWRITE_RULE_NAME" \
  --request-headers "Host={var_host}"

As an alternative, remove the Host header rewrite entirely if the backend should receive the original client Host header.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$REWRITE_RULE_SET_NAME" ] && read -rp "Rewrite Rule Set Name: " REWRITE_RULE_SET_NAME
[ -z "$REWRITE_RULE_NAME" ] && read -rp "Rewrite Rule Name:     " REWRITE_RULE_NAME

az network application-gateway rewrite-rule update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --rule-set-name "$REWRITE_RULE_SET_NAME" \
  --name "$REWRITE_RULE_NAME" \
  --request-headers ""

3. Request $FAILING_URL and then check that the backend receives the correct Host header.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and originalHost_s contains '$FAILING_HOSTNAME' | project TimeGenerated, originalHost_s, host_s, httpStatus_d, serverRouted_s | order by TimeGenerated desc | take 10" \
  --timespan PT1H \
  --output json

If the issue persists, go to Resolution E.

Resolution D

Listener priority values cause Application Gateway to evaluate a less-specific listener (for example, wildcard *.contoso.com or a catch-all that has no hostname) before a more specific listener (for example, app.contoso.com). Therefore, the wrong routing rule handles the request.

Common scenarios include:

• Wildcard listener *.contoso.com has priority 100, but app.contoso.com listener has priority 200. The wildcard matches first.
• A catch-all listener (no hostname) has the highest priority (lowest number) and intercepts all requests.
• After you add a new multi-site listener, the priority is set higher than existing listeners.

Run the following commands in Azure CLI (as applicable).

1. List all rules sorted by priority Step 2b.

Identify:

• The intended listener for $FAILING_HOSTNAME and its current priority.
• Any competing listener that matches the same hostname (wildcard or catch-all) with a higher priority (lower number).

Record:

• $RULE_NAME, the rule that should handle the request.
• $CORRECT_PRIORITY, the new priority value (lower number means higher priority).
• $COMPETING_RULE_NAME, the rule that is incorrectly matching first.
• $COMPETING_NEW_PRIORITY, the new priority for the competing rule (higher number).

2. Update the routing rule priorities.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Routing Rule Name: " RULE_NAME
[ -z "$CORRECT_PRIORITY" ] && read -rp "New Priority:       " CORRECT_PRIORITY

az network application-gateway rule update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME" \
  --priority "$CORRECT_PRIORITY"

If the competing rule also needs a priority adjustment:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:  " RESOURCE_NAME
[ -z "$COMPETING_RULE_NAME" ] && read -rp "Competing Rule Name:  " COMPETING_RULE_NAME
[ -z "$COMPETING_NEW_PRIORITY" ] && read -rp "Competing New Priority: " COMPETING_NEW_PRIORITY

az network application-gateway rule update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$COMPETING_RULE_NAME" \
  --priority "$COMPETING_NEW_PRIORITY"

Priority guidelines

• Exact hostname listeners: priority 100–199.
• Wildcard hostname listeners: priority 200–299.
• Catch-all (no hostname) listeners: priority 300 or greater.
• Leave gaps between priority values (for example, 100, 110, 120) for future additions.

3. Request $FAILING_URL and verify that the correct listener handles it.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and originalHost_s contains '$FAILING_HOSTNAME' | project TimeGenerated, listenerName_s, ruleName_s, httpStatus_d, serverRouted_s | order by TimeGenerated desc | take 10" \
  --timespan PT1H \
  --output json

If the problem persists, file an Azure support request.

Resolution E

The back-end application receives a Host header that it doesn't recognize because the HTTP settings don't override the Host header (passing through the client's original header), or the override is set to the wrong value. This problem commonly occurs when the backend is App Service, Azure Function, or any multitenant PaaS that requires its own FQDN in the Host header.

Common scenarios include:

• Backend is App Service (myapp.azurewebsites.net) but receives Host: contoso.com. App Service doesn't recognize this hostname and returns a default page or error.
• Backend is an IP-based VM but pickHostNameFromBackendAddress sends the raw IP as the Host header.
• Multiple backends behind the same pool need different Host headers.

Run the following commands in Azure CLI (as applicable):

1. Identify the backend type and the correct Host header value for that backend.

2. Update the HTTP settings to send the correct Host header.

Option 1: Pick hostname from back-end address (for App Service backends)

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:   " RESOURCE_NAME
[ -z "$HTTP_SETTINGS_NAME" ] && read -rp "HTTP Settings Name: " HTTP_SETTINGS_NAME

az network application-gateway http-settings update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$HTTP_SETTINGS_NAME" \
  --host-name-from-backend-pool true

Option 2: Set a static hostname

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:          " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:           " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:         " RESOURCE_NAME
[ -z "$HTTP_SETTINGS_NAME" ] && read -rp "HTTP Settings Name:       " HTTP_SETTINGS_NAME
[ -z "$CORRECT_BACKEND_HOSTNAME" ] && read -rp "Correct Backend Hostname: " CORRECT_BACKEND_HOSTNAME

az network application-gateway http-settings update \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$HTTP_SETTINGS_NAME" \
  --host-name "$CORRECT_BACKEND_HOSTNAME"

3. Rerun Step 4 to verify that the HTTP settings now show the correct host header configuration. Request $FAILING_URL and verify that the backend returns the expected response.

Check access logs:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$WORKSPACE_ID" ] && read -rp "Log Analytics Workspace ID: " WORKSPACE_ID
[ -z "$FAILING_URL" ] && read -rp "Failing URL:                " FAILING_URL
FAILING_HOSTNAME="${FAILING_HOSTNAME:-$(printf '%s' "$FAILING_URL" | sed -E 's#^[a-z]+://([^/:]+).*#\1#')}"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and Category == 'ApplicationGatewayAccessLog' and originalHost_s contains '$FAILING_HOSTNAME' | project TimeGenerated, originalHost_s, host_s, httpStatus_d, serverRouted_s | order by TimeGenerated desc | take 10" \
  --timespan PT1H \
  --output json

References

• Application Gateway request routing rules overview
• URL path-based routing overview
• Application Gateway redirect overview
• Rewrite HTTP headers and URL with Application Gateway
• Application Gateway multi-site hosting
• Application Gateway listener configuration
• Troubleshoot Application Gateway with Azure Monitor
• Application Gateway HTTP settings configuration