How long for a new custom domain routed worker to go live?
I decided to switch from hosting on GitHub Pages to hosting with a Cloudflare worker with an associated custom domain.
I know that officially, it's said that it can take 24 hours for DNS changes to propagate, but I feel like that's very conservative. It's been about an hour, and from
dig I'm getting Cloudflare A records. But my site isn't coming up, and I feel like something's wrong.
I've actually published this exact site (same version of the same code) via wrangler versions upload, and that comes up exactly as documented and expected. But wrangler deploy hasn't gone as smoothly. What should I look at to get a better sense of whether I've configured everything correctly, or whether I just need to be patient and wait for some propagation?26 Replies
Maybe I'm getting an infinite loop due to a slash? Debugging with curl.
Are you seeing some kind of error?
From a "deployment" perspective, it all looks like it's deployed error-free.
I can also see a worker.dev deplyment... but my custom domain isn't linked up correctly.
I meant, if you visit the custom domain, do you see some kind of error?
Just a moment.. plain curl gives me an empty response... figuring out the right switches to get more detail..
❮ curl -L https://theescapement.com
curl: (47) Maximum (50) redirects followed
I'm getting a ton of redirects, and I think this is due to how slash is getting redirected.
That might be it.
What's the correct solution to this? This is just a static site, and there's a index.html at the root of what I've uploaded. Also... this works fine with the normal worker.dev stuff (
wrangler versions upload), so not sure why it's too much different with a custom domain.
I'm trying to add an explicit route, but that's not quite it.
Any suggestions?
Upgrading to Business, just to get chat support, seems like a somewhat heavy price to pay for something that might be simple.I don’t think this would have an effect, but is your SSL/TLS setting for the domain set to Full?
Current encryption mode: Full theescapement.com is using automatic SSL/TLS
Hm, ok yeah, then that’s not the problem… maybe try throwing the request into trace, and see if something is being matched? https://developers.cloudflare.com/rules/trace-request/
Cloudflare Docs
Trace a request
Cloudflare Trace (beta) follows an HTTP/S request through Cloudflare's reverse proxy to your origin. Use this tool to understand how different Cloudflare configurations interact with an HTTP/S request for one of your hostnames. If the hostname you are testing is not proxied by Cloudflare, Cloudflare Trace will still return all the configurations...
My DNS has no manual A/AAAA/CNAME records. Just the record created by the worker, that I can't edit.
Trace should still be able to discover the route the request takes, even with a Worker Custom Domain
It seems like it's just running curl, similarly to me. Maybe a little more. But I'm not getting more insights from it.
I just don't understand why I would get an infinite redirection loop on a static site.
DNS over Discord: AAAA records
theescapement.com AAAA @1.1.1.1 +noall +answer +short
diggy diggy hole
Did you change the DNS record? It definitely shouldn't be
100::...I have a theory that my Vite configuration wa errant.
DNS over Discord: A records
theescapement.com A @1.1.1.1 +noall +answer +short
diggy diggy hole
Just a moment... let me push through the work in front... redeploy... and then I'll circle back to the DNS stuff you're dropping here.
Okay... let me see what you have.
I tried to address the Vite build with an explicit
base: '/'. Probably a good idea, but didn't fix this.
I just reran things above, and DNS looks better now.
But the site still has problems.
I think in my flurry to find a fix, I just broke things further. We're back to where I started.
Hell yeah... the trace was awesomely helpful. I just wasn't seeing the detail correctly. Absolutely an HTTP->HTTPS redirect I set up originally was just looping.
I'm guessing Cloudflare is trying to be extra helpful, and implicitly has that rule, and then my old rule was getting triggered in a loop.
I don't want to overthink it. But disabling that rule fixed it all. The trace debugging absolutely helped me find this problem. And HTTP->HTTPS routing is still in play, even with my rule disabled.Looks to be working
Hooray!
Yeah, often times, the simplest explanation is the right one
The pile of simple simple explanations is where it gets complex.
But thanks! How do I close this as "solved?"
I found the tag.
@Hard@Work I could open another thread... but a follow-up question. I tried putting in a CNAME to point www.mydomain.com to mydomain.com. I thought that's what the right move was (did I misremember?). Or is there something more I need to do when using Workers + custom domain routing?
I think I solved it... just used another custom domain route.
rubber 🦆 ftw.
Are you trying to redirect? At least for SEO, it’s recommended to not have to separate (sub)domains serving the same content
It's just "www." What do you recommend?
Which page do you want to actually serve the content? You can make the other redirect, so if I visit www.theescapement.com, it immediately redirects to theescapement.com(or the other way around, if you prefer)
I think I did the desirable thing. Rather than serving the same content from theescapement.com and www.theescapement.com with two custom domains, I only published to the non-www domain, and instead created a CNAME for www. However, that didn't work alone, and I found I needed to supplement it with both a Worker Route and a Rule (used the template www.@ -> @ rule). Maybe that all makes sense, but it wasn't obvious to me when setting things up.
It all works now, though, and I believe it's a redirect instead of two sites, for SEO.
You should only need the Rule on
www for redirecting, not the Worker(should save you a few requests)Huh... I definitely tried that, and it didn't work.
I can try taking away the worker route and see if it holds.