Why App Store downloads crawl behind a UniFi gateway

Apple delivers App Store apps and OS updates through a content delivery network — a blend of Apple Edge Cache (AEC) nodes that Apple installs inside ISP networks and third-party CDN capacity such as Akamai — fronted by domains like apps.apple.com, mzstatic.com, and updates.cdn-apple.com.¹⁸ Apple’s own enterprise documentation says these hosts use CNAME chains in DNS specifically to “provide fast and reliable content delivery to users in all regions.”¹ Translation: the edge node that serves you — and therefore your download speed — is chosen at DNS-resolution time.

The mechanism underneath is EDNS Client Subnet (ECS): the resolver passes a coarse slice of your network’s location to the CDN so it can hand back a nearby node.⁷ That is why the resolver you use materially changes which Apple cache answers you. Point clients at a resolver that steers Apple traffic to a congested, poorly-peered, or simply broken edge, and Apple downloads crawl while every other service — which rides different CDNs and different nodes — stays fast.

The clearest documented case is an Aussie Broadband fibre user on a UniFi UCG-MAX (fibre on WAN1, 4G failover on WAN2). Apple updates took hours over the fibre but ran normally over 4G. An ISP engineer spelled out the mechanism exactly: “When using ABB DNS you will be steered to a local cache, using someone like Cloudflare may result in steering you away (e.g. to Sydney),” and added “we are aware of some problems with a cache in VIC we’re working on getting sorted.”⁴ The fix that worked for multiple users on that thread was switching the resolver to Cloudflare. One report is worth quoting because it contains the whole nuance: “If you use google DNS (8.8.8.8) the slow apple downloads persist. If you swap to cloudflare (1.1.1.1) the speed issues instantly resolve.”⁴

And here is the trap that wastes the most time: the answer is not always Cloudflare. The “correct” resolver is the one that happens to steer your location to a healthy node, and that is ISP- and region-dependent. There are well-documented cases pointing the other way — App Store downloads slow specifically with Cloudflare and normal on a different resolver.⁶ So the test is not “switch to Cloudflare,” it is “try several resolvers and let the result decide”: the ISP’s own DNS, Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9), measuring an App Store download after each.

On UniFi specifically, two configuration details decide whether your DNS test is even valid. First, changing the gateway’s upstream WAN DNS is not enough if the DHCP scope still advertises the ISP resolver to clients — set the resolver in both places, and during the test do not leave the ISP’s DNS as a secondary, because clients may still reach for it and hand you a false negative. Second, UniFi’s Content Filtering and DNS Shield override client DNS at the network level: with either enabled, a device’s own DNS choice is ignored and every lookup is funnelled through Ubiquiti’s filtering service — which can itself steer Apple to a different node.⁹¹⁰ If those are on, they are part of your DNS path whether you meant them to be or not.

The second real Apple-only cause is a pair of Apple privacy features that change where your traffic appears to come from. “Limit IP Address Tracking” is on by default, set per Wi-Fi network, and it routes traffic through iCloud Private Relay’s infrastructure to mask your address.³ Private Relay sends requests through two separate relays and, in Apple’s words, “replaces the user’s original IP address with one assigned from the range of IP addresses used by the service.”² Because the apparent client IP and location change, the CDN’s node-selection logic changes with it — which is how a privacy toggle ends up throttling App Store downloads even though, as one affected user put it, “I thought this feature only worked in Mail and Safari.”⁵

The matching case is a Superloop user in Sydney: “My iPhone can only pull App updates at under 3–5 Mbps recently, if I switch to 5G they come in at full speed.” DNS changes did not fix it. What did: “disabling [Limit IP address Tracking] reverts to full speed.”⁵ This is the decisive reason DNS and the privacy toggle are separate tests — either one alone can be the whole answer, and the first masks the second if you only try one.

There is a UniFi-specific way to manufacture this exact symptom, and it catches a lot of MSPs. Many networks deliberately block Private Relay for content-filtering or compliance reasons. If you block it the wrong way — by silently dropping its packets or letting its DNS lookups time out — Apple devices hang and fall back slowly, producing precisely the “everything Apple is slow” complaint. Apple is explicit about the right way: return an NXDOMAIN or a “no error no answer” response for mask.icloud.com and mask-h2.icloud.com, and “avoid causing DNS resolution timeouts or silently dropping IP packets sent to the Private Relay server, as this can lead to delays on client devices.”² Done correctly, the device is cleanly told the network blocks Private Relay and prompts the user, rather than stalling. On UniFi the sanctioned method is a Policy Table DNS rule pointing those two domains at NXDOMAIN, and it requires a UXG or a Cloud Gateway (it lives in the Zone-Based Firewall).¹¹ So if your standard build blocks Private Relay, the first thing to verify is how.

