Free Tool

4.9/5

Free NGINX Redirect Generator

Build production-ready nginx server-block config from a friendly form. 301/302/307/308 rules, regex rewrites, HTTPS blocks, and www / trailing-slash policy, copy in one click.

Quick presets

Server settings

Server name (domain)

www handling

Trailing slash

Generate full HTTPS server block (listen 443 ssl)

Redirect rules (1)

Rule 1

Source path

Destination

Status:

Regex (rewrite)

Generated nginx config

# ─── Redirect HTTP to HTTPS ───
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# ─── Redirect www to bare over HTTPS ───
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

# ─── Main HTTPS server with redirects ───
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location = /old-page {
        return 301 /new-page;
    }

    # Your application proxy goes below:
    # location / { proxy_pass http://localhost:3000; }
}

Drop this into your /etc/nginx/sites-available/ or wherever your server blocks live. Validate with sudo nginx -t and reload with sudo systemctl reload nginx.

Tired of editing nginx for every redirect?

Use Flyn branded short links instead, editable, trackable, no server access needed. Change destinations in seconds without touching config.

Shorten for free

How to Generate NGINX Redirect Config in 3 Steps

Enter your domain and rules

Type your server_name (domain), pick global options like force HTTPS, www / non-www, trailing slash handling, and add redirect rules with source path, destination, and status code.

Switch between snippet and full server block

Toggle between two output modes, a paste-into-existing-server-block snippet, or a complete server { } block with listen directives, SSL placeholders, and HTTP-to-HTTPS redirect logic.

Copy, validate, and reload

Copy the config into /etc/nginx/sites-available/ or your conf.d/ directory. Run sudo nginx -t to validate, then sudo systemctl reload nginx to apply with zero downtime.

What Is an NGINX Redirect?

An nginx redirect is a server-side instruction that tells the client (browser, search-engine crawler, or other HTTP client) to fetch a different URL. Unlike client-side redirects from JavaScript or HTML meta-refresh, nginx redirects happen at the edge, before any application code runs, so they are faster, more reliable, and visible to crawlers that may not execute JavaScript. If you have no server access at all, the meta refresh redirect generator builds that client-side fallback for you.

In nginx, redirects are built from three directives: return for fixed source paths, rewrite for regex patterns, and location blocks to scope them. Each lives inside a server { ... } block. This generator builds that config from a form, so you do not have to remember the order of arguments or the difference between permanent and redirect flags.

NGINX Redirect Directives Reference

The directives this generator produces and what each one does.

`return 301`

The simplest, fastest redirect. Use for fixed source paths that do not need URL parts captured. Syntax: return 301 https://new.example.com$request_uri;. Nginx stops processing the location block immediately on a return, no further rewrites run.

`rewrite ... permanent`

For regex-based redirects with capture groups. Use when you need to extract path segments. The permanent flag emits a 301; redirect emits a 302. Always anchor patterns with ^ and $ to prevent partial or recursive matches.

`location = /path`

Exact-match location block, highest priority, fastest lookup. Perfect for a handful of fixed-source redirects. Nginx hashes these at config-load time so they cost O(1) at request time, even with hundreds of them.

`location ~ /regex`

Regex location block, case-sensitive. Use ~* for case-insensitive. Regex locations are checked in file order, first match wins. Place specific patterns before catch-alls to avoid surprises.

`add_header`

Add response headers like Strict-Transport-Security, X-Frame-Options, and X-Content-Type-Options. Use the always parameter so headers apply to error responses (4xx, 5xx) too, without it, nginx skips add_header on errors.

`server_name`

Defines which Host header(s) this server block matches. Supports exact names, wildcards (*.example.com), and regex (~^www\d+\.example\.com$). The default_server flag on listen overrides server_name when no match found.

NGINX Redirect Best Practices

Lessons learned from running nginx at scale.

Always use 301 for permanent moves

Browsers cache 301s aggressively. If you ship a 301 by mistake, fixing it later can take days to propagate as users' browsers re-validate. Use 302 for anything experimental, then promote to 301 once you are confident the redirect is permanent.

