HTTP/3 is already enabled by default on Azure Front Door Standard/Premium, and it’s not something you explicitly "turn on" via a toggle.
Here’s how it works under the hood and what you need to know to ensure your traffic is actually using it.
Front Door acts as a global, scalable entry point for your web applications. When a client (like a browser) connects to your Front Door endpoint, it negotiates the best possible protocol. If the client supports HTTP/3 and the network path is suitable, Front Door will serve traffic over HTTP/3. Otherwise, it gracefully falls back to HTTP/1.1 or HTTP/2.
To see this in action, let’s look at a typical Front Door configuration and how you’d verify HTTP/3 usage.
Imagine you have a Front Door profile named my-frontdoor-std with a custom domain www.example.com pointing to an origin group my-origin-group which contains your web application servers.
{
"properties": {
"frontendEndpoints": [
{
"name": "defaultFrontendEndpoint",
"properties": {
"hostName": "my-frontdoor-std.azurefd.net",
"sessionAffinityEnabled": false,
"timeoutsInSeconds": 240,
"customDomains": [
{
"hostName": "www.example.com",
"routeConfigurations": [
{
"routes": [
{
"name": "defaultRoute",
"enabled": true,
"மையாகEnabled": true,
"originGroup": {
"id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Network/frontDoors/my-frontdoor-std/originGroups/my-origin-group"
},
"supportedProtocols": [
"Http",
"Https"
],
"patternsToMatch": [
"/*"
],
"linkToDefaultDomain": true,
"httpsRedirect": true,
"forwardingProtocol": "HttpsOnly"
}
]
}
]
}
]
}
}
],
"originGroups": [
{
"name": "my-origin-group",
"properties": {
"origins": [
{
"name": "my-web-app-origin",
"properties": {
"hostName": "mywebapp.azurewebsites.net",
"httpPort": 80,
"httpsPort": 443,
"originHostHeader": "mywebapp.azurewebsites.net",
"priority": 1,
"weight": 1000,
"enabled": true
}
}
],
"sessionAffinityEnabled": false,
"restoreHealthProbeEnabled": true,
"loadBalancingSettings": {
"sampleSize": 4,
"successfulSamplesRequired": 3,
"additionalLatencyMilliseconds": 50
}
}
}
]
}
}
Notice there’s no explicit http3Enabled: true setting here. That’s because Front Door handles the protocol negotiation. The supportedProtocols on the route simply indicates that the route can handle HTTP and HTTPS traffic, and Front Door’s internal logic will decide if HTTP/3 is the best choice.
The key to observing HTTP/3 is to check your client’s network activity. When you access https://www.example.com through your Front Door endpoint, open your browser’s developer tools, go to the "Network" tab, and reload the page. You’ll want to look at the "Protocol" column for the requests.
If you’re seeing h3 or http/3 in that column for your requests to www.example.com, then HTTP/3 is active. If you see h2 or http/2, or http/1.1, then a fallback occurred.
Here’s what influences whether HTTP/3 is used:
- Client Support: The user’s browser or HTTP client must support HTTP/3. Most modern browsers (Chrome, Firefox, Edge, Safari) have had HTTP/3 support for years, but it might be disabled in some older versions or specific configurations.
- Front Door’s Global Network: Front Door’s Points of Presence (PoPs) are designed to speak HTTP/3. The decision to use HTTP/3 happens at the edge PoP closest to the client.
- UDP Availability: HTTP/3 runs over QUIC, which uses UDP. If there’s network infrastructure between the client and the Front Door PoP that blocks or has high latency on UDP, Front Door might opt for TCP-based protocols like HTTP/2 or HTTP/1.1. This is the most common reason for fallback outside of client support.
- TLS 1.3 Support: HTTP/3 requires TLS 1.3 for its QUIC handshake. If TLS 1.3 isn’t successfully negotiated between the client and the Front Door PoP, HTTP/3 won’t be used. Front Door’s certificate management for custom domains is crucial here.
To verify the protocol at the Front Door PoP level, you’d typically look at Azure Monitor logs for Front Door. You can enable diagnostic settings for your Front Door profile to send logs to a Log Analytics workspace.
Once logs are flowing, you can query them. For example, to see requests by protocol:
AzureFrontDoorAccessLog
| where TimeGenerated > ago(1h)
| summarize count() by RequestMethod, Protocol
| order by count_ desc
This query would show you counts of requests categorized by HTTP method and the protocol used (e.g., HTTP/3, HTTP/2, HTTP/1.1). The Protocol field in these logs directly indicates what was negotiated.
The most surprising thing about HTTP/3 on Front Door is that you don’t configure it directly; it’s an emergent property of your clients and the network. Front Door’s infrastructure is built to offer it transparently.
The real levers you control are your origin configurations, custom domain TLS settings, and ensuring your client environment is capable of and not blocked from using UDP.
The one thing most people don’t realize is that even if a client supports HTTP/3, network path issues at the UDP layer are the silent killers of QUIC connections. Firewalls, intermediate routers, or even ISP-level packet inspection can drop UDP packets, forcing a fallback. Front Door’s health probes, for instance, will use TCP to check origin health, but the client-to-PoP connection is where UDP negotiation for HTTP/3 happens.
Once you’ve confirmed HTTP/3 is being used, the next thing you’ll want to investigate is how to optimize your origin response times to fully leverage the low-latency benefits of HTTP/3.