Issues with Azure Front Door Built-in HTTP to HTTPS Redirect (404 Not Found & CONFIG_NOCACHE with curl)

Question

Issues with Azure Front Door Built-in HTTP to HTTPS Redirect (404 Not Found & CONFIG_NOCACHE with curl)

이재옥 145

Hi,

I am configuring Azure Front Door to redirect HTTP traffic to HTTPS using the built-in option, but I am encountering inconsistent behavior between web browsers and CLI tools.

Current Setup:

Route accepts both HTTP and HTTPS.
"Redirect all traffic to use HTTPS" option is enabled.
Forwarding protocol is set to HTTPS only.
Origin group is properly configured and healthy.

Observed Behavior:

When accessing via a web browser (ex http://www.test.com), it correctly redirects to HTTPS as expected.
However, when testing with curl, the redirect is completely bypassed: $ curl -I http://www.test.com Output: HTTP/1.1 404 Not Found X-Cache: CONFIG_NOCACHE (The request is being incorrectly forwarded to the origin as an HTTP request, which subsequently returns a 404 error.)

Questions & Concerns:

Is this a known expected behavior when relying solely on the built-in "HTTPS redirect" option? Are there any hidden issues or edge cases (such as User-Agent or caching mechanics) associated with this feature?
Does Azure Front Door handle or evaluate routing rules differently for CLI tools (like curl) compared to standard web browsers?
To ensure a robust and consistent HTTP → HTTPS redirection across all types of clients, is it a best practice to avoid the built-in checkbox and explicitly use a Rule Set (Rules Engine) instead?

Any insights, workarounds, or official guidance on this behavior would be greatly appreciated.

Thanks!

0 comments

Answer accepted by question author

Jerald Felix 18,760 Volunteer Moderator

Hello 이재옥

Greetings! Thanks for raising this question in Q&A forum.

This is a very well-observed issue and the behavior you're seeing is not a curl-specific bug it's actually a route configuration mismatch. Let me explain exactly what's happening and how to fix it properly.

Why curl behaves differently from a browser

Azure Front Door does not treat curl or browsers differently — both are just HTTP clients. The real reason for the inconsistency is that browsers automatically follow redirects while curl -I only shows the first response without following through. But more importantly, the 404 Not Found with X-Cache: CONFIG_NOCACHE you see in curl tells a very specific story — the HTTP request is not hitting your redirect route at all. Instead it is matching a different route that forwards directly to your origin as HTTP, and your origin is returning 404 because it does not serve HTTP traffic.

Step 1: Understand why CONFIG_NOCACHE + 404 happens X-Cache: CONFIG_NOCACHE means Front Door received the request, matched a route, but found no cached content and forwarded it to the origin. The 404 comes from your origin, not from Front Door itself. This means the HTTP request is bypassing your redirect logic entirely and landing on a forwarding route most likely because another route is matching first with higher priority.

Step 2: Check your route priority and pattern matching In the Azure Portal, go to your Front Door profile > Endpoints > your endpoint > Routes. Look carefully at the order and configuration of your routes. The most common cause of this exact issue is:

A route that accepts both HTTP and HTTPS and forwards to the origin is matching the HTTP request before the redirect can fire. Front Door evaluates routes in order and the first matching route wins. If a broad forwarding route (e.g., with pattern /* accepting both HTTP and HTTPS) appears before your redirect route, it will swallow all HTTP requests.

Step 3: The recommended fix — use two separate dedicated routes The correct and explicit way to configure HTTP to HTTPS redirection is to use two separate routing rules:

First, create a route named HttpToHttpsRedirect set the Accepted Protocol to HTTP only, set the Route Type to Redirect, set the Redirect type to Moved (301), and set the Redirect protocol to HTTPS only.

Then create a second route named DefaultForwardingRoute set the Accepted Protocols to HTTPS only, set Route Type to Forward, and set the Forwarding Protocol to HTTPS only.

This completely separates HTTP traffic (which gets redirected) from HTTPS traffic (which gets forwarded), with no overlap or ambiguity.

Step 4: If you prefer to use a Rule Set for the redirect In Azure Front Door Standard/Premium tier, you can configure URL redirect using a Rule Set. Use the 301 (Moved Permanently) status code for HTTP to HTTPS redirection. A Rule Set approach gives you more flexibility and is useful when you need conditional logic, but for simple HTTP to HTTPS enforcement the two-route approach in Step 3 is cleaner and equally reliable.

If you do use a Rule Set, make sure it is associated with the route that accepts HTTP traffic a common mistake is associating the rule set with a route that only accepts HTTPS, which means HTTP requests never hit it.

Step 5: Test correctly with curl after the fix Once you have the two-route setup in place, test with curl using the -L flag which tells curl to follow redirects:

bash

curl -IL http://www.test.com

You should see a 301 Moved Permanently on the first response with a Location: https://www.test.com header, followed by a 200 OK from the HTTPS route. Without -L, you will only see the 301 which is the correct behavior.

Step 6: Wait for propagation After saving any route or Rule Set changes in Front Door, wait 5–10 minutes for the configuration to fully propagate across all edge nodes before retesting.

To directly answer your three questions no, Front Door does not have any special handling for curl vs browsers; the 404 is caused by a route matching issue, not a curl-specific quirk; and yes, using explicit separate routes (or a Rule Set) is a more robust and predictable approach than relying solely on the built-in checkbox when you have multiple routes configured.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

0 comments

2 additional answers

Your answer

Answer 1

Hi 이재옥 ,

Thank you for reaching out on Microsoft Q&A forum.

As @Jerald Felix rightly pointed out, this behavior is due to how Azure Front Door evaluates route matching rather than any difference between curl and browser requests.

Specifically, the presence of X‑Cache: CONFIG_NOCACHE along with the 404 response indicates that the HTTP request is directly matching a forwarding route and being sent to the origin, instead of being evaluated against the redirect configuration. This typically happens when a broader route (for example /* accepting both HTTP and HTTPS) takes precedence and captures the request before the redirect logic is triggered.

As highlighted, Azure Front Door processes the first matching route, and once selected, the request does not fall back to other redirect logic. Because of this, any overlap between redirect and forwarding routes can result in inconsistent behavior like the one observed.

To address this, aligning with Jerald’s recommendation, it is best to:

Keep HTTP handling isolated to a redirect configuration
Avoid having forwarding routes that accept both HTTP and HTTPS when you intend to enforce HTTPS

This matches the recommended configuration approach for HTTP → HTTPS redirection: Configure HTTP to HTTPS redirect

For more advanced scenarios, you can also use Rule Sets to explicitly control redirect behavior at the edge: Azure Front Door Rules Engine

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

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Azure Front Door evaluates all clients (browsers, curl, other HTTP tools) the same way: decisions are based on host, path, and protocol, not on User-Agent. The behavior described indicates a routing/route‑match issue rather than a special case for curl.

Key points from the platform behavior in the context:

Route matching and 404/CONFIG_NOCACHE

For each request, Front Door first tries to match a route on:
- Frontend host (domain)
- Protocol (HTTP/HTTPS, depending on what the route accepts)
- Path pattern (Patterns to match)
If no route matches, Front Door returns 400: Bad Request.
If a route matches but is configured to forward to the origin, the origin’s response (such as 404 Not Found) is returned.
X-Cache: CONFIG_NOCACHE indicates the request is being processed by configuration (no cache hit) and forwarded to the origin.

From the endpoint configuration description:

“Azure Front Door determines the traffic based on exact match first. If no paths match exactly, then Front Door looks for a wildcard path that matches. If no routing rules are found with a matching path, then the request gets rejected and returns a 400: Bad Request error HTTP response.”

This means:

If the browser and curl are not sending identical host + path + protocol, they may hit different routes.
For example, differences like / vs /index.html, or a different host (with/without www) can cause different route matches.

Built-in HTTP→HTTPS redirect vs. explicit redirect routes

The built-in “Redirect all traffic to use HTTPS” on a route is effectively a per-route redirect flag. It is not a separate global rule engine. It applies only when that specific route matches.

The best-practices guidance explicitly recommends enabling HTTP→HTTPS redirection on the route:

“You can configure Azure Front Door to automatically redirect HTTP requests to use the HTTPS protocol. You should enable the Redirect all traffic to use HTTPS setting on your route.”

There is no indication in the context of:

User-Agent–specific behavior.
Known issues where curl is treated differently.

Answers to the specific questions

Expected behavior / hidden issues

The platform treats HTTP→HTTPS redirect as a normal route behavior. There is no documented special handling for curl or other CLI tools.
If some HTTP requests are being forwarded to the origin as HTTP instead of being redirected, it means those requests are not matching a route where Redirect all traffic to use HTTPS is enabled, or another route with higher precedence is matching first and forwarding instead of redirecting.
Common causes (based on the routing model in the context):
- The route with redirect does not include all relevant hosts (e.g., only www.test.com but curl is using test.com, or vice versa).
- The route’s Patterns to match do not cover the exact path curl is using (e.g., route matches /app/* but curl is requesting /).
- Another route with a more specific pattern (exact match) is taking precedence and forwarding to the origin.

Different handling for CLI tools vs browsers

No. Front Door supports HTTP, HTTPS, and HTTP/2, and routing is based on host, path, and protocol, not on client type.
Any difference observed between browser and curl is due to differences in the actual request (host header, path, protocol, or possibly following redirects differently), not to Front Door treating them differently.

Best practice: built-in checkbox vs Rule Set

Best practices recommend using the built-in HTTP→HTTPS redirect on the route: “You should enable the Redirect all traffic to use HTTPS setting on your route.”
Rule sets (rules engine) are powerful for more complex scenarios (path/host rewrites, header manipulation, conditional redirects), but the context does not state that rule sets are required or preferred over the built-in redirect for simple HTTP→HTTPS enforcement.
For robust behavior across all clients:
- Ensure all relevant hosts are covered by routes that:
  - Accept HTTP and HTTPS.
  - Have Redirect all traffic to use HTTPS enabled.
- Ensure Patterns to match cover / and any other paths that should redirect (for example, use /* when appropriate).
- Avoid conflicting routes where a more specific route forwards to the origin without redirect while a broader route has redirect enabled.

If a rules engine–based redirect is used instead, it should be configured on the same matching criteria (host + path) and applied consistently to avoid similar mismatches.

References: