How to Redirect an IP Address to a Domain in Nginx

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

To redirect visitors who enter your server’s IP address, point the domain’s DNS records to that IP, then add a dedicated Nginx server block that returns a permanent redirect to the domain. Use $request_uri when the original path and query string must survive the redirect. Configure HTTPS separately, because TLS certificate selection occurs before Nginx can process the HTTP Host header.

What an IP-to-domain redirect actually does

DNS and Nginx perform different jobs. An A record maps a hostname such as example.com to an IPv4 address, while an AAAA record maps it to an IPv6 address. DNS does not redirect an HTTP request. After the browser resolves the hostname, it connects to the resulting address and sends an HTTP request.

#	Preview	Product	Price
1		NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing	$37.53	Buy on Amazon
2		NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance	$23.69	Buy on Amazon
3		NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server	$12.31	Buy on Amazon
4		NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life...	$51.99	Buy on Amazon
5		NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing	$26.99	Buy on Amazon

If a visitor types http://203.0.113.10/docs/install?lang=en, the HTTP Host header normally contains 203.0.113.10. Nginx can match that host in a dedicated server block and immediately respond with a Location header such as https://example.com/docs/install?lang=en. The browser then makes a second request to the canonical hostname.

The redirect changes the URL the visitor sees; it does not move the server, change DNS, or make the IP address an alias for the domain. Keep your application or reverse-proxy configuration in a separate server block whose server_name contains the real domain.

#1 Best Overall

Sale

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$37.53

Buy on Amazon

Prerequisites and decisions

• You need administrative access to the Nginx host and permission to edit its configuration.
• The domain’s A record must point to the server’s public IPv4 address. If the site is reachable over IPv6, its AAAA record must point to the correct public IPv6 address as well.
• TCP port 80 must be reachable for an HTTP redirect. TCP port 443 must be reachable for the canonical HTTPS site.
• Decide whether the redirect should preserve every path and query string or send all wrong-host requests to the home page.
• Decide whether to match one known IP exactly or catch every unmatched HTTP host. An exact match is narrower; a default_server catch-all also handles stale DNS names and arbitrary Host headers that reach this listener.

Choose the redirect pattern

Use Nginx’s return directive for a single host-wide redirect. It is immediate, easy to read, and valid in server and location contexts. A regular-expression rewrite is unnecessary when the same destination applies to every request.

Step 1: Point DNS at the server

At your DNS provider, create or update the records used by the site:

• A: example.com (and usually www.example.com, if used) to the server’s public IPv4 address.
• AAAA: the same hostnames to the server’s public IPv6 address, only if Nginx and the firewall are configured for IPv6.

Do not point the domain at a private address such as 192.168.1.10 unless the service is intentionally private and clients can route to it. DNS changes can be cached according to the records’ TTL, so test from a resolver that returns the new address before diagnosing Nginx.

Step 2: Add an exact IP redirect server

Use this pattern when you want a request whose Host value is one specific IPv4 address to go to the canonical domain:

server {
    listen 80;
    server_name 203.0.113.10;

    return 301 https://example.com$request_uri;
}

Replace 203.0.113.10 with the address visitors use and replace example.com with the canonical hostname. The 301 status means the redirect is permanent. The variable $request_uri contains the original URI, including its path and arguments, so a request for /docs/install?lang=en becomes https://example.com/docs/install?lang=en.

Leave the application in a different block, for example:

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

    # Existing root, proxy_pass, locations, and application settings go here.
}

Separating the redirect block prevents the IP request from accidentally reaching the application under the wrong host. It also makes later changes to the application server block less likely to break the redirect.

Rank #2

Sale

NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance

$23.69

Buy on Amazon

Step 3: Catch unmatched HTTP hosts when appropriate

If you want every HTTP request that does not match another virtual server to go to the canonical hostname, make the redirect listener the default server:

server {
    listen 80 default_server;
    server_name _;

    return 301 https://example.com$request_uri;
}

The underscore is a conventional non-matching name; the important behavior comes from default_server. Nginx uses this block when no other server_name on that address and port matches the request.

