Nginx Redirect Generator

Nginx supports two primary methods for URL redirection: the "return" directive and the "rewrite" directive. The "return" directive is simpler, faster, and highly recommended for simple domain-level or path-level redirects (e.g., return 301 https://example.com$request_uri;). The "rewrite" directive, on the other hand, is a more powerful regex-based parser used when you need to match complex URL query parameters, capture subpatterns, or modify paths before passing them downstream. In terms of server performance, "return" is preferred because Nginx stops processing the block immediately once matched.

To redirect all incoming traffic from an old domain to a new domain, place a return directive inside your Nginx server block. Use the code: `return 301 $scheme://newdomain.com$request_uri;`. This syntax captures the request protocol (HTTP or HTTPS) and the exact path query parameters, passing them cleanly to the new domain. Make sure this directive is placed within a server block that is listening on port 80 and/or 443 with the server_name set to your old domain.

Use a 301 redirect (Moved Permanently) for permanent site migrations, URL structure updates, or domain transfers. A 301 redirect passes roughly 95-99% of ranking authority (link equity) to the new destination page, signaling search engines to update their indexes. Use a 302 redirect (Moved Temporarily) only for short-term changes, such as running seasonal promotions, performing site maintenance, or A/B testing layouts, which tells search engines to keep indexing the original URL.

A trailing slash redirect ensures that URLs resolve consistently (e.g., redirecting /blog to /blog/). Inconsistent trailing slashes can create duplicate content issues where Google indexes both versions separately. You can enforce a trailing slash in Nginx by adding a rewrite rule: `rewrite ^([^.?]*[^/])$ $1/ permanent;`. This rule matches any URL path that does not contain a file extension or a trailing slash, and appends a slash before executing a 301 redirect.

Nginx evaluates location blocks based on a strict matching precedence hierarchy: first, it checks for exact matches using the `=` modifier; second, it checks for preferential prefix matches using the `^~` modifier; third, it evaluates regex matches using `~` (case-sensitive) or `~*` (case-insensitive); and finally, it falls back to standard prefix matches (e.g., `location /`). Once Nginx finds a match in a higher priority group, it stops checking subsequent blocks. Our generator lets you choose these matching types to ensure your redirects fire in the correct order.

Before reloading your live Nginx server, always validate your configuration files for syntax mistakes by running the terminal command: `sudo nginx -t`. This command checks all active config files, testing locations, rewrites, and file inclusions for compile errors. If the test passes with "syntax is ok" and "test is successful", you can safely apply the new rules by running `sudo systemctl reload nginx` or `nginx -s reload` without causing downtime.

Yes, Nginx handles query parameters differently depending on the directive. The "return" directive automatically appends the incoming query string to the destination URL. For the "rewrite" directive, Nginx appends the query string by default; if you want to discard the query parameters in a rewrite rule, you must append a question mark at the end of the destination path (e.g., `rewrite ^/old-path$ /new-path? permanent;`).