Redirect from Netlify subdomain to custom primary domain not working

[Sujay]

Hello,

I am trying to implement a redirect from the Netlify subdomain to custom primary domain for my website built with Gatsby.

Netlify subdomain: optimistic-bhaskara-b7453a

Here are rules that figure in my _redirects file that is in the static folder of my Gatsby project.

# Redirect default Netlify subdomain to primary domain
https://optimistic-bhaskara-b7453a.netlify.com/* https://www.meetstargazers.com/:splat 301!

# Redirect dynamically created page
/resetpassword/* /resetpassword/index.html 200

Expected result : Redirect from Netlify subdomain to custom primary domain.
Actual result : Redirect doesn’t work.

I have tried the following :

1. Moving the _redirects file from static folder to root of the project.
2. Changing the order of the rules within the _redirects file.
3. Different syntaxes for the redirect rule.
4. Emptying the cache in Netlify and redeploying the project.

What is strange is that the redirect rule for the dynamically generated page /resetpassword/:id works perfectly.

Can anyone please help me to solve this problem ? This is important for me to not be punished by Google for duplicate content.

[luke]

Hi, @Sujay, and welcome to the Netlify community site.

It appears that you got it working on your own. I see you have made deploys since the topic was posted and the redirect does work now when I test.

Here is an example of the redirect working with curl:

$ curl -svo /dev/null https://optimistic-bhaskara-b7453a.netlify.com/  2>&1 | egrep -i "^< (HTTP/|location)"
< HTTP/2 301
< location: https://www.meetstargazers.com/

If there are other questions about this, please let us know and we’ll be happy to answer.

[Sujay]

Hello @luke

Thanks for your answer but the redirect is still not operational. When I click on the Netlify subdomain address it still points to the subdomain address and doesn’t redirect to the primary custom domain.

https://optimistic-bhaskara-b7453a.netlify.com/

[luke]

Hi, @Sujay, again this is not what I see when testing.

I see there is a service worker for this site. I suspect the local service worker is preventing the HTTP request from reaching Netlify and blocking the redirect. The redirect doesn’t occur because the browser doesn’t even make the HTTP request (at least that is my hypothesis).

Would try unregistering that service working and trying again?

[Support Guide] Understanding & unregistering service workers

Last reviewed by Netlify Support - August, 2023 A service worker is a script that your browser runs in the background to accomplish a variety of tasks. Browsers cache service workers for 24 hours by default, and don’t update them when you reload your page. Therefore, you may have a service worker on your site which could prevent you from seeing the latest and greatest changes that you’ve made. If you suspect a service worker is causing this issue, I recommend disabling/removing the service wor…

If that doesn’t resolve the issue, we will need more information to troubleshoot.

The most specific information to send us the x-nf-request-id header which we send with every HTTP response. There more information about this header here:

[Support Guide] Netlify Support asked for the 'x-nf-request-id' header? What is it and how do I find it?

Last reviewed by Netlify Support staff August 2023 What is the x-nf-request-id header? Web servers and web browsers communicate using a protocol called HTTP - which stands for “HyperText Transfer Protocol”. Both web browsers and web servers use a feature called headers as part of this protocol. The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”. The web servers headers are called “response headers” because web servers send an “HTTP …

If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:

• the complete URL requested
• the IP address for the system making the request
• the IP address for the CDN node that responded
• the day of the request
• the time of the request
• the timezone the time is in

With those details we’ll be able to find out why the redirect isn’t occurring. If there are questions about any of this, please let us know.

[Sujay]

Hello @luke,

Thanks for your response. I unregistered the service worker but the redirect from the Netlify subdomain to my primary custom domain was still not working. Hence I have restored the service worker because Google appreciates websites that work offline, a feature that service workers facilitate by making the website more resistant to bad network conditions. So I need to keep the service worker operational.

Please find the x-nf-request-id for the base URL of the Netlify subdomain.

x-nf-request-id: dd94f500-a415-4f1f-b699-77851a0c4fcc-10821024

[fool]

That request ID was served on 11 March, though you wrote in on 13 March. Pretty sure it the misbehavior for you is still service worker + caching related - the redirect is working well for everyone else without cache (even upon return visits)

[Sujay]

Hello @fool @luke,

I had made the request on the same day as I wrote my response i.e. 13.03.2020 strictly following Luke’s article mentioned above. What is reassuring is that I checked the redirection on Safari and it’s working but not on Chome. So it’s very likely that some local Chrome setting on my computer is causing the misbehaviour.

Thanks for your support.

[luke]

Hi, @Sujay. For that x-nf-request-id I think we have an explanation for why the redirect didn’t work. I’m showing this was the active deploy when that request was received:

Netlify App

Note what is says in the “Deploy summary” section at the top. Quoting:

No redirect rules processed
This deploy did not include any redirect rules. Learn more about redirects.

I do see redirects proceed in the currently published deploy:

Netlify App

And that redirect is working now when I test:

$ curl -svo /dev/null https://optimistic-bhaskara-b7453a.netlify.com/  2>&1 | egrep -i "<\s(HTTP/2|location)"
< HTTP/2 301
< location: https://www.meetstargazers.com/

Would you please test the curl command below? (It is the same as the one above but not filtered with egrep.)

curl -svo /dev/null https://optimistic-bhaskara-b7453a.netlify.com/

If you do not get a 301 redirect locally when you use that command, would you please post the full output of that command here?

You can also direct message (DM) that information to us but I don’t think there will be any sensitive data and posting publicly will receive a faster reply than a DM will. I personally think publicly posting the command output is completely safe but please do what you think is best.

As always, if there are any other questions for us please share them anytime.

[Sujay]

Hello @luke,

When I test the curl command you have mentioned, the redirect is working. But in Chrome the redirect doesn’t work whereas on Safari it does. So it’s certainly misbehaviour caused by a local setting on my individual Chrome browser. I am sending you the output of the curl request by DM but I am considering the problem as solved. Thanks for the time you and Chris invested to solve my problem.

Warm regards and all the best.

[niansa]

Yeah, that must be a cache problem, try clearing it: Clear cache & cookies - Computer - Google Account Help

[Sujay]

Thanks for your suggestion. That is the first thing I tried. It didn’t work.

[hyuta]

@Sujay
Hi, I had the same problem lately and found this page.
The DNS behavior is correct, but it is not redirected in the browser by Serviceworker.

So I found that redirecting with Javascript in an html file then it works well.
I’m making SPA with vue-cli and vue/cli-plugin-pwa.
But this can be solved simply.
I add bellow code in the header of index.html.

<head>
<title>title</title>
<script>
  if (location.host === "subdomain.netlify.app") {
    location.href = "https://original-domain.com";
  }
</script>
</head>

I hope this helps you.

[Sujay]

@hyuta Thanks for your message. Luke and Chris’s answers helped me to solve the problem. But thanks anyways because it is always good to know that alternative approaches exist. Thank you very much for sharing learning from your experience.
Warm regards.