Page rule subdomain redirects not working as expected

DNS & Network
#1

Hello

I am in need of some advice please - I’ve tried for 2 days but not seeing the result I need… I also followed the various tutorials etc

I am moving a site away from Hubspot and have several subdomains that I want to redirect to the new origin server as follows (the > indicates what it should forward to - all need to work with https )

  1. blog.example.com/some-article > example.com/blog/some-article
  2. www.example.com/some-page > example.com/some-page
  3. resources.example.com << currently on hubspot and will remain there and continue as is

I have set up the following DNS records:

A example.com 123.456.789 proxied
A blog 123.456.789 proxied
A www 192.0.2.1 proxied
CNAME resources 12345.group.hubspot…
and more but those are the important ones.

–
Next I added page redirects as follows…

Page-Rules-1
Page-Rules-1815×343 40.3 KB
Page-Rules-2
Page-Rules-2847×333 45.7 KB

–

The result is as follows:

  1. blog.example.com/some-article > example.com/blog/some-article
    Does not work: continues to load the blog from Hubspot at blog.example.com/some-article

  2. www.example.com/some-page > example.com/some-page
    Does Not Work continues to load the Hubspot pages www.example.com/some-page

  3. resources.example.com works fine

  4. naked domain pages on the new origin server work as expected (e.g. http://example.com)

I have cleared caches, viewed from different devices and used proxy servers to view from other machines - all with the same result as above… for some weird reason the redirects are not working…

I would be happy to share the domain name on a private message but prefer to keep it off the public forum.

Thank you for your help
@sandro fyi sitemeer lookup for www.fine at 2:20 am Saturday, 19 December 2020

1 Like
#4

Your “resources” host is not proxied, so the page rule won’t fire here in the first place.

As for the redirects, your page rules would seem okay. Do you have any other page rules in place before those? Are you sure you are configuring the right account? Could you possibly have added the domain to another account? Could you confirm the nameservers mentioned in the Cloudflare account are b*d and c*e?

Particularly because your “www” record does not point to a “proper” address, but still loads would suggest you might be possibly configuring the wrong account.

1 Like
#5

Hi @sandro thanks for your prompt reply!

Your “resources” host is not proxied, so the page rule won’t fire here in the first place.

Correct - intentional because it’s pointing to Hubspot (no proxy needed) and I do not have a page rule for resources, just the cname.

Do you have any other page rules in place before those?

No - Only one other page rule in place but it’s #3 so doesn’t take priority

Are you sure you are configuring the right account? Could you possibly have added the domain to another account?

I am 99.999% sure I am configuring the top level account for that domain… I only recently added it.

Could you confirm the nameservers mentioned in the Cloudflare account are b*d and c*e ?

Correct, they are those nameservers.

Particularly because your “www” record does not point to a “proper” address, but still loads would suggest you might be possibly configuring the wrong account.

Yes, when I originally set up the DNS in CF, I pointed the www to the new origin IP - however, after looking at multiple tutorials, they all suggested using a dummy IP because the page rule would take priority.

I am rather stumped with this one. I am wondering if Hubspot have somehow hijacked the DNS ! I guess I could reach out to their support too, however, as the domain DNS is pointing to CF, and the page rules are set in CF, I would have thought that would have over-ruled any HS DNS stuff.

#6

Just for clarification, by that you mean the nameservers showing up on the DNS page on Cloudflare, not just the nameservers you set, right? In that case you should be configuring the right account.

If you are additionally saying, there is no page rule which should take priority, it would be slightly strange. Requests to “www” should either get redirected according to the page rule or time out, but they do load instead.

I’d remove all page rules and the “www” record, then wait for five minutes and verify that “www” does not load any more (important that you check the Cloudflare nameservers, not just your local resolver), and then set up everything from scratch. Maybe something got stuck with your configuration.

Should that still not work, then you might have to contact Cloudflare’s support I am afraid.

#7

[quote=“sandro, post:6, topic:230764”]

Just for clarification, by that you mean the nameservers showing up on the DNS page on Cloudflare, not just the nameservers you set, right? In that case you should be configuring the right account.

Correct those NS are showing up in the CF account and are what I set in my domain at the registrar.

If you are additionally saying, there is no page rule which should take priority, it would be slightly strange. Requests to “www” should either get redirected according to the page rule or time out, but they do load instead.

Indeed - I am scratching my head

I’d remove all page rules and the “www” record, then wait for five minutes and verify that “www” does not load any more (important that you check the Cloudflare nameservers, not just your local resolver), and then set up everything from scratch. Maybe something got stuck with your configuration.

Yes good idea - I guess that will indicate if it will load or not…

Should that still not work, then you might have to contact Cloudflare’s support I am afraid.

I think my suspicion is correct - somehow HS have hijacked the DNS - but I am perplexed how that could be if the authoritative DNS is in CF !

#8

They can’t really do that. Unless, there is some partner setup involved and their Cloudflare configuration is still messing with your account, but that would still be something for Cloudflare’s support to resolve.

I presume your DNS records all point to that IP address ending in 114, right?

#9

Hi @sandro

I did as you suggested and removed the CF page rule and www A record.

Now the www returns “site cannot be reached” YAY :slight_smile:

I am going to try adding the page rules again now

#10

Now add “www” again and point it to 192.0.2.1.

#11

done - just waiting for it to propagate… 3, 2, 1

#12

Well that is odd - after adding back the www record and the page rule - now it is loading with the old HS site again ! I even loaded it from a VPN proxy to ensure I am not seeing a cached version…

#13

That’s exactly the odd thing.

Do you possibly have a Worker configured on your account?

#14

pretty sure I don;'t have any workers… I will inspect now to check… I also disabled the page rule just to see what happens… viewing site thru proxy still loads the old HS site

EDIT I checked and no, I don’t have any workers

#15

I just noticed one thing, it is served from the cache. Purge your Cloudflare cache and try again.

#16

Good idea - I have done that now and also enabled dev mode

#17

Still being served from the cache though.

At this point I’d open a support ticket. If your previous host was a partner, there might be some configuration stuck.

#18

Hmmm ok - thanks for helping - huge big high five to you - you helped me determine I was not going mad !! lol

… any way to know how to get a bump up the support queue ? Last time I opened a ticket, it took 10 days to get a reply :tired_face:

#19

Tickets from free plans do not have the highest priority. The best thing is to reply when they send you an automated response, saying that it is not fixed.

Also, post the ticket number here for @cloonan.

3 Likes
#20

@sandro @cloonan

Ticket ID is 2048304

Thank you once more for your assistance.

1 Like
#21

I have the same problem for my site, please email : {redacted} me more details if you can so I can fix my problem. Thanks

#22

HubSpot appears to be a partner or at least used to be

https://www.cloudflare.com/en-gb/case-studies/hubspot

In addition to asking support about any issues in this context I’d also point out that purging the cache has no effect. That might still be related to any misconfiguration in the context with your previous host (if there is such) but it’s worth pointing out.

Interestingly enough, the cache just expired and refetched the document. Nobody knows from where, assuming you still have that 192 address in place.

1 Like