Apple CDN not picking up updated apple-app-site-association file (valid, 200, since Oct 2)

Apple's AASA CDN is still serving an old version of our apple-app-site-association file, 10 days after we updated it on our server.

Setup

  • App ID: 4572YRV3M6.gr.kathimerini.Kathimerini
  • Entitlement: applinks:www.kathimerini.gr
  • File: https://www.kathimerini.gr/.well-known/apple-app-site-association
  • The site is behind Cloudflare.

Change

We added this exclude, placed before the /syndromes/* entry:

{ "/": "/syndromes/gastronomos-prosfora/*", "exclude": true },
{ "/": "/syndromes/*" },

What we see

  • Our server returns the new file: HTTP 200, Content-Type: application/json, no redirects, valid JSON. The Last-Modified header is Fri, 02 Oct 2026 07:06:39 GMT.
  • It returns the same response when requested with -A "AASA-Bot/1.0.0".
  • https://app-site-association.cdn-apple.com/a/v1/www.kathimerini.gr still returns the old file without the new rule.
  • A clean install on a test device still uses the old rules.

Questions

  1. Is there a way to see whether Apple's crawler is failing to fetch our file, and why?
  2. Can the CDN copy be refreshed, or is there a typical maximum delay?
  3. Is there a Cloudflare or caching configuration known to cause this?

Thanks!

Answered by DTS Engineer in 909517022

Thanks so much for your reply and the great details.

The previous cf-cache-status: HIT from Cloudflare is almost certainly why the CDN cached stale version of the file. The hit-stale status you are seeing from the CDN indicates that the cache TTL has expired, and the CDN is serving the stale cached copy while it attempts an asynchronous background fetch to your origin. Now that you have bypassed Cloudflare caching (cf-cache-status: DYNAMIC) and are serving the correct 1953-byte file with a 200 OK, the next background fetch by the AASA-Bot will succeed and update the CDN cache.

Triggering a Re-sync There is no manual way or API to force a cache purge or trigger an immediate re-sync on the AASA CDN. The CDN will update automatically based on its internal schedule.

If you want to support links on the other domain, you must add applinks:domain to your Associated Domains entitlements in Xcode and release a new version of your app. You will also need to ensure the AASA file is accessible at https://kathimerini.gr/.well-known/apple-app-site-association.

Please keep an eye on your server to make sure they always return a none cached version of the AASA file and your solution will keep working.

Albert  WWDR

Thanks for the question, the file should be located at

curl -v https://kathimerini.gr/.well-known/apple-app-site-association 
* Host kathimerini.gr:443 was resolved.
* IPv6: 2606:4700:10::ac42:94ca, 2606:4700:10::6814:23aa
* IPv4: 172.66.148.202, 104.20.35.170
*   Trying [2606:4700:10::ac42:94ca]:443...
* Connected to kathimerini.gr (2606:4700:10::ac42:94ca) 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 h2
* Server certificate:
*  subject: CN=kathimerini.gr
*  start date: Oct 13 13:50:37 2026 GMT
*  expire date: Jan 11 14:50:27 2027 GMT
*  subjectAltName: host "kathimerini.gr" matched cert's "kathimerini.gr"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://kathimerini.gr/.well-known/apple-app-site-association
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: kathimerini.gr]
* [HTTP/2] [1] [:path: /.well-known/apple-app-site-association]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /.well-known/apple-app-site-association HTTP/2
> Host: kathimerini.gr
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 301 
< date: Tue, 13 Oct 2026 17:14:35 GMT
< content-type: text/html
< location: http://www.kathimerini.gr/.well-known/apple-app-site-association
< server: cloudflare
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< x-server-powered-by: nxcode.gr

Right now returns a redirect instead of the AASA file. I would recommend to add it into that directory instead of

https://www.kathimerini.gr/.well-known/apple-app-site-association

However making a request at the Apple CDN I see a file synced today.

curl -v https://app-site-association.cdn-apple.com/a/v1/www.kathimerini.gr
* Host app-site-association.cdn-apple.com:443 was resolved.
* IPv6: 2620:149:a00:f000::148, 2620:149:a21:f000::139, 2620:149:a0c:f000::9, 2620:149:a0c:f100::8, 2620:149:a00:f000::140, 2620:149:a00:0:17:253:253:9, 2620:149:a21:f000::137, 2620:149:a00:0:17:253:253:4
* IPv4: 17.253.17.203, 17.253.253.9, 17.253.5.144, 17.193.136.202, 17.193.136.201, 17.253.17.208, 17.253.253.8, 17.253.5.136
*   Trying [2620:149:a00:f000::148]:443...
* Connected to app-site-association.cdn-apple.com (2620:149:a00:f000::148) 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: Sep 22 23:52:36 2026 GMT
*  expire date: Dec 15 20:17:55 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/www.kathimerini.gr HTTP/1.1
> Host: app-site-association.cdn-apple.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820
< Date: Tue, 13 Oct 2026 17:16:16 GMT
< Content-Type: application/json
< Content-Length: 1863
< Apple-From: https://www.kathimerini.gr/.well-known/apple-app-site-association
< Apple-Origin-Format: json
< Cache-Control: max-age=21600,public
< Vary: Accept-Encoding
< X-B3-TraceId: 102abea7f6ab9cad
< Strict-Transport-Security: max-age=31536000
< Age: 2
< Via: https/1.1 usprz4-vp-vst-014.ts.apple.com (acdn/20.17688), https/1.1 usprz4-vp-vfe-008.ts.apple.com (acdn/20.17688), https/1.1 ussjc2-xdc-mx-027.ts.apple.com (acdn/20.17688), https/1.1 ussjc2-edge-fx-034.ts.apple.com (acdn/20.17688)
< X-Cache: hit-stale, miss, miss, miss
< CDNUUID: 4288cfb5-b906-4fbc-8c9c-c55207fe2e1b-109273926
< Connection: keep-alive
< 
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "4572YRV3M6.gr.kathimerini.Kathimerini",
                "components": [
                          { "/": "/politics/*" },
                          { "/": "/economy/*" },
                          { "/": "/society/*" },
                          { "/": "/world/*" },
                          { "/": "/culture/*" },
                          { "/": "/special-reports/*" },
                          { "/": "/k/*" },
                          { "/": "/life/*" },
                          { "/": "/athletics/*" },
                          { "/": "/nytimes/*" },
                          { "/": "/visual/*" },
                          { "/": "/istoria/*" },
                          { "/": "/opinion/*" },
                          { "/": "/explainers/*" },
                          { "/": "/investigations/*" },
                          { "/": "/epikairothta/*" },
                          { "/": "/tag/*" },
                          { "/": "/columns/*" },
                          { "/": "/author/*" },
                          { "/": "/authors/*" },
                          { "/": "/ekpompes/*" },
                          { "/": "/podcast-folder/*" },
                          { "/": "/my-account/*" },
                          { "/": "/games/*" },
                          { "/": "/newsletters/*" },
                          { "/": "/ereplica/*" },
                          { "/": "/syndromes/nytimes-prosfora/*", "exclude": true },
                          { "/": "/syndromes/revolut-plans/*", "exclude": true },
                          { "/": "/syndromes/*" },
                          { "/": "/kairos-prognosi/*" },
                          { "/": "/imia-30-chronia-meta/*" }
                        ]
            }
        ]
    }
* Connection #0 to host app-site-association.cdn-apple.com left intact

Of course is a suggestion to avoid subdomains.

Albert  WWDR

Thank you for looking into this.

The CDN did sync, but it still has the old version of the file. The CDN copy is 1863 bytes, while our current file is 1953 bytes (ETag W/"6abf57ff-7a1"). The 90-byte difference is exactly the new line:

{ "/": "/syndromes/gastronomos-prosfora/*", "exclude": true },

Current state on our side (Oct 14, 07:50 UTC)

Requesting https://www.kathimerini.gr/.well-known/apple-app-site-association with -A "AASA-Bot/1.0.0" returns:

  • HTTP 200, Content-Type: application/json, no redirect
  • ETag: W/"6abf57ff-7a1" (1953 bytes, includes the new line)
  • cf-cache-status: DYNAMIC (Cloudflare is not caching this file; it is served directly from our origin)

Earlier this week Cloudflare was returning a cached copy (cf-cache-status: HIT), which may explain the stale sync on Oct 13. That is no longer the case.

Apple CDN (Oct 14, 06:59 UTC, Frankfurt edge)

https://app-site-association.cdn-apple.com/a/v1/www.kathimerini.gr still returns:

  • Content-Length: 1863 (old version, without the new line)
  • Age: 3818
  • X-Cache: hit-stale, miss, hit-fresh, miss

Questions

  1. Could you check whether your crawler's latest attempts to fetch our file are succeeding? The hit-stale suggests the CDN is still serving the old copy while a re-fetch is pending or failing.
  2. Now that our origin serves the correct file without caching, is there a way to trigger a re-sync, or should we wait for the next scheduled one?
  3. Regarding the apex domain: our app currently uses only applinks:www.kathimerini.gr. If we serve the file directly on kathimerini.gr, do we also need to add applinks:kathimerini.gr to the entitlements in a new app release?

Thanks again for your help.

Accepted Answer

Thanks so much for your reply and the great details.

The previous cf-cache-status: HIT from Cloudflare is almost certainly why the CDN cached stale version of the file. The hit-stale status you are seeing from the CDN indicates that the cache TTL has expired, and the CDN is serving the stale cached copy while it attempts an asynchronous background fetch to your origin. Now that you have bypassed Cloudflare caching (cf-cache-status: DYNAMIC) and are serving the correct 1953-byte file with a 200 OK, the next background fetch by the AASA-Bot will succeed and update the CDN cache.

Triggering a Re-sync There is no manual way or API to force a cache purge or trigger an immediate re-sync on the AASA CDN. The CDN will update automatically based on its internal schedule.

If you want to support links on the other domain, you must add applinks:domain to your Associated Domains entitlements in Xcode and release a new version of your app. You will also need to ensure the AASA file is accessible at https://kathimerini.gr/.well-known/apple-app-site-association.

Please keep an eye on your server to make sure they always return a none cached version of the AASA file and your solution will keep working.

Albert  WWDR