// build nginx redirect and rewrite rules instantly
Generate Nginx redirect and rewrite rules instantly. Build 301/302 redirects, URL rewrites, return directives, and regex-based rules for any redirect scenario.
Ready to generate
Select a redirect type and fill in the fieldsChoose from exact match, prefix, regex, domain, or URL cleanup redirects.
Enter your source path/pattern and destination URL. Select 301 or 302 status code.
Click Generate, copy the config block, paste it into your Nginx server block, then reload Nginx.
This tool generates ready-to-use Nginx location blocks, rewrite directives, and return statements for common redirect and URL rewrite scenarios. No regex knowledge required for most cases.
A 301 is a permanent redirect — search engines transfer link equity and update their index. A 302 is temporary — browsers and crawlers keep the original URL cached. Use 301 for site migrations and permanent URL changes; use 302 for A/B testing or temporary maintenance pages.
return directive do in Nginx?The return directive stops processing the current request and sends the specified HTTP status code and optional URL to the client. It's faster than rewrite for simple redirects because Nginx doesn't need to evaluate regex or run PCRE.
rewrite vs return?Use return for simple redirects — it's more performant and readable. Use rewrite when you need to capture groups from the URL (e.g. rewrite ^/blog/(.*)$ /news/$1 permanent) or when you need to modify the URI internally without redirecting the client.
^~ location modifier?The ^~ modifier tells Nginx to stop searching for regex location matches if this prefix match is found. It has higher priority than regex locations but lower than exact = matches. Use it when a prefix match should always win over any regex rules.
After editing your Nginx config, run nginx -t to test for syntax errors, then reload with systemctl reload nginx or nginx -s reload. A reload applies config changes without dropping active connections, unlike a full restart.
Location blocks and rewrite directives go inside the server { } block of your site config, typically in /etc/nginx/sites-available/your-site or /etc/nginx/conf.d/your-site.conf. Server-level return statements (like HTTP→HTTPS) need their own server { } block.
With return, append $is_args$args to the destination URL — this adds the ? and query parameters only if they exist. With rewrite, query strings are automatically passed unless you end the replacement URL with a ? to strip them.
Yes. Use a regex location block with a pipe-separated pattern: location ~ ^/(old-page|another-page|third-page)$ { return 301 /new-page; }. Alternatively, list individual exact-match location blocks for each URL — this is more explicit and easier to maintain.
An Nginx redirect generator is a tool that creates properly formatted Nginx configuration directives for URL redirects and rewrites. Instead of writing location blocks and rewrite rules from scratch — and risking typos or incorrect modifier syntax — you fill in a form and get copy-ready config code.
Nginx is one of the most widely deployed web servers in the world, powering millions of websites from personal blogs to large-scale platforms. Configuring redirects correctly in Nginx is critical for SEO, security (HTTPS enforcement), and a smooth user experience when URLs change.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and server configuration guides — worth checking out.
Nginx offers several mechanisms for redirecting traffic, each suited to different scenarios:
=): Matches only the exact URI. Nginx stops searching once an exact match is found, making it the fastest option for specific URLs.^~): Matches URIs beginning with a specified string and prevents regex location blocks from being checked. Ideal for static directories or specific path prefixes.~ / ~*): Uses PCRE regular expressions to match URI patterns. The ~* variant is case-insensitive. Powerful for complex URL patterns with capture groups.permanent, redirect) or change the URI internally for further processing.return Directive vs rewriteFor most redirect scenarios, Nginx documentation recommends using the return directive over rewrite. Here's why:
return is evaluated immediately during the server configuration phase without invoking the PCRE regex engine. This makes it significantly faster for simple redirects. The syntax is clean: return 301 https://example.com$request_uri;
rewrite is evaluated in a subsequent phase and requires regex compilation. It's necessary when you need to capture parts of the URL and use them in the destination: rewrite ^/old/(.+)$ /new/$1 permanent;. The capture group $1 is reused in the replacement string — something return can't do on its own.
Every production website should redirect HTTP traffic to HTTPS. In Nginx, this requires a dedicated server block listening on port 80 that returns a 301 redirect to the HTTPS equivalent:
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}Search engines treat www.example.com and example.com as different URLs. Choose one canonical form and redirect the other. This avoids duplicate content penalties and consolidates link equity to one domain variant.
When relaunching a website with new URL structures, preserving old URLs with 301 redirects is essential for SEO. Each old URL should map precisely to its new equivalent. A mass redirect (all old URLs → homepage) is far less effective than page-specific redirects that maintain content relevance signals.
Inconsistent trailing slashes create duplicate content. The rewrite rule rewrite ^/(.*)/$ /$1 permanent; normalizes all URLs to their slash-free form. Combine this with a consistent linking strategy in your application to avoid redirect chains.
After generating your rules with this tool, follow these steps to deploy them safely:
/etc/nginx/sites-available/your-domain or /etc/nginx/conf.d/your-domain.conf.server { } context. Location blocks go inside the server block; separate server blocks (like for HTTP→HTTPS) go at the top level of your config.sudo nginx -t. Never skip this step — a syntax error will prevent Nginx from reloading.sudo systemctl reload nginx to apply changes without dropping connections.curl -I http://your-domain/old-path to confirm the expected status code and Location header.Understanding location priority is key to writing effective redirect rules. Nginx evaluates locations in this order:
=) — highest priority, stops search immediately^~ — stops regex search if matched~ and ~*) — evaluated in config file order, first match winsThis ordering matters when multiple rules could apply to the same URL. Place more specific rules before general ones, and use = for frequently-hit exact URLs to maximize performance.