Why does my redirect work for everyone except me?

Your browser almost certainly cached a previous 301. A private window bypasses that cache and confirms it in seconds.

Why does my rule never fire?

Usually a trailing slash, a query string, a case difference, or a broader rule earlier in the evaluation order matching first.

How do I tell which layer is redirecting?

Request the origin directly where you can, and read the Server and vendor headers on the response. A redirect that vanishes when the CDN is bypassed came from the CDN.

Questions

Why is my redirect not working?

Almost always one of four things: another rule matched first, the redirect is cached in your own browser, a layer in front of the application is answering before your rule is reached, or the rule never matched because of a trailing slash, a query string or a case difference. Following the request hop by hop with curl identifies which of the four within a minute, and the answer is rarely in the rule you have been editing.

Start by seeing what actually happens

`curl -sIL https://example.com/old-path | grep -iE '^(HTTP|location)'` prints every hop with its status and target.

No `Location` header at all means the rule did not match. A `Location` pointing somewhere unexpected means a different rule matched. The same URL twice means a loop.

Use curl rather than a browser for this: the browser follows and caches, so it shows you the destination and hides the path taken.

Test both the trailing-slash and non-trailing-slash forms, and both the `http` and `https` forms. Four requests, and one of them usually behaves differently from the other three.

Add `--max-redirs 5` so a loop reports an error instead of hanging, and `-v` when you need to see which headers the request carried.

Cause one — your browser cached a 301

Browsers cache permanent redirects, sometimes for a very long time, and clearing that entry is not something the server can do.

The symptom is distinctive: the redirect works correctly for colleagues and automated checks, and only your browser keeps going to the old destination.

A private window bypasses the cache and settles it immediately.

This is also why a 301 published by mistake is expensive: every visitor who received it keeps it until their own cache expires.

A CDN caches redirects too, so the same symptom can come from the edge rather than the browser — a cold request from another network separates the two.

Cause two — another rule matched first

Redirect rules are evaluated in order, and the first match usually wins. A broad rule near the top silently shadows every specific rule under it.

Rules commonly live in several places at once: the CDN, the web server configuration, the application framework, and a redirects table in the content management system.

Each of those layers runs before the next, so a CDN rule beats a server rule, which beats an application rule.

Find which layer is answering by requesting the origin directly, where you can. A redirect that disappears when the CDN is bypassed was being served by the CDN.

The `Server` header and any vendor-specific headers on the response name the component that answered.

Order matters inside a layer as well as between them. Moving a specific rule above a broad one fixes more redirect reports than rewriting either rule.

Cause three — the pattern does not match what is requested

Trailing slashes: a rule for `/old-path` does not match `/old-path/` unless it was written to.

Query strings: many rule syntaxes match the path only, so `/old-path?ref=email` may not match a rule for `/old-path`.

Case: most web servers treat paths case-sensitively, so `/Old-Path` is a different path.

Anchors are never sent to the server, so a rule that tries to match one can never fire.

Regular expressions that are unanchored match more than intended, and anchored ones frequently match less. Both failure modes look like the rule being ignored.

Cause four — the loop that looks like a failure

Two canonicalisation rules that disagree — one adding a trailing slash, one removing it — alternate forever, and the browser reports that the page is not redirecting properly.

The classic version is an application enforcing HTTPS behind a proxy that terminates TLS and forwards plain HTTP. The application sees HTTP, redirects to HTTPS, and the cycle closes.

The fix there is the forwarded-protocol header, not another redirect rule.

Read the sequence rather than the endpoint: the two URLs that alternate name the two rules in conflict, and one of them is the one to remove.

Authentication flows produce the same shape: an unauthenticated visitor sent to a login page that itself requires authentication, which loops until the browser stops.

What a scan reports

VeriFixScan follows redirects during a crawl and reports `transport.redirect_chain` with the hops, so a chain is visible as a chain rather than as a working link.

`availability.redirect_loop` reports cycles that never resolve, which are a hard failure on those URLs rather than a slow path.

`transport.http_redirect` reports whether the plain-HTTP form of the site redirects to HTTPS, which is the redirect most often misconfigured behind a proxy.

A scan follows redirects from one client. Rules that depend on a cookie, a session or a geography may behave differently for real visitors and will not be reproduced.

Frequently asked questions

Why does my redirect work for everyone except me?: Your browser almost certainly cached a previous 301. A private window bypasses that cache and confirms it in seconds.
Why does my rule never fire?: Usually a trailing slash, a query string, a case difference, or a broader rule earlier in the evaluation order matching first.
How do I tell which layer is redirecting?: Request the origin directly where you can, and read the Server and vendor headers on the response. A redirect that vanishes when the CDN is bypassed came from the CDN.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website