Solving Connectivity Problems Caused by Interlocking Apple Privacy Settings
Complaints about website loading have been trickling in of late, and while the details vary, the commonality has been that the problems started with macOS 12.4 Monterey. Sometimes the problem was just with Safari; other times, it affected Chrome and other browsers too. In some cases, the entire page would refuse to load; in others, only portions of the page would fail.
The solution to the problems I’ve seen so far is simple: in System Preferences > Network, turn off Limit IP Address Tracking for each network adapter you use (Ethernet and Wi-Fi below—they look surprisingly different).
For some people, the problems have extended to iOS 15 and iPadOS 15. Apple provides the same Limit IP Address Tracking option in Settings > Wi-Fi > YourNetwork and Settings > Cellular > Cellular Data Options.
If you read the fine print underneath the iPhone screenshots above, you’ll notice that it says, “When this is turned off, iCloud Private Relay will also be turned off for this network.” That message appears on my iPhone because I do have iCloud Private Relay enabled for the iPhone, whereas I turned it off on my Mac.
I wish I better understood what’s happening here, but it’s devilishly difficult to test a feature that prevents tracking by malicious actors, given that I’m neither malicious nor an actor. Clouding the situation even further is the fact that features that say they’ll limit IP address tracking or hide your IP address exist in three completely separate places:
- iCloud Private Relay: This overarching privacy feature routes all your traffic through two separate Internet relays to hide your IP address from the site to which you’re connecting. You can turn it on and off in System Preferences > Apple ID on the Mac and Settings > YourName in iOS and iPadOS.
- Limit IP Address Tracking: This option is either enabled or disabled for each network you use, whether Wi-Fi, Ethernet, or cellular. As noted above, its description changes depending on whether iCloud Privacy Relay is on or off.
- Hide IP Address: Safari and Mail both offer this option in their preferences but say little about how it relates to iCloud Private Relay.
Here’s what I think is going on and where I’m unsure. I hope you can use this information to walk the fine line between increased privacy and more frequent connection problems.
iCloud Private Relay
The first thing to check if you experience sporadic networking failures is iCloud Private Relay. This feature, available only to iCloud+ subscribers who pay Apple for additional storage space, routes all your traffic through two Internet relays, one run by Apple and another run by a major content-delivery network like Akamai, Cloudflare, or Fastly. Apple has a white paper that explains it in detail, but here are the basics.
The privacy win is that only your ISP and Apple know your IP address because your ISP and the first relay (called the “ingress proxy”) have to associate the connection with you to send the response back to you. The address of the website you want to load is encrypted, however, so neither your ISP nor Apple knows where you’re going.
The second relay (known as the “egress proxy”) assigns a new, temporary IP address to the request, decrypts the address of the destination website, and completes the connection to the remote site. In other words, the egress proxy doesn’t know your IP address—it gets only enough information to locate you in roughly the right region of the world so geolocation isn’t a problem.
Apple acknowledges that iCloud Private Relay can cause problems, in part due to the new transport protocols it uses. iCloud Private Relay also takes over from your DNS servers, which may account for some of the problems; at least one user had a Pi-hole ad blocker installed. macOS tells you this when you specify DNS servers in System Preferences > Network > YourNetwork > Advanced > DNS.
As a user, however, if you have problems, there are only two things you need to try, as described above:
- Disable iCloud Private Relay entirely. It’s easily turned on and off, so there’s no harm in flipping that switch as needed.
- Disable Limit IP Address Tracking for a particular network. That would let you, for instance, disable it on your iPhone for your home Wi-Fi network while leaving it on for your cellular data connection.
You wouldn’t necessarily guess that Limit IP Address tracking would disable iCloud Private Relay for a particular network, and Apple mentions it only once in its documentation of iCloud Private Relay, saying:
Private Relay can be turned on or off just for a specific network using the Limit IP Address Tracking preference.*
The asterisk points to a footnote that says:
* In earlier versions of iOS, iPadOS, and macOS, this preference is called iCloud Private Relay.
So why did Apple rename that option? Here’s where things get murky. I think it has to do with Limit IP Address Tracking doing more than just disabling iCloud Private Relay.
Limit IP Address Tracking
Apple has said that disabling Limit IP Address Tracking turns iCloud Private Relay off for a particular network. And I think it’s safe to say that if you disable both iCloud Private Relay and Limit IP Address Tracking, traffic will flow normally to and from your ISP and destination sites.
But what about the remaining possibility, where iCloud Private Relay is turned off, but Limit IP Address Tracking is turned on? Here’s where that fine print comes into play. When iCloud Private Relay is turned on, the fine print reads:
Limit IP address tracking by hiding your IP address from known trackers in Mail and Safari. When this is turned off, iCloud Private Relay will also be turned off for this network.
With iCloud Private Relay turned off, the fine print shrinks to:
Limit IP address tracking by hiding your IP address from known trackers in Mail and Safari.
I haven’t been able to find any Apple documentation of what this means, but my guess is that Apple has essentially embedded the iCloud Private Relay approach of routing traffic through two Internet relays into Mail and Safari, such that it affects only requests from those apps. What I don’t understand is what “hiding your IP address from known trackers” means and how it differs from hiding your IP address in general. Let’s investigate.
Hide IP Address
On the Mac, you can go to Safari > Preferences > Privacy to find another Hide IP Address setting. In Mail, look in Mail > Preferences > Privacy, though you must disable Protect Mail Activity to manage the Hide IP Address option separately. (Generally speaking, leave Protect Mail Activity enabled if you can.)
In iOS and iPadOS, you’ll find the equivalent options in Settings > Safari > Hide IP Address and Settings > Mail > Privacy Protection. In Mail, again, you must turn off Protect Mail Activity if you want to control Hide IP Address on its own.
So what do these Hide IP Address features do? With Safari, it’s difficult to know. If you click or tap the Learn More link on either the Mac or iPhone, it takes you to an explanatory page about iCloud Private Relay that offers no insight into the link to Safari.
Mail, however, is more forthcoming. Click or tap its Learn More link, and you’ll get quite a bit of information about how Protect Mail Activity uses a two-hop system that sounds nearly identical to iCloud Private Relay. It even clarifies that if you turn off Protect Mail Activity and leave Hide IP Address enabled, it will continue to “mask your IP address using the same two-separate-internet-relays design.”
In addition, Protect Mail Activity routes all remote content downloaded by Mail through two separate relays operated by different entities. The first knows your IP address, but not the remote Mail content you receive. The second knows the remote Mail content you receive, but not your IP address, instead providing a generalized identity to the destination. This way, no single entity has the information to identify both you and the remote Mail content you receive. Senders can’t use your IP address as a unique identifier to connect your activity across websites or apps to build a profile about you. … If you choose to disable Protect Mail Activity, the Hide IP Address feature will still mask your IP address using the same two-separate-internet-relays design.
I suspect that it’s iCloud Private Relay all the way down.
Putting It All Together
Here’s how I believe we should think about these interlocking settings.
- iCloud Private Relay: At the top level is iCloud Private Relay. Turn it on, and it runs all your traffic through the ingress and egress proxies, providing the highest level of privacy. However, it’s entirely likely that iCloud Private Relay will cause problems, so Apple lets users drop down to a lower level of privacy.
- Limit IP Address Tracking: That’s where the Limit IP Address Tracking option at the network level comes in. You can disable it to turn off iCloud Private Relay selectively or enable it (with iCloud Private Relay disabled) to apply iCloud Private Relay-like traffic routing to traffic from Safari and Mail. But since those apps are quite different—Safari needs to be able to connect to a far more varied set of servers than Mail—Apple separated them as well.
- Hide IP Address: That’s why each app has its own Hide IP Address setting. You might need to turn off iCloud Private Relay, turn off Limit IP Address Tracking, and turn off Safari’s Hide IP Address setting but still want to keep Mail’s Hide IP Address option enabled. It’s conceivable you’d want to disable Mail’s tracking protection and enable Safari’s, but that seems less likely.
Lending support to my theory is that if you disable Hide IP Address for Safari and Limit IP Address Tracking for your network and then turn on iCloud Private Relay, it first prompts you to turn on Safari’s Hide IP Address setting (below left) and then alerts you that it’s disabled for your network (below right).
Again, I don’t know what Apple means when it specifies that Limit IP Address Tracking and Hide IP Address affect only “known trackers.” The Hide IP Address screen in Safari makes the distinction clear—as long as iCloud Private Relay is enabled, you can choose from either Trackers and Websites or just Trackers. Without iCloud Private Relay turned on, you can only choose to hide your IP address from Trackers.
I’ve been unable to find any Apple documentation of how the company identifies known trackers and massages Safari and Mail traffic to protect your IP address from them. What happens when you connect to a remote site that’s not a known tracker? Does Apple send your IP address through in the clear? Perhaps someone who knows how to analyze network traffic could find out, but that’s beyond my skill set.
Realistically, however, what’s important is that if you’re having problems, you can turn off iCloud Private Relay first, and if that doesn’t resolve the issue, turn off Limit IP Address Tracking. If even that’s not enough, turn off Hide IP Address for Safari or Mail.
Otherwise, just leave them all on and enjoy whatever level of additional privacy they provide.
A related setting, “Private Wi-Fi Address” has caused me lots of problems, at least in understanding my network. That changes the MAC address, which is what most routers use to connect IP addresses to actual physical machines. You can disable that on a per-WiFi basis, and I’ve turned that off for the home WiFi. (You’ll get complaints from iOS when you do that…)
It’s pretty easy to see what web servers are seeing for your IP address. You can do a Google search for “what’s my ip” or use one of the sites that shows your IP address.
https://www.whatismyip.com/
https://whatismyipaddress.com/
For example, if you use the Tor browser (which does something similar to Apple iCloud Private Relay), you’ll see a different IP address, that of a Tor exit node. From a Terminal window, you can use the host command to get info about that IP address. Here’s an example using an IP address as seen when browsing with Tor:
host 185.220.100.253
That yields this response which shows the above IP apparently belongs to a Tor exit server.
253.100.220.185.in-addr.arpa domain name pointer tor-exit-2.zbau.f3netze.de.
Doing this, you should be able to compare what happens with the various settings and from using different browsers.
Debugging why a connection fails is more complex, especially when you’re adding two (or three in the case of Tor) intermediates between you and the server you’re connecting to. Some servers will block connections from the Tor network or VPNs, and maybe they will start doing that with Apple’s intermediates as well.
I consider myself a reasonably competent network guy. But the complexity of this just blows my mind. I don’t know how Apple could expect anyone not a certified network engineer to comprehend this, and I’m guessing real network engineers already know how to set up proxies. This strikes me as a solution in search of a problem. I’ve built lots of those!
Think I’ll leave all that off.
I spent a couple of hours trying to understand this aburdly complex, poorly designed feature. The article here is by far the best one I’ve read.
I think there’s a logical error, though:
“You might need to turn off iCloud Private Relay, turn off Limit IP Address Tracking, and turn off Safari’s Hide IP Address setting but still want to keep Mail’s Hide IP Address option enabled.”
This wouldn’t work. The feature would be disabled in Mail too.
See Use Mail Privacy Protection on Mac - Apple Support for more clarity:
“Note: If you deselect the checkbox in Network preferences to limit IP address tracking for your Wi-Fi or Ethernet network, your IP address isn’t hidden from senders when using the network.”
Trackers and a loss of privacy online is a real problem and the motivation for these features. The complexity of this solution is due to the fact that the problem it is targeted toward was intentionally created and frequently refined by nefarious people.
Don’t agree. I use a VPN, uBlock Origin and an email provider with some built-in privacy protection. None of these is complicated.
The problem here, IMO, is very poor, almost Kafkaesque design and the fact that the information which Apple provides is scattered and inadequate.
Apple could simply provide system-wide basic VPN functionality with an on-off switch and add privacy settings to Safari and Mail. The network layer is not necessary. (Who wants to block email and website trackers in network A but not in network B?)
My guess is that 95+ out of 100 people have no idea how to set this up.
I don’t know if this pun was intentional, but it made me smile in any case
Sometimes public WiFi networks are persnickety about what you can and can’t do with them (e.g., they block certain ports that may be used by these settings, or, such as in some countries, block traffic to all VPN services), so the ability to do this discretely by network isn’t such a bad idea.
I would just turn the VPN off. I wouldn’t want macOS to remember the public Wi-Fi anyway.
I think private Wi-Fi addresses are static for each network, though. It shouldn’t give you problems, although, yes, I too disable it on trusted networks, because reasons.
But Private Relay is a cluster. It doesn’t filter all traffic—only TCP port 80 universally, and all traffic from Safari. The selective options that are also available in Mail and Safari with full coverage in iCloud Plus turned off appear to be a subset of those HTTP requests for known trackers. Both types of coverage are then disabled completely on an interface-by-interface basis. The whole shebang runs over UDP port 443, which then means that many Wi-Fi hotspots de facto block it completely because, paradoxically, they only allow TCP ports 80 and 443 (web) and DNS. (OTOH, if you’re on a public Wi-Fi, you’re getting some de facto anonymity, but not privacy.) And the speeds, well, sometimes they leave a lot to be desired: my RSS reader lire sends a flurry of requests over HTTP, which with Relay on, grinds my whole device to a crawl.
I think what they should have done is just given iCloud Plus users full-coverage VPN that could fall back to TCP port 443 for encapsulation with options for setting which networks to use it on (in the same area of the UI), and have Mail’s and Safari’s tracker blockers use simple application-layer proxying to do the whole privacy thing. I mean, really, isn’t that what this is all about—keeping the adtech people at bay? You could, with a bit more engineering, implement a two-hop relay for all protocols and sites, albeit that it would be a bit more challenging, if that was thought important enough, but a VPN is already going to get you most of the way there today, with controls in your web browser. I’ve always run with remote images off in Mail. Plus of course a VPN is going to give you geoblock avoidance, which Apple can’t do because they’re in bed with the content industry. Worse, ISPs and governments (often in hock) can trivially target iCloud, because it’s big; unless Apple proposes to make this “on by default” and ensure that it works in spite of obstacles—and part of me hopes it might, to annoy authoritarian and acquisitive ISPs and governments everywhere—it is questionable how useful this can be as a long-term means of keeping your browsing habits out of the hands of data collectors.
There’s only one bright spot in the whole situation, AFAICT: IPv6. Because the application traffic terminates at IPv6-enabled proxies, turning on Private Relay gets you IPv6 access, even if you only have IPv4. Yay! The revolution is here!
Adam, thanks for this analysis!
I previously had “Block Remote Content” in Mail activated prior to Monterey. When I updated to Monterey, I switched this to “Protect Mail Activity”. I then began having all kinds of problems with Mail not loading message content correctly, even what you would think is simple text.
Turning off “Limit IP address tracking” on the network interface cleared all that up. I’m not too worried about turning that option off, since I run a Pi-Hole and unbound (using DNSSEC) on an entire network basis.
I’m growing more and more suspicious of this as the root cause for Safari connectivity problems since Monterey. I was originally skeptical about a profile since it appeared to be happening only at work (where I need that profile to be able to connect to staff wifi at all), but after reading this article, I figured I’d just try turning off Sys Prefs > Network > Wifi > Limit IP Address Tracking. And presto, ever since I did that I had no more connectivity issues with Safari on work wifi. Then this morning as an experiment, I flipped that setting back on after I had connected to work wifi, and sure enough, after about 1 hr Safari could no longer connect to a local webpage here (while Firefox had no problems). Had to toggle wifi networks to get Safari to connect again.
However, I’m not 100% sure I’m ready to fully believe this is the lone culprit quite yet. For one, Safari’s own prefs still have “Hide IP address from trackers” [as an aside, why does Apple capitalize differently in Safari Prefs vs. Sys Prefs? — actually, a closer look reveals they’re inconsistent even within the Network Sys Prefs] selected—not sure if that’s a contradiction or relevant actually. For another, just toggling the Network preference “Limit IP Address Tracking” after the issue started, did not suffice to fix the connectivity issue. I still had to toggle wifi networks first. Perhaps, I’ll never know. But for now I’m tempted to just leave the Network pref toggled off and hope that was it.
I was having unusual issues with an Apple Mail email attachment from a trusted source, one from which I’ve received the same types of attachments before. Upon clicking the attachment, Safari refused to open the “file://…”. But it had opened the same type of attachment perfectly a couple of weeks ago.
Turns out, this type of file required “Limit IP Address Tracking” to be turned off in Network Preferences as detailed in this article in order to be opened properly. But the minute I’d read this article upon publication, I had done just that. So how did it get turned back on?
The timing makes me suspect the macOS 12.5 update I’d installed July 20 as the culprit. (I can’t prove it and have no evidence.) But I’m posting this in case others have a sudden Mail or Safari issue they thought they’d already solved. In my 12.5 installation at least, this was toggled back on without my input.
Thank you for posting this article. I’m a network guy so I generally know my way around these kinds of things, DNS etc. Apple has a way to “disable” private relay via some DNS entries. I have these on my home network, so I thought I was good to go. I did a fresh install of Ventura and some sites wouldn’t hardly load in Safari. Once I found the setting regarding “trackers” and turned it off, everything loaded fine.
What’s super disappointing is that there are so many places to touch to enable/disable/verify this. Seems more like something Microsoft would design. For me personally I’m going the all or nothing route. Either turn everything on “full blast” or turn it all off.
Just in case this helps anyone else: had a weird problem in which a new iPhone 14 would not allow me to connect with Kindle. In the course of trying to fix that, Amazon’s so-called tech support discovered that I couldn’t log into any Amazon app or even into Amazon’s home page via Safari. In all cases, I got an error message that I was not connected to the internet (but no problem with any other site). Eventually I was asked to do a full restore on the phone, which did not help. They had no further suggestions and told me to talk to Apple.
The Apple tech eventually had me going through a full examination of settings on the phone. The problem turned out to be that Private Relay under the iCloud settings had been enabled. Unfortunately, you can only turn it off temporarily for a specific website, so I have disabled it entirely and will reply on my VPN, which doesn’t cause a problem with Amazon.
For info on Private Relay—About iCloud Private Relay - Apple Support
OK, so oddly enough, after months of the “Protect Mail Activity” setting in Mail resulting in every message with external content appearing with the “content could not be loaded privately” warning, suddenly, this afternoon such email is loading without that warning, and with the external content! This happened once before (under Monterey…don’t think it’s ever worked for me under Ventura). I did no updates to anything, nor changed any settings. One moment (well the interval between Mail checks was probably on the order of a couple hours) it wasn’t working, then boom! all of a sudden it was. I would love to figure out what changed where that caused this to happen. And we’ll see how long it lasts this time…