Redirect rules, internal server error (in CF GUI!)

I have been with smugmug for a photo website for years, and had google as registrar and DNS provider. I recently moved both to cloudflare.

To use a custom domain there one puts in a cname for www to “domains . smugmug . com”. That works, all good.

Then, previously at Google, to make the root work, one asked google to “redirect” the root to www. I tried to emulate that here.

On cloudflare I set a rule (redirect rule) for blank (root redirect) to www. Specifically to “www . captivephotons . com”. I did not include the “https://” on it and I left the host name blank. Didn’t work.

So first question is what was the proper setup but…

Now I cannot get back in there. I first tried to edit in the “https://” but the page vanished and the web site vanished from the dashboard. I logged out and back in, and now while I see my web sites, every time I got to the rules page I get a variety of errors, 403, code 10000, code 10007, internal server errors, and “there was an error fetching your rule”.

It seems as though whatever I did has broken the GUI to the extent I cannot get back in. Occasionally it will display the rule, and I tried to delete it without impact (it still sat there showing, then literally while I watched cleared and said “there was an error fetching your rule”.

Yes, I’m using the free service so I assume I cannot enter a ticket.

Any ideas what to do to straighten this out?

And… if I can get back to the rule, what is the right redirect? The process on Google was:

www . captivephotons . com cname => domains . smugmug . com
captivephotons . com redirect => www . captivephotons . com

Just trying to recreate that. Note smugmug can’t do an A record for the root, it has to go through that cname.

But right now I can’t change anything.

Linwood

There’s an active incident ongoing: Cloudflare Status - Cloudflare Dashboard and Cloudflare API service issues
If your errors just started now in the dash, I would wait for that to be fixed and then try later.

1 Like

Ah… didn’t see that, now I know where to look, thanks.

That’s the dashboard issue – any chance of a recommendation of the proper redirect format so I don’t have to do by trial and error?

Would it be blank (for root) to the full URL, i.e. with https:// and path?

I also found it allowed blank to create it (for root) but wouldn’t take it to edit, or did not appear to. Is blank root, as it won’t take the @ sign.

1 Like

You don’t create redirects in the DNS.

Use redirect rules…
https://dash.cloudflare.com/?to=/:account/:zone/rules/redirect-rules

Copy these examples…

Note that any apex domain/subdomains being redirected from must have a proxied DNS entry. If there’s no origin server as you are redirecting the whole apex domain/subdomain, use a proxied dummy record of A 192.0.2.1 or AAAA 100::

That’s where I put the entry, sorry for conflating it, I associate it with DNS because that is what I moved onto cloudflare. And I do have “www” proxied. It looks like this, but I get DNS_PROBE_FINISHED_NXDOMAIN from a browser now.

Note when I go into edit, I get a red error that the host name was not specified, but it accepts it as blank. Previously I tried @ but it wouldn’t take, but that may be because of the dashboard incident. I just changed to @ and not working though that could be a caching issue, will give it a while.

My question is what is the proper format?

Note in DNS www is proxied, but nothing else is proxied (but nothing else should really be involved for that link).

Put the actual domain name or hostname you want to match in the hostname box, don’t use @.

@ would be the domain, but you mention you only have a DNS record for www. You need a DNS record for every hostname you will specify in rules.

Like this? That doesn’t seem right (i.e. “host”):

It’s not working but that could be caching, since my home uses DNS servers on comcast I think. I’ll give it a while and see, but is the above what you meant?

You don’t have a DNS entry for captivephotons.com. You must add the proxied dummy record as I noted above or it won’t resolve and your redirect can’t happen.
https://cf.sjr.org.uk/tools/check?28d12fdc71fa4fc4a80e6fb394f4570a#dns

Sorry, correction, my home firewall uses cisco DNS servers.

I’m sorry for being dense, what sort of record would I add for the domain root? There’s no proper A address for me to add. Should I just make one up?

:point_up_2:

OK, I think I have it working now. I think the problem was this (this is the working version):

I had the CNAME record also marked for proxy, and kept getting infinite redirects for reasons unclear. With it as shown here, and using host=captivephotons . com it works fine (obviously no spaces). I was thinking that all the pieces in the redirect needed to be proxied.

At least that’s what appears to have been happening.

Thank you for the help.

Linwood

Check your SSL/TLS is set to “Full (strict)” here…
https://dash.cloudflare.com/?to=/:account/:zone/ssl-tls

Are you saying that should be true regardless, or that was the issue with the proxy causing redirects?

I really don’t want cloudflare’s cdn invovled beyond the redirect from root → www. Smugmug has their own CDN (I think it’s cloudflare actually), so there’s no benefit.

And if I did want CF to be the CDN wouldn’t strict prevent it from caching?

:point_up_2: This one.

If you don’t want to use the proxy for www (or it’s already provided by your host) then there’s no need, but shouldn’t be any harm in setting it now. Useful in case you later use a proxied record for other than redirecting to ensure connections are secured end-to-end.

That makes sense. Sorry to have been so dense in setting this all up, thank you for helping me resolve it.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.