A couple weeks back I attempted to update to the version previous to 2.2.0beta4 (2.2.0beta3 ?) and the same thing happened so I thought I would wait to see if the next one helped fix this.
Suggestions on correcting this would be appreciated, thanks in advance.
Can you please use your browserâs âview sourceâ command to get the HTML source of the home page and provide it here? That will help us pinpoint anything unusual about your setup. Thanks.
Test using safe mode /safe-mode and if that works visit /admin to disable any customisations. Just create a new theme with no changes and temporarily set it to default.
If safe mode works and disabling customisations doesnât restore your front page you need to start disabling plugins to pinpoint the cause.
Ok, I donât currently use any customizations, itâs bone stock. I will certainly still try this though and see what happens.
I do use cloudflare and I set the caching to dev mode ( no caching ) and also purged all cached data to see if that would help. It did not.
Any other suggestions are appeciated, I will let you know what the results are when I try testing using safe mode later. Iâm currently AFK and it takes a bit of time.
Well, turning off the orange cloud defeats the purpose of using Cloudflare and significantly elevates risk. Iâll test though using a burner domain or something, thank you for the suggestion. I would not recommend people doing this as it will reveal your servers IP to crawlers immediately and the damage will be done once logged. Even if you turn orange cloud back on afterwards and have not cycled your IP, Cloudflare will no longer protect your server as the IP will be known.
It wouldnât help to give the URL at the moment because I reverted back to a good snapshot, as users are using the site at the moment. Iâll need to do maintenance in the early hours of the morning.
Thank you again, I will report back later. If anyone has suggestions related to those errors shown, I will gladly test other things as well.
For now itâs a diagnostic step. It doesnât significantly elevate risk unless youâve increased the attack surface of your server and done some very silly things. There are no nefarious âcrawlersâ out to get you, the period of time this would be done for is minimal.
Your server isnât protected by Cloudflare, it actually does nothing to protect the server itself, it only proxies the FQDN, the server IP is still as vulnerable with or without it turned on. The kinds of attack you should be worried about are bots scanning entire subnets of machines, which priorities the ranges allocated to VPS services.
Thatâs an exaggeration, Discourse only needs one rule to work with cloudflare, there are plenty of servers which use it with Discourse.
Itâs always stuff added beyond that, such as apps and other rules which cause the problems. This week alone weâve had a number of good examples.
Either way, Cloudflare doesnât do anything to harden a server beyond masquerade the FQDN. Servers which which use it are easily identifiable. Assuming it affords some additional level of protection beyond the proxy demonstrates why it can lull people into a false sense of security and actually make you more vulnerable, instead of less.
I respectfully disagree with you. There are in fact crawlers whose job is to continuously crawl domains, resolve the IP and log the DNS info. In fact, itâs a huge market.
If you use Cloudflare properly, no one should ever know your servers true IP. Hence, itâs security through obscurity. I could give you a domain which has properly used Cloudflare and even the class B subnet the server is on and I doubt you will be able to correlate the two, unless of course, you slip and create an A record which has the servers true IP in it, which will get logged very quickly.
I digress, the intent of this topic is derailing. If you would like to discuss passive DNS, crawlers and opsec. I will be happy to do so in another category/thread.
Thatâs 19 addresses over 9 years for the front end site, and even viewdns admits that they donât track subdomains. I donât think youâre making the point you think you are.
Either way, it looks like youâre on your own fixing this. Good luck!
Discourse works with Cloudflare, itâs almost certainly something youâve done to yourself, as to what we canât say without more information that youâre either unwilling or unable to provide.
Weâre not really ones for tech support whilst blindfold and at least one arm tied behind our back(s). At least not for free.
You donât want anything interfering with the javascript or how the page is loaded, which minification and rocket loader will do. Both usually end up with the issue youâre reporting.
If you want to cache assets then only turn that on after proving the site works with the above, and even then only use standard caching with /uploads/* - caching other stuff isnât supported.
Knowing the FQDN helps us use other tools to look, but as we donât have it we will skip that stage entirely.
That should be the only rule touching your site. If you have any others which risk overlapping then for now just shut them off.
If that doesnât work then itâs time to look at apps.
Because your upgrade triggered the problem though itâs also still possible this is due to an old plugin. You said your install is bone stock, but do you mean just in terms of customisations? Are there any plugins added to the app.yml beyond the defaults? Broken plugins are also going to rear their heads during an upgrade.
I thought this page rule was already set but it was not. So I added this page rule for the domain and it seems to be working again . Also, it had worked fine up until two updates ago, .
Great suggestion and thank you for your time. Iâll continue to test and monitor.
. Also, it had worked fine up until two updates ago, 
.