# Endless loading behind Cloudflare **URL:** https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596 **Category:** Support **Tags:** cloudflare **Created:** [May 2, 2025, 10:18pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596 "2025-05-02T22:18:04Z") **Posts on this page:** 17 **Page:** 1
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 2, 2025, 10:18pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/1 "2025-05-02T22:18:04Z")
We moved our server from one VPS provider to another and I upgraded the instance via `launcher rebuild` to the latest version as well, from `3.5.0.beta3` to `3.5.0.beta4`. The instance was always running fine behind Cloudflare, but now trying to access it leads to endless 5 dots loading animation. I have a hosts file entry on my local system to bypass Cloudflare, since my ISP (Deutsche Telekom AG) has shitty peering policies so that access is very low through Cloudflare by times. So at first I did not recognize the issue, as access without Cloudflare works fine. So I upgraded the instance, and hence am now not sure whether the changed VPS or the Discourse upgrade was the relevant change. I assured via VPN and mobile network, that the issue really is Cloudflare itself now, not the bad peering of my ISP, and also other users face the same issue. Old and new VPS have IPv6 available, and the whole system is exactly the same, transferred as raw image file. There are zero error message, neither in browser (console), nor by the host system’s proxy, nor by Nginx within the container, nor by Rails or anywhere else. The HTML documents and several scripts load fine, and comparing them with those served when bypassing Cloudflare show that everything (I checked) is identical. Also response headers look mostly the same, aside of a few Cloudflare-specific ones, of course. The last things I see being loaded is the mini profiler: ![The image displays a line of code highlighting an HTTP request to fetch an XML file with various processing instructions and a file size of 14.5 KB received in 568 ms. (Beschriftet durch KI)](https://global.discourse-cdn.com/meta/original/4X/d/a/1/da1f8e4d96fc233139d02046e470007b09296575.png) Of course clearing browser cache, using private windows etc all did not change something. Also clearing/disabling the Cloudflare cache does not help, so the cache is not the issue. I temporarily disabled the CF cache completely for the whole forum. Notable to say that the forum runs on a sub path behind an Apache proxy on the host, following these instructions: [Serve Discourse from a subfolder (path prefix) instead of a subdomain](https://meta.discourse.org/t/serve-discourse-from-a-subfolder-path-prefix-instead-of-a-subdomain/30507) Previously, we created just a `ln -s . forum` symlink instead of the uploads/backups symlinks and doubled rewrites of the instructions, which worked well for years (and also now without Cloudflare), but as part of my debugging efforts I switched to those instructions to assure the internal proxy applies all rules as intended. Trusted header is `CF-Connecting-IP`, though I enabled `cloudflare.template.yml` as well, even that it doubles things somewhat. And I also tried to change back and forth various parts of these templates and above instructions, also in attempt to check whether the proxy IP headers do any difference, as missing `CF-Connecting-IP` is one thing when bypassing Cloudflare. At this point I am completely out of ideas, have not a single trace where the issue might be coming from, not a single related log/output anywhere. Through Cloudflare, Discourse just hangs in loading animation without further trace. I hope someone has an idea how to debug this, or whether there was a change between `3.5.0.beta3` and `3.5.0.beta4` which could be related. I guess a downgrade is problematic? This is the instance: [https://dietpi.com/forum/](https://dietpi.com/forum/) EDIT: I disabled Cloudflare for now. But there is a CNAME which is still passed through Cloudflare, so those two can be compared: [https://www.dietpi.com/forum/](https://www.dietpi.com/forum/) ---
### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ) #### Post date: [May 3, 2025, 10:59am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/3 "2025-05-03T10:59:11Z")
Interesting problem. It’s simply [https://www.dietpi.com/forum/](https://www.dietpi.com/forum/) that is hanging forever. ```plaintext $ wget https://www.dietpi.com/forum/ --2025-05-03 10:52:18-- https://www.dietpi.com/forum/ Resolving www.dietpi.com (www.dietpi.com)... 104.21.12.65, 172.67.193.183, 2606:4700:3035::6815:c41, ... Connecting to www.dietpi.com (www.dietpi.com)|104.21.12.65|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: âindex.html.1â [<=> ``` The interesting thing is that calls like [https://www.dietpi.com/forum/site.json](https://www.dietpi.com/forum/site.json) do succeed. [https://www.dietpi.com/forum/t/why-there-are-two-kernals-in-my-raspberry-pi4/23355](https://www.dietpi.com/forum/t/why-there-are-two-kernals-in-my-raspberry-pi4/23355) does not work and hangs forever, but [https://www.dietpi.com/forum/t/why-there-are-two-kernals-in-my-raspberry-pi4/23355.json](https://www.dietpi.com/forum/t/why-there-are-two-kernals-in-my-raspberry-pi4/23355.json) does. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 3, 2025, 12:19pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/4 "2025-05-03T12:19:30Z")
Interesting indeed. I recognize just now that the HTML documents are not loading completely but hang at some point. I compared `/forum/` in both cases and thought they were identical, but probably I was focusing too much on the head, while parts of the body at the bottom are missing. That last line when loading via Cloudflare: ```html Do you have some optimization enabled? ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 3, 2025, 12:58pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/6 "2025-05-03T12:58:30Z")
Nope, no (content) optimizations. I did have the 103 Early Hints feature enabled, but disabled it already as attempt to solve things. Tried the same with the protocol settings, but that did not change anything eiher: ![The image shows a settings page for HTTP/2 configuration, including options that highlight HTTP/3 with QUIC and Enhanced HTTP/2 Prioritization, with a prompt to upgrade to a Pro plan for the latter feature. (Captioned by AI)](https://global.discourse-cdn.com/meta/original/4X/7/c/8/7c86cbb6a43d61ccd432fc07d697744f5e9f2ecb.png) Btw, there is no `content-length` response header, could that cause an issue? I mean it does not exist when bypassing Cloudflare either, but probably Cloudflare then has some issue? EDIT: No seems to be normal for dynamic pages, same with our Wordpress and Matomo pages which however do not cause any issues. And another find when playing with `curl`. Printing to STDOUT results in full HTML document being displayed, but it still hangs and at the end: ```html

Powered by Discourse, best viewed with JavaScript enabled

``` But when trying to save it via `-o` or simple redirect, or even just piping into `grep`, it hangs at a different place: ```html
General Discussion ``` And I can 100% replicate this very same 73728 bytes when accessing `https://www.dietpi.com/forum/` with curl without just printing it to console right away. This is so weird 🧐. * * * So: - All clients hang at loading any HTML document from our Discourse instance. - Each client hangs at the very same byte when loading the same page. - Different clients hang at different points, but at the very same byte when repeating with the same client. - Each page hangs at a different point in the document and at different downloaded size. - The same tool `curl` hangs at different points when just printing to STDOUT vs piping or storing the document somewhere. - `wget` is able to download the full document (at least `https://www.dietpi.com/forum/`) to a file, but still hangs at the end, same when `curl https://www.dietpi.com/forum/` prints the full document to console, but hangs at the end. ---
### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ) #### Post date: [May 3, 2025, 2:55pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/7 "2025-05-03T14:55:32Z")
> [@MichaIng](#): > > Yeah each page/HTML document hangs at the very same character when loaded via browser again and again, in private window etc. I think that might be buffering. But when investigating, I noticed something else. `wget -O - https://www.dietpi.com/forum/latest` Ends with ```plaintext ``` But the connection is never closed. Theory: there is a configuration issue somewhere where there is a mismatch in HTTP versions or headers (like keep alive connection) and this only becomes a problem when a document is larger than X (I suspect 64KB). ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 3, 2025, 3:16pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/8 "2025-05-03T15:16:45Z")
Yes, `wget` always downloads the whole document, and `curl` does so when printing directly to console, but connection is not closed. Same happens with much smaller documents, like I tested a 14k one of a topic with only 2 posts. But even the smaller ones usually are not fully downloaded by `curl` when piping or storing to file, neither in browser. Both tools always show HTTP/2, and in Cloudflare I have HTTP/2 origin requests enabled. But worth to test using other HTTP versions explicitly. Yesterday I disabled all protocol settings in Cloudflare seen on the screenshot above, and it did not help. But I’ll try again. Also I can enable access logs on the server to see the actually incoming request from Cloudflare. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 3, 2025, 5:30pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/9 "2025-05-03T17:30:26Z")
I tried all combinations of supported HTTP (1.1-3) and TLS (1.2-1.3) versions, but that does not make a difference. I also disabled HTTP3 support, HTTP2 origin requests this 0-RTT connection resumption again. No difference, `curl` keeps hanging at exactly the same 73,728 bytes of `https://www.dietpi.com/forum/`. Regarding the theory of too large document sizes, `https://www.dietpi.com/dietpi-software.html` has 199,475 bytes and loads perfectly fine. I should mention that the server (same webserver) hosts a static website, MkDocs instance, Wordpress, Matomo, which all work perfectly fine. Also there is a Grafana instance where the front webserver acts as proxy via UNIX socket. But I agree it seems to be related to buffers or chunk sizes or something like that. It is just weird that the downloaded size until hang varies so much between clients and pages, while it remains exactly the same despite changing protocol versions, and that the connection is not even closed when the document has been fully downloaded. Like if the stop signal is missing, though I am missing insights into HTTP at this point. Hence I thought about `content-length` header, but that one is obviously not mandatory. The webserver also acts as proxy for the Discourse container via UNIX socket. I could enable the TCP listener to make the Discourse instance additionally available without the proxy (leaving the Nginx within the container, of course). ---
### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ) #### Post date: [May 3, 2025, 6:30pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/10 "2025-05-03T18:30:25Z")
Could you try `KeepAlive Off` in Apache? > [@MichaIng](#): > > I could enable the TCP listener to make the Discourse instance additionally available without the proxy (leaving the Nginx within the container, of course). I guess that would at least possibly rule out the webserver, so that would be worth a try. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 3, 2025, 7:03pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/11 "2025-05-03T19:03:53Z")
> [@RGJ](#): > > Could you try `KeepAlive Off` in Apache? No change. Also from Apache docs: > In addition, a Keep-Alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. Hence as of missing `content-length` probably it makes sense that it is not used anyway for this request. > [@RGJ](#): > > I guess that would at least possibly rule out the webserver, so that would be worth a try. Since it requires a rebuild, I’ll do a little later when our common website activity is at a minimum. Um, I am just thinking about HTTPS … looks like I need to do some custom adjustments to the internal Nginx config to keep the UNIX socket functional as well as plain HTTP connections, while listening on an additional port for HTTPS with the TLS certificates from the host, but without HTTPS redirect/enforcement. … and additional plain HTTP TCP port would be also interesting, for clients which can ignore HSTS. ---
### Author: ![tdperry](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tdperry/32/496593_2.png) [@tdperry](https://meta.discourse.org/u/tdperry) #### Post date: [May 4, 2025, 12:29am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/12 "2025-05-04T00:29:17Z")
Are you by chance using RocketLoader in CloudFlare? I know with some other scripts it causes issues. Also, did you clear the CF cache? Are you using inbound rules on CF that may have been tied to your old VPS IP address and not updated to the new one? ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 4, 2025, 10:53am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/13 "2025-05-04T10:53:39Z")
No RocketLoader: Note that as of above tests with `curl` and `wget`, which do not interpret any syntax, hence do not load any JavaScript or styles or anything else, the problem is that the download of the raw HTML document always hangs. Cloudflare cache is not active for the forum, the raw HTML documents were never cached anyway. No VPS-specific rules. Generally not rules for the forum, aside of to bypass cache. The issue appears in both cases, so cache isn’t the issue either. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 11, 2025, 1:23am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/14 "2025-05-11T01:23:32Z")
While testing to bypass the Apache2 proxy at the Discourse container host, and disabling forced HTTPS redirects at Cloudflare to test plain HTTP connections via `curl` as well, I finally found the culprit at Cloudflare: ![The image shows a feature labeled "Automatic HTTPS Rewrites" on a web settings page, designed to automatically change "http" to "https" for all resources or links on a website, with an option to create a configuration rule by hostname. (Captioned by AI)](https://global.discourse-cdn.com/meta/original/4X/0/a/6/0a6c4c39b2548f843b2d5e3edd1ed4370f25330e.png) > **[Automatic HTTPS Rewrites](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/automatic-https-rewrites/)** > > Fix mixed content by rewriting HTTP URLs to HTTPS in page responses. I am not sure what changed with our VPS switch and/or Discourse 3.5.0.beta3 to 3.5.0.beta4 upgrade and/or coincidentally at Discourse at the same time, but it seems that something in the Discourse HTML, CSS or JavaScript documents causes Cloudflare’s HTTPS rewrite of embedded URLs to choke. Looks like the partial and hanging `curl` requests were not really related, or maybe they are. Weird that in the browser network tab one can see the partial content of HTML document, as if the HTTPS rewrite feature does it while streaming through the document. Does maybe someone else have an instance and a Cloudflare account to test this with, whether it is a general issue or related to our particular instance/setup? Btw, to test bypassing the proxy as well as HTTP, while keeping the connection via proxy active, manually adjusting the Nginx config within the container like this works perfectly fine: ```plaintext root@dietpi-discourse:/var/www/discourse# cat /etc/nginx/conf.d/outlets/server/10-http.conf listen unix:/shared/nginx.http.sock; set_real_ip_from unix:; listen 8080; listen [::]:8080; listen 8443 ssl; listen [::]:8443 ssl; http2 on; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_certificate /shared/fullchain.cer; ssl_certificate_key /shared/dietpi.com.key; ssl_session_tickets off; ssl_session_timeout 1d; ssl_session_cache shared:SSL:1m; ``` Important to remove HTTPS redirects and HSTS header, of course, and to expose the added ports. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 11, 2025, 2:41am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/15 "2025-05-11T02:41:34Z")
And another find: We use [`mod_sed`](https://httpd.apache.org/docs/current/mod/mod_sed.html) to add our Matomo tracker code to all `text/html` responses, right in front of the `` end tag. Disabling it for Discourse (or bypassing the Apache2 proxy) solves things as well, despite Cloudflare Automatic HTTPS Rewrites active. To disabling either of both solves things. On all other pages the combination works fine, also on very large pages we have, larger than failing forum pages. So maybe the two filters, first `mod_set` on our proxy and then the embedded URL rewrites by Cloudflare cause something to break, related to document or chunk sizes or whatever. We embed the tracker via Discourse theme edit now, and I additionally disabled the Cloudflare Automatic HTTPS Rewrites. There is no mixed content on our whole website. And if there is, good to see and fix it, instead of having Cloudflare masking it forever. ---
### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman) #### Post date: [May 11, 2025, 10:27am UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/16 "2025-05-11T10:27:14Z")
> [@MichaIng](#): > > to test plain HTTP connections via `curl` as well, I’m pretty sure that can’t work. I’m not quite sure what problem you’re trying to solve, but you probably need to enable force\_https in your app.yml. ---
### Author: ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng) #### Post date: [May 11, 2025, 1:36pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/17 "2025-05-11T13:36:24Z")
I imagine just from the name “Cloudflare Automatic HTTPS Rewrites” it can be misunderstood. Cloudflare has 2 features: - “Always Use HTTPS” redirects all plain HTTP requests to HTTPS, just like `force_https` in Discourse does. Both were previously enabled, and I disabled both to test whether HTTPS has anything to do with the issue or the endless loading Discourse pages and hanging `curl` requests. This worked perfectly fine, even solving the whole issue for HTTPS requests as well, but just because I disabled “Cloudflare Automatic HTTPS Rewrites” in the same turn. - “Cloudflare Automatic HTTPS Rewrites” alters HTML, CSS and JavaScript documents to replace all embedded plain HTTP URLs with HTTPS variants, where Cloudflare thinks the host is reachable via HTTPS (based on HSTS preload list and such). This is to avoid mixed content warnings. Enforcing or not enforcing HTTPS at Cloudflare, at the host proxy or at Discourse does not matter. What did cause the issue is the combination of `mod_sed` filter at the host proxy and embedded plain HTTP edits by Cloudflare. So two stages at which the content of the documents was passed through a filter. Problem was not that there was any actual content change (there is no mixed content at our site, “Cloudflare Automatic HTTPS Rewrites” hence does not actually change the document body), but probably related to chunks, buffer or timing. ---
### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system) #### Post date: [June 10, 2025, 1:37pm UTC](https://meta.discourse.org/t/endless-loading-behind-cloudflare/364596/18 "2025-06-10T13:37:18Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.