How to Fix an NGINX Reverse Proxy Redirecting to the Wrong Domain

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

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

Find the first incorrect Location header before changing configuration. That response identifies the component producing the bad URL. If NGINX selected the wrong virtual server, fix server_name and the default-server arrangement. If the application returned its internal hostname or port, pass the public host and scheme in forwarded headers and rewrite the upstream Location with proxy_redirect. If NGINX generated the redirect, review server_name_in_redirect and absolute_redirect. Intentional www/non-www policy belongs in separate server blocks with an explicit return 301.

What a wrong-domain redirect usually means

A reverse proxy can preserve the public URL while forwarding the request to an application on another host and port. A redirect becomes confusing when one layer builds an absolute URL from information that is valid internally but not publicly reachable. Typical symptoms include a login redirect to localhost, a backend name such as app_backend, an internal IP address, an unexpected port, or a loop between www and non-www names.

#	Preview	Product	Price
1		Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes	$14.98	Buy on Amazon
2		Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled...	$7.98	Buy on Amazon

There are three possible redirect producers:

• Virtual-server selection: NGINX receives a Host value that does not match the intended server_name, so an earlier or default server block handles the request.
• The upstream application: the application sees an internal host, scheme, or port and emits an absolute Location header based on that information.
• NGINX itself: a rewrite, return directive, or core redirect constructs an absolute URL using its configured server name or request context.

The correct fix depends on which of these produced the first bad URL. Changing all three layers at once makes the result difficult to verify and can create a redirect loop.

Diagnose the redirect chain before editing NGINX

1. Capture every response and Location header

Run the request against the public hostname, not the backend address:

#1 Best Overall

Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes

• B5 Recipe Book: This hardcover blank recipe book measures 10''×7.3'', containing 150 blank pages, comes with 1 sheet of DIY category stickers, perfect for writing down your own recipes and organizing them in one place.
• Practical Layout - 5 pages of conversion charts show you everything you'll ever need to know in the kitchen. The table of contents will help organize your personal favorite recipes. A back pocket is designed for loose items.
• Easy to Use - This blank cookbook is made of high-quality paper with a beautiful hardcover for long-term use. The sturdy gold double-wire spiral binding makes writing easier and page turning smoother.
• Make Your Own Recipes - This blank cookbook has up to 150 blank pages for you to write in your own recipes, with plenty of space to record ingredients and instructions. You can write down all the special tips for your family members.
• Thoughtful Gift - A personalized recipe book makes a thoughtful gift for your children or newlyweds, and a great gift for housewarming, weddings, bridal showers, anniversaries, or any other occasion.

$14.98

Buy on Amazon

curl -I -L https://public.example/path

The -I option requests headers, while -L follows each redirect. Record every status code and every Location value in order. The first response that introduces the wrong hostname, scheme, or port identifies the emitting layer. For example, if the first response from the public host says Location: http://backend:8080/login, the upstream is leaking its internal address. If the first response already names an unrelated virtual host, investigate server selection before changing proxy headers.

For a single hop, omit -L so you can inspect only the initial response:

curl -I https://public.example/path

Repeat the test with the exact path that fails, such as a login callback or a trailing-slash URL. Redirect behavior can differ by location block and by whether the application creates the response.

2. Inspect the loaded configuration, not just an edited file

Use:

nginx -T

This prints the complete configuration that the running NGINX instance can load, including files pulled in with include. Locate the relevant server block and verify its listen address, TLS settings, server_name, and proxy location. A syntactically correct file has no effect if it is not included by the active configuration or if another server block catches the request first.

3. Establish the public request context

Write down the values the browser should retain:

• Canonical hostname, such as public.example or www.example.com.
• Public scheme, usually https.
• Public port, if it is not the scheme’s default port.
• Whether the policy is to preserve the requested host or redirect every request to one canonical host.

These decisions determine whether you should pass the original host through, rewrite an upstream response, or deliberately return a canonical redirect.

Fix virtual-server selection and default-server mistakes

NGINX matches the request’s Host value against server_name. If no name matches, the request is handled by the default server for the listen address and port. The default server might contain an old domain, a catch-all redirect, or a certificate and redirect policy intended for another site.

Check the relevant listen sockets

In nginx -T, inspect every block listening on the address and port involved, including both HTTP and HTTPS. Confirm that the intended block contains the exact public name:

server {
    listen 443 ssl;
    server_name public.example;
    ...
}

Names are evaluated separately for each listen socket. A correct HTTPS block does not correct an HTTP block that redirects to the wrong domain, and a correct IPv4 listener does not automatically describe a separate IPv6 listener.

Look for an earlier or explicit default server

For a given address and port, the first matching server can become the default unless another block uses the default_server parameter. Search the full output of nginx -T for default_server, catch-all names such as _, and broad redirects. Remove an unintended default designation or give the default block a safe, deliberate response. Do not assume the file you edited is loaded first; included files determine the final order.