A necessary correction on QUIC. It is common to blame QUIC (HTTP/3 over UDP 443) for slow App Store downloads. Be precise here, because it changes what you check: Apple’s enterprise documentation lists the App Store and software-update hosts on TCP 443 and 80, not UDP.¹ Where QUIC over UDP 443 genuinely matters is Private Relay itself — Apple states Private Relay “uses QUIC … set up using port 443 and TLS 1.3.”² So a firewall that drops or mishandles UDP 443 is a Private Relay problem, relevant here precisely because Private Relay is already in the frame — not a separate App Store transport you need to chase on its own.

These are the settings people reach for first. They are worth checking — but with clear eyes about which ones can actually produce an Apple-only symptom and which would slow the whole connection.

• IDS/IPS (Threat Management). Deep packet inspection disables hardware offload on a UDM, UDM-Pro, or older Cloud Gateway and caps WAN throughput at a fraction of line rate. But a cap slows everything, and even capped you keep enough for a small app — so it is rarely the Apple-only cause. Worth a temporary off-test regardless; the full mechanism and the model-by-model numbers are in our IDS/IPS throughput-ceiling article.
• Smart Queues / QoS. Stale or too-low bandwidth values (often left behind after a plan upgrade) cap throughput — again, everything, not just Apple. Quick to rule out; covered in the Smart Queues and bufferbloat article.
• HTTPS / SSL inspection. This one can be Apple-specific. Apple is unambiguous: “Apple services will fail any connection that uses HTTPS Interception (SSL Inspection),” and inspecting encrypted Apple traffic causes dropped connections, retries, and poor throughput.¹ If your build inspects TLS, exempt the Apple hosts.
• Content / domain filtering and policy rules. Beyond the DNS-override behaviour in §02, a mis-scoped traffic rule — “limit media downloads,” “limit app stores,” an aggressive guest cap — can throttle exactly this traffic. Audit Traffic Rules, QoS, application filtering, CyberSecure, DNS Shield, SSL inspection, guest-VLAN limits, and policy-based routing, and use UniFi’s Traffic Flows to prove whether a policy is actually touching the flow.¹²

If you do filter or inspect, the practical artifact is an Apple bypass list. Allow or exempt these App Store and software-update hosts from filtering and inspection: itunes.apple.com, *.itunes.apple.com, *.apps.apple.com, *.mzstatic.com, ppq.apple.com, *.appattest.apple.com, updates.cdn-apple.com, updates-http.cdn-apple.com, appldnld.apple.com, mesu.apple.com, swcdn.apple.com, gdmf.apple.com, xp.apple.com. If your policy engine only does IP rules, Apple says you can allow outbound to 17.0.0.0/8 — but hostname rules are preferable, because Apple’s CNAME chains change and an IP allow-list goes stale.¹

The gateway frequently gets blamed for a problem that lives on the ISP’s path to Apple’s cache. The Aussie Broadband thread is the clean proof: the ISP itself acknowledged a broken regional cache, and forcing the network onto the 4G WAN restored full Apple speed immediately.⁴ That is the ISP path failing, not the UniFi hardware — and no amount of gateway tuning fixes a sick edge node upstream.

Double-NAT and CGNAT make this worse. When the UniFi gateway sits behind an ISP router that is also doing NAT — including carrier-grade NAT — the location signal the CDN sees can be wrong, and node selection degrades along with a list of other services. The diagnostic and the carrier-by-carrier bridge-mode fixes are in the double-NAT and CGNAT article.

The isolation test is simple and decisive: swap WANs, even to a 4G backup. If Apple downloads are fast on the second WAN and slow on the first, the problem is the first WAN’s path to Apple — escalate to the ISP with evidence rather than rebuilding the gateway.

Run these in sequence; each step either fixes the problem or eliminates a whole class of cause before you spend time on the next.

