Azure Front Door: diagnose an origin before changing WAF or routing

When Azure Front Door returns 502, 503 or intermittent failures, the first reaction is often to change the WAF policy, remove an origin from the pool, edit a route or redeploy the backend. Those actions may hide the symptom, but they often mix several layers: edge, health probe, origin, DNS, TLS, Private Link, WAF policy and application behavior.

The use case is a production service exposed through Azure Front Door Standard or Premium, with an origin group pointing to an Azure application or an internal backend. The runbook goal is to decide whether the incident comes from a truly unavailable origin, a misleading health probe, a TLS mismatch, a Private Link path, a WAF block, a routing rule or an application change that should be rolled back.

Freeze the entry contract

Start by naming the expected path. Front Door is a production interface: public hostname, route, origin group, origin, protocol, health probe, WAF policy, logs and rollback. Without that contract, each team reads only its layer and the diagnosis becomes circular.

Exposed service
Public hostname: api.contoso.example
Front Door profile: afd-prod-global
Route: route-api-prod
Origin group: og-api-prod
Origins: app-api-weu, app-api-neu
Protocol to origin: HTTPS 443
Health probe: GET /health/live every 30s
WAF policy: waf-api-prod-prevention
Private path: Private Link enabled or not

Questions before changing anything
Which route served the request?
Is the origin unhealthy or only unreachable by the probe?
Does the certificate presented by the origin match the expected host header?
Is the WAF blocking the request before it reaches the origin?
Does the problem affect one region, one route or one request class?
Is the known rollback a route, an origin, a WAF policy or an application revision?

This prevents the team from treating a 502 as a WAF block or a broken probe as an application outage.

Separate edge, route and origin

First prove that the request reaches the expected Front Door profile and uses the expected route. A routing rule, ruleset, custom domain or priority can send part of the traffic to the wrong origin group.

SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
RG="rg-edge-prod"
PROFILE="afd-prod-global"
ENDPOINT="afd-prod-endpoint"
ROUTE="route-api-prod"

az account set --subscription "$SUBSCRIPTION"

az afd route show --resource-group "$RG" --profile-name "$PROFILE" --endpoint-name "$ENDPOINT" --route-name "$ROUTE" --query "{enabled:enabledState,patterns:patternsToMatch,domains:customDomains,originGroup:originGroup.id,forwardingProtocol:forwardingProtocol,httpsRedirect:httpsRedirect}" --output json

az afd origin-group show --resource-group "$RG" --profile-name "$PROFILE" --origin-group-name "og-api-prod" --query "{probeSettings:healthProbeSettings,loadBalancing:loadBalancingSettings,sessionAffinity:sessionAffinityState}" --output json

If the route is disabled, the pattern does not match, or the ruleset rewrites the path before the origin, do not touch the WAF yet. The failure still belongs to routing.

Read health probes as a signal, not as truth

An unhealthy origin does not automatically mean the application is unavailable to users. The probe may target an endpoint that is too deep, require authentication, depend on a database, fail on a host header mismatch or traverse a different network path than real requests.

Qualify the health probe
Probe endpoint: /health/live or /health/ready
Method: GET or HEAD
Expected code: 200 to 399 depending on the contract
Host header expected by the origin
Certificate presented by the origin
Dependencies included in the probe
Behavior by region and by origin

Block changes when
The probe tests a non-critical dependency
The probe requires authentication
The host header does not match the certificate
One origin is unhealthy but load balancing still works
The application is healthy directly but not through Front Door

The right fix may be to simplify the probe, correct the host header or remove one origin from the pool. It is not necessarily an application change.

Check TLS and host header before the backend

Front Door can connect to the origin over HTTPS with a specific host header. Certificate rotation, an internal domain change, a slot swap or an App Service configuration update can break that relationship without making the application itself unavailable.

ORIGIN_HOST="app-api-prod.azurewebsites.net"
EXPECTED_HOST="api.internal.contoso.example"

openssl s_client -connect "$ORIGIN_HOST:443" -servername "$EXPECTED_HOST" -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

curl -I --resolve "$EXPECTED_HOST:443:10.20.30.40" "https://$EXPECTED_HOST/health/live"

In a private environment, run the test from an allowed network point. The important part is to prove SNI, certificate and host header before blaming the WAF or the code.

Qualify Private Link, DNS and private origin state

With Front Door Premium and Private Link, an origin can be healthy at the application layer but unreachable from the edge if Private Link approval, DNS, target resource or internal routing drifted. Private Link carries the private path to the origin; it does not explain every failure by itself.

RG="rg-edge-prod"
PROFILE="afd-prod-global"
ORIGIN_GROUP="og-api-prod"
ORIGIN="app-api-weu"

