I used to be able to do CNAME to .onrender.com.
No more.
CloudFlare hosts the DNS. I can’t do an A record to the above. I tried the numeric IP address and CloudFlare said it was invalid.
Two weeks ago the top version worked. What changed?
So your doc on using CloudFlare seems out of date. Crypto settings are called TLS/SSL (which is crypto, of course). Your own docs still recommend using CNAME. But, in the custom domain array you’ve changed that. Docs matter–they’re meant to prevent probelms and solve them when they do happen.
I added an A record to the numeric ip address you provide. ALIAS records only work with DNSimple (or something like that). Better or not, it seems you should use the most generic thing. You are on the receiving end and don’t do registrar and DNS so you want to work with everyone as easily as possible and not restrict or exclude anything.
The A record seems to require a numeric IP address. That’s OK for me: you tell me what it is and I can type it in. But, it seems bad for you. You can never move it. And it might be harder to have some sort load balancer in front of it. Not my problem except when you do change the IP address and things break. Much better to use a name that resolves to any physical IP address you choose to use.
They now default to HTTP/3. Does that cause problems for you? I can override the default choice and go to HTTP/2 (but not /1).
Seems to work but I get bad cert (so the lock for https in Firefox has exclamation point).
I have proxy on and the routing still comes to render and everything looks fine on the site except the certs.
I will turn off proxy. I think I am getting CloudFlare certs instead of yours–hence the problem. Update: I did this–still waiting for the DNS update to propagate.
This really needs to be plug and play. I have wasted a hour and a half on this today. I don’t like doing DevOps work. That’s why we go SSG and server-less: so we don’t have to. Content creation and theming are harder than WordPress (…etc) but we don’t do any server admin and the site is faster and more secure.
I like Render despite some frustrations. But SSG hosting isn’t a business (as you know). It’s just a freemium lead in to something else. Not sure what your something else is. You have a nice UI and do the SSG stuff well.
I did another site a month ago and it worked pretty much first time with CloudFlare. Now, problems…
There was also something wrong with your UI.
When added the custom domain, it double added it: 2 times for the base domain and 2 times for hte www. subdomain.
I deleted and redid it about 4+ times. Finally, on the last try it only added 1: once for the base domain and once for www.
The DNS update seems particularly slow today so we’ll see if it ever updates. I’ll leave it alone for a while.
Whole thing is not confidence inspiring.
Update: good news. It works now. HTTPS works with no certificate problem.
But, once again your doc is wrong. You MUST use the CloudFlare proxy. The certificates for https have to match the URL and they own the URL and its routing (when using their DNS, which they sort of insist on…).
There is still a problem: the custom domain DNS entries haven’t resolved.
In order for Render to be able to verify your custom domain, you will need to temporarily update DNS to point to the load balancer IP in the custom domain doc or a CNAME to your service’s onrender subdomain. Once it is verified, you can revert DNS back to Cloudflare.
Thanks. A little confused. The site works. At CloudFlare DNS I had an A route to the numeric IP address you provide in the ui for setting up a custom domain. That worked. The site was at .onrender.com and it appeared under .org entered in the browser. But your scanning of the DNS records did not resolve. I then went in and used the “old” documentation using CNAME records at CloudFlare. That also works: the website is reached at .onrender.com. But, the DNS for the custom domain in your UI still shows as unresolved. By unresolved I mean that your UI shows: “DNS Update Needed”.
The inconsistency you’ve got is htat you say for the primary custom site address (no www.) I must use ALIAS or ANAME. CloudFlare doesn’t support these. I suspect a lot of registrar’s don’t. A record requires numeric IP address. CNAME will take a name. Right now I have a CNAME for wintercove.org and another for www.wintercove.org. The CloudFlare specific documentation you provide still says to use 2 CNAMEs, as I did the 2nd time.
I’ll note that my other site, a-view.org, worked with 2 CNAMES and the names resolved. That one is now pointing to another hoster. So, seems like you may have changed something.
It all works. Should I just ignore the DNS Update needed?
The inconsistency you’ve got is htat you say for the primary custom site address (no www.) I must use ALIAS or ANAME.
Could you point out where you noticed this in the docs? From what I see, the Cloudflare document recommends using a CNAME for the apex domain (likely using CNAME flattening behind the scenes) and the non-vendor specific document gives options for both ALIAS/ANAME records as well as A records. I’d like to make sure we don’t have any out of date docs that cause confusion.
Should I just ignore the DNS Update needed?
Since you’re using Cloudflare to manage your SSL certificate, you should be fine to just ignore the error in the dashboard. It just means that Render won’t be managing the cert for your custom domain. If you want to get rid of the error, you can update DNS to point to Render temporarily and click “Refresh DNS”. After a short period of time, it should be verified. You can then point it back to Cloudflare.
In the settings section for the custom domain it makes the recommendation for an A and a CNAME. In the docs for custom domain there is a specific page for CloudFlare and it still says to use 2 CNAMES.
Good to know that the warning doesn’t matter for CloudFlare. You’re right that they’re different than most registrars because when they do the name servers and proxy they can provide the https certificate for the base domain and any subdomains. I switched from Hover because Hover’s name servers could not flatten 2 cnames to protect the www subdomain if Render was providing the cert for the primary name. They actually recommended CloudFlare.
When CloudFlare gets the bugs out of SSG hosting you are going to have to watch out and do a bunch of value add—like static pages with forms and/or js that can talk to database for auth, personalized content and other dynamic content.
- Lewis
I’ve been moving a lot of my apps to Render the last few days, so I’ve gone through the process of setting up custom domains and using Cloudflare quite a few times now. For anyone interested, this works without problems for me:
- Add the domain to Render
- Check what subdomain you’re on (e.g.
example.onrender.com) - On Cloudflare, add a
CNAMEpointing@(that’s root) toexample.onrender.com - On Cloudflare, add a
CNAMEpointingwwwtoexample.onrender.com - Make sure not to use Cloudflare proxying (cloud icon should be gray, not orange)
- Click the buttons in Render to verify the DNS is configured correctly. This might take a while depending on DNS caches, your DNS TTL settings, etc.
- Once Render shows everything is ready, you can turn on proxying in Cloudflare if you want
- Optionally, you can also switch Cloudflare’s SSL mode to Strict as the connection between Cloudflare and Render should now be secured by Let’s Encrypt certificates
For people new to Cloudflare step 3 can be a bit confusing. As generally you cannot set a CNAME on root, but Cloudflare does some magic. (Similar to ANAME or ALIAS on other services I think).
For people new to Render, having to temporarily disable proxying is a bit surprising.
@jake Can you confirm that once set up, the SSL certificate will auto renew without having to disable proxying again? It’s not clear to me why disabling it’s necessary, but I think it has to do with the Let’s Encrypt challenge?
1 Like
Thanks. That’s a good way and uses Render’s certificates instead of CloudFlare’s. It’s what the “old” Render documentation says to do rather than the messages that appear on the Custom Domain settings. Avoids confusion, too.
Render confirmed to me that with proxy ON at CloudFlare, you get CloudFlare’s certificates rather than Render’s. You are protected. But the warnings appear at Render—which simply mean the Render certificates aren’t being used.
Both work.
Now another question: with CloudFlare proxy ON do you get CloudFlare CDN? With CloudFlare proxy OFF do you get Render CDN (Fastly)? Just curious…
As to which CDN is “better”: 1) sort of irrelevant for my low traffic site; 2) various attempts to benchmark CDNs have been published, but it’s really hard to do. Seems like either CDN is a major plus over no CDN—so not looking for any evaluation there.
1 Like
Technically you can use both certificates.
If you enable Cloudflare proxying they will secure the connection between the client (i.e. someone visiting your website) and the Cloudflare server. Cloudflare will then pass through the request to Render. If you want that connection to also be secured, you should make sure Render’s SSL certificates are working as expected. From the client’s perspective, they won’t notice whether the connection between Cloudflare and Render is secured, but you as the business owner probably want to secure things as much as possible.
Now another question: with CloudFlare proxy ON do you get CloudFlare CDN? With CloudFlare proxy OFF do you get Render CDN (Fastly)? Just curious…
Yes, this seems correct to me.
As to which CDN is “better”
I’m not too familiar with Fastly, but I imagine it’s configured in the most generic way possible. With Cloudflare however, you get full control over how it behaves. So if you want the flexibility and added features you might want to use Cloudflare.
That said, it’s probably best not to overthink it. Maybe even better to disable Cloudflare proxying, until you need it. That way your setup is a bit simpler and easier to troubleshoot for Render in case you run into any problems.
1 Like
My point was not to overthink the CDN. Both good.
I think the way you get https in both is to first turn off proxying at CF. Wait until Render resolves the DNS for the custom domain and adds its certs. Then, turn CF proxying on. That’s what someone from Render suggested to me.
- Lewis
1 Like
@lewisl Thanks for this thread.
@marc Thanks for your 8-step process. I followed it and had zero issues, which is always nice.
I would also like an answer to this question:
@jake Can you confirm that once set up, the SSL certificate will auto renew without having to disable proxying again? It’s not clear to me why disabling it’s necessary, but I think it has to do with the Let’s Encrypt challenge?
Will Render be able to get a Let’s Encrypt cert with Cloudflare proxying enabled?
I want to enable “Full (Strict)” mode at Cloudflare which requires a valid CA signed certificate from the Render side.
1 Like
Our site went offline due to this. We have Cloudflare in front of Render. It seems like Render was unable to renew our cert with Lets Encrypt (there was about 29 days left on the cert).
We have Cloudflare configured with “Full (Strict)” and Cloudflare suddenly started reporting that the cert served by Render was invalid. Specifically, it reported HTTP 526: Troubleshooting Cloudflare 5XX errors – Cloudflare Help Center
It seems two things went wrong:
- Render should not have stopped using the existing cert (which still had 29 days remaining) just because it could not renew it with Lets Encrypt
- With Cloudflare enabled, Render should still be able to renew a cert with Lets Encrypt. It should be able to use the HTTP-01 challenge to do so.
Our Cloudflare settings:
Ping @jake
And the rest of our settings:
(The forum software doesn’t let me attach more than one image as a new user)
I suspect the issue is with always using HTTPS: Cloudflare never sends us the HTTP-01 request because it redirects it to HTTPS. @Hao-Ji_Wu has been digging into this on our end and we’ll keep you posted here.
We return 301s for all HTTP requests that aren’t ACME HTTP-01 challenges, so if CF respects that 301, you won’t need to enable the Always HTTPS setting there.
That makes sense! We don’t really need the “Always Use HTTPS” settings since we also set that header in our Node server. Nice that Render sets it too.
We’ll give disabling “Always Use HTTPS” a shot. Is there a way to force Render to regenerate the cert early so we can test if this solution works?
We tried testing on a new subdomain to see if Render could generate a cert with the Cloudflare “Always Use HTTPS” setting off. But it seems like Render refuses to generate a cert if the DNS doesn’t point to the Render CNAMEs. We see “DNS update needed” so we had to disable the Cloudflare Orange Cloud to get it to generate the cert, which means we really didn’t test if it can generate a cert behind the Cloudflare proxy.
1 Like
Yeah: we’re discussing this behavior internally and will probably add other ways to mark a domain verified on our end.
1 Like