Setting Up Redirects with Nginx on VPS: A Complete Configuration Guide

Redirects are a fundamental component of any well-managed web infrastructure. Whether you're restructuring your website, migrating to a new domain, or temporarily routing traffic during maintenance, properly configured redirects protect your SEO rankings, preserve link equity, and ensure visitors always land on the right page. Nginx — one of the world's most powerful and widely used web servers — makes implementing redirects both flexible and efficient.

This comprehensive guide walks you through everything you need to know about configuring HTTP redirects using Nginx on a VPS Hosting environment, from understanding redirect types to testing and verifying your setup in production.

1. Understanding HTTP Redirects

Before touching a single configuration file, it's important to understand what redirects actually do and why choosing the correct type matters — especially for SEO.

An HTTP redirect is a server response that instructs the client (typically a web browser or crawler) to navigate to a different URL than the one originally requested. The server communicates this instruction using a 3xx HTTP status code, and the specific code you choose carries significant implications for both user experience and search engine behavior.

The Most Common Redirect Types

#### 301 Permanent Redirect

The 301 redirect is the most SEO-critical redirect type. It signals to search engines that a resource has moved permanently to a new URL, transferring the original page's accumulated link equity (also called "link juice") to the destination. Use this when permanently renaming URLs, consolidating duplicate content, or migrating to a new domain.

#### 302 Temporary Redirect

A 302 redirect tells browsers and crawlers that the move is temporary and the original URL will eventually be restored. Because search engines interpret this as transient, they do not transfer link equity to the destination URL. Use this for A/B testing, temporary maintenance pages, or short-term promotional redirects.

#### 307 Temporary Redirect

The 307 redirect behaves similarly to a 302 but with one critical difference: it explicitly preserves the original HTTP request method. If a client sends a POST request to a URL that returns a 307, the client must repeat the POST to the new URL rather than defaulting to a GET. This is important for API endpoints and form submissions.

#### 308 Permanent Redirect

The 308 redirect is the permanent counterpart to 307 — it signals a permanent move while also preserving the HTTP request method. It's less commonly used than 301 but valuable in API-heavy environments.

2. Prerequisites: Accessing Your VPS via SSH

To configure Nginx redirects, you need command-line access to your server. If you're running a Linux-based VPS Hosting environment, this means connecting via SSH.

Step 1: Open Your Terminal and Connect

On Linux or macOS, open your terminal. On Windows, use a client like PuTTY or the built-in Windows Terminal with OpenSSH support.

ssh username@your_server_ip

Replace username with your actual system user (e.g., root or a sudo-enabled user) and your_server_ip with your VPS's public IP address.

Example:

ssh admin@203.0.113.45

Once connected, confirm that Nginx is installed and running:

sudo systemctl status nginx

You should see output indicating the service is active (running). If Nginx isn't installed yet, you can install it with:

# On Ubuntu/Debian
sudo apt update && sudo apt install nginx -y

# On CentOS/RHEL/AlmaLinux
sudo dnf install nginx -y

3. Locating and Understanding Nginx Configuration Files

Nginx uses a hierarchical configuration structure. Understanding where files live is essential before making any changes.

Default Configuration Paths

On Ubuntu/Debian systems, the recommended approach is to create individual configuration files in /etc/nginx/sites-available/ and then enable them by creating symbolic links in /etc/nginx/sites-enabled/.

On CentOS/RHEL/AlmaLinux systems, configurations typically live in /etc/nginx/conf.d/.

Opening a Configuration File

To edit the configuration for a specific domain:

sudo nano /etc/nginx/sites-available/example.com

If the file doesn't exist yet, this command will create it. You can also use vim or any other text editor you prefer.

4. Configuring Redirects in Nginx

Nginx handles redirects primarily through two directives: return and rewrite. The return directive is simpler, faster, and recommended for most redirect scenarios. The rewrite directive offers more power for complex pattern-based redirections.

Method 1: Using the return Directive (Recommended)

The return directive stops processing and immediately returns the specified HTTP status code and URL to the client. It's the most efficient approach for straightforward redirects.

#### Setting Up a 301 Permanent Redirect (Single URL)

server {
    listen 80;
    server_name example.com www.example.com;

    location /old-page {
        return 301 https://example.com/new-page;
    }
}

In this configuration, any request to http://example.com/old-page will be permanently redirected to https://example.com/new-page. Search engines will update their indexes to reflect the new URL and transfer link equity accordingly.

#### Setting Up a 302 Temporary Redirect

server {
    listen 80;
    server_name example.com;

    # Temporary redirect during maintenance
    location /promo-page {
        return 302 https://example.com/temporary-landing;
    }
}

This configuration temporarily redirects visitors from /promo-page to /temporary-landing without affecting SEO signals on the original URL.

#### Redirecting an Entire Domain (Non-WWW to WWW)

A very common use case is enforcing a canonical domain — for example, redirecting all http://example.com traffic to https://www.example.com:

server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    # SSL configuration here
    # ...
}

The $request_uri variable preserves the original path and query string, so http://example.com/blog/post-1?ref=newsletter correctly redirects to https://www.example.com/blog/post-1?ref=newsletter.