az afd origin show --resource-group "$RG" --profile-name "$PROFILE" --origin-group-name "$ORIGIN_GROUP" --origin-name "$ORIGIN" --query "{enabled:enabledState,hostName:hostName,originHostHeader:originHostHeader,httpPort:httpPort,httpsPort:httpsPort,priority:priority,weight:weight,privateLink:sharedPrivateLinkResource}" --output json

az network private-endpoint-connection list --id "/subscriptions/$SUBSCRIPTION/resourceGroups/rg-app-prod/providers/Microsoft.Web/sites/app-api-prod" --query "[].{name:name,status:privateLinkServiceConnectionState.status,description:privateLinkServiceConnectionState.description}" --output table

A pending, rejected or recently recreated Private Link connection can explain an edge-to-origin incident. If Private Link is healthy, continue with WAF, route and application evidence.

Look for WAF evidence in KQL

Do not disable the WAF just to see whether the request passes. First search for blocks that match the hostname, route, URI, client and incident window. An explicit 403 and an origin 502 do not call for the same action.

let StartTime = datetime(2026-07-06T07:00:00Z);
let EndTime = datetime(2026-07-06T08:00:00Z);
let Hostname = "api.contoso.example";
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProvider == "MICROSOFT.CDN"
| where host_s == Hostname or requestUri_s has Hostname
| project TimeGenerated,
        Category,
        trackingReference_s,
        httpStatusCode_d,
        clientIp_s,
        requestUri_s,
        ruleName_s,
        action_s,
        details_msg_s,
        backendHostname_s,
        originName_s
| order by TimeGenerated desc

If the logs show a WAF rule blocking a precise URI, prepare a targeted WAF change. If the dominant signal is 502 or 503 with a named origin, stay on origin group, TLS, probe or application diagnosis.

Correlate with the application revision

Front Door can reveal a backend regression without being the cause. Compare the incident with deployments, slot swaps, configuration changes, certificate rotations and infrastructure edits.

let StartTime = datetime(2026-07-06T06:30:00Z);
let EndTime = datetime(2026-07-06T08:30:00Z);
AppRequests
| where TimeGenerated between (StartTime .. EndTime)
| summarize Requests=count(), Failures=countif(Success == false), P95=percentile(DurationMs, 95) by bin(TimeGenerated, 5m), AppRoleName, ResultCode
| order by TimeGenerated asc

If the application sees no requests while Front Door returns 502, the problem is before the runtime. If the application receives requests and fails with 5xx, rollback probably belongs to the revision, configuration or dependency layer.

Decide: route, origin, WAF or application rollback

Make the decision explicit and reversible. The worst outcome is a pile of untracked fixes: disabling WAF, relaxing a probe, adding an origin and redeploying the application during the same incident.

Change the route
The hostname or pattern does not match the contract
The ruleset rewrites to the wrong path
The change can be reverted to the previous route

Remove or disable an origin
One origin is unhealthy and the others are healthy
Impact is regional or tied to one revision
Weight and priority allow controlled removal

Change the WAF policy
Logs prove a targeted WAF block
The legitimate request is identified
The exclusion or custom rule is minimal and rollbackable

Rollback the application
The origin receives the requests and produces the errors
The regression aligns with a revision or configuration change
Probes and Front Door match the contract

Every decision should cite the evidence used: tracking reference, origin name, probe status, certificate, WAF logs, application logs and recent change.

Validate after correction

Validate the complete path, not only the HTTP status of a manual request. The fix must prove that Front Door routes correctly, the origin responds, the WAF still protects traffic and metrics return to normal.

validation:
edge:
  - public_hostname_resolves
  - expected_route_enabled
  - tracking_reference_captured
origin:
  - origin_group_healthy
  - health_probe_stable_across_two_windows
  - certificate_and_host_header_valid
security:
  - waf_policy_still_enabled
  - no_broad_exclusion_added_without_evidence
application:
  - requests_visible_in_backend_logs
  - 5xx_rate_back_to_expected_level
  - synthetic_probe_ok_from_relevant_regions
rollback:
  - change_documented
  - rollback_tested_or_immediately_available

Keep validation across several probe windows. An origin can recover for a few seconds and fail again if the issue is tied to load, certificate handling, warm-up or a dependency.

Conclusion

An Azure Front Door incident should be handled as a delivery chain, not as a standalone error page. The useful question is not “should we disable the WAF?” but “where did the edge-to-origin contract break?”.

By separating route, origin group, probes, TLS, Private Link, WAF and application logs, the team can choose a bounded action: fix routing, remove one origin, adjust a probe, prepare a targeted WAF rule or roll back the application revision. That bounded, validated and reversible decision is what makes Front Door operable instead of opaque in front of production.