1. Confirm it is Apple-only. Pull a large non-Apple file. Fast means the problem is not raw throughput, Smart Queues, or an IDS/IPS cap — skip those entirely.
2. Cellular vs. Wi-Fi. Same iPhone, same app. Fast on 5G but slow on Wi-Fi implicates the gateway/ISP path; slow on both points at the device, the Apple account, or a CDN node everyone is hitting.
3. Swap WANs if multi-WAN, to separate an ISP-path problem from the gateway itself.
4. Capture a baseline. From an affected client, load test.edge.apple/debug/ — Apple’s own diagnostic, which reports the DNS server in use, the Apple CDN/edge node you are being routed to, and a throughput sample of a 5 MB object.⁸ Record it before you change anything.
5. Test multiple resolvers at the gateway and the DHCP scope — ISP-native, Cloudflare, Google, Quad9 — without leaving the ISP DNS as a secondary. Renew leases or forget-and-rejoin Wi-Fi, then re-test the download and re-capture test.edge.apple/debug/ to see the node change.
6. Toggle the privacy features. Turn off “Limit IP Address Tracking” on the test network and test with Private Relay disabled. If your build blocks Private Relay, confirm it uses the NXDOMAIN method, not a silent drop.²
7. Disable the policy stack on one VLAN/client — Content Filtering / DNS Shield, SSL inspection, app filtering, Smart Queues, IDS/IPS, guest limits — then re-enable one at a time to find the offender.
8. Confirm UDP 443 is flowing (it matters for Private Relay) and that firmware is current.
9. Run an mtr/traceroute to the Apple edge you are landing on to spot a congested hop on the way to the cache.

In order of how often each one resolves it:

1. Change the resolver at gateway and DHCP scope, testing several (not assuming Cloudflare). This resolves the majority of Apple-only cases in the literature, often instantly.
2. Turn off Limit IP Address Tracking / test Private Relay off; if you block Private Relay for compliance, switch to the Apple-sanctioned NXDOMAIN method so devices stop hanging.
3. Exempt Apple hosts from SSL inspection and content filtering (the bypass list in §04), since inspection of Apple TLS is a documented failure mode.
4. Right-size or relax Smart Queues and IDS/IPS if the non-Apple test in step 1 was also slow — that points back at a genuine throughput cap.
5. Ensure UDP 443 is open and firmware is current for clean Private Relay behaviour.
6. Escalate to the ISP when a WAN swap proves the path to Apple’s cache is the bottleneck.

The one-pass test we actually run on site. Rather than work the list serially across several visits, do a merged first pass on one affected site: set a test resolver at both the gateway and the DHCP scope, capture test.edge.apple/debug/ before and after, and at the same time toggle “Limit IP Address Tracking” off on a test device and confirm UDP 443 is flowing. That single pass covers the two most likely causes plus the two most commonly under-weighted ones, so the problem usually resolves in one visit instead of three.

For sites with a lot of Apple devices, there is a structural fix that sidesteps the CDN path entirely: Apple Content Caching, a service built into macOS. Point the network at an always-on Mac and every Apple device pulls installers, app updates, and iCloud content through it — the first device downloads from Apple once, and every device after that is served from the local network at LAN speed.¹³ For an office full of iPhones, iPads, and Macs, that turns “each device fights the CDN” into “download once, share locally,” and the Apple-edge question stops mattering for repeat downloads.

• The “right” DNS is not universal. We have cited cases where Cloudflare fixed it and a case where Cloudflare caused it.⁴⁶ The mechanism (resolver decides the CDN node) is solid; the specific resolver that helps is local. Test, do not assume.
• There is no official Ubiquiti “App Store bug” advisory. The evidence points to DNS / CDN / ISP-cache selection and gateway policy — not a known UniFi defect. Anyone claiming a specific firmware bug for this exact symptom is over-reaching.
• QUIC for the App Store itself is a hypothesis, not a documented fact. Apple lists App Store and update hosts on TCP 443.¹ Keep QUIC/UDP-443 scoped to Private Relay, where Apple does document it.²
• The case evidence is thin in number. The real- world reports here rest on a small set of ISP-forum threads plus Apple’s and Ubiquiti’s official documentation. The underlying mechanisms are well-established; the individual anecdotes are illustrations, not a statistical sample.
• The newest multi-gig Cloud Gateway flow-control quirks are broad, not Apple-only. They affect all large transfers and speed tests, so they are only a suspect when everything is abnormal — not for an isolated Apple symptom.

None of this changes the headline: when only Apple downloads crawl and everything else is fine, the answer is almost never the gateway’s bandwidth. It is which Apple cache your DNS is steering you to, or a privacy feature changing the route — and both are testable in a single, structured pass.