What is macOS Content Caching?
In environments with multiple Apple devices (like a home with three iPhones and two MacBooks, or an office with fifty iMacs), downloading the exact same 4GB macOS software update or 2GB iOS update on every single device consumes a massive amount of internet bandwidth. To solve this, Apple built a feature into macOS called Content Caching.
When Content Caching is enabled on a Mac (usually a desktop like a Mac mini that is always plugged in via ethernet), it intercepts software updates, iCloud data, and App Store downloads. The Mac downloads the file once and stores it on its local hard drive. When the next iPhone on the network requests the same update, it pulls the file directly from the Mac over the local Wi-Fi network at blazing speeds, completely bypassing the external internet connection.
However, Apple devices configure this silently in the background using Bonjour. If a client device is failing to download updates quickly, it can be incredibly difficult to tell if it has successfully found your caching server. The assetcachelocatorutil command in the Terminal solves this.
Step 1: Open the Terminal
You must run this command on the client machine (the MacBook or iPhone you suspect is failing to connect to the cache), not the server itself.
- Press Command + Space to open Spotlight Search.
- Type
Terminaland press Enter.
Step 2: Run the Locator Utility
Type the following command and press Enter. Because it is simply querying the local network, you do not need sudo privileges:
assetcachelocatorutil
Step 3: Analyze the Output
The command will take a few seconds to run, as it actively pings the local subnet and queries Apple’s cloud directory to see if a registered caching server is supposed to exist on your public IP address.
The output is heavily structured. Look for the section labeled “Found X local caching servers”.
Scenario A: The Server is Found
If your Mac successfully located the server, you will see output that looks like this:
Found 1 local caching server:
192.168.1.150:49213 (healthy)
This confirms that your client Mac is actively routing its App Store and software update traffic to the Mac located at IP address 192.168.1.150 on port 49213. The “(healthy)” tag confirms the server is responding.
Scenario B: The Server is Not Found
If the output says “Found 0 local caching servers,” you have a network routing issue. Even if the Mac acting as the server is powered on, the client cannot find it.
This usually occurs in corporate or university networks where client devices are on a different subnet (e.g., a Wi-Fi VLAN) than the caching server (e.g., an Ethernet VLAN). Because the Bonjour protocol (mDNS) does not cross subnets by default, the client Mac has no idea the server exists.
Step 4: Check External Reachability
Further down in the assetcachelocatorutil output, you will see a section labeled “Public IP address configuration.”
If a client Mac cannot find the server via local Bonjour, it will ask Apple’s cloud servers: “Hey, I am coming from public IP 203.0.113.5. Did anyone register a caching server on this IP?”
If your network uses multiple WAN IP addresses (like a load-balanced dual-WAN router), the client Mac might be browsing the web on a different public IP address than the caching server. The output will clearly state if the public IP addresses do not match, which explains why the client is being forced to download updates directly from Apple rather than using your local cache.