Enabled Only Means It Was Stored, Not That It Ran

Enabled only means it was stored, not that it ran


The rule sits in the list where you left it. Its switch reads Active, the dashboard is green, and the URL still opens the old page. Nothing in the interface looks wrong, because nothing there is. Active says the setting was accepted and is eligible to run; it says nothing about whether any call ever got through to it.



Matching is where most of an afternoon disappears, and one quirk accounts for more of it than the rest together. A wildcard is compared against the whole address, the query string included, so a pattern that does not end open will skip any request carrying parameters. That is exactly what happens when you append something to defeat the browser cache: the cache-buster beats the pattern instead, the page loads normally, and you assume the rule is faulty. Operators vary in whether they care about capitals, which turns a path copied from a design document into a rule that matches nothing. Bulk lists act the other way round and disregard parameters completely, but subpath and subdomain coverage stay disabled unless switched on, and a list that no rule activates does nothing at all.


Something may have responded before your turn


Rules products run in a fixed order, and a redirect stops evaluation the moment it triggers. Two settings that match the same address are not a draw: the first one reached wins, and the product order determines which that is. Older forwarding settings yield to the current products, which sounds like welcome news until the new pattern fails — then the old one activates, the visitor lands somewhere nobody configured this week, and the symptom stops resembling a redirect problem at all. Checking the order is faster than changing either one.



That gap is most of the assessment. Saved and ran are two different states, and the dashboard can only show the first one. Between a visitor and your setting there is the proxy mode of the entry, the order in which products are checked, and sometimes a zone in an account that is not yours. Until you know which handler received the request first, debating the rule itself is guesswork. The answer comes from a request, not from another glance at the configuration.



The full write-up, with every stage and what each answer resolves: cloudflare redirect rule does not fire



The sequence is what rescues the evening: did it arrive, did the template cover it, did something respond earlier, and are you viewing a plain query rather than a browser tab that may be showing you yesterday. Each question is resolved once, and the one that comes back wrong is the one to repair.