Here is another example of a failing request to https://testa.uff2.de/.well-known/apple-app-site-association through Apple’s CDN: curl -v https://app-site-association.cdn-apple.com/a/v1/testa.uff2.de * Host app-site-association.cdn-apple.com:443 was resolved. * IPv6: 2a01:b740:a06:f000::203, 2a01:b740:a05:0:17:253:254:5, 2a01:b740:a05:0:17:253:254:6, 2a01:b740:a06:f000::209, 2a01:b740:a30:f000::152, 2a01:b740:a02:f000::143, 2a01:b740:a02:f000::137, 2a01:b740:a30:f000::155 * IPv4: 17.253.37.197, 17.253.15.137, 17.253.37.204, 17.253.15.144, 17.253.53.137, 17.253.254.6, 17.253.254.9, 17.253.53.160 * Trying [2a01:b740:a06:f000::203]:443... * Connected to app-site-association.cdn-apple.com (2a01:b740:a06:f000::203) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF * ALPN: server accepted http/1.1 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=app-site-association.cdn-apple.com * start date: Aug 4 23:51:50 2026 GMT * expire date: Oct 28 19:40:30 2026 GMT * subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" * issuer: C=US; O=Apple Inc.; CN=Apple Public Server ECC CA 1 - G1 * SSL certificate verify ok. * using HTTP/1.x > GET /a/v1/testa.uff2.de HTTP/1.1 > Host: app-site-association.cdn-apple.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 404 Not Found < Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 < Date: Tue, 08 Sep 2026 20:46:23 GMT < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Apple-Failure-Details: {"cause":"Connection timed out"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://testa.uff2.de/.well-known/apple-app-site-association < Apple-Try-Direct: true < Cache-Control: max-age=3600,public < Vary: Accept-Encoding < X-B3-TraceId: 5c7a524bb0bf3e27 < Strict-Transport-Security: max-age=31536000 < Expires: Tue, 08 Sep 2026 20:46:33 GMT < Age: 737 < Via: http/1.1 defra2-vp-vst-019.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 uklon6-edge-lx-001.ts.apple.com (acdn/331.16659), https/1.1 uklon6-edge-bx-021.ts.apple.com (acdn/331.16659) < X-Cache: hit-fresh, miss, miss, miss < CDNUUID: fab7275a-b44a-4b8e-823b-003dac048cc4-1461985252 < Connection: keep-alive < Not Found * Connection #0 to host app-site-association.cdn-apple.com left intact

Re: DTS Engineer's answer Thanks for your response. Actually, we don't want the root domain to open the app. Instead any subdomain with the path /s/<ID> and /o/<ID> should open the app. But again, this works correctly intermittently. curl -v https://uff2.de/.well-known/apple-app-site-association (Note the https instead of http) returns the AASA file for me. According to Supporting associated domains https should be used. So yes, while *.uff2.de does not match uff2.de this is not actually our problem. Our AASA file is only additionally hosted on the root uff2.de domain since according to this stackoverflow answer this is needed for the wildcards to work. This link for example should match: https://testa.uff2.de/s/ABC12345 So to answer your questions, the AASA file is located at: https://uff2.de/.well-known/apple-app-site-association, https://testa.uff2.de/.well-known/apple-app-site-association and many other subdomains eventually, but can be tested with these 2. How does the CDN know? I think a phone will trigger a request when coming across a subdomain. PS: We did more research and probably discovered the reason for the /apple-app-site-association request. If the first request fails, this seems to be a fallback since iOS 9.3. But weirdly, if this request succeeds, why does the first one time out?

Re: DTS Engineer's answer Thanks for your response. It was while working through these debug steps that we first noticed the CDN issue. As this is an intermittent issue, we are confident that everything is configured correctly on the app side and the AASA file is valid. Our app is configured with the following entitlement: <key>com.apple.developer.associated-domains</key> <array>     <string>applinks:*.uff2.de</string> </array> swcutil also confirms that our target URL matches that domain using a copy of the file hosted on our server: sudo swcutil verify -d '*.uff2.de' -j ./apple-app-site-association.json -u https://testa.uff2.de/s/ABC12345 { s = applinks, a = JQWD9LFG28.de.uff2.app, d = *.uff2.de }: Pattern "https://testa.uff2.de/s/ABC12345" matched. Here is the relevant section of the swcutil_show.txt file you asked for (pulled from a phone during a failing interval): -------------------------------------------------------------------------------- Service:              applinks App ID:               JQWD9LFG28.de.uff2.app App Version:          1.0 App PI:               <LSPersistentIdentifier 0xcc0ca1180> { v = 0, t = 0x8, u = 0x1d7c, db = 294E5FAA-C50D-4B0B-BA3C-E38A60A17A0E, {length = 8, bytes = 0x7c1d000000000000} } Domain:               *.uff2.de User Approval:        unspecified Site/Fmwk Approval:   unspecified Flags:                 Last Checked:         2026-09-02 20:22:03 +0000 Next Check:           2026-09-02 23:41:53 +0000 Error:                Error Domain=SWCErrorDomain Code=7 "SWCERR00301 Timeout -- {"cause":"Connection timed out"}" UserInfo={Line=275, Function=-[SWCDownloader URLSession:dataTask:didReceiveResponse:completionHandler:], NSDebugDescription=SWCERR00301 Timeout -- {"cause":"Connection timed out"}, UnderlyingError=Error Domain=HTTP Code=404 "(null)" UserInfo={Line=275, Function=-[SWCDownloader URLSession:dataTask:didReceiveResponse:completionHandler:]}} Retries:              1 -------------------------------------------------------------------------------- Site/Fmwk Approval: unspecified prompted us to look into the requests to the Apple-CDN, which is when we noticed that for every failing CDN requests our servers got a request to /apple-app-site-association instead of a request to /.well-known/apple-app-site-association.

Bellow I also have an example without the query string: curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 18:54:00 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 02d1d89c44e0c48c Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-006.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-017.ts.apple.com (acdn/331.16659), https/1.1 defra2-xdc-mx-006.ts.apple.com (acdn/331.16659), https/1.1 defra1-edge-fx-019.ts.apple.com (acdn/331.16659) X-Cache: hit-stale, hit-stale, hit-stale, miss CDNUUID: d2fabf15-4734-4ee7-880c-2018498293a7-1153445817 Connection: keep-alive Access Log Entry: 2026/09/05 18:54:00.180 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.166", "remote_port": "1036", "client_ip": "57.103.82.166", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000074622, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}}