We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

Hi everyone, Just recently we started having issues in our integration environment with publicly available well known files not being fetched properly by the Apple CDN. The CDN keeps returning an SWCERR00301 Timeout fault. I noticed a very similar thread around the same time it went wrong with us as well: https://developer.apple.com/forums/thread/821908 However, the fault is ever so slightly different. Note that for security reasons, the actual domain has been redacted and replaced by the generic "domain.com" When calling the command curl -i https://app-site-association.cdn-apple.com/a/v1/domain.com The following is returned HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 21 May 2026 10:44:08 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://domain.com/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: eb38e1901a83ad9b Strict-Transport-Security: max-age=31536000 Expires: Thu, 21 May 2026 10:44:18 GMT Age: 712 Via: http/1.1 defra2-vp-vst-004.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-lx-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-bx-021.ts.apple.com (acdn/302.16436) X-Cache: hit-fresh, hit-stale, hit-stale, hit-stale CDNUUID: 859e620c-7e2c-438c-a43d-68b6344e890c-1593129103 Connection: keep-alive Not Found Where other issues on the forum specifically target "waiting on headers", it does not in our case. We checked our internal infrastructure, we clearly see incoming requests from the ASAA-bot requesting the well known file. These requests hit our backends as they should and return a 200 OK. All within a couple of milliseconds. Again - nothing changed here. After this validation, I read the Tech notes: TN3155: Debugging universal links | Apple Developer Documentation but it does not provide anything we did not already check. Besides on our side, hosting wise and content-wise, nothing changed. This is not new material. I ultimately enabled developer mode on my test device, pushed the Integration app version causing the issues. When keeping the entitlements asis, the apple CDN is called from the iOS device (verified through ProxyMan) but the redirects do not work (as the CDN contains 404 Not Found) When changing the entitlements, and adding "?mode=developer", the CDN is of course skipped and our backend is called directly (as verified through ProxyMan). Now the redirects work as intended, the universal links were fetched properly. (the embedded universal link tester on the iOS device in settings - Developer still did not validate the universal link correctly though. But this seems an issue in the tool. The working production universal link also does not validate while it definitely works) To make sure our backend is not too 'slow' (internal logging shows requests are handled within 100 ms), I checked against UAT. Same processing times, there no issues with CDN. We conducted a very thorough investigation on our side and I do not see any reason as to why the CDN should be throwing timeout exceptions. As we cannot flush the CDN cache and do not see issues on our side, there is no way for us to validate why this is going wrong. Does anyone have any clues on what else I can do? Thanks

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding Apple App Site Association (AASA) and Universal Links behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. We currently support Universal Links through our Apple App Site Association (AASA) configuration. Could you clarify the following: After the app transfer, will existing Universal Links continue functioning for users who already have the app installed? Will we need to update our AASA file to include the recipient account’s new Team ID in order for Universal Links to continue functioning properly? If so, is there a recommended transition strategy for supporting both existing installed app instances and newly installed versions during the migration period? Any clarification on the expected Universal Links and AASA transition behavior during and after an app transfer would be greatly appreciated. Thank you.

We have an issue where Safari on iOS is not handing off to our app after an Auth0 authentication redirect. Issue After a user completes sign-in via an Auth0-hosted login page in Safari, the callback redirect is followed as a plain HTTP navigation rather than being intercepted and handed off to the app. Callback URL format https://identity.example.com/ios/com.example.app/callback Steps to reproduce Open an Auth0 /authorize URL in Safari on iOS with a redirect_uri pointing to a Universal Link callback, log in, and observe that Safari navigates to the callback URL as a plain HTTP request rather than launching the app. What works ASWebAuthenticationSession inside the app handles the same callback correctly. Navigating directly to a Universal Link launches the app, confirming AASA and Universal Links are correctly configured on the affected devices. The issue is specific to Safari intercepting the callback URL when it arrives as the result of an Auth0 redirect. Affected devices Reproducible across multiple devices and iOS versions from iOS 18.x through iOS 26.x. Does Safari have a restriction on intercepting Universal Links that result from a cross-domain redirect? Any guidance appreciated 🙏

