The discussion revolves around whether to use Cloudflare’s name server settings or stick with the host server’s settings when using Cloudflare. Andy02 initially asked the question, and tehspaceg pointed out that Cloudflare’s nameservers are necessary for Cloudflare to work.
Jameshahnii shared their setup, where Namecheap points to Cloudflare, and Cloudflare points to Digital Ocean and Mailgun. Stephen advised to turn off the orange cloud and use the Cloudflare proxy after installation completes. However, Stephen also mentioned that a Cloudflare template needs to be added to the app.yml file to get the correct source IPs.
Codinghorror recommended against sending all traffic through Cloudflare, citing potential issues with JavaScript-heavy applications. Jameshahnii turned off the proxy, and Andy02 asked for clarification on why this was recommended. mpalmer mentioned that there are periodic reports of Cloudflare’s optimizations breaking Discourse, and Stephen suggested using a rule to disable disruptive features. However, mpalmer noted that it’s often easier to just not use Cloudflare proxying.
Hi, i have our site spread out across three servers, with Discourse on its own server. Right now the name server on the server hosting Discourse is set to use the default values (ns1.digitalocean.com, ns2, etc).
As the entire site is connected and piped through cloudflare, should i update the nameservers on the server Discourse is running on using the cloudflare values instead? or leave it as it is now?
Thank you.
In order for Cloudflare to be used at all, the nameserver for your domain name needs to be through Cloudflare.
You can safely use the Cloudflare proxy after installation completes. Let’s Encrypt doesn’t like it initially, but it uses a different method to renew than enrol.
There is a Cloudflare template which needs adding to the app.yml to get the correct source IPs.
Great. I didn’t know. Where can I find the template … or is that added automatically once you turn it back on?
It’s in /var/discourse/templates if memory serves.
Indeed it was. Copy/pasted into app.yml, ran ./launcher rebuild app and got this error…
FAILED
--------------------
Pups::ExecError: /tmp/add-cloudflare-ips failed with return #<Process::Status: pid 5910 exit 2>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params "/tmp/add-cloudflare-ips"
2b27a4ac57cf9e8f76602ca570ebffce817a001e36a0c898195199d32c63a1d6
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages
Guessing I needed to do more than copy/paste the template?
I still would not recommend sending all traffic through cloudflare, unless you have a compelling reason to do so (as in you frequently get ddosed).
Noted. Turned off again. Thank you.
That’s very interesting @codinghorror, I’ve never heard that before. why would you recommend turning them all off?
We have 6 subdomains across three servers, in a fairly complicated build, they all have the little cloud switched on. We’ve also had issues with not being able to auto-renew our Lets-Encrypt, is that likely to be the issue we’ve had?
Do a search for Cloudflare here on meta; there are periodic reports of one or the other of Cloudflare’s optimisations breaking Discourse (and probably other JavaScript-heavy applications).
It’s easy to use a rule to disable any disruptive features.
Assuming you can identify which feature it is that is causing the problem this time, sure. It’s certainly a lot easier just to not use Cloudflare proxying.