Hey there! As someone who’s walked plenty of NGINX newbies through server migrations, this is a really solid strategy—let me show you exactly how to make this work.

The core idea is simple: Configure NGINX to first send every request to your new server. If the new server returns a 404 (meaning the resource doesn’t exist there yet), NGINX will automatically fall back to forwarding the request to your old server.

Working Config Example #

Here’s a complete, commented NGINX config that implements this logic:

http {
    # Define your upstream server groups (easy to update later if you add more nodes)
    upstream new_server {
        server new.yourdomain.com:80; # Replace with your new server's address/port
    }

    upstream old_server {
        server old.yourdomain.com:80; # Replace with your old server's address/port
    }

    server {
        listen 80;
        server_name yourdomain.com www.yourdomain.com; # Your actual domain(s)

        # Primary location: Send all traffic first to the new server
        location / {
            proxy_pass http://new_server;
            
            # Pass important request headers to the backend so it behaves correctly
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            # Critical line: If new server returns 404, route to the fallback location
            error_page 404 @fallback_to_old;
        }

        # Named fallback location: Handle requests that failed on the new server
        location @fallback_to_old {
            proxy_pass http://old_server;
            
            # Same header settings as above to keep consistency
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            # Optional: If old server also returns 404, serve a custom 404 page
            # error_page 404 /custom_404.html;
        }
    }
}

Key Notes for Success #

• Test thoroughly: After setting this up, test a path you know exists only on the old server—you should see it load without issues. Also test a path that exists on both to confirm the new server takes priority.
• Handle other errors (optional): If you want to fall back to the old server for other errors (like 500, 502), update the error_page line to include those codes:

  error_page 404 500 502 503 504 @fallback_to_old;
  

• Avoid caching 404s: Make sure your browser or any CDN isn’t caching 404 responses during migration—this could cause users to see missing content when it’s actually available on the old server.
• Verify connectivity: Double-check that your NGINX server can reach both the new and old servers (no firewall blocks, correct ports open).

内容的提问来源于stack exchange，提问作者dkimot