Redirect Fixes in Apache and nginx

Which directive for which job

Both servers offer a simple directive and a powerful one. The simple one is easier to read, harder to get wrong and cheaper to run, so use it unless you need what only the powerful one offers.

Two behaviours trip people up. Apache's Redirect is a prefix match: Redirect 301 /shop /store also sends /shop/boots to /store/boots and /shopping to /storeping. If you mean one exact page, use RedirectMatch 301 ^/shop$ /store. And nginx's return stops processing immediately, while rewrite changes the URI and may continue through other rules unless you use permanent, redirect, last or break.

Apache: mod_alias, mod_rewrite and .htaccess

On Apache, rules can live in the main server configuration, a virtual host, or an .htaccess file in a folder. .htaccess is read on every request and only works if the virtual host allows it with AllowOverride; if nothing you write there has any effect, check that first. On shared hosting, .htaccess is usually the only place you can edit.

Things that behave differently in .htaccess

• No leading slash in the pattern. In .htaccess, the path a RewriteRule sees has the folder prefix removed, so it is old-page, not /old-page. A rule written as ^/old-page$ works in a virtual host and silently never matches in .htaccess. Redirect and RedirectMatch always use the full path with its leading slash.
• [L] is not the end. In a folder context, [L] ends the current pass, but if the URL was rewritten internally Apache starts the rules again from the top. For an external redirect with R=301 this rarely matters, but for internal rewrites that are meant to stop, [END] does what people expect [L] to do.
• Mixing modules. mod_alias and mod_rewrite run independently, and in .htaccess mod_rewrite rules generally take effect first regardless of the order in the file. If a Redirect line appears to be ignored, a RewriteRule above or below it may already have handled the request. Use one module per file where you can, and mod_rewrite when you need conditions.

A clean mod_rewrite block

RewriteEngine On

# 1. host and scheme in one hop (skip if the CDN or panel already does this)
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.co\.uk$ [NC]
RewriteRule ^ https://www.example.co.uk%{REQUEST_URI} [R=301,L]

# 2. single moved pages
RewriteRule ^services/plumbing-repairs$ /services/plumbing/ [R=301,L]
RewriteRule ^team\.html$ /about/team/ [R=301,L]

# 3. whole folder moved, keeping the rest of the path
RewriteRule ^news/(.+)$ /blog/$1 [R=301,L]

# 4. application front controller last
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [END]

Order matters: host rules first, then specific pages, then patterns, then the catch-all that hands everything else to your application. If the catch-all comes first, none of the redirects below it ever run.

nginx: return, rewrite and server blocks

nginx has no per-folder files. Every rule lives in the configuration, which is checked and loaded when you reload the service. That makes rules faster and more predictable, but it means you need server access, or a hosting panel box that writes into the configuration for you.

# every http request, any host, goes straight to the final https host
server {
    listen 80;
    server_name example.co.uk www.example.co.uk;
    return 301 https://www.example.co.uk$request_uri;
}

# https on the bare domain
server {
    listen 443 ssl;
    server_name example.co.uk;
    # ssl_certificate lines here
    return 301 https://www.example.co.uk$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.co.uk;

    location = /services/plumbing-repairs { return 301 /services/plumbing/; }
    location = /team.html                 { return 301 /about/team/; }
    location ^~ /news/ {
        rewrite ^/news/(.+)$ /blog/$1 permanent;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

How nginx chooses a location matters for redirects. Exact matches with = win outright. Otherwise nginx finds the longest matching prefix; if that prefix is marked ^~ it is used, and if not nginx tries regular expression locations in the order they appear. A redirect placed in a regex location can therefore be skipped because another regex location earlier in the file matched first. Exact and ^~ locations avoid the guesswork.

Use $request_uri when copying the whole original path and query string, because it is the address exactly as the visitor sent it. $uri is the decoded, normalised path without the query string, and can change after internal rewrites.

Regular expressions that do not overreach

Most broken redirects are pattern mistakes. These are the ones the Redirect Checker exposes most often:

The loop test is simple and worth doing for every pattern rule: write down the target for one real example, then ask whether that target would match the same pattern. If it would, the rule needs a tighter pattern or a condition that excludes the target.

Query strings: kept, dropped or matched

The two servers handle the part after ? differently, and the difference decides whether campaign tags survive a redirect.

• Apache RewriteRule keeps the original query string by default. If the target has its own ?, the original is replaced unless you add [QSA]. [QSD] drops it. A pattern in RewriteRule never sees the query string; to match on it, use RewriteCond %{QUERY_STRING}.
• Apache Redirect and RedirectMatch pass the query string through to the target.
• nginx rewrite appends the original arguments unless the replacement ends in ?.
• nginx return sends exactly the address you give it, so add $is_args$args or use $request_uri if you want the query string kept.

# Apache: old product IDs in the query string
RewriteCond %{QUERY_STRING} (^|&)id=42(&|$)
RewriteRule ^product\.php$ /shop/oak-bench/? [R=301,L]

# nginx: same move
location = /product.php {
    if ($arg_id = "42") { return 301 /shop/oak-bench/; }
}

The trailing ? on the Apache target drops id=42 so it is not carried onto the new, clean address.

Long redirect lists without long config files

After a site rebuild you may have hundreds of old URLs. Hundreds of separate rules are slow to read and easy to break, and in .htaccess they are evaluated on every request. Both servers have a lookup table for this.

# nginx: in the http block
map $request_uri $moved_to {
    default                         "";
    /services/plumbing-repairs      /services/plumbing/;
    /team.html                      /about/team/;
    /news/opening-hours-2024        /blog/opening-hours/;
}

# in the server block
if ($moved_to) { return 301 $moved_to; }

# Apache: in the virtual host, not .htaccess
RewriteMap moved "txt:/etc/apache2/redirects/moved.txt"
RewriteCond ${moved:%{REQUEST_URI}|NONE} !=NONE
RewriteRule ^ ${moved:%{REQUEST_URI}} [R=301,L]

# moved.txt, one pair per line
/services/plumbing-repairs /services/plumbing/
/team.html /about/team/

Keep the list in a file under version control or in a spreadsheet you export, and before loading it, check that no target also appears as a source. That single check prevents most chains.

The fix, step by step

When a rule does not do what you expect

Both servers can tell you exactly what their rewrite engine did, which is quicker than guessing.

• Apache: in the virtual host, set LogLevel alert rewrite:trace3, reload, make one request and read the error log. Each line shows the pattern tried, the input and whether it matched. Turn it off afterwards; the log grows quickly.
• nginx: add rewrite_log on; and set the error_log level to notice for the server block. return does not appear in this log, but rewrite does.
• Browser caching: a 301 from an earlier mistake can be cached by the browser for a long time. Test in a private window or with curl, never only in your everyday browser.
• Not your rule at all: if the response headers show a CDN or the Server header is not your web server, the redirect is coming from further up the stack.

curl -sI http://example.co.uk/news/spring-opening | grep -iE "^(HTTP|location|server)"