Test the Host that NGINX actually receives

When a load balancer or another proxy sits in front of NGINX, it may replace the browser’s Host header. Test the edge address with an explicit Host value where appropriate, then compare it with a direct request to the NGINX listener. A mismatch indicates that the upstream proxy or TLS terminator needs its own host-preservation setting; changing the application alone will not correct server selection.

Make the upstream see the public host and scheme

By default, NGINX sets the proxied request’s Host field to the value of $proxy_host. That is commonly the hostname from proxy_pass, not the domain in the browser’s address bar. An application that uses Host to build absolute links or redirects can therefore publish its internal service name.

In the proxy location, override that behavior:

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_pass http://app_backend;
}

$host is the request host normalized by NGINX and is generally preferable when the application should use the public name. X-Forwarded-Host is useful for frameworks that read that header instead of Host. X-Forwarded-Proto tells the application that the browser used HTTPS even when NGINX talks HTTP to the backend. X-Forwarded-For preserves the client address chain.

Configure the application’s trusted-proxy behavior

Forwarded headers only help if the framework is configured to trust them from NGINX. Many frameworks otherwise ignore X-Forwarded-Proto and conclude that the request is HTTP, generating an HTTPS redirect on every request. Configure the application’s trusted proxy or proxy-awareness setting according to that framework’s documentation, and restrict trust to the proxy network you control. Do not blindly trust client-supplied forwarding headers when NGINX is reachable directly from the internet.

Preserve a non-standard public port

If users access the site through a public port that is not implied by the scheme, $host alone does not include that port. Ensure the application receives the public port through the forwarding mechanism it supports, or rewrite the absolute upstream URL with the correct public port. Test the resulting Location header rather than assuming that a successful page response proves the port is correct.

Rewrite backend Location and Refresh headers with proxy_redirect

If the upstream still returns an absolute internal URL, use proxy_redirect in the same proxy location. This directive changes the Location and Refresh response headers from a proxied server.

Rewrite an internal URL to the current public host

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://app_backend;
    proxy_redirect http://backend:8080/ /;
}

The first argument is the exact internal prefix emitted by the application. The replacement / makes the browser reuse the public scheme and host that it already used. This is suitable when NGINX is the public endpoint and the upstream path layout is unchanged.

Rank #2

Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled Pages with Memo Pocket - Write In Your Own Recipes & Meal Planning Notebook

• Create a Culinary Legacy: The Pipilo Press Blank Family Cookbook Recipe Binder offers a timeless platform for chronicling beloved recipes. With its hardcover and spiral binding, this recipe book to write in your own recipes ensures durability and ease of use for generations
• Thoughtful Gifting Choice: This book for writing recipes is an ideal present for various occasions, adding a personal touch to celebrations. Its elegant design makes it perfect for moms cookbook DIY projects or anyone passionate about preserving family traditions
• Durable Design Features: Constructed with a 300gsm cardstock cover and matte lamination, this cookbook you can write in ensures longevity. Its spiral-bound format provides convenient access to pages, making it a practical tool for everyday use
• Organized Recipe Storage: The included memo pocket offers a space to store handwritten notes or recipe cards, enhancing its functionality. This feature transforms the recipe book for moms into a sentimental family memento
• Ample Writing Space: Measuring 6.5 x 8.2 inches, this blank spiral family recipe cookbook offers plenty of room for detailed notes. It is perfect for jotting down ingredients, preparation methods, and serving suggestions for a complete culinary record

$7.98

Buy on Amazon

Rewrite to an explicit canonical origin

proxy_redirect http://backend:8080/ https://public.example/;

Use an explicit replacement when the desired public origin must be fixed, including its scheme or port. You can use variables such as $host in the replacement when the policy is to preserve the requested host:

proxy_redirect http://backend:8080/ https://$host/;

Match the upstream URL exactly enough to avoid accidental substitutions. If the application emits several internal origins, add a focused rule for each one or correct the application’s base URL so that it stops generating the wrong value at its source.

Know what proxy_redirect does not change

proxy_redirect changes response headers; it does not rewrite hyperlinks in an HTML body, JavaScript-generated URLs, cookies, or an API payload. If only the redirect header contains the internal name, it is the right tool. If page content also exposes that name, fix the application’s public base URL or its generated asset configuration separately.

Control redirects generated by NGINX itself

Not every absolute redirect comes from the application. NGINX can generate redirects for rewrites, directory normalization, and other core behavior. Two directives determine how NGINX chooses the host and whether it emits an absolute URL.

server_name_in_redirect

server_name_in_redirect controls whether an absolute redirect uses the primary server_name of the selected server or the Host value from the request. If NGINX is using an unintended primary name, correct the server block and its names first. If the request host should be retained, review this directive and test the resulting header with curl.

absolute_redirect

