Redirects exposing subdomain name

I’m trying to migrate my site a few pages at a time.

The following worked when my old site had a totally different domain name.

/* https://myoldsite.com/:splat 200

But now I want to use one name, by adding a subdomain to the old server.
https://old.mydomain.com.

The subdomain setup is working with SSL. https://old.mydomain.com

Now here is my updated _redirects file:
/* https://old.mydomain.com/:splat 200

This still redirects but is now routing to my subdomain name instead. So, instead of seeing https://mydomain.com/about, I am now seeing https://old.mydomain.com/about

What can I do to fix it?

My DNS is managed with Netlify.

old.mydomain.com 3600 IN A 206.xxx.xxx.xx

mydomain.com 3600 IN NETLIFY mydomain.netlify.app

www.mydomain.com 3600 IN NETLIFY mydomain.netlify.app

Hi, @djmtype, to troubleshoot we need to know the URL being tested. Would you please send us the real URLs being used?

You can private message (PM) that to one of our support staff and I’ve confirmed that PMs are enabled for your community login. Note, that only one person can see the PM and this will likely mean a slower reply than posting the information publicly. Please feel free to reply to however you prefer though.

Now, I do think I know the real URL based on the account for this email address and the redirect works when I use the custom domain for the site. It does not display the other custom domain name when this is done.

Did you resolve the issue already? If not, please send us more details and we will be happy to troubleshoot. For example, what URL you are testing plus what you see versus what you expect to see would be helpful.

Hey @luke, this is for https://spinlinedesign.com

Hi, @djmtype. This is happening because you proxy this site to a system which returns 301 redirects to custom domain.

For example, take a look at the HTML returned for the URL https://spinlinedesign.com/ :

$ curl https://spinlinedesign.com/
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Example</title>
</head>
<body>
<ul>
<li><a href="/">Home</a></li>
    <li><a href="/work">Work</a></li>

    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
  <h1>Welcome to the Example on Netlify</h1>
  <p>Etiam porta sem malesuada magna mollis euismod. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Maecenas sed diam eget risus varius blandit sit amet non magna. Maecenas faucibus mollis interdum. Etiam porta sem malesuada magna mollis euismod. Donec sed odio dui.</p>
  <p>Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. Cras mattis consectetur purus sit amet fermentum. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Sed posuere consectetur est at lobortis.</p>
</body>
</html>

The href tag for About is “/about”. This makes the new URL for that link this:

https://spinlinedesign.com/about

Let’s see what happens when we request that URL (using the -I option to see the response headers):

$ curl -I https://spinlinedesign.com/about
HTTP/2 301
content-type: text/html; charset=iso-8859-1
date: Thu, 22 Oct 2020 02:37:23 GMT
location: https://old.spinlinedesign.com/about/
server: Netlify
age: 0
x-nf-request-id: 566916f2-9b5e-49e7-98ab-c7a76d772c70-8290908

This shows that there was a 301 redirect returned for this URL to the other custom domain, old.spinlinedesign.com.

This isn’t being returned by Netlify. It is being returned by the server you are proxying to. Here is the same lookup directly to that server:

$ curl -I https://old.spinlinedesign.com/about
HTTP/1.1 301 Moved Permanently
Date: Thu, 22 Oct 2020 02:39:40 GMT
Server: Apache/2.4.41 (Ubuntu)
Location: https://old.spinlinedesign.com/about/
Content-Type: text/html; charset=iso-8859-1

To summarize, your old server is returning 301 redirects back to it’s own custom domain. Netlify isn’t doing this; your old server is. You proxy your site to this server and it is this server returning the 301 redirect with the old.spinlinedesign.com domain name.

Hey @luke thanks for the explanation.

In order to set an SSL cert on old.spinlinedesign.com, an A record is required. Otherwise, if left it without an SSL and without an A record, it would still fetch the page at the correct url, https://spinlinedesign.com/about, but without any content (no errors).

These are my only records on my remote server:
NS old.spinlinedesign.com redirects to ns1.digitalocean.com 1800
NS old.spinlinedesign.com redirects to ns2.digitalocean.com 1800
NS old.spinlinedesign.com redirects to ns3.digitalocean.com 1800

Sorry, I’m so confused when it comes to subdomains and splitting hosting between them. It’s my first attempt without much luck.

Hi, @djmtype. The redirect is happening at the HTTP level not the DNS level (meaning it isn’t the DNS that is the root cause).

The issue is that when you proxy the site to the other server, the other server response with an HTTP resolve with a 301 status and a Location: HTTP header which tells the browser where to go next.

When the browser makes the request to https://spinlinedesign.com/about this is sent to an IP address Netlify controls and a CDN node with an HTTP service receives the HTTP request for this URL.

Our CDN node sees there is a redirect rule for this URL. That redirect says to make the use the same request path but change the domain name portion of the URL to old.spinlinedesign.com. Our CDN node then proxies the original request to this URL at the new domain name. Whatever that response is, our CDN node then returns to the visitor’s web browser.

The issue here is that your HTTP server at old.spinlinedesign.com doesn’t return content for this URL. Instead it returns a 301 status with an HTTP response header of Location: https://old.spinlinedesign.com/about/.

The old.spinlinedesign.com domain name is returned by the other server. This is a server we don’t control so we cannot stop it from sending this response.

You might be able to resolve this with a new redirect rule to handle this case like so:

/:path https://old.spinlinedesign.com/:path/ 200
/* https://old.spinlinedesign.com/:splat 200

The “*” rule will match all URLs (without a matching file in the deploy) so it is important to put that rule last as it would alway apply and prevent the “:path” rule from working.

Note, the “:path” token won’t match “/”. It wouldn’t match /about/more or /about/.

However, it would match just /about and silently proxy it to https://old.spinlinedesign.com/about/ and this might be all that is needed to prevent the 301.

If this doesn’t work or if there are other questions, please let us know.