A catch-all can be useful on a single-site server, but it is broader than an exact IP match. On a multi-tenant server, an overly broad catch-all can redirect mistyped or unrelated hostnames to the wrong site. Define the intended domain blocks first and use the fallback only when that broad behavior is acceptable.

Preserve paths and query strings correctly

Use $request_uri when a visitor should arrive at the equivalent page on the canonical domain:

return 301 https://example.com$request_uri;

Unlike a bare hostname, this destination carries the original path and query arguments. It is the appropriate choice for bookmarks, deep links, documentation pages, login callbacks, and URLs containing tracking or filter parameters.

To send all wrong-host requests to the home page instead, omit the variable:

return 301 https://example.com;

With that form, both /old-page and /old-page?x=1 end at the domain root. Choose it deliberately: dropping the path can be correct for a retired site, but it can also break links and hide missing-page problems.

Rank #3

Sale

NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server

$12.31

Buy on Amazon

Do not add a second question mark or manually concatenate query parameters after $request_uri. The variable already includes the original arguments.

Step 4: Configure HTTPS separately

An HTTP redirect can send the browser to HTTPS, but it cannot provide a valid certificate for a literal IP unless the certificate specifically contains that IP. During a TLS connection, the browser validates the certificate before Nginx receives the HTTP request and its Host header. Server Name Indication (SNI) lets Nginx choose among certificates when the client requests a hostname; a browser requesting an IP may instead see a certificate mismatch or the listener’s default certificate.

Configure the canonical domain on an HTTPS server block with a certificate covering that domain:

server {
    listen 443 ssl;
    server_name example.com;

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

    # Application or proxy configuration belongs here.
}

Add www.example.com to server_name and use a certificate containing that name if it is also a valid hostname. The certificate paths above are an example layout; use the paths produced by your certificate-management process.

For ordinary visitors, the common flow is:

1. The browser requests http://example.com and receives an HTTP-to-HTTPS redirect from the domain’s port-80 server block.
2. The browser requests https://example.com and completes TLS using the domain certificate.
3. Nginx serves or proxies the application from the HTTPS block.

If someone enters https://203.0.113.10 directly, the browser may stop on a certificate warning before any HTTP redirect can run. The reliable user-facing URL is therefore the domain’s HTTPS address, not an IP-based HTTPS entry point.

Exact IP matching versus a default catch-all

If both patterns could match, Nginx’s virtual-server selection rules determine which block handles the request. Keep the canonical domain block and any other hosted domains clearly defined, then mark only the intended fallback listener as default_server.

return versus regex-based rewrite

For this use case, a single return 301 is generally easier to audit than a regex-only rewrite. Test with a temporary status if you are still deciding the destination, because browsers and intermediaries may cache a permanent redirect.

Rank #4

NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life examples

$51.99

Buy on Amazon

IPv6 and multiple addresses

Test IPv4 and IPv6 independently. A browser may prefer IPv6 when an AAAA record exists, so a working IPv4 redirect does not prove that the IPv6 path is configured.

Ensure Nginx listens on IPv6 as well as IPv4 when required. A listener commonly includes both an IPv4 wildcard and an IPv6 wildcard, for example:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;

    return 301 https://example.com$request_uri;
}

If you use exact matching instead of a catch-all, include the IPv6 address as an intended host value and verify how your Nginx version parses the literal form. The simplest operational approach for a single-site server is often a dual-stack default catch-all, while a shared server may need explicit per-site blocks and a carefully chosen fallback.

Validate and reload Nginx safely

1. Save the configuration in the location loaded by your Nginx installation, such as the enabled site file used by the host.
2. Run the syntax check: sudo nginx -t. Do not reload if it reports an error.
3. Reload Nginx with the host’s normal service manager, for example sudo systemctl reload nginx. A reload applies the new configuration without deliberately stopping existing workers.
4. Request an IP URL containing a path and query string, such as http://203.0.113.10/path?x=1.
5. Inspect the response headers and confirm that Location is exactly https://example.com/path?x=1 when path preservation is intended.
6. Request the canonical HTTPS URL and confirm that it serves the intended application rather than redirecting back to the IP or looping between HTTP and HTTPS.
7. If an AAAA record exists, test through IPv6 separately and confirm the same result.