absolute_redirect controls whether NGINX emits absolute redirects. When relative redirects are acceptable for your deployment, disabling absolute redirects can prevent NGINX from inventing a hostname; however, it does not fix an application that emits an absolute internal URL. Treat it as a deliberate URL-format decision and verify clients, caches, and any external integrations that consume the redirect.

Separate NGINX redirects from application redirects

A response generated by a return or rewrite in the matched server block will appear before the request reaches the upstream. If the first response already contains the wrong host, inspect those directives and the values of server_name_in_redirect and absolute_redirect instead of adding more proxy-header rules.

Implement intentional www/non-www canonicalization

Canonicalization is different from preserving whichever host the visitor requested. If the site policy is to use one hostname, express it with dedicated server blocks and an explicit redirect. For example:

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

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

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://app_backend;
    }
}

The first block has one job: redirect the old hostname while preserving the path and query string through $request_uri. The second block serves the canonical HTTPS host. Add an equivalent redirect block for the non-canonical HTTPS name if it can receive traffic, and ensure its certificate covers that name so the TLS handshake succeeds before the redirect is sent.

Do not use a broad if-based redirect inside a proxy location as a substitute for separate servers. NGINX’s rewrite guidance describes that approach as “a wrong, cumbersome, and ineffective way”; the recommended design is a separate server for the alternate name. Keeping canonicalization outside the application also prevents the application and NGINX from issuing opposing redirects.

Choose the fix by redirect origin

Apply changes safely and retest

1. Save a copy of the working configuration before editing.
2. Make one focused change: server selection, forwarded headers, response rewriting, or canonicalization.
3. Run nginx -t. Do not reload if the syntax test fails; fix the reported file and line first.
4. Reload NGINX using the service method provided by your operating system, then confirm that the worker processes accepted the new configuration.
5. Repeat the original curl -I -L test and compare each hop with the baseline. Test the login or callback path that originally failed, not only the home page.
6. Check both the canonical hostname and any alternate hostname that should redirect. Include HTTP and HTTPS where both listeners are exposed.

Browsers can cache permanent (301) responses. Clear the browser’s cached redirect or use a fresh client only after the server-side chain is correct; otherwise a stale cached response can make a fixed configuration appear broken. A cached redirect cannot be repaired by another server response until the browser requests the original URL again.

Common failure patterns and recovery steps

The backend name remains after setting Host

Inspect the next response with curl -I. If the application still sends its internal URL, it may be using a configured base URL rather than request headers. Correct that application setting, or add a precise proxy_redirect rule for the exact internal origin. Confirm that the rule is inside the location handling the failing request.

HTTPS redirects loop forever

Compare the scheme in each hop. NGINX may receive HTTPS from the browser but speak HTTP upstream; if the application does not trust X-Forwarded-Proto $scheme, it will repeatedly redirect to HTTPS. Configure trusted-proxy handling in the application and ensure NGINX sends the header. Also remove competing HTTP-to-HTTPS rules from the upstream or from another server block.

Only one hostname redirects incorrectly

Compare the matching server_name blocks and their included snippets. The affected name may be handled by a default block, a separate TLS server, or a location with different proxy headers. Test each hostname explicitly and identify the first hop that diverges.

The redirect works for a simple path but fails during login

Authentication often returns an absolute URL from a different application component. Capture the complete login chain, including callback parameters, and inspect whether the response is from the main upstream, an authentication service, or NGINX. Apply the public host and scheme settings to the location that actually handles that callback, then use proxy_redirect only for the internal origin that appears.

Changing proxy_redirect has no visible effect

Verify that the upstream response contains a header, not a body link, and that its prefix exactly matches the rule. Check for a relative Location, a different port, or a trailing path segment. If the first incorrect response is produced by NGINX before proxying, a proxy response rule cannot affect it; return to server selection and core redirect settings.

Quick Recap

Bestseller No. 1

Recipe Book to Write in Your Own Recipes, Spiral Blank Cookbook 150 Recipes

$14.98

Bestseller No. 2

Pipilo Press Blank Family Cookbook Recipe Binder - 6.5 x 8.2 in Hardcover Spiral Bound - 90 Ruled Pages with Memo Pocket - Write In Your Own Recipes & Meal Planning Notebook

$7.98

Final verification checklist

• The first incorrect Location header has a known producer.
• The public Host matches the intended server_name and is not caught by an unintended default server.
• The upstream receives the public Host and the correct forwarded scheme.
• The application’s trusted-proxy configuration is restricted and enabled where required.
• Any backend absolute URL is rewritten with a narrowly scoped proxy_redirect rule or removed at the application source.
• NGINX-generated redirects use the intended server name and absolute/relative format.
• Canonical www/non-www policy is expressed with separate server blocks and explicit returns.
• nginx -t passes, the configuration is reloaded, and the complete chain finishes at one expected URL.

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.