#### Redirecting HTTP to HTTPS (SSL Enforcement)

Enforcing HTTPS is a security best practice and a confirmed Google ranking signal. Once you have an SSL Certificate installed on your server, configure the redirect as follows:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Your site configuration continues here
    root /var/www/example.com/html;
    index index.html index.php;
}

This configuration catches all HTTP traffic on port 80 and issues a 301 redirect to the HTTPS equivalent, ensuring all visitors and crawlers use the secure version of your site.

#### Redirecting an Entire Old Domain to a New Domain

When migrating your website to a completely new domain, use the following pattern:

server {
    listen 80;
    listen 443 ssl;
    server_name old-domain.com www.old-domain.com;

    ssl_certificate /etc/letsencrypt/live/old-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old-domain.com/privkey.pem;

    return 301 https://new-domain.com$request_uri;
}

This preserves the full URL path during the domain migration, which is critical for maintaining your SEO rankings. If you need to register a new domain for your project, AlexHost offers affordable Domain Registration services.

Method 2: Using the rewrite Directive (Pattern-Based Redirects)

The rewrite directive uses regular expressions to match and transform URLs. It's more powerful but also more resource-intensive than return. Use it when you need to redirect multiple URL patterns with a single rule.

#### Basic rewrite Syntax

rewrite regex replacement [flag];

Flags:

last — Stops processing current rewrite directives and starts a new location search
break — Stops processing rewrite directives in the current block
redirect — Returns a 302 temporary redirect
permanent — Returns a 301 permanent redirect

#### Redirecting URLs with a Pattern
Suppose you're restructuring your blog and need to redirect all URLs from /blog/YYYY/MM/post-slug to /articles/post-slug:
server {
    listen 80;
    server_name example.com;

    rewrite ^/blog/[0-9]{4}/[0-9]{2}/(.*)$ /articles/$1 permanent;
}
This single rule handles the entire blog URL restructure, capturing the post slug and inserting it into the new URL pattern.
#### Redirecting Multiple Specific URLs
For a small number of specific URL changes, using multiple return directives in separate location blocks is cleaner and more performant:
server {
    listen 80;
    server_name example.com;

    location = /about-us {
        return 301 /about;
    }

    location = /services/web-design {
        return 301 /services/web-development;
    }

    location = /contact-form {
        return 301 /contact;
    }
}
The = modifier in location performs an exact match, which is the fastest matching type in Nginx.
Method 3: Redirecting Based on Query Strings
Nginx doesn't natively match query strings in location blocks, but you can use the $arg_ variable or if directives for query-string-based redirects:
server {
    listen 80;
    server_name example.com;

    location /page {
        if ($arg_id = "123") {
            return 301 /new-page-123;
        }
        if ($arg_id = "456") {
            return 301 /new-page-456;
        }
    }
}
> Note: While if directives work for simple cases, they can cause unexpected behavior in complex configurations. The Nginx community often refers to this as the "if is evil" problem. Use with caution and test thoroughly.
5. Advanced Redirect Scenarios
Redirecting a Subdirectory to Another Domain
server {
    listen 80;
    server_name example.com;

    location /shop/ {
        return 301 https://shop.example.com$request_uri;
    }
}
Removing Trailing Slashes
Inconsistent trailing slashes can create duplicate content issues. To canonicalize URLs by removing trailing slashes:
server {
    listen 80;
    server_name example.com;

    rewrite ^/(.*)/$ /$1 permanent;
}
Adding Trailing Slashes to Directory URLs
Conversely, if your CMS or application requires trailing slashes:
server {
    listen 80;
    server_name example.com;

    location ~ ^(/[^.]*[^/])$ {
        return 301 $1/;
    }
}
Geo-Based Redirects Using GeoIP
For websites serving multiple regions, you can redirect users based on their geographic location using the ngx_http_geoip_module:
geoip_country /usr/share/GeoIP/GeoIP.dat;

server {
    listen 80;
    server_name example.com;

    if ($geoip_country_code = "DE") {
        return 302 https://de.example.com$request_uri;
    }

    if ($geoip_country_code = "FR") {
        return 302 https://fr.example.com$request_uri;
    }
}
6. Testing Your Nginx Configuration
Never apply changes to a production server without testing first. A syntax error in your Nginx configuration can take your entire website offline.
Step 1: Validate the Configuration Syntax
sudo nginx -t
Expected output for a valid configuration:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
If you see errors, Nginx will report the specific file and line number where the problem was detected, making debugging straightforward.
Step 2: Reload Nginx to Apply Changes
Once the configuration test passes, reload Nginx gracefully (without dropping active connections):
sudo systemctl reload nginx
Alternatively, for a full restart (which briefly interrupts active connections):
sudo systemctl restart nginx
For most redirect changes, reload is sufficient and preferred.
7. Verifying That Your Redirects Work Correctly
After applying your configuration, verify that redirects behave exactly as intended before considering the task complete.
Method 1: Browser Testing
Open your browser and navigate to the old URL. Observe whether you're correctly redirected to the new destination. For more detail, open Developer Tools (F12), navigate to the Network tab, and reload the page. You'll see the full redirect chain, including the status codes returned at each step.
Method 2: Using curl from the Command Line
The curl command is the most reliable way to test redirects without browser caching interfering:
curl -I http://example.com/old-page
The -I flag fetches only the HTTP response headers. Look for the Location header and the status code in the response:
HTTP/1.1 301 Moved Permanently
Server: nginx/1.24.0
Date: Mon, 01 Jan 2024 12:00:00 GMT
Content-Type: text/html
Location: https://example.com/new-page
Connection: keep-alive
To follow the entire redirect chain automatically:
curl -IL http://example.com/old-page
The -L flag instructs curl to follow redirects, and combined with -I, it shows the headers at each step of the chain.
Method 3: Online Redirect Checker Tools
Several free online tools can visualize your redirect chains and identify issues like redirect loops or excessive redirect hops:

