Which iOS Shortcuts break when iCloud Private Relay is on, even though the shortcut itself is fine?

The ones that ask the network who you are. A Shortcut that sets a Focus, runs a Home scene, or edits a file on the phone does not care that iCloud Private Relay is on. Get Contents of URL breaks when the server allowlists your home IP, rejects Apple’s relay ranges, or answers a different country than the one you are standing in. Shortcuts that read “my IP” and then configure something with it break for the same reason. The actions are fine. The path is not the path the server expected.

Private Relay is not a VPN for every packet the phone sends. It covers Safari and a slice of traffic Apple routes through its relays, including a lot of the DNS and web fetches people casually put inside Shortcuts. That is enough to make a working shortcut fail only on the phones where Relay is enabled, which is a miserable bug to hunt, because the shortcut runs cleanly the moment you test it on a phone that never turned Relay on.

Which fetches fail, and which do not?

A fetch to a public API that does not care about your IP keeps working. Weather you already paid for, a status page, a paste you host on a service that answers everyone. The shortcut looks the same as yesterday.

A fetch to your house fails when the house only allows your home address or your phone’s usual mobile IP. Relay presents an Apple egress address. The firewall, the reverse proxy, or the app’s own allowlist says no. You get a 403, an empty body, or a timeout, and Shortcuts shows a failed Get Contents of URL. Nothing in the shortcut changed. Your NAS, your webhook, your “is the garage closed” endpoint did not start hating you. It started seeing a stranger.

A fetch that worked on cellular and fails on home Wi-Fi, or the reverse, is the same bug in a different costume. Relay’s egress depends on the network path. An allowlist of one IP was always brittle. Relay makes it fail on the phone you use for iCloud+, which is the phone you actually run the shortcut on.

What about the shortcut that looks up your IP?

It still runs. It returns the relay’s address, or an address that is not the one your router has. Any later step that writes that address into a firewall, a Dynamic DNS update, a “trusted device” list, or a Slack message you use as a record is now writing the wrong fact. The shortcut is logically fine and operationally a lie. Stop chaining “get IP” into configuration. If you need the phone’s real address for a home allowlist, Relay and that design cannot share a phone. Turn Relay off for the test, see the old IP come back, and then decide which one you actually wanted.

Geofenced content is the polite version of the same lie. A shortcut that fetches a page and parses a price, a menu, or a local listing can receive the page Apple’s egress region gets. You are in one city. The HTML is for another. The parser does not crash. It extracts the wrong number, and you blame the regex. Compare the fetch with Relay off before you edit the shortcut.

Do local addresses break?

A URL that is already an IP on your LAN, 192.168.x.x or a similar private address, usually still goes direct. Relay is not supposed to swallow that. The shortcut that calls the printer, the Home Assistant box, or the Pi by address keeps working if the phone is on that Wi-Fi.

Names are the part that break. A hostname you only resolve at home, or a DNS record your resolver handles and Apple’s relay DNS does not, fails lookup when the query goes through Relay. The shortcut still says Get Contents of URL. The error is “could not connect” or a name that does not resolve. Use the LAN IP inside the shortcut if this phone has Relay on, or accept that the name only works when Relay is off. Do not keep a hostname that depends on a DNS path Relay replaced.

Limit IP Address Tracking, the per-network toggle, is a cousin of this mess. A Wi-Fi network with that limit on can change how the phone presents itself even when you think you are debugging Relay alone. When a shortcut fails only at home, check both Relay and that network’s limit before you rewrite the actions.

Which shortcuts are innocent and should be left alone?

Anything that never leaves the phone. Set Focus, set playback, append to a note in the Shortcuts app, save a file to iCloud Drive from data you already have, control a Home hub with the Home action rather than with a hand-rolled HTTP call. Those do not present an IP to a server you operate. Relay cannot break them. If one of those fails, look at permissions, the lock screen, and Low Power Mode. You are in a different article.

Opening a URL in Safari is a gray case. Safari is exactly what Relay is for. The site may challenge, captcha, or geoblock Apple’s relays. The shortcut “Open URLs” did its job. The site refused the session. That is not a broken action. It is a site that does not like the privacy path. A bank, a university login, and some ticketing sites do this. Use the app, or turn Relay off for the hour, instead of adding retry steps that will also be refused.

How do you prove Relay is the cause in five minutes?

Run the shortcut once and save the error. Turn iCloud Private Relay off in Settings, under your name, iCloud, Private Relay. Run the same shortcut again without changing a single action. If it succeeds, Relay was the condition. Turn Relay back on and decide. Do not “fix” the shortcut by duplicating actions. You will forget why the duplicate exists, and it will fail again on the next phone that has Relay on.

If it still fails with Relay off, stop blaming Relay. The server, the URL, the cellular path, or a permission is the cause. Relay is a convenient ghost because it is invisible. It is not the cause of every red step.

Test on the phone that has the problem, not on a spare that never joined iCloud+. The spare will make you “fix” a shortcut that was already fine.

What should you change, the shortcut or the server?

Change the server if you control it and the shortcut is worth having while Relay stays on. Allow the action without an IP allowlist. Use a token. A shared secret in the header beats a list of home IPs that Relay will never match. If you cannot change the server, the shortcut cannot both use that server and keep Relay on. Pick one. Turning Relay off globally to save one shortcut is a big price. Moving that one fetch to a machine at home that is already allowed, and letting the shortcut trigger the machine, is the smaller price.

Do not add a step that toggles Relay. Shortcuts cannot reliably flip iCloud Private Relay as a casual action, and teaching a shortcut to disable a privacy control so a webhook can see your house is the wrong direction. Leave Relay on. Stop sending the house a request that requires your naked IP.

Why does it work in the editor and fail at 7 a.m.?

Because you tested with the phone unlocked, on Wi-Fi, and you watched the step. Private Relay plus a locked phone plus Low Power Mode is three different failures stacked, and only one of them is Relay. If the morning run fails and a manual run with Relay still on also fails, Relay or the server is the cause. If the manual run succeeds and the morning run does not, the shortcut is fine and the phone never gave it a network in the first place. Do not toggle Relay off to fix a scheduler problem. You will mask it until the next iOS update turns Relay back on and the morning fails again.

iCloud+ is per account. A shared iPad that is not in the same plan will not reproduce the bug. A child’s phone on Ask to Buy will not either. The phone that shows Private Relay in Settings is the only honest test device. Run it there, with Relay on, then with Relay off, and write down which run matched the failure you actually care about.

1. If the shortcut never uses the network, ignore Relay.
2. If it fetches a public API and fails only with Relay on, the API is rejecting the egress. Try another endpoint or turn Relay off and accept that.
3. If it fetches your own server, replace the IP allowlist with a token.
4. If it stores “my IP,” stop. That value is no longer yours.
5. If a LAN hostname fails, call the private IP, or turn Relay off and live with the name.

The shortcuts that break under iCloud Private Relay are the ones whose servers still believe an IP address is an identity. The shortcut was fine. The identity moved to Apple’s relay, and the server kept the old list.