Hi Everyone,
We're experiencing a persistent issue where Apple's CDN returns SWCERR00301 Timeout for some of our associated domains, while other domains hosted on the exact same server work perfectly.
Note: Using aliases below for privacy. "working.example.com" and "failing.example.com" are not our actual domains.
The Problem Our app has multiple associated domains. When checking Apple's CDN:
Working domain:
$ curl -sD - "https://app-site-association.cdn-apple.com/a/v1/www.working.example.com" -o /dev/null
HTTP/1.1 200 OK Apple-Origin-Format: json Cache-Control: max-age=21600,public Failing domain (same server, same IP, same AASA content):
$ curl -sD - "https://app-site-association.cdn-apple.com/a/v1/www.failing.example.com" -o /dev/null
HTTP/1.1 404 Not Found Apple-Failure-Reason: SWCERR00301 Timeout Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} Apple-Try-Direct: true Cache-Control: max-age=3600,public On device, swcutil dl -d www.failing.example.com returns SWCErrorDomain error 7, confirming the CDN has no valid cache.
What We've Verified Both domains are hosted on the same server (same IP) and serve identical AASA files:
HTTP 200, Content-Type: application/json, 229 bytes Valid JSON with correct appID Valid SSL certificates (Amazon RSA 2048), no redirects Both registered in the app's Associated Domains entitlement Response time < 500ms from multiple locations We simulated Apple's crawler locally:
$ curl -H "User-Agent: com.apple.swcd (unknown version) CFNetwork/1568.200.51 Darwin/24.1.0"
--connect-timeout 5 --max-time 5 -4 --tls-max 1.2
"https://www.failing.example.com/.well-known/apple-app-site-association"
Result: 200 OK, 0.25s — well within the 5-second limit. We cannot reproduce the timeout from any network we've tested.
Scope Out of 43 associated domains, 5 return 404 (Timeout) on Apple CDN while the other 38 work fine. All 43 domains serve valid AASA files from the same server infrastructure.
What We've Tried Verified AASA content, headers, SSL, and response times for all domains Submitted new TestFlight builds to trigger re-crawl — timeout persists The failing CDN cache (max-age=3600) expires every hour, but Apple's crawler keeps timing out on retry No WAF or rate-limiting rules that would block Apple IPs (17.0.0.0/8) Impact The failing domain is our primary email campaign domain. Universal Links not working means newsletter links open in the browser instead of the app, affecting millions of email recipients daily.
Questions Is there a way to request Apple's CDN to refresh/invalidate the cache for specific domains? Could the Apple crawler be experiencing connectivity issues to our server (AWS us-west-2) for specific SNI hostnames? We have 43 associated domains — could the volume affect crawl reliability? Is there an internal team we can escalate this to for CDN-side investigation? Any guidance would be greatly appreciated. Thank you!
Thank you for your post.
Looks like you do not want to provide the URL to your AASA file. If you want to move this conversation privately for privacy.
I'd like you to submit a code-level support request so we can discuss this further privately. When you create the request, indicate that you were referred by me at Apple and make sure to include a link to this thread.
Before that, I would also recommend you to go over this great written Tech Note that goes over all the steps to troubleshoot Universal Links:
TN3155: Debugging universal links | Apple Developer Documentation
Most developers found this tech note a solution to their configuration. Including to answer your 2 questions at the end that seems like you are blocking the user agent or the IP address from Apple, as well as there is no way to invalidate the cache, you can always change the AASA file to change the cache.
There is no public-facing API or portal to manually flush or invalidate the AASA CDN cache for a specific domain. The cache is entirely automated.
When a device installs the new build, it requests the AASA file from the CDN. If the CDN's cache is stale (older than the max-age), it reaches out to your server.
To absolutely confirm the issue is the CDN and not your app's entitlement or the file itself, you can append ?mode=developer to your associated domains entitlement (e.g., applinks:yourdomain.com?mode=developer). This forces the iOS device to bypass Apple's CDN entirely and hit your server directly. (Note: This only works on devices in Developer Mode, but it is crucial for isolating the issue). Do not use it in productions as this is not going to work on your customer's devices.
You can check exactly what the CDN is seeing by manually querying it:
https://app-site-association.cdn-apple.com/a/v1/yourdomain.com
Hope this helps. Looking forward to your code level support request if you still need helps after reading the Tech Note.
Albert Pascual Worldwide Developer Relations.