Redirect Checker (redirect-checker.org)
httpstatus.io
Screaming Frog SEO Spider (desktop application, free up to 500 URLs)

Checking for Redirect Loops
A redirect loop occurs when URL A redirects to URL B, which redirects back to URL A (or through a longer chain that eventually loops back). This causes browsers to display an error like *"ERR_TOO_MANY_REDIRECTS"*.
To detect loops with curl:
curl -IL --max-redirs 10 http://example.com/old-page
If curl hits the maximum redirect limit, you have a loop. Review your configuration carefully to ensure no circular redirect paths exist.
8. Common Redirect Mistakes and How to Avoid Them
Mistake 1: Using 302 When You Mean 301
This is the most common SEO mistake with redirects. If a URL change is permanent, always use 301. Using 302 by accident means search engines won't transfer link equity and will continue indexing the old URL.
Mistake 2: Redirect Chains
Avoid chaining redirects unnecessarily (e.g., A → B → C → D). Each additional hop adds latency and dilutes the SEO value passed through the chain. Audit your redirects regularly and update them to point directly to the final destination.
Mistake 3: Not Preserving Query Strings
When redirecting entire domains or directories, always include $request_uri or $query_string in your redirect target to avoid stripping important URL parameters.
Incorrect:
return 301 https://new-domain.com;
Correct:
return 301 https://new-domain.com$request_uri;
Mistake 4: Forgetting to Handle Both HTTP and HTTPS
If your site serves both HTTP and HTTPS, ensure your redirect rules account for both protocols, or you may end up with inconsistent behavior.
Mistake 5: Not Testing After Changes
Always run sudo nginx -t before reloading, and always verify redirects with curl after applying changes. A few seconds of testing can prevent hours of troubleshooting.
9. Nginx Redirects vs. .htaccess Redirects
If you're migrating from an Apache-based hosting environment to Nginx on a VPS, you may be accustomed to managing redirects via .htaccess files. It's important to understand that Nginx does not support .htaccess files. All redirect logic must be placed directly in Nginx server block configuration files.
This is actually an advantage: Nginx doesn't need to read .htaccess files on every request, which contributes to its superior performance compared to Apache in many scenarios.
If you prefer a managed control panel experience for your VPS, AlexHost offers VPS with cPanel and a range of VPS Control Panels that provide graphical interfaces for managing redirects and other server configurations without editing configuration files directly.
10. SEO Best Practices for Nginx Redirects
Properly configured redirects are a critical component of technical SEO. Here are the key principles to follow:
Use 301 Redirects for Permanent Changes
Any time you permanently change a URL — whether renaming a page, restructuring your site architecture, or migrating domains — use a 301 redirect. This ensures Google and other search engines update their indexes and transfer the ranking power of the old URL to the new one.
Minimize Redirect Hops
Google's crawlers follow redirect chains, but each hop consumes crawl budget and slightly dilutes PageRank. Keep your redirect chains as short as possible — ideally a single hop from old URL to final destination.
Update Internal Links
Redirects are a safety net, not a substitute for clean internal linking. After implementing redirects, update your internal links to point directly to the new URLs. This reduces server load and ensures crawlers spend their budget on content rather than following redirects.
Submit an Updated Sitemap
After significant URL changes, update your XML sitemap to reflect the new URLs and resubmit it through Google Search Console. This accelerates the re-indexing process.
Monitor with Google Search Console
After implementing redirects, monitor Google Search Console for crawl errors, coverage issues, and any unexpected drops in impressions or clicks. Redirect issues often surface within days of implementation.
Conclusion
Mastering Nginx redirect configuration is an essential skill for any system administrator or website owner running a VPS. Whether you're enforcing HTTPS, consolidating duplicate URLs, migrating to a new domain, or restructuring your site architecture, Nginx provides the tools to handle every scenario efficiently and reliably.
The key takeaways from this guide:

Choose the right redirect type: 301 for permanent moves (SEO-critical), 302/307 for temporary moves
Use the return directive for simple redirects — it's faster and cleaner than rewrite

If you're looking for a reliable, high-performance environment to run your Nginx server, explore AlexHost's VPS Hosting plans — built for speed, security, and full root access so you have complete control over your server configuration.