Recommended Free Tools
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.
A subdomain reaches the parent domain when NGINX selects the wrong virtual server or when NGINX or the application behind it sends a redirect whose Location header contains the parent hostname. The usual causes are a missing or misspelled server_name, a different configuration on port 80 and 443, a default_server catch-all, or a canonical-URL rule copied into the subdomain block.
Find the emitter first: run curl -I for HTTP and curl -Ik for HTTPS, read the exact Location value, then inspect the merged configuration with sudo nginx -T. Once you know which block or upstream produced the response, the fix is normally a precise hostname declaration, a corrected listener or certificate, or a redirect rule moved to a dedicated server block.
What a parent-domain redirect tells you
A redirect is an HTTP response, not a DNS decision. NGINX (or an upstream application) returns a status such as 301 or 302 together with a Location header. The browser then requests the hostname in that header. If the header says https://example.com/path while you entered https://app.example.com/path, the redirecting component explicitly chose the parent name.
There are two broad possibilities:
- NGINX selected a server block that does not belong to the subdomain. That block may contain a parent-domain redirect, or it may proxy the request to the wrong application.
- NGINX selected the intended block, but a rewrite, an absolute redirect generated by NGINX, or the upstream application emitted the parent hostname.
Do not infer the source from the URL shown after the browser follows the redirect. Capture the first response before following it.
#1 Best Overall
How NGINX selects a server block
server_name is the virtual-host key
For each listening address and port, NGINX compares the request host with the server_name values on the server blocks attached to that listener. Matching supports exact names, wildcards and regular expressions. Exact names take priority; then NGINX uses the longest matching wildcard at the beginning of a name, the longest wildcard at the end, and finally the first matching regular expression in configuration order.
Declare the complete subdomain, not only the parent:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://app_backend;
}
}A typo such as apps.example.com, a declaration in a file that is not included, or a name placed only on another port leaves the request without an exact match.
Unmatched hosts go to the port’s default server
When the Host header does not match a server name, NGINX uses the default server for the address and port that received the request. The NGINX administration guide states: If the Host header field does not match a server name, NGINX Plus routes the request to the default server for the port on which the request arrived.
A parent-domain block or a catch-all block is often the default, so it appears to have stolen the subdomain.
Look for listen 80 default_server;, listen 443 ssl default_server;, and catch-alls such as server_name _;. A wildcard like *.example.com can also match the subdomain before a later block is considered. Duplicate names across files create a similar problem because only one server block can effectively answer a given listener/name combination.
Rank #2
HTTP and HTTPS are separate selections
http://app.example.com arrives on port 80, while https://app.example.com arrives on port 443. Each listener needs a matching server_name. The TLS block also needs a certificate whose names cover the subdomain. It is common for HTTP to work while HTTPS falls into a default TLS block, or for an HTTP canonicalization rule to send the browser to HTTPS where the subdomain is not declared.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors| Observed behavior | Most likely selection issue | What to inspect |
|---|---|---|
| HTTP subdomain immediately redirects to the parent | Port 80 matched a parent or catch-all block | listen 80, every port-80 server_name, and parent-domain return directives |
| HTTP serves the app but HTTPS redirects to the parent | Port 443 has no exact subdomain match or uses the wrong TLS default | listen 443 ssl, the TLS server_name, certificate names and the 443 default block |
| Every unknown hostname reaches one site | A deliberate default or catch-all server is handling unmatched hosts | default_server, server_name _; and wildcard declarations |
| The response contains an application-specific parent URL | The upstream generated the redirect | Upstream headers, application base URL and proxy redirect settings |
Redirect directives that can change the hostname
A misplaced return 301
return can issue 301, 302, 303 or 307 responses in a server or location context. It is the clearest way to canonicalize an old hostname when it is placed in a server block dedicated to that old hostname:
server {
listen 80;
server_name old.example.com;
return 301 https://example.com$request_uri;
}$request_uri carries the original path and query string. The same directive in the block intended to serve app.example.com will redirect valid subdomain requests to the parent by design. Check snippets included from distribution files or control panels; an apparently absent directive may be inherited from an include.
Broad or overlapping rewrites
A broad rewrite can match requests that were meant for another host. Server-context rewrites run once before NGINX selects a location. The last flag starts a new location search, whereas break stops rewrite processing in the current context. Multiple rules can therefore apply sequentially, create a second match, or form a redirect cycle.
Keep hostname canonicalization in one dedicated server block and use return when the destination can be built directly from standard variables. NGINX’s rewrite-conversion guidance describes an if-based host redirect as a wrong, cumbersome and ineffective approach and calls a separate server for the old name the right way.
Redirects generated by the upstream application
With proxy_pass, NGINX may simply relay a Location: https://example.com/... header returned by the application. The browser cannot tell that the application, rather than NGINX, chose the parent domain. Correct the application’s canonical URL or base URL, or configure an appropriate proxy redirect policy so upstream locations are rewritten to the public subdomain. Do not change NGINX host matching until you have confirmed who sent the header.
server_name_in_redirect and absolute URLs
NGINX can generate absolute redirects itself, for example when adding a trailing slash to a directory. The core directive server_name_in_redirect controls whether those redirects use the primary name from the selected server_name directive. If the selected block lists the parent as its primary name, an absolute redirect can expose that name even though the request arrived through another hostname. Verify the selected block and this directive before changing it globally; changing it will not fix a request that is already being handled by the wrong server.
Build a separate HTTP and TLS block for the subdomain
Port 80 destination block
Use an exact name in the block that serves the application. Keep parent-domain canonicalization in a different block:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://app_backend;
}
}
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}The second block is only an example of a parent-domain policy; do not copy a parent redirect into the first block. If you intentionally redirect HTTP subdomain traffic to HTTPS, make the destination retain the subdomain:
server {
listen 80;
server_name app.example.com;
return 301 https://app.example.com$request_uri;
}Port 443 destination block
Repeat the exact hostname on the TLS listener and provide a certificate and key that cover it:
server {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
location / {
proxy_pass http://app_backend;
}
}If one certificate covers several names, its subject alternative names still must include app.example.com. A certificate mismatch is normally a TLS warning rather than a clean redirect, but administrators often work around a failed TLS block by adding a broad redirect; that workaround can hide the original listener error.
Diagnose the redirect in a controlled sequence
- Confirm DNS and the endpoint. Verify that the subdomain resolves to the address running this NGINX instance and that both HTTP and HTTPS reach the intended machine. A different load balancer, CDN or reverse proxy can be the component returning the parent URL.
- Capture the first response. Run
curl -I http://app.example.com/pathandcurl -Ik https://app.example.com/path. Record the status, everyLocationheader and identifying response headers. The-koption allows the HTTPS request to continue when a certificate is temporarily invalid; it does not repair certificate configuration. - Inspect the merged configuration. Run
sudo nginx -T, not only the file you edited. Search the output for every occurrence ofapp.example.com,default_server,server_name _;, wildcard names,return 301,return 302andrewrite. Includes loaded before or after your file can change which block is effective. - Compare listener coverage. Confirm that the subdomain appears in an exact
server_nameon both the port-80 and port-443 blocks that receive traffic. Check that the TLS certificate and key paths are valid and that the 443 block is actually enabled. - Temporarily narrow canonical rules. Remove or restrict a parent-domain redirect so it matches only the old hostname. Test the syntax with
sudo nginx -t, then reload usingsudo nginx -t && sudo nginx -s reload. Never reload an untested configuration. - Check logs while reproducing. Watch the access and error logs as you run the curl commands. The selected server, request host, status and upstream response information usually reveal whether NGINX generated the response or proxied one.
- Inspect upstream headers. If the intended block is selected but the response still contains the parent URL, query the application directly where possible and inspect its canonical URL, base URL and trusted-proxy settings. Correct the application or apply a deliberate proxy redirect policy.
- Retest without cached redirects. Browsers cache 301 responses. Use curl, a private window or a new browser profile after the configuration change. Test both a root path and a nested path with a query string so you can verify that the intended host and URI survive.
Fixes for the common failure modes
The subdomain name is missing or misspelled
Add the exact fully qualified name to every relevant listener. If you use both IPv4 and IPv6 listen directives, ensure the subdomain is covered on each address. Remove accidental spelling variants unless they are deliberate aliases, then test with nginx -T and curl.
A catch-all or parent block is the default
Choose a clear default policy for each address and port. Keep a catch-all for rejected or redirected unknown hosts if needed, but do not rely on it to serve the subdomain. Add an exact subdomain block and avoid placing broad wildcards ahead of it when a narrower rule is intended.
Only HTTPS is wrong
Copying the port-80 server_name into the TLS block, installing a certificate that includes the subdomain and checking the 443 default server resolves this split behavior. Remember that a successful HTTP redirect to HTTPS does not prove that the HTTPS virtual server is correct.
NGINX is correct but the application emits the parent
Set the application’s public origin to the subdomain and make sure it trusts the forwarded scheme and host supplied by the proxy. If the application must keep an internal origin, rewrite its Location headers at the proxy deliberately and test absolute as well as relative redirects. A parent URL in an upstream header is not fixed by adding another NGINX server_name.
A rewrite loops or applies twice
Consolidate host redirects into one server-level return, remove overlapping regex rules, and check whether a last rewrite sends the request into a block that runs the original rule again. Use break only when you intentionally want to stop processing in the current context. Retest a path that previously looped and inspect the complete redirect chain with repeated curl requests.
Preserve paths, queries and the intended host
When a redirect is deliberate, construct its destination explicitly. https://app.example.com$request_uri retains the path and query string while changing only the scheme or host. Hard-coding https://example.com/ discards the original path unless you append the appropriate variable. Conversely, blindly appending variables to several nested rewrites can duplicate path segments, so verify the final Location header rather than assuming it is correct.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Use a single canonical policy per hostname. For example, decide whether HTTP becomes HTTPS, whether a bare parent becomes a preferred parent variant, and whether the subdomain remains separate. Implement each policy in the server block for the hostname being redirected, then let the destination block serve content instead of redirecting again.
Final verification checklist
- The subdomain resolves to the NGINX endpoint that contains the configuration.
- An exact
server_nameexists on the actual port-80 listener. - An exact
server_nameand a covering certificate exist on the actual port-443 listener. - No unintended
default_server, catch-all, wildcard or include captures the request first. - Parent-domain
returnandrewritedirectives are confined to the hostnames they are meant to redirect. curl -Iandcurl -Ikshow the expected status and aLocationcontaining the intended hostname.- If NGINX proxies the request, the upstream does not emit a parent-domain location, or an intentional proxy policy rewrites it safely.
nginx -tsucceeds before reload, and tests are repeated after clearing cached 301 responses.
The decisive question is always which component emitted the first redirect. Once the Location header, listener and selected server block are known, a subdomain-to-parent redirect is a concrete configuration mismatch rather than an unexplained NGINX behavior.
Quick Recap
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.
