Page could not be loaded

[ekool]

After switching from the Let's Encrypt SSL cert to Google Trust Services for the SSL cert (as modern let's encrypt can have a compatibility issue with iOS 13 or older), and disabling HTTP/3 (QUIC) the issues appear to be resolved for my client.

The ticket from Cloudflare had this as the "explainer" for the http/3 (quic) issue, but only once I mentioned that I disabled this option.

It took an annoyingly long time to get to that point, and they didn't suggest the http/3 (quic) option may be the cause.

I'm seeing this issue, even on Chrome on a brand new Macbook Pro. I don't think it's a browser issue.

I hate the idea of disabling HTTP3/QUIC because it does make the sites faster. I feel like the issue isn't a browser issue. I think we need to dig into this more.

 

[eDaddi]

What a PIA this one was to discover.

Went down a few rabbit holes ... turns out it was the HTTP/3 (QUIC) setting thats been set on CF for 5yrs.

 

[eric990]

I've been chasing this problem for months for my Firefox and Safari users. Disabling http3/quic in Cloudflare solved the problem but didn't seem like an ideal solution.

Today in Cloudflare I disabled caching for css.php and proxy.php and purged the cache for those files. Afterwards I reenabled http3/quic and I'm no longer seeing any issues, but I'll continue to monitor.

Edit: My users had to purge their browser cache to clear out the css.php and proxy.php files, but they're reporting no issues now.

 

[eDaddi]

I've been chasing this problem for months for my Firefox and Safari users. Disabling http3/quic in Cloudflare solved the problem but didn't seem like an ideal solution.

Today in Cloudflare I disabled caching for css.php and proxy.php and purged the cache for those files. Afterwards I reenabled http3/quic and I'm no longer seeing any issues, but I'll continue to monitor.

Edit: My users had to purge their browser cache to clear out the css.php and proxy.php files, but they're reporting no issues now.

Curious what got you looking at those two? I found a longwhile back to add CF rules TO cache those. I had Claude CLI dive into my local host and it came back with diffrent potential issues coinciding with this HTTP/3 Issue.

 

[eric990]

Curious what got you looking at those two? I found a longwhile back to add CF rules TO cache those. I had Claude CLI dive into my local host and it came back with diffrent potential issues coinciding with this HTTP/3 Issue.

I was reviewing my Cloudflare logs for something unrelated and happened to notice ~25% connection failure rate just for those 2 files, which I recognized as the only 2 php files that I had enabled caching. I'm still scratching my head on how this caused the problem, tbh.

 

[eDaddi]

I was reviewing my Cloudflare logs for something unrelated and happened to notice ~25% connection failure rate just for those 2 files, which I recognized as the only 2 php files that I had enabled caching.

interesting.... I just did some digging at those two files ... one thing that likely made it worse on my end: my css.php was responding with Vary: User-Agent … so every bot UA (and there were a ton until now) got its own cache entry …. near-zero hit rate for crawler traffic ... every miss hitting PHP and spawning another cached variant.

I was reviewing my Cloudflare logs for something unrelated and happened to notice ~25% connection failure rate just for those 2 files, which I recognized as the only 2 php files that I had enabled caching. I'm still scratching my head on how this caused the problem, tbh.

I read ... somewhere ... that the recent updates from the browsers and how the HTTP/3 -> HTTP/2 fallback works is what is failing the user's browser ... I would think there would be a lot more info on the web about it though ...

 

[eric990]

I've been chasing this problem for months for my Firefox and Safari users. Disabling http3/quic in Cloudflare solved the problem but didn't seem like an ideal solution.

Today in Cloudflare I disabled caching for css.php and proxy.php and purged the cache for those files. Afterwards I reenabled http3/quic and I'm no longer seeing any issues, but I'll continue to monitor.

Edit: My users had to purge their browser cache to clear out the css.php and proxy.php files, but they're reporting no issues now.

Following up on this because the problem returned a few days later (when I made a css edit?), so I turned caching back on for those files and disabled http3 again.

BUT last week I added

$config['enableGzip'] = false;

and

$config['enableContentLength'] = false;

to my config.php so that nginx could handle the compression itself and, after a Cloudflare cache purge, this has completely fixed the http3 problems for my forum. Firefox and Safari connections no longer hang and Chrome has stopped constantly swapping between ipv4/ipv6.

I'm not sure which one (or both) actually fixed this issue, so I'm curious if this works for anyone else.

 

[Joe Link]

Following up on this because the problem returned a few days later (when I made a css edit?), so I turned caching back on for those files and disabled http3 again.

BUT last week I added

$config['enableGzip'] = false;

and

$config['enableContentLength'] = false;

to my config.php so that nginx could handle the compression itself and, after a Cloudflare cache purge, this has completely fixed the http3 problems for my forum. Firefox and Safari connections no longer hang and Chrome has stopped constantly swapping between ipv4/ipv6.

I'm not sure which one (or both) actually fixed this issue, so I'm curious if this works for anyone else.

Thanks for the update. Which version of XF?