Cloudflare Access broken on iOS 14

I’ve opened support ticket #1972356 for this, but lately the responses I’ve gotten from support have been unhelpful until I ask for escalation on the forums, so I’m posting here as well. The support representatives always assume it’s something naive on my end; I understand that’s probably the case for most support requests they receive, but they’re unable to recognize when an issue isn’t the result of customer error.

iOS 14 appears to be incompatible with Cloudflare Access. I reported the issue to Apple early in the beta; they’ve fixed most of the issues I’ve reported, but they’ve given no indication that they plan to fix compatibility with Cloudflare Access. Given that the anticipated iOS 14 stable release date is fast approaching, it may be worth looking into this on Cloudflare’s end.

Attempting to load a site behind Cloudflare Access on iOS 14 usually results in a blank page or 0-byte download. For example, the following pages are typically inaccessible on iOS 14:

A factory reset may temporarily work around the issue, but it will always return.

The issue is not related to the backend server. Our servers never even see the requests because the issue occurs as part of the redirect response returned by Cloudflare:

  1. User visits
  2. User hasn’t yet authenticated with Cloudflare Access, so Cloudflare attempts to return a 302 response with a redirect to
  3. Safari doesn’t see the correct key for the Location header; it shows an empty string as the header key

Example response headers, as reported by Safari’s network inspector:

Set-Cookie: __cfduid=...; expires=Thu, 08-Oct-20 19:29:33 GMT; path=/;; HttpOnly; SameSite=Lax; Secure
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Date: Tue, 08 Sep 2020 19:29:33 GMT
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Vary: Accept-Encoding
Alt-Svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400
cf-request-id: 0510caf8fb0000153a9da18200000001
Server: cloudflare
expect-ct: max-age=604800, report-uri=""
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
cf-ray: 5cfb143b2fd3153a-EWR

Note the line between “Very” and “Alt-Svc”: it’s missing a header name.

There is a HAR attached to the support ticket, but I can’t upload it here, as it isn’t a permitted file type.

Update: If I try to manually navigate to the redirect URL, Safari “loads” indefinitely. The request doesn’t appear in the network inspector, so there’s no way for me to figure out what happened. To make matters more interesting, despite nothing appearing in the network tab, Safari shows’s address bar shows that I’ve been redirected from the original URL to… If I wait long enough, sometimes the redirect chain eventually appears in the network inspector, though it usually gives up without any entry or just loads indefinitely. When it does appear, I see the following redirect chain:

  4. Attempt to redirect to…, although it never succeeds because the header name is empty instead of Location.

Update 2: By manually visiting different URLs along the redirect chain, I can get slightly different behavior, but it always gives up at step 4. Nowhere along the way are the correct cookies set; the only Set-Cookie header I ever receive is for __cfduid, even when I get redirected back to I’ve tried disabling any experimental features related to cookies.

I see the same, was always meaning to contact @SamRhea about it, but always forgot :confused:

Works on other browsers, but not on Safari on any of the new versions (both iOS and macOS). I can’t get into Argo Tunnels with Access (need to copy and paste the URL into Chrome), often can’t login into Cloudflare’s dashboard and sometimes it doesn’t work on Access.


Thanks for the heads up! Are both of you on the public beta or developer?


I joined the developer beta, but there’s no clear indication anywhere on my device that I’m in the developer beta as opposed to the public beta. I joined before there was a public beta. Specifically, I’m on 14.0 (18A5369b), running on an iPhone 11 Pro (MW9V2LL/A).

Developer. Last public beta should be the same build though.

One of the devices it’s exactly the same.

Thanks for the reports!

Have either of you noticed this on macOS or is it just iOS14? I believe that you said you have seen this behavior on macOS @matteo but I just wanted to double check.

I personally haven’t been able to replicate yet, but I think a new update just dropped today. So the issue might have been fixed in the versions i’m running. I’m in the public beta on my mac (20A5364e - safari 16610.2.2.4) and it seems to work as expected so far, although I’m still testing. We were also able to test an iPhone XR, iOS 14 (18A5319i), Safari and it also worked as expected. Downloading the public beta to my ipad to try it out there. (edit: ipad works)

If you get a chance to try out the new release let me know.

1 Like

I haven’t noticed in Safari Technology Preview on Catalina, but I don’t use that much.

It doesn’t always happen immediately, but once it starts, it’s practically impossible to recover without wiping the whole device–wiping Safari’s data might work once or twice, but eventually it stops working. It might appear on a fresh install, or it might require a few weeks of heavy use.

I’m installing Beta 8 now; I’ll report back with the results.

That’s good to know. I’ll keep an eye on it.

I have seen them on most cases on iOS 14/iPadOS 14 (18A5369b) and macOS 11 (20A5364e, same as you). All dev betas, latest versions.

I have 2 main issues, they may be all related to macOS.

  • On the Cloudflare SSO login when it redirects back it shows a blank page without seemingly any error on the console. I can’t login into support on Safari.
  • On Access if the start hostname includes _ or - (maybe only one of them, but only have hostnames with both or none of them) it fails to compeltely establish a secure connection as if the cert is invalid. This includes issues while using SSH/RDP. I imagine it can be an issue with macOS’ networking stack, though.

Updating to beta 8 now…

Still an issue on Beta 8.

@james, if you’re still having trouble reproducing it, I wouldn’t doing a video call with screensharing so you can troubleshoot via my devices.

This may be an issue with HTTP/3. When I disable the HTTP/3 experimental feature and restart Safari, it correctly interprets the Location header. However, it’s also possible that disabling that feature just resets some internal, otherwise-persistent state, and that the issue will return.

I don’t see a way to enable HTTP/3 in the macOS Safari Technology Preview; there’s no experimental feature option for it, and it’s not using HTTP/3 by default. Safari for iOS 14 has the HTTP/3 experimental feature enabled by default.

It doesn’t change anything for me, unfortunately :frowning:

It took a few restarts to get the toggle to take effect. Try visiting /cdn-cgi/trace to make sure it’s actually disabled.

@Zenexer Thanks to your latest comment I was able to replicate! If I turn on http3 in the experimental options and have http3 turned on in my cloudflare dash I can see this behavior.

I’ll post updates as we investigate this. Thanks again for all the help debugging!


I fear mine is a different issue… Tomorrow I have time and will test things.

I suspect it may affect HTTP/2 as well, as I was previously able to reproduce it with HTTP/3 disabled. What happens if you disable both HTTP/2 and HTTP/3 for your website?

Small update. At least with the HTTP/3 related problem, we were able to get in contact with Apple and they identified the issue. We are working with them to figure out next steps right now.


That is a great update! :smiley:

Happen to get any more info from Apple or an ETA on this? I’ve got a growing list of iOS 14 issues; it would be nice to be able to check this one off. Although, it worth noting that only one of my devices had that experiment enabled by default upon upgrading, but that’s not a very large sample size.

1 Like