A command-line check can display the redirect without following it:

curl -I http://203.0.113.10/path?x=1

Look for a 301 status and a single Location header. To test a specific virtual host before public DNS has updated, send the intended Host header to the address:

curl -I -H 'Host: 203.0.113.10' http://203.0.113.10/path?x=1

Troubleshooting common failures

The IP request serves the application instead of redirecting

• Check that the request reaches the same address and port covered by the redirect block.
• Confirm that the block is loaded and that nginx -t passes.
• On a shared listener, inspect which block is the default_server. An exact server_name match should be used when the request’s Host value is the literal IP.
• Make sure another proxy, load balancer, or CDN is not terminating the request before it reaches this Nginx instance.

The redirect loses the path or query string

Check the return target. https://example.com$request_uri preserves both; https://example.com intentionally sends every request to the root. Also verify that an earlier proxy or application redirect is not replacing the URL after Nginx responds.

The browser reports a certificate mismatch

This is expected when a user opens an HTTPS IP URL and the certificate does not contain that IP. Use the domain’s HTTPS URL and install a certificate covering every hostname you publish. An HTTP IP redirect cannot repair a TLS validation failure that occurs before the HTTP request exists.

Best Value

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$26.99

Buy on Amazon

Nginx reports a duplicate default server

Only one server block can be the default for a given address and port. Remove default_server from competing blocks or choose which site should handle unmatched hosts. Keep exact domain blocks separate from the one deliberate fallback.

The redirect loops

• Check that the HTTPS server block serves the application and does not redirect the canonical HTTPS URL back to HTTP.
• Check reverse-proxy headers and any upstream application force-HTTPS setting.
• Request the final URL directly and inspect each Location header with curl -I until the first unexpected hop is identified.

IPv4 works but IPv6 does not

Verify the AAAA record, IPv6 firewall rules, Nginx’s listen [::]:80 and listen [::]:443 directives where needed, and the IPv6 server address itself. A stale or incorrect AAAA record can send browsers to a different host even when the A record is correct.

Operational and security considerations

A redirect does not block direct access to the IP; it tells HTTP clients where to go. Automated clients can ignore it, and services that connect by IP may continue doing so. If the goal is access control rather than canonical URLs, use firewall rules, authentication, or an explicit server policy instead of relying on a redirect.

Keep the canonical hostname consistent in application-generated links, cookies, callback URLs, and proxy configuration. Otherwise, users may see a correct first redirect followed by links that send them back to the IP.

Use a permanent status only after verifying the destination. Browsers and intermediary caches can retain a 301, making an incorrect target persist after you fix the configuration. A temporary 302 is safer during a brief validation period; change to 301 once the final behavior is confirmed.

Reference configurations

Exact IPv4 redirect with path preservation

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

Single-site HTTP catch-all to HTTPS

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://example.com$request_uri;
}

Catch-all that always sends visitors to the home page

server {
    listen 80 default_server;
    server_name _;
    return 301 https://example.com;
}

Canonical HTTPS application server

server {
    listen 443 ssl;
    server_name example.com;

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

    # root, proxy_pass, or other application directives
}

Final checklist

• The A record points to the intended public IPv4 address.
• The AAAA record, if present, points to an IPv6 address served by this host.
• The IP redirect is separate from the canonical application server block.
• The listener is exact-match or default_server by deliberate choice.
• $request_uri is present when paths and query strings must be retained.
• The canonical HTTPS block has a certificate covering the requested domain.
• nginx -t passes before the reload.
• An IP request returns the expected Location header, and the final HTTPS URL does not loop.

The durable pattern is therefore simple: DNS directs the domain to the server, a dedicated HTTP Nginx block handles requests addressed to the IP or other unmatched hosts, and return 301 sends them to the canonical domain. Add $request_uri for deep-link preservation, and treat HTTPS as a separate certificate and listener configuration rather than as an extension of the HTTP redirect.

Quick Recap

SaleBestseller No. 1

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$37.53

SaleBestseller No. 2

NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance

$23.69

SaleBestseller No. 3

NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server

$12.31

Bestseller No. 4

NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life examples

$51.99

Bestseller No. 5

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$26.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.