Anchor every regex pattern

A rewrite like rewrite /old /new permanent; will match /old, /something/old, /old/anything, probably not what you want. Always use ^ at the start and $ at the end: rewrite ^/old$ /new permanent;. This single habit prevents most redirect loops.

Prefer return over rewrite when possible

return is faster (no regex evaluation), clearer (no capture group ambiguity), and stops processing immediately. Reach for rewrite only when you actually need to extract URL parts. For static one-off redirects, location = / { return 301 ...; } is the gold standard.

Validate before every reload

sudo nginx -t parses your full config (every include) and reports syntax errors with file and line numbers. Make it a habit: edit, nginx -t, then reload. The 30 seconds you spend testing prevents a misplaced semicolon from taking down your site.

Reload, do not restart

sudo systemctl reload nginx (or nginx -s reload) replaces workers without dropping connections. systemctl restart fully tears down the master process and kills active TCP connections, only restart when upgrading the nginx binary itself.

Keep redirects in a dedicated server block

Put your HTTP-to-HTTPS redirect in a tiny server block of its own, and your www/non-www enforcement in another. This keeps each block focused on one job, makes the main HTTPS block easier to read, and lets you change redirect logic without touching application config.

Skip the Server Edit, Use Flyn Branded Short Links

Editing nginx config every time a marketing URL changes? There is a better way. Flyn short links are editable, trackable, and live outside your server.

Editable destinations

Change where a link points in seconds. No SSH, no nginx -t, no reload. Marketing owns the redirect.

Click analytics

Every redirect is counted in real time, and Pro logs device, country, and referrer detail. See exactly how each link is used.

Branded domains

On Pro, use your own domain with automatic TLS, the link still looks like yours, but you never touch nginx.

Sub-50ms redirects

Global edge delivery means redirects feel instant. Faster than most self-hosted nginx setups.

Frequently Asked Questions

Where does the nginx config live on my server?

