Unity Addressables Remote Catalog Not Updating - CDN Caching Fix

Problem: You shipped a new Addressables build and uploaded fresh catalog and bundle files to your remote host or CDN, but players (or your own test devices) still download old assets. The game may log hash mismatches, CatalogLoadOperationException, Unable to load dependency, or simply never pick up new art or scenes. In the Editor, Play Mode Script using Use Existing Build may also appear to load an outdated catalog if you are pointing at a cached URL.

Root cause (typical): HTTP caches (CDN edge, reverse proxy, browser-like stacks, or aggressive corporate proxies) are returning 304 Not Modified or a stale body for catalog.json, catalog_*.hash, or bundle URLs. Less often, RemoteLoadPath in the Addressables profile does not match where you uploaded files, or you incremented content locally but did not rebuild and upload the full set of remote files that match the new catalog.

This guide focuses on remote catalog freshness. For local build pipeline errors, see Unity’s Addressables documentation and your CI logs for the Addressables content build step.

Quick fix checklist

Open the remote catalog URL in a private browser window or with curl -I and confirm Cache-Control and ETag behavior; force-refresh should return 200 with a new body after deploy.
Confirm RemoteLoadPath (and BuildPath for remote content) matches the exact folder and file names you uploaded (trailing slashes, bucket region, and case sensitivity on some hosts).
After each content release, upload both the new catalog files and any new or changed bundles referenced by that catalog; partial uploads cause silent fallback to old hashes.
On mobile, clear the app’s persistent data or bump catalog location (path or query) once to rule out device-side caching of the catalog file.
If you use a CDN, purge or invalidate the path for catalog.json (and hash files) after every Addressables content publish, or set short TTL for those objects.

Step 1 - Verify what the client actually downloads

Copy the full RemoteLoadPath from your active Addressables profile (for example https://cdn.example.com/game-addressables/[BuildTarget]).
Append the catalog file name your build emits (often catalog_*.json depending on version; check ServerData output folder).
Fetch headers:

curl -I "https://your-cdn.example.com/.../catalog_2026.03.22.json"

Look for Cache-Control: max-age= with a large value, or immutable flags on catalog objects. That explains why updates appear late.

Verification: Change one byte in the catalog on the server (in a test bucket), repeat curl, and confirm you see the change when bypassing cache (curl -H "Cache-Control: no-cache").

Common mistake: Testing only in the Editor with Use Asset Database while production players use remote catalogs; behaviors differ.

Step 2 - Fix CDN and origin cache headers

Apply short TTL or no-cache for catalog and hash files, while keeping long TTL for content-addressed bundles (files named with hashes) if your pipeline supports it.

Typical pattern:

Catalog JSON / hash files: Cache-Control: public, max-age=60 (or no-cache during active development).
Bundles with hash in filename: Cache-Control: public, max-age=31536000, immutable (safe when the file name changes every build).

On AWS CloudFront, Azure CDN, Cloudflare, or Fastly, create a cache behavior or rule that matches catalog*.json and *.hash separately from *.bundle or your bundle extension.

Verification: After rule changes, curl -I should show the new Cache-Control for catalog URLs.

Step 3 - Bust caches without breaking players mid-session

Preferred options:

Versioned folder per release (for example .../v202/ → .../v203/) and update RemoteLoadPath in the next app update or via a tiny bootstrap config.
Query string on catalog URL only if your host and Addressables path support it consistently (some CDNs ignore query strings for cache keys unless configured).
Purge the exact catalog path immediately after upload as part of your release script.

Avoid renaming only the catalog on the server without uploading matching bundle entries; players will request missing or mismatched hashes.

Step 4 - Align Addressables profiles and build output

In Window > Asset Management > Addressables > Groups, open Profiles.
Confirm RemoteLoadPath uses the same variable you think (e.g. RemoteLoadPath custom entry) across Default and Release profiles.
Run Build > New Build > Default Build Script (or your CI equivalent) and upload the entire ServerData/<platform> output for that build id.

Verification: Compare bundle file names on the server with the catalog JSON references (search for a bundle name). Mismatches mean wrong folder or incomplete upload.

Step 5 - Clear local player cache during QA

On Windows standalone, Addressables may cache under persistentDataPath. For a clean test:

Close the build.
Delete the app’s persistent data folder for your company/product name (path varies by OS).
Launch again and watch Addressables logs with verbose logging enabled.

Common mistake: Assuming uninstall always clears every custom cache path your code created.

Alternative causes (if CDN is innocent)

Player binary still points at an old RemoteLoadPath (shipped client never updated).
SSL termination or redirect (HTTP → HTTPS) serves a different tree than you expect.
Mixed regions: upload went to eu-west bucket while RemoteLoadPath points to us-east.
Catalog update at runtime disabled or failed silently; check Addressables.InitializeAsync and CheckForCatalogUpdates results in logs.

Prevention tips

Automate upload + CDN purge in one script tied to your Addressables content version.
Store content version in PlayerPrefs or server config and log it on boot so testers can prove which catalog they loaded.
Treat catalog files as release artifacts with the same seriousness as player binaries.

FAQ

Should I use DisableCatalogUpdateOnStartup?
Useful when debugging, but for live games you usually want controlled update checks with clear failure UI, not silent stale data.

Does Addressables replace AssetBundles completely?
Addressables manages bundles and catalogs; you still must host files correctly and respect HTTP caching.

Why does Editor work but device fails?
Editor may use local build paths or fast mode; device uses remote URLs and real network caches.