Dear Team, We are trying to implement universal linking app to app redirection for our banking application. We have configured the associated domains in our application as can be seen below in the info plist of our IPA <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>application-identifier</key><string>2TK5X82C47.com.bankalbilad.NewRMB</string><key>aps-environment</key><string>production</string><key>beta-reports-active</key><true/><key>com.apple.developer.associated-domains</key><array><string>applinks:rob-auth.bankalbilad.com</string></array><key>com.apple.developer.icloud-container-identifiers</key><array></array><key>com.apple.developer.pass-type-identifiers</key><array><string>2TK5X82C47.*</string></array><key>com.apple.developer.payment-pass-provisioning</key><true/><key>com.apple.developer.team-identifier</key><string>2TK5X82C47</string><key>com.apple.developer.ubiquity-kvstore-identifier</key><string>2TK5X82C47.com.bankalbilad.NewRMB</string><key>com.apple.security.application-groups</key><array><string>group.com.NewRMB</string></array><key>get-task-allow</key><false/><key>keychain-access-groups</key><array><string>2TK5X82C47.com.bankalbilad.NewRMB.keychain</string></array></dict></plist> We are unable to see the call made from IOS reaching the endpoint which is https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association We performed curl of our domain and get the below error. curl -i https://app-site-association.cdn-apple.com/a/v1/rob-auth.bankalbilad.com HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 14 May 2026 11:42:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection failed"} Apple-Failure-Reason: SWCERR00305 Network error Apple-From: https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association Apple-Try-Direct: false Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: bfafe8fa87a6828f Strict-Transport-Security: max-age=31536000 Age: 21 Via: https/1.1 defra2-vp-vst-017.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-006.ts.apple.com (acdn/302.16436), http/1.1 defra2-xdc-mx-023.ts.apple.com (acdn/302.16436), http/1.1 defra1-edge-fx-060.ts.apple.com (acdn/302.16436) X-Cache: hit-stale, hit-stale, hit-fresh, hit-fresh CDNUUID: 6fb88181-f58a-4059-a770-26a43e1f32d0-16071773867 Expires: Thu, 14 May 2026 11:42:26 GMT Connection: keep-alive Not Found curl -v https://app-site-association.cdn-apple.com/a/v1/rob-auth.bankalbilad.com * Host app-site-association.cdn-apple.com:443 was resolved. * IPv6: (none) * IPv4: 17.253.15.159, 17.253.63.204, 17.253.63.201, 17.253.29.140, 17.253.29.162, 17.253.39.133, 17.253.39.145, 17.253.15.162 * Trying 17.253.15.159:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Connected to app-site-association.cdn-apple.com (17.253.15.159) port 443 * using HTTP/1.x > GET /a/v1/rob-auth.bankalbilad.com HTTP/1.1 > Host: app-site-association.cdn-apple.com > User-Agent: curl/8.13.0 > Accept: */* > < HTTP/1.1 404 Not Found < Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 < Date: Thu, 14 May 2026 11:42:16 GMT < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Apple-Failure-Details: {"cause":"Connection failed"} < Apple-Failure-Reason: SWCERR00305 Network error < Apple-From: https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association < Apple-Try-Direct: false < Cache-Control: max-age=3600,public < Vary: Accept-Encoding < X-B3-TraceId: bfafe8fa87a6828f < Strict-Transport-Security: max-age=31536000 < Age: 33 < Via: https/1.1 defra2-vp-vst-017.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-006.ts.apple.com (acdn/302.16436), http/1.1 defra2-xdc-mx-023.ts.apple.com (acdn/302.16436), http/1.1 defra1-edge-fx-058.ts.apple.com (acdn/302.16436) < X-Cache: hit-stale, hit-stale, hit-fresh, hit-fresh < CDNUUID: 77d7de5e-f827-44b1-bbf5-ae2d8e36e104-16053052830 < Expires: Thu, 14 May 2026 11:42:26 GMT < Connection: keep-alive We also don't see any blocks in our firewall or in WAF or any network level Load balancers. Can you please help in troubleshooting the same.

Last week our Universal Links stopped working. We made some changes and uploaded a new AASA file, but https://app-site-association.cdn-apple.com/a/v1/(domain) still returns 404 Not Found for all our domains. When I query directly from our server like domain/.well-known/apple-app-site-association, it returns 200 and the file is accessible. Could you help us resolve this issue? Our app relies on working Universal Links (deep links). Thank you!

I'm following up from an old existing post per the recommendation by DTS Engineer I'm referencing that comment specifically because i'm only able to reproduce this issue when using a device through browserstack. (a service that allows remote access to physical ios devices for testing, etc) I haven't been able to reproduce the issue on my physical device. When attempting to launch an ASWebAuthenticationSession using callback: .https(host: path:), The session immediately fails (before even presenting the web modal) with the error: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 NSLocalizedFailureReason=Application with identifier com.builderTREND.btMobileAppAdHoc is not associated with domain test.buildertrend.net. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for test.buildertrend.net. Which doesn't make sense, since our AASA file does specify that url and has the app ID listed in webcredentials Our app's entitlements file also contains webcredentials:*.buildertrend.net So it seems like everything is set up properly, but this issue is persistent.

How does Associated Domains Development work on watchOS? In comparison, on iOS we have Diagnostics menu that allows to input a link and test the setup. How to achieve the same on a watch? watchOS: iOS:

My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?

Hi everyone, I've been working on an application that provides different subdomains for different customers, so we need to support app linking with all of them. However, using wildcard notation like applinks:*.domain.com doesn't work, while hardcoding applinks:subdomain.domain.com works fine. The association file is being served from both the main domain and subdomains. It used to work fine about a month ago, and I can't find any recent breaking changes on Apple's side . Any ideas why this could happen. ?

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!

Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioning under an Apple Enterprise Developer account. This introduces considerable operational complexity, as it would require us to maintain separate signing and distribution paths alongside our existing Apple Developer Program membership. Before pursuing that path, we wanted to understand Apple's perspective on the following: Is there a supported or recommended approach for preserving Associated Domains entitlements when an app is re-signed by a third party (e.g., a cloud testing platform)? Are there any provisioning or entitlement configurations that would allow Universal Links to function correctly in re-signed builds without requiring an Enterprise Developer account? Does Apple have documented best practices for validating Universal Link–based flows in automated or cloud-based testing environments? Are there any alternative deep linking patterns that would be more resilient to re-signing while still meeting App Store and platform security requirements? Any guidance or recommendations from Apple on how to handle this within the bounds of the standard Apple Developer Program would be greatly appreciated. Thank you for your time.

I have a feature that relies on Apple Universal Links, which requires the apple-app-site-association file. I made some changes to this file a week ago, but I noticed that the corresponding file still hasn’t been updated when queried via: https://app-site-association.cdn-apple.com/a/v1/x When I query directly from our server, I can see the latest file here: https://x/.well-known/assetlinks.json Could anyone please help us update the file in the CDN? Thank you.

We are experiencing an issue where Apple’s CDN is not fetching the updated apple-app-site-association (AASA) file correctly for our domain. Domain - app.myloft-stage.com AASA File Locations (Both Return Correct JSON): https://app.myloft-stage.com/.well-known/apple-app-site-association https://app.myloft-stage.com/apple-app-site-association Both endpoints: Return HTTP 200 Return valid JSON Content-Type: application/json No redirects Valid SSL certificate JSON validated and correctly formatted Apple CDN URL - https://app-site-association.cdn-apple.com/a/v1/app.myloft-stage.com Error Returned by Apple CDN - {"cause":"invalid character '\u003c' looking for beginning of value"} This error indicates that Apple CDN is receiving HTML content (starting with <) instead of JSON, even though the origin server returns proper JSON. Observations : Direct access to AASA file returns correct JSON. Apple CDN appears to be caching an older or incorrect response. The CDN response does not match the current server response. Universal Links fail due to this incorrect AASA retrieval.

To use passkeys, you need to place the correct AASA file on the web server and add an entry in the Entitlements.plist, for example webcredentials:mydomain.com. This is clear so far, but I would like to ask if it's possible to set this webcredentials in a different way in the app? The reason for this is that we are developing a native app and our on-premise customers have their own web servers. We cannot know these domains in advance so creating a dedicated app for each customer is not option for us. Thank you for your help!

We're handling our universal links (deep links) via our custom router written in express.js. We recently update our .well-known format as per: https://developer.apple.com/documentation/xcode/supporting-associated-domains Our own domain link shows them correctly if we apply cache bust to it: Normal link: https://links.sastaticket.pk/.well-known/apple-app-site-association Cache bust: https://links.sastaticket.pk/.well-known/apple-app-site-association?1 Now, since app-site cache is not updating at: https://app-site-association.cdn-apple.com/a/v1/links.sastaticket.pk Our main domain link is not getting updated response either. Its been more than 72 hours now. Any help, how to push the app-site cache to update? I can provide more context if needed, Thanks

We put the apple-app-site-association file at https://ourdomain.com.tr/.well-known/apple-app-site-association. When we send a request to url, we get 200 response code every time and we can see the file. But sometimes when we try to access https://app-site-association.cdn-apple.com/a/v1/ourdomain.com.tr url with browser or CMD tool, we are facing with 404 response code. There isn't any ip adress filter in our systems and we tried using vpn for sending same request from different locations(america and europe) but nothing changed. In addition, can anyone provide the ip list of apple cdn servers to check the F5 Load balancer WAF logs? CMD output: C:\Users\Name>curl -Lv https://app-site-association.cdn-apple.com/a/v1/ourdomain.com.tr Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 17.253.122.197, 17.253.15.210, 17.253.122.196, 17.253.107.201, 17.253.57.203, 17.253.15.198, 17.253.57.200 Trying 17.253.122.197:443... Connected to app-site-association.cdn-apple.com (17.253.122.197) port 443 schannel: disabled automatic use of client certificate ALPN: curl offers http/1.1 ALPN: server accepted http/1.1 using HTTP/1.x GET /a/v1/ourdomain.com HTTP/1.1 Host: app-site-association.cdn-apple.com User-Agent: curl/8.9.1 Accept: / Request completely sent off schannel: remote party requests renegotiation schannel: renegotiating SSL/TLS connection schannel: SSL/TLS connection renegotiated < HTTP/1.1 404 Not Found < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://ourdomain.com.tr/.well-known/apple-app-site-association < Apple-Try-Direct: true < Cache-Control: max-age=3600,public < Content-Length: 10 < Content-Type: text/plain; charset=utf-8 < Date: Mon, 14 Apr 2025 12:52:04 GMT < Expires: Mon, 14 Apr 2025 12:52:14 GMT < Age: 1770 < Via: http/1.1 uklon5-vp-vst-004.ts.apple.com (acdn/268.14469), https/1.1 uklon5-vp-vfe-002.ts.apple.com (acdn/268.14469), http/1.1 frmrs1-edge-mx-008.ts.apple.com (acdn/268.14469), http/1.1 frmrs1-edge-fx-005.ts.apple.com (acdn/268.14469) < X-Cache: hit-fresh, hit-stale, hit-fresh, hit-fresh < CDNUUID: 9e72cf99-1503-4644-9ea3-173328a25c94-31496306226 < Connection: keep-alive < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact

% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) 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-AES256-GCM-SHA384 / [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: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn 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 < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact