How to Set Up Nginx Redirects

You've moved a page, merged two domains, or finally switched to HTTPS — and now you need the old URLs to land somewhere useful instead of throwing a 404. Someone tells you "just add a redirect in Nginx," you open the config file, and you're staring at server and location blocks with no idea which directive is safe to touch.

The good news is that Nginx redirects are one of the more forgiving parts of server configuration once you know the two directives that do almost all the work. You don't need to understand the full Nginx module system — you need one correct block, a test command, and a reload.

What is an Nginx redirect?

An Nginx redirect is a directive placed inside a server or location block that tells a visitor's browser (or a search engine crawler) to request a different URL than the one it asked for, along with an HTTP status code explaining why.

• return — sends the redirect immediately, without evaluating the URL any further. This is the recommended directive for simple, fixed redirects.
• rewrite — matches the request against a regular expression and can rewrite it internally (no redirect sent to the browser) or externally as a redirect, using capture groups for pattern-based rules.
• Status codes — 301 means "moved permanently" and 302 means "moved temporarily." The code you choose changes how browsers cache the redirect and how search engines treat it.
• Where it lives — redirects go inside /etc/nginx/nginx.conf, or more commonly inside a site-specific file under /etc/nginx/sites-available/ that's symlinked into sites-enabled/.

Everything else — domain migrations, HTTPS enforcement, www normalization — is a variation on those two directives applied to a specific server_name or path.

Why getting redirects right matters

A redirect that's misconfigured doesn't always fail loudly — it often just quietly costs you traffic or rankings:

• Broken links stop working. Every inbound link, bookmark, and search result pointing at an old URL turns into a 404 the moment that URL stops existing without a redirect in place.
• Search rankings don't transfer on their own. A 301 redirect tells search engines to pass the old page's ranking signals to the new URL; without it, that history is effectively lost.
• The wrong status code sends the wrong signal. A 302 used for a permanent move can cause search engines to keep indexing the old URL instead of updating to the new one.
• Performance is on the line too. A rewrite directive used where a simple return would do adds unnecessary regex evaluation on every request to that path.

Step-by-step: setting up a redirect

1. Identify the old URL and the new URL. Write down exactly what should redirect to what, including whether it's a single page, a whole path, or an entire domain.
2. Open the site's Nginx config file. This is usually at /etc/nginx/sites-available/your-site — edit it with sudo nano or your preferred editor.
3. Find or create the relevant server block. For a single page, add the redirect inside a location block; for a whole domain or protocol change, add it inside the server block itself.
4. Add the return directive. For example: location /old-page { return 301 /new-page; } for a single path, or return 301 https://$host$request_uri; for an HTTP-to-HTTPS redirect.
5. Test the configuration. Run sudo nginx -t — this checks the syntax without applying anything, and will point to the exact line if something's wrong.
6. Reload Nginx. Run sudo systemctl reload nginx (or sudo nginx -s reload) to apply the change without dropping active connections.
7. Verify the redirect. Run curl -I https://yoursite.com/old-page and confirm the response shows the correct status code and a Location header pointing to the new URL.

Common mistakes

1. Using rewrite when return would do the job

rewrite is built for pattern matching with regular expressions. For a straightforward one-to-one redirect, it adds unnecessary processing and unnecessary complexity — return is faster and harder to get wrong.

2. Creating a redirect loop

This usually happens when the destination URL falls inside the same location block that's issuing the redirect, or when an HTTPS redirect sits behind a proxy that doesn't correctly forward the original protocol, so Nginx thinks every request is still on HTTP and keeps redirecting it.

3. Reaching for 302 on a permanent move

A 302 tells search engines the old URL might come back, so they keep it in the index instead of transferring its ranking signals. If the move is permanent, the status code should say so.

4. Editing the config and forgetting to reload

Saving the file doesn't apply anything on its own. Without running nginx -t and then reloading, the live server keeps serving the old configuration until it's explicitly told to pick up the change.

5. Mismatched trailing slashes

location /old-page and location /old-page/ are not the same match in Nginx. A redirect rule written for one won't necessarily catch requests to the other, which can leave some incoming links unredirected.

Real-world examples

How the same two directives cover most situations you'll actually run into:

return vs rewrite vs map compared

Nginx offers more than one way to redirect traffic. Here's how the main approaches differ.

Generate your Nginx redirect rule right now — free

The Rebrixe Nginx Redirect Generator builds a clean, ready-to-paste server or location block for the most common redirect scenarios — single page, domain move, www normalization, and HTTPS enforcement. No account needed, just fill in the URLs and copy the result.

Frequently asked questions