Failure to load, but only on mobile phones over mobile networks with Cloudflare proxy

Was excited about migrating an ecommerce site over to Cloudflare to help boost performance and security, but shortly after activating we ran into a completely baffling issue. I am starting a support ticket, but as a lowly “pro” subscriber I’ve been warned it may take a few days, so I’ll take a stab at crowd sourcing.

Here’s the puzzling fact matrix, that emerged within 12 hours of activating Cloudfare’s proxy service:

  • Certain pages with complex PHP/mysql content completely failed to load on mobile phones connected over mobile network. Multiple phones (iOS and Android), different browsers (Chrome or Safari) in different regions and on different carrier networks. Blank white page with no error message.
  • This blank white page is characteristic of an uncaught fatal PHP error early in the page (especially since other pages with stripped down code still loaded successfully), except that there’s no errors being registered in the PHP log, and…
  • The site loads completely fine on dekstop browsers (of all kinds), and on mobile browsers connected over wifi. The same phone using the same browser successfully loads the site over wifi, then immediately fails after switching off wifi onto the carrier’s data, and attempting a refresh.
  • I attempted loading on a desktop browser over a hotspot connection from a phone, to isolate the issue to the mobile carrier network, but remarkably it worked just fine. A short test, but loaded several dynamic pages, with “no cache” headers, and it was fine. So it’s just mobile phones on mobile networks.
  • Cloudflare has lots of settings directed at mobile, many of which were enabled when the issue was first observed, most notably including “mirage” (notable because it is meant for mobile phones on slower networks). But toggling off all these functions had no immediate effect (within 15 minutes). Neither did purging all of the cache and activating developer mode to prevent further caching.
  • The only thing that resolved the issue was disabling the Cloudflare proxy completely, and just using Cloudflare as a DNS redirecting to the server.
  • I’ve wondered about an SSL issue, but the site has its own publicly authorized SSL certificate, that gets a completely clean bill of health of from the SSL Labs test. The proxy was on “full strict” mode to use this certificate. And this doesn’t really fit with the fact that it loaded fine on wifi, and loads fine now with Cloudflare bypassed.

I’m being encouraged by the message template to give the domain. I’d prefer not to, but if it helps you in some to form an opinion on this then let me know. I’m not going to try enabling Cloudflare again until I at least have an idea for what to try, as this is quite disruptive to the site’s ecommerce business.

I figured it out! I’ll record what happened here, on the off chance that one day someone runs into the same or a similar issue.

The eCommerce website in question is built on an opensource framework, and incorporates some community-developed modules. One of them, added many years ago, was designed to buff the security of the site. It added a series of checks on page load, including, among other things, to deny certain IP “blocklist” addresses, and to permit only certain allowlist IP addresses to load some pages (like, only Paypal IP’s were supposed to be able to load certain pages related to paypal payment processing). There are a variety of reasons this is a crummy way to achieve this, but alas.

The problem wasn’t with any particular IP address being allowlisted or blocklisted, but with a gating check, that, in order to compare the requesting IP with the white and blacklists, first confirmed that the IP was in the expected format. The expected format, at the time, being IPV4, with only numbers and decimal places. An IPV6 address fails this check. And how did the security module handle this? By issuing a “die” command, and presenting a blank page. No error is recorded in the log, because this isn’t an uncaught exception. It’s actually what the code is, incredibly, meant to do!

So why only mobile networks, and why only when Cloudflare’s proxy is enabled? Good question. The IPV6 address that was being passed through with Cloudfare enabled was actually not a Cloudflare IP address, but apparently the originating address of my cellphone carrier where the page load originated. So why didn’t the same error trigger when I loaded the webpage without Cloudflare enabled? That’s just going to remain one of life’s mysteries, because I’m not planning to switch off Cloudflare again to investigate it. In any event with IPV6 starting to finally become more common, it was inevitable that this code was going to cause problems that extended beyond just Cloudflare on mobile phones on mobile networks.

1 Like

Ok, so at the risk of sounding like a complete moron, although I am not the most code savvy monkey on the planet, how did you fix it? I have been having this problem for months with no end in site and no one who could figure it out. I have removed my site from CF because of it, but really want to get back on. Sincerely, Dean
Go Leafs

I disabled the security module that was filtering traffic based on the IP address, and which was confused when handling IPV6 addresses. It’s not a very effective way to filter traffic to begin, that’s much better left for firewall rules, and Cloudflare offers loads of them by default.

Unless you installed the same very specific module that I did, your issue may be different. But if you’re getting a blank white page, and nothing is registering in the apache error log, then I’d search your code for a “die” command (at least that’s what it is in PHP, i’m not fluent in other languages).

If you’re not checking your error log, then you definitely need to do that before concluding it’s something like what I experienced. The really weird thing in my case was that no error was being registered, and it was also baffling that it only affected mobile devices (IPV6 is much more common on mobile devices).

1 Like

Hey TW…
Thanks for taking the time. I will have a look.
Sincerely,
Dean

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.