I’m finally switching DNS for my custom domain over to my Micro.blog hosted site instead of my previous website on GitHub Pages, but I’m having trouble getting it set up the way I’d like… I use Cloudflare as my DNS provider and I have a few nit-picky details that I really prefer for my website:
Support visiting the www subdomain but redirect it to the root domain (i.e. redirect https://www.davidcel.is/* to https://davidcel.is/$1)
Given Micro.blog seems set up to do that first one by default, that just leaves the other two. The last one is easy enough using a page rule on Cloudflare (which is what I used to do), but this actually depends on proxying being enabled, and I can’t seem to get my site working at all when my A and CNAME records have Cloudflare’s proxy enabled. As soon as I enable that and the DNS changes take effect, trying to visit my site shows a “too many redirects” error:
Because of this, my A and CNAME records are set to “DNS Only” on Cloudflare for now (no proxy). My site works okay, but I’d prefer www to redirect to my root domain, and my uploaded images load extremely slowly. It takes one photo between 2-3s to load for me and, for some reason, those images don’t seem to be getting cached by my browser at all. I checked the HTTP request for one of my images and it shows a Cache-Control: max-age=7200 header declaring a 2-hour cache along with the corresponding Expires: Sat, 7 May 2022 23:45:48 +0000 header, but no ETag (not sure if that’s the issue).
Even if I could figure out the image caching issue, 2 hours is a very short expiration time for something like an uploaded image, given it’s extremely unlikely to change. Part of why I like the Cloudflare proxying is that the caching support it gives me just works and I can set a longer cache expiration time.
Anybody out there been successfully using Cloudflare and their DNS proxying feature?
The two most common causes for this, according to Cloudflare, are incompatible SSL settings and page rules misconfigurations. So maybe it’s an SSL thing?
After Micro.blog has set up HTTPS, you can re-enable the Cloudflare proxy and it should continue to work. For the www redirect, Micro.blog will handle that automatically. Under the Design screen, set your custom domain name to be davidcel.is instead of www.davidcel.is. That will tell Micro.blog to also redirect the www version.
After Micro.blog has set up HTTPS, you can re-enable the Cloudflare proxy and it should continue to work.
Ah okay, I assumed that because I was already able to visit my site using HTTPS that it was set up. Is there a way I can tell that the process is complete, or should I just give it a few days, a week, etc. before trying to re-enable the Cloudflare proxy?
For the www redirect, Micro.blog will handle that automatically. Under the Design screen, set your custom domain name to be davidcel.is instead of www.davidcel.is. That will tell Micro.blog to also redirect the www version.
Oh interesting, I thought I had to set it to www.davidcel.is for both to work! But without the www subdomain, micro.blog will redirect it? I still need both DNS records though, right?
HTTPS is enabled right away now, there shouldn’t be any delay in Micro.blog. Our servers request a new HTTPS certificate whenever it is needed. (The certificates do expire after a few months and automatically renewed, and to be honest I’m not sure if the Cloudflare proxying will cause a problem again when that happens.)
For the DNS, yes, keep both DNS records, but just set the non-www version in Micro.blog’s setting. That basically sets it as the “preferred” domain name, but Micro.blog will also host and redirect the www version.
Aha, thanks a ton for the help, you two! It looks like the biggest issue was that I still had my SSL mode to “flexible” instead of “strict”, so Cloudflare was trying to request my site via HTTP which was redirecting to HTTPS infinitely. I changed it to strict and everything seems to be working great now. My site is still visible at www.davidcel.is without redirecting, but I’m guessing that’s a caching thing on micro.blog’s end so I’ll keep an eye on it and try again later to see if that clears up