On most Linux distros the main config is at /etc/nginx/nginx.conf, with site-specific server blocks in /etc/nginx/sites-available/ symlinked into /etc/nginx/sites-enabled/. On Debian and Ubuntu the sites-available pattern is the default; on RHEL, CentOS, and Amazon Linux the convention is /etc/nginx/conf.d/*.conf. After editing any file, run sudo nginx -t to validate, then sudo systemctl reload nginx to apply.

What is a server block and how does it work?

A server block is nginx's equivalent of an Apache virtual host, a config section that handles requests for a specific domain, port, or IP. Each server block is wrapped in server { ... } and is selected based on the Host header, listen port, and server_name directives. You can have many server blocks in one config: one for HTTP, one for HTTPS, one per subdomain. Redirects typically live in a small dedicated server block at the top of the chain.

When should I use return 301 vs rewrite ... permanent?

Use return 301 for any redirect that does not need to capture parts of the URL, it is faster, clearer, and harder to misconfigure. Use rewrite when you need a regex to extract path segments (rewrite ^/blog/(.*)$ /posts/$1 permanent;). The permanent keyword on rewrite is the equivalent of 301; redirect is 302. Nginx evaluates rewrite directives in order and may loop, so always anchor your regex with ^ and $.

What do the location modifiers =, ~, ~*, and ^~ mean?

location = /path is an exact match (highest priority, fastest). location ^~ /prefix is a prefix match that wins over regex. location ~ /regex is a case-sensitive regex match. location ~* /regex is case-insensitive regex. With no modifier, you get a plain prefix match. Nginx checks exact and ^~ matches first, then walks the regex blocks in file order, first regex hit wins. Use = for one-off redirect rules and ~ for patterns.

How does regex work in nginx redirects?

Nginx uses PCRE regex syntax. In rewrite directives, the source pattern is matched against the request URI (path + optional query string). Capture groups are referenced with $1, $2, etc. in the destination. Always anchor patterns with ^ and $ to prevent partial matches: rewrite ^/old/(.*)$ /new/$1 permanent;. Escape literal dots with a backslash. Use ~ for case-sensitive location regex and ~* for case-insensitive.

How do I test my nginx config before reloading?

Run sudo nginx -t. This parses your full config tree (every include) and reports syntax errors and unknown directives with file and line numbers. It does NOT catch logic errors like infinite redirect loops or unintended pattern overlaps, only syntax. For deeper testing, use sudo nginx -T to dump the resolved config to stdout, then curl -I against a staging environment before promoting changes to production.

Should I reload or restart nginx after changes?

Always reload, never restart, for config changes. sudo systemctl reload nginx (or sudo nginx -s reload) re-reads the config and gracefully replaces worker processes without dropping in-flight connections. systemctl restart fully tears down the master process and drops active TCP connections. Only do that if you upgraded the nginx binary itself or changed something that requires a full restart (very rare).

What are the most common nginx redirect errors?

Top three: (1) Missing semicolons, every directive must end with a ; including the last one before a closing brace. (2) Trailing-slash mismatches, /old does not match /old/ unless you redirect both. (3) Rewrite loops, a rewrite that matches its own destination will redirect forever; always anchor with ^ and $ and exclude the destination path from the source pattern. nginx -t will catch (1) but not (2) or (3).

When should I use 301 vs 302 redirects?

Use 301 (Moved Permanently) for any redirect you intend to keep, domain migrations, slug changes, deprecated URLs. Search engines transfer ranking signals to the new URL and browsers cache the redirect aggressively. Use 302 (Found) only for temporary redirects like A/B tests, geo-targeted variants, or scheduled maintenance pages. To verify your redirects work as intended, use our free redirect checker, it traces the full chain and flags loops.

How do I add HSTS and other security headers to my nginx config?

Add add_header directives inside your HTTPS server block. The essentials: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always;. The always parameter ensures the header is set on error responses too. Audit your live headers with the security headers checker before going live.

How does nginx compare to Apache (.htaccess) for redirects?

Nginx evaluates config at startup and reload, so changes need a reload, there is no per-directory .htaccess equivalent. Apache reads .htaccess on every request, which is slower but lets you change rules without server access. Nginx redirects are typically faster (single rewrite pass, no file lookup) and the syntax is cleaner. If you are on Apache or need .htaccess, use our htaccess redirect generator instead.

Do nginx redirects affect performance?

Negligibly. Nginx evaluates return directives in O(1), they are basically free at the scale you will hit. Even hundreds of location = / blocks add no measurable latency because nginx hashes exact-match locations at config-load time. Where you can hurt yourself: long lists of regex rewrite directives, since each is tested in order on every request. Convert frequently-hit redirects to exact-match location = blocks for best performance.

More Free Developer Tools

Free tools that pair with your nginx work, generators, checkers, and validators. For a full migration, the redirect map generator exports every rule as an nginx block in one go.

HTAccess Redirect Generator

The Apache equivalent, build .htaccess rewrite rules from a form.

Redirect Checker

Trace 301/302 redirect chains, detect loops, and verify your nginx rules work.

WordPress Redirect Generator

For managed WP hosting where nginx config isn't accessible, Redirection plugin or PHP.

Shopify Redirect Generator

Shopify URL Redirects CSV for bulk migration imports.

Webflow Redirect Generator

Webflow Old Path → Redirect to Path 301 with wildcard support.

Squarespace Redirect Generator

Squarespace URL Mappings 301/302 rules with [slug] capture.

URL Cleaner

Strip tracking params and normalize URLs before redirecting.

Canonical URL Checker

Verify your redirects line up with the canonical URLs search engines see.

URL Shortener

Branded short links, change destinations without touching nginx.

Ready to skip the server edit?

Generate your nginx config here, then use Flyn for everything else: short links you can edit without server access, click counts on every link, QR codes, and analytics breakdowns plus custom domains on Pro.

Start free, no credit card Read the API Docs