Fix Azure Front Door: Setup Errors, Routing & WAF Issues
Why Azure Front Door Is Giving You Trouble
I've seen this exact frustration play out dozens of times: you spin up an Azure Front Door profile, wire up your origins, configure a custom domain , and then traffic either doesn't reach your backend at all, or it arrives with the wrong headers, or your WAF starts blocking requests you never intended to block. The portal shows green health checks, but your users are hitting 502 errors or getting redirected into an infinite loop. Nothing in the error message tells you what actually went wrong.
The root of most Azure Front Door problems isn't a single misconfiguration , it's the gap between what the product's tiers actually do and what people assume they do. Azure Front Door comes in four distinct flavors: Front Door Standard, Front Door Premium, Front Door (classic), and CDN Standard from Microsoft (classic). Each tier has a different feature set, and the two classic tiers are actively being retired. If you're on classic and wondering why certain WAF rules or health probe logs aren't available, that's your answer, those features simply don't exist in the classic tier.
The retirement timeline matters here. Front Door (classic) stops accepting new resource creation as of March 31, 2025, and fully retires March 31, 2027. CDN Standard from Microsoft (classic) had its new-resource cutoff on August 15, 2025, and retires September 30, 2027. On top of that, as of August 15, 2025, Azure-managed certificates are no longer issued for either classic tier, if you haven't migrated and you're relying on a managed cert, that cert stays valid only until April 14, 2026. After that, your HTTPS traffic breaks unless you bring your own certificate or migrate to Standard or Premium.
Beyond the tier confusion, the most common Azure Front Door setup issues I see fall into five buckets: origin health probe failures (your backend is up but Front Door doesn't think so), TLS certificate problems with custom domains, routing rules that silently drop or misroute traffic, WAF policies that are either too aggressive or misconfigured for your traffic patterns, and caching behavior that doesn't match what you configured. We'll walk through all of them.
The Quick Fix, Try This First
Before diving into deep troubleshooting, this one check resolves probably 40% of Azure Front Door issues I see in the field: verify your origin group health probe configuration and confirm your WAF policy is in Detection mode, not Prevention mode.
Go to the Azure portal, open your Front Door profile, and navigate to Origin groups in the left sidebar. Click your origin group, then scroll to Health probes. Check three things:
- The probe path must return HTTP 200 from your origin. If your app returns 301 or 404 on
/, Front Door marks the origin unhealthy and stops sending traffic. Change the probe path to a dedicated health endpoint like/healthor/pingthat always returns 200. - The probe protocol must match what your origin actually accepts. If your backend only listens on HTTPS but you probe over HTTP, the probe fails silently.
- The probe interval should be 30 seconds for production. Setting it too high means Front Door takes too long to detect recovery; too low and you're hammering a struggling origin.
Next, navigate to Security > WAF policies. If you recently attached a WAF policy and traffic started dropping, open that policy and check the Policy mode in the Overview blade. If it says Prevention, switch it temporarily to Detection and watch whether your traffic resumes. In Detection mode, the WAF logs rule matches without blocking them, this lets you identify which rule is triggering before you commit to blocking behavior.
If either of those fixes your issue, great. If not, read on, because we're going deeper.
A failing origin health probe is quiet and devastating. Azure Front Door will stop routing traffic to your backend without showing a visible error to users, they just get a 503 or 421. The first thing you need is the raw health probe data.
In Standard and Premium tiers, you have access to health probe logs. In the Azure portal, open your Front Door profile and go to Monitoring > Diagnostic settings. Add a diagnostic setting and check FrontdoorHealthProbeLog, then route it to a Log Analytics workspace. Give it about 5 minutes to populate, then run this query in Log Analytics:
AzureDiagnostics
| where ResourceType == "FRONTDOORS"
| where Category == "FrontdoorHealthProbeLog"
| where httpStatusCode_d != 200
| project TimeGenerated, originName_s, httpStatusCode_d, probeURL_s, result_s
| order by TimeGenerated descThis shows you every failed probe with the exact HTTP status code your origin returned. If you see 404s, your probe path doesn't exist on the origin server. If you see 000 or connection timeouts, your origin's firewall or network security group is blocking the probe source IPs. Azure Front Door's health probes originate from multiple Microsoft edge nodes worldwide, your origin must accept inbound traffic from the AzureFrontDoor.Backend service tag in your Network Security Group rules.
In the Azure portal, open your origin server's NSG, go to Inbound security rules, and add a rule allowing TCP 80 and 443 from the AzureFrontDoor.Backend service tag. Once the probes start returning 200, Front Door will mark the origin healthy again within two probe intervals (typically 60 seconds at default settings).
I know this is frustrating, especially when your site was working fine and then the certificate just stopped renewing. Here's the situation: if you're on Front Door (classic) or CDN Standard from Microsoft (classic), Azure-managed certificate issuance was cut off on August 15, 2025. Any existing managed certificate stays valid until April 14, 2026, after that date, your HTTPS traffic will break with a certificate error unless you act now.
Your options are: migrate to Front Door Standard or Premium, or bring your own certificate. For the bring-your-own-certificate path on any tier, the process is:
- Upload your certificate to Azure Key Vault as a certificate object (not a secret). Your Front Door profile needs a managed identity with Key Vault Certificate User role on that vault.
- In the Azure portal, go to your Front Door profile > Domains, select your custom domain, and under Certificate type choose Bring your own certificate.
- Select your Key Vault, the certificate, and the specific version (or leave it as "Latest" to auto-rotate on renewal).
For TLS version requirements: all four Azure Front Door tiers support TLS 1.2 and TLS 1.3. If you have clients running TLS 1.0 or 1.1, they will be rejected, this is by design and not a bug. Front Door's minimum TLS version is configurable at the domain level. In your domain settings, look for Minimum TLS version and confirm it's set to TLS 1.2. You cannot lower it below 1.2.
If your custom domain CNAME validation is stuck in "Pending" state, the fix is to ensure the CNAME record at your DNS provider points to your Front Door endpoint hostname (the *.azurefd.net address), not to your origin directly. Front Door validates domain ownership by checking that the CNAME resolves correctly before it will serve traffic or provision a certificate for that domain.
Routing problems in Azure Front Door almost always come down to one of three things: route matching order, missing URL redirect/rewrite rules, or a mismatch between accepted protocols at the route level and what your origin expects.
All four tiers support path-based routing, URL redirect and rewrite, and IPv4/IPv6 dual stack. But server variables and regular expressions in the rules engine are only available in Standard and Premium, not in classic. If you're on classic and trying to write a regex-based routing rule, the portal will appear to accept it but it will not evaluate correctly. That's a migration blocker worth knowing about.
To diagnose a routing issue, go to your Front Door profile > Routes. Open the specific route and review:
- Accepted protocols: If your route accepts only HTTPS but a user hits HTTP, Front Door will redirect to HTTPS only if you have a redirect rule configured. Without it, HTTP traffic returns a 421 or gets dropped.
- Patterns to match: The path pattern
/*is a wildcard catch-all. If you have a more specific route like/api/*and a general/*route, make sure your specific route is evaluated first. Front Door evaluates routes in the order listed in the portal. - Forwarding protocol: If you set this to "HTTPS only" but your origin is on HTTP, every request will fail at the origin connection. Set it to "Match incoming request" or explicitly set it to the protocol your origin accepts.
For HTTP-to-HTTPS redirects specifically, you need a dedicated redirect route. Create a route that matches HTTP on your domain with pattern /*, then in the Route type drop-down choose Redirect, set the redirect type to 301 (Permanent), and set the destination protocol to HTTPS. Place this route above your main forwarding route. When you see users stuck in redirect loops, the usual cause is that your origin is also redirecting back to itself, temporarily disable any server-side HTTP-to-HTTPS redirect on your origin while Front Door handles it.
The WAF is one of the most powerful features in Azure Front Door, and one of the most common sources of support tickets. Custom WAF rules are available on Standard, Premium, and classic tiers. The Microsoft-managed rule set (which gives you pre-built protection against OWASP Top 10 and similar threats) is available on Standard and Premium; classic gets only the default rule set 1.1 or earlier. Bot protection is available on Standard and Premium, while classic is limited to bot manager rule set 1.0.
When your Azure Front Door WAF is blocking legitimate traffic, the fastest way to identify the culprit rule is through Log Analytics. Query the WAF log:
AzureDiagnostics
| where ResourceType == "FRONTDOORS"
| where Category == "FrontdoorWebApplicationFirewallLog"
| where action_s == "Block"
| project TimeGenerated, clientIP_s, requestUri_s, ruleName_s, action_s, details_message_s
| order by TimeGenerated desc
| take 50The ruleName_s field tells you exactly which rule fired. If it's a managed rule like Microsoft_DefaultRuleSet-2.1/REQUEST-942-APPLICATION-ATTACK-SQLI/942440, you can create a custom exclusion for that rule on specific request elements. In the WAF policy, go to Managed rules > Exclusions and scope the exclusion to the specific rule ID, the request attribute (query string, request body, cookie name), and the match variable, never create broad exclusions that bypass entire rule groups, as that defeats the protection.
For geo-filtering, which all four tiers support, go to your WAF policy > Custom rules and add a rule with match condition RemoteAddress, operator GeoMatch, and the country codes you want to block. Set the action to Block and give it a priority lower than your allow rules (lower number = higher priority in Azure WAF). If you need to allow a specific IP from a blocked country, put an IP-based Allow rule at a higher priority (e.g., priority 10) and the geo-block at lower priority (e.g., priority 100).
Caching issues in Azure Front Door usually show up as one of two symptoms: content that should be cached isn't being cached (your origin is getting hammered), or cached content is stale and users are seeing old versions of your site. All four tiers support query string caching, cache management including purge and rules, and gzip/Brotli compression. Cache behavior is controlled through the standard rules engine on all tiers.
Start with a cache purge to rule out stale content as the cause. In the Azure portal, go to your Front Door profile > Caching > Purge cache. You can purge by domain and path. To purge everything, use the wildcard path /*. After purging, wait 30 seconds and test again. If the problem resolves, the issue was stale cache, you need a better cache invalidation strategy tied to your deployment pipeline.
If caching isn't happening at all, check your origin's response headers. Azure Front Door respects Cache-Control: no-store and Cache-Control: private headers from your origin, if your origin sends these, Front Door will not cache the response regardless of your rules. Check what headers your origin actually sends by using curl:
curl -I https://your-origin.azurewebsites.net/your-pathIf you see Cache-Control: no-cache or no-store coming from your origin and you want Front Door to cache anyway, you need a cache override rule in the rules engine. In your Front Door profile, go to Rules engine, create a new rule, and add an action to Modify response header, set Cache-Control to max-age=3600 (or your desired TTL). This overrides what the origin sends before the caching decision is made.
For compression, all tiers support gzip and Brotli, but compression only activates when the response is larger than 1 KB and the client sends an Accept-Encoding header. Compression MIME types are configurable on all tiers. If Brotli isn't being served to clients that support it, verify the client is sending Accept-Encoding: br in the request and that your origin's response Content-Type is in the list of compressible MIME types for your Front Door configuration.
Advanced Troubleshooting for Azure Front Door
If the steps above didn't solve your problem, you're likely dealing with something more nuanced. Let's go deeper.
Event Viewer and Diagnostic Logs for Azure Front Door
Azure Front Door doesn't expose Windows Event Viewer logs (it's a cloud PaaS service), but it does have rich diagnostic logging in Azure Monitor. Beyond the WAF and health probe logs mentioned earlier, enable the FrontdoorAccessLog in your diagnostic settings. This gives you every request that transits your Front Door endpoint with fields including httpStatusCode, originUrl, cacheStatus, timeTaken, and securityProtocol. Use this query to find all 5xx errors from your origin:
AzureDiagnostics
| where ResourceType == "FRONTDOORS"
| where Category == "FrontdoorAccessLog"
| where httpStatusCode_d >= 500
| project TimeGenerated, requestUri_s, originUrl_s, httpStatusCode_d,
originLatency_d, cacheStatus_s, securityProtocol_s
| order by TimeGenerated descThe cacheStatus_s field tells you whether the response was a cache hit, miss, or bypass, which helps you understand whether traffic is actually reaching your origin or being served from edge cache.
Private Link Origins (Premium Only)
If you're on Front Door Premium and trying to connect to a private origin via Azure Private Link, and traffic isn't reaching your backend, the most common issue is that the Private Link connection is in "Pending" state. Go to your origin server's resource (App Service, Storage Account, etc.) > Networking > Private endpoint connections and look for the pending approval request from Front Door. You must manually approve this connection, it doesn't auto-approve. This is by design: the private endpoint approval is an explicit security control that requires an operator action on the origin side.
Managed Identities for Origin Authentication
In Standard and Premium (currently in Preview), you can configure managed identities for origin authentication, this allows Front Door to authenticate to your origin using an Azure AD token rather than a shared secret or API key. If you're testing this Preview feature and it's not working, verify that the system-assigned or user-assigned managed identity on your Front Door profile has been granted the correct role on the origin resource. The specific role depends on the origin type (e.g., Storage Blob Data Reader for blob storage origins).
Domain Fronting Behavior
All four tiers include domain fronting protection by default. This means Front Door will block requests where the SNI hostname in the TLS handshake doesn't match the Host header in the HTTP request. If you're seeing mysterious 421 errors on connections that look legitimate, this is often the cause, especially if you have a proxy or CDN in front of Front Door that is rewriting headers. Ensure your upstream systems pass the correct Host header through to Front Door.
Rules Engine Debugging
The Standard and Premium rules engine supports server variables and regular expressions, which the classic tier does not. If you're migrating a classic configuration and your rules suddenly stop working, this is likely why. Server variables like {http_req_referer}, {http_req_x-forwarded-for}, and {socket_ip} are only evaluated in Standard/Premium. To test a rules engine configuration, use the Test rules engine option under the rules engine blade, it lets you simulate a request and see which rules match and what actions would be applied, without actually routing live traffic through them.
Escalate to Microsoft Support if you're seeing consistent 5xx errors that the access logs show as originating from Front Door itself (not your origin), specifically if originUrl_s is empty or null in the access log for failed requests, which indicates the failure is happening at the Azure network edge before your origin is even contacted. Also escalate if your Private Link connection approval is stuck or if your managed certificate fails to provision on the Standard/Premium tier despite all CNAME validation passing correctly. These are platform-level issues that require Microsoft's internal tooling to diagnose.
Prevention & Best Practices for Azure Front Door
The best Azure Front Door troubleshooting session is the one you never have to have. Based on what I've seen go wrong repeatedly in production environments, here are the configurations that keep things running smoothly.
Plan Your Tier Migration Now, Not Later
If you're still on Front Door (classic) or CDN Standard from Microsoft (classic), migration isn't optional, it's a matter of when, not if. The classic tiers stop accepting new resources and are heading toward full retirement. More importantly, Azure-managed certificates stopped being issued on August 15, 2025, and existing certs expire April 14, 2026. If you haven't started your migration evaluation, start today. Microsoft provides step-by-step migration guidance and a Migration Considerations doc for both paths. The Standard tier is appropriate for most workloads; Premium is necessary if you need Private Link origins, Microsoft-managed WAF rule sets beyond the defaults, or advanced analytics with built-in reports.
Use Azure Policy to Enforce Front Door Standards
Standard, Premium, and Front Door (classic) all support Azure Policy integration. Use this to enforce minimum TLS version, require WAF policies on all Front Door profiles, and flag any Front Door resource that doesn't have diagnostic logging enabled. This prevents configuration drift across large teams where someone might deploy a new Front Door endpoint without the required security controls attached.
Monitor with Azure Advisor
Standard, Premium, and classic all have Azure Advisor integration. Advisor generates recommendations specifically for your Front Door resources, things like "your origin health probe interval is too high" or "your WAF policy has rules that have never triggered in 30 days." Check Advisor recommendations monthly and act on the high-priority ones. It's a free check that catches real problems before they become incidents.
Build a Dedicated Health Endpoint on Every Origin
Never point your Front Door health probe at /. Build a /healthz or /health endpoint on every origin that performs a shallow check (database connectivity, key service availability) and returns HTTP 200 with a minimal JSON payload. This way, your health probe gives you meaningful signal, if the probe fails, you know the origin is genuinely degraded, not just that someone changed a redirect rule on the homepage.
- Enable diagnostic settings (access log + WAF log + health probe log) on every Front Door profile immediately after creation, retroactive logging is not possible for past events.
- Set your WAF policy to Detection mode during initial rollout, then switch to Prevention only after reviewing a week of matched-but-not-blocked traffic in your logs.
- Add the
AzureFrontDoor.Backendservice tag to your origin's NSG inbound rules on day one, missing this causes inexplicable health probe failures. - Use "Latest" certificate version in Key Vault for bring-your-own-certificate setups so that when you renew your cert, Front Door automatically picks it up without a manual update.
Frequently Asked Questions
Why is Azure Front Door returning a 502 Bad Gateway even though my backend is up?
This usually means Front Door reached your origin but got an unexpected response, or couldn't establish the connection at all. The most common causes are: your origin's NSG or firewall is blocking Front Door probe traffic (add the AzureFrontDoor.Backend service tag to your inbound NSG rules), your origin is returning a TLS error because the certificate is self-signed or expired, or your origin is taking too long to respond and hitting Front Door's origin response timeout. Pull the FrontdoorAccessLog from Azure Monitor and look at the originLatency_d and httpStatusCode_d fields, if latency is near 60,000ms, you're hitting a timeout. If httpStatusCode is blank, the connection itself failed before any HTTP response was received.
My Azure Front Door WAF is blocking API calls that should be allowed, how do I whitelist them?
Don't create IP-based whitelists for API traffic if you can avoid it, IP ranges change. Instead, identify the exact managed rule ID that's triggering the block using the WAF log query above (look for ruleName_s in FrontdoorWebApplicationFirewallLog). Then, in your WAF policy under Managed rules > Exclusions, create a scoped exclusion for that rule ID tied to the specific request attribute causing the match, for example, excluding rule 942440 for a specific request body field name. This is far safer than disabling the entire rule or creating a broad Allow rule that bypasses the WAF for those requests entirely.
I'm on Front Door classic, do I really need to migrate, and what does it break if I don't?
Yes, migration is non-negotiable. Front Door (classic) stops accepting new resources since March 31, 2025 and fully retires March 31, 2027, after that date, existing resources stop functioning. More urgently, Azure-managed certificates were cut off on August 15, 2025, and any existing managed certs expire April 14, 2026. If you miss that certificate expiry without migrating or bringing your own cert, your HTTPS endpoints go dark. Microsoft provides step-by-step migration instructions in the Azure update documentation, and the migration to Standard or Premium preserves your routing and WAF configurations in most cases.
Does Azure Front Door work with HTTP/2 and what TLS versions does it support?
Yes, all four tiers of Azure Front Door support HTTP/2 for client-to-edge connections. For TLS, all tiers support TLS 1.2 and TLS 1.3; nothing below TLS 1.2 is accepted. You can configure the minimum TLS version per custom domain in the Azure portal under your domain's settings. If you have legacy clients that only support TLS 1.1 or below, they will not be able to connect to Azure Front Door, there is no way to enable TLS 1.0 or 1.1, and this is intentional for security compliance reasons.
Why isn't Azure Front Door caching my responses even though I configured caching rules?
Front Door honors origin-sent cache control headers by default, so if your origin sends Cache-Control: no-store, no-cache, or private, Front Door will not cache, regardless of your rules configuration. Use the FrontdoorAccessLog to check the cacheStatus_s field for your requests: "CONFIG_NOCACHE" means a rule explicitly bypassed caching, "BYPASS" means an origin header prevented caching, and "MISS" means it should be caching but the object wasn't in cache yet. To override origin cache headers, use a rules engine action to modify the response's Cache-Control header before the caching decision is evaluated.
What's the difference between Azure Front Door Standard and Premium, which one do I need?
Standard is right for most web applications: you get full WAF with custom rules, Microsoft-managed rule sets, bot protection, HTTP/2, gzip and Brotli compression, advanced analytics, regular expressions in the rules engine, and Azure Policy and Advisor integration. Premium adds three things Standard doesn't have: Private Link connections to origins (so your backends never need a public IP), the full advanced WAF analytics report including WAF-specific dashboards, and managed identities for origin authentication (currently in Preview). If your origin needs to stay fully private and off the public internet, you need Premium. Otherwise, Standard covers everything.