Apple's Content Caching service is a powerful tool for organizations looking to reduce bandwidth usage and improve download speeds for iOS apps and system updates. However, when it stops working, it can be frustrating to diagnose. This guide walks you through identifying and fixing common issues with your Apple Content Caching server.
Identifying the Problem
When your content caching server isn't working, you'll typically see no incoming requests and zero data transfer statistics. Here's how to confirm this.
Step 1: Check for Incoming Requests
First, examine the recent logs to see if any requests are coming into your caching server:
log show --predicate 'subsystem == "com.apple.AssetCache"' --last 5m
If your server isn't receiving requests, you'll see output similar to this:
Filtering the log data using "subsystem == "com.apple.AssetCache""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp Thread Type Activity PID TTL
--------------------------------------------------------------------------------------------------------------------
Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0
Activity - Create: 0, Transition: 0, Actions: 0
Step 2: Verify Transfer Statistics
Next, check the data transfer statistics:
AssetCacheManagerUtil status
A non-functional server will show all zeros:
TotalBytesDropped: Zero KB
TotalBytesImported: Zero KB
TotalBytesReturnedToChildren: Zero KB
TotalBytesReturnedToClients: Zero KB
TotalBytesReturnedToPeers: Zero KB
TotalBytesStoredFromOrigin: Zero KB
TotalBytesStoredFromParents: Zero KB
TotalBytesStoredFromPeers: Zero KBStep 3: Verify Public IP Assignment
Check that your server has a valid public IP address assigned:
AssetCacheManagerUtil status
Look for these key fields in the output:
PersonalCacheUsed: Zero KB
Port: 49597
PublicAddress: 21.44.33.356
RegistrationStatus: 1
RestrictedMedia: false
ServerGUID: <guid>
StartupStatus: OK
The PublicAddress field should show your actual public IP address.
Step 4: Confirm IP Discovery
Verify that the public IP can be discovered by Apple's services:
AssetCacheLocatorUtil
You should see output confirming the same public IP:
2025-09-18 11:46:08.654 AssetCacheLocatorUtil[26790:7953306] This computer's public IP address is 21.44.33.356.
2025-09-18 11:46:09.434 AssetCacheLocatorUtil[26790:7953306] There might be content caches available.
2025-09-18 11:46:09.439 AssetCacheLocatorUtil[26790:7953306] localhost:49597, rank 0, not favored, healthy, guid <guid>
Important: If the public IP isn't listed in AssetCacheLocatorUtil, you may need to disable and re-enable the content cache service. This often happens when the cache was enabled before NAT rules were properly configured.
Step 5: Restart the Service (If Needed)
If the IP addresses don't match or the service can't be discovered, disable and re-enable the content caching service. When you do this, check the logs again:
log show --predicate 'subsystem == "com.apple.AssetCache"' --last 5m
You should now see startup parameters including your external IP and address ranges:
AssetCache: [com.apple.AssetCache:builtin] Registering with local address: 192.168.26.250 (1000 Mbit/sec wired); port 49153; listen range only: 192.168.86.1-192.168.86.250, 174.88.40.1-174.88.40.200; version: 251
AssetCache: [com.apple.AssetCache:builtin] Got back public IP 21.44.33.356.
Step 6: Update Configuration
In my particular example, the IP ranges given where not the ones used by the client device, which caused the content caching server to ignore those requests because they were not in the correct range, this therefore required an update through the command line.
This will trigger a re-registration, both the configuration/reload are shown below (remember to change for your IP ranges)
sudo -u _assetcache defaults write /Library/Preferences/com.apple.AssetCache.plist ListenRanges '( { first = 192.168.86.1; last = 192.168.86.250; }, { first = 174.88.40.1; last = 174.88.40.200; } )'
sudo AssetCacheManagerUtil reloadSettings
AssetCache: [com.apple.AssetCache:builtin] ListenRanges setting changed
AssetCache: [com.apple.AssetCache:builtin] Re-registering because the configuration changedStep 7: Confirm Active Caching
Once your server is properly configured, you should see requests coming in when iOS devices download apps or updates:
log show --predicate 'subsystem == "com.apple.AssetCache"' --last 5m
Active caching will show entries like:
AssetCache: [com.apple.AssetCache:builtin] Received GET request by "com.apple.appstored/1.0" for /itunes-assets/Purple211/v4/bd/86/80/...
AssetCache: [com.apple.AssetCache:builtin] Served 26.9 MB of 43.7 MB; 0 bytes from cache, 26.9 MB stored from Internet
Step 8: Check Transfer Statistics
Finally, verify that data is being served:
AssetCacheManagerUtil status
A working server will show non-zero values:
TotalBytesDropped: Zero KB
TotalBytesImported: Zero KB
TotalBytesReturnedToChildren: Zero KB
TotalBytesReturnedToClients: 577.5 MB
TotalBytesReturnedToPeers: Zero KB
TotalBytesStoredFromOrigin: 580.6 MB
TotalBytesStoredFromParents: Zero KB
TotalBytesStoredFromPeers: Zero KB
Common Issues and Solutions
IP Range Mismatches
The most common issue is incorrect IP range configuration. Your content cache will only serve requests from clients within the configured IP ranges. If your clients are on different subnets than what's configured, they won't be able to use the cache.
Solution: Update your IP ranges in the Content Caching settings to include all client subnets.
NAT Configuration Problems
If your content cache was enabled before NAT rules were configured, it may not register properly with Apple's services.
Solution: Disable and re-enable the content caching service after ensuring your NAT configuration is correct.
Network Discovery Issues
Sometimes the cache server can't determine its public IP address correctly, especially in complex network environments.
Solution: Verify your firewall and NAT configurations allow the cache server to communicate with Apple's registration services.
By following these steps systematically, you should be able to identify and resolve most Apple Content Caching server issues. The key is understanding that the service depends heavily on proper network configuration and IP range matching between the server and its clients.