cache-domains: the hostname list a LAN game cache needs

A hostname corpus, not a caching server

The repository description says it plainly: domain names required for LAN content cache DNS spoofing. The README calls the project Game Content Cache Hostnames and describes it as a list of all hostnames that are required to be redirected for running a game content cache, adding that the list will change frequently and that it is designed to be a definitive list.

That framing matters. There is no daemon here, no proxy, no cache storage logic. What the project provides is the input a cache needs: the set of hostnames whose traffic must be intercepted and pointed at a local cache server, kept current by the people who run such caches. The value is in the maintenance, since a game publisher adds or renames content hosts regularly and a stale list means cache misses that look like slow downloads.

The audience is a UK LAN event network engineer, or anyone running a game content cache on a local network, who already has a cache server and needs to know what to redirect. The top level of the repository is a directory of text files named after services, with a JSON index, a FAQ document and a scripts directory. The licence is MIT, with copyright held by UK LAN Techs since 2017.

The project is not archived and the last push was on 2026-10-12, which fits a list that is expected to change constantly. There are no GitHub releases, so there is no version to pin; a deployment takes the current branch.

Two ways to consume the list: DNS override or Squid with WCCP

The README gives two ways to use the list, and the choice is about where the redirect happens rather than what the list contains.

The first is overriding DNS for these hostnames so that they resolve to the IP of your cache server. The second is using them in Squid with WCCP to redirect content to the right cache server. In the first case your network's resolver is the interception point and the cache server is addressed directly; in the second, the proxy is the interception point and it is told which destinations to divert.

The difference matters in practice. A DNS override is a blunt instrument, since every client that uses your resolver will be sent to the cache for those names whether or not the client is on the event network, and it depends on the caching resolver being under your control. The Squid route is more explicit and keeps the redirect decision inside the proxy, at the cost of running and configuring the proxy and the WCCP relationship.

Either way, the list is only the domain inventory. The README does not describe the cache server side, the disk layout, the storage sizing or how the content is fetched, so the deployment work of standing up a cache is entirely outside this project. It is one input to a network design, and a well maintained one at that.

cache_domains.json indexes the services and their files

Each cacheable service gets a text file of hostnames, and a JSON file, cache_domains.json, ties those files together with metadata. The README documents its structure as a cache_domains array of cache_domain objects, each with a name, a description, notes and a domain_files array of files within the repository associated with the cdn, noting that most CDNs only need one file.

The example entry is a single service with a short name and one file.

{
    "cache_domains": [
        {
            "name": "steam",
            "description": "CDN for steam platform",
            "domain_files": ["steam.txt"]
        }
    ]
}

The fields have rules. The name is a shortname for the cache domain and should match the regular expression ^[0-9A-Za-z]$, so single alphanumeric characters only, which is a tighter constraint than the example entry suggests. The description is a longer description to aid others in identifying what this domain does, and the README is explicit about the reason: not all users of this repository will want to enable all caches. The notes field holds implementation specific notes which may be useful for other users.

The contribution rule is stated in the same file. If the CDN you are adding does not already exist, the README says to add an entry within cache_domains.json as well as a new .txt file, so a new service needs both halves, and a pull request that adds only a text file leaves the index out of date.

Wildcards follow strict rules that Squid will not accept as written

The host files allow wildcards, and the rules for them are specific enough to trip people up. The README states that wildcards should be represented with an asterisk, that if a wildcard is used it should be the first character on the line, that wildcards are not treated as matching null, so that *.example.com will match a.example.com but will not match example.com, and that only simple domain wildcards will be accepted, for example *.example.com and not a pattern with a host prefix such as *ww.example.com.

That last restriction is a real constraint on a cache list. A wildcard that is not a pure subdomain wildcard cannot be expressed in the format at all, so a service that needs it is either excluded or handled by listing hosts explicitly.

Squid users hit a second wall. The README notes that if you use these files within a squid dst_domain acl you will need to reformat the wildcard entries to be compliant with the squid acl format, gives the regular expression s/*\./\./ as sufficient, and warns that latest versions of squid are very particular about duplicate domains. The scripts/create-squid.sh script exists to handle that conversion.

So the same file cannot be consumed unchanged by both routes. A DNS deployment can use the wildcard lines as written, while a Squid deployment needs a conversion step, and the duplicate domain sensitivity means the conversion is not always a clean mechanical substitution.

One text file per service, with a strict line format

The host file format is documented separately, and the rules are the kind that a linter can enforce but a human can break by accident.

Every line should be a separate hostname for that service, only one entry is permitted per line, wildcards are permitted as described, lines starting with a # are treated as a comment, files must end with an empty newline, and file names must match the regular expression ^[0-9A-Za-z].txt.

The last two rules catch the mistakes that matter. A file that does not end with a newline can have its last hostname silently dropped by a consumer that reads line by line, and a file name that does not match the pattern will not be picked up by tooling that globs for it.

The top level of the repository shows the current inventory of services, and it is a good picture of what a LAN event actually caches. The files include steam.txt, blizzard.txt, bsg.txt, riot.txt, nintendo.txt, sony.txt, square.txt, epicgames.txt, origin.txt, uplay.txt, warframe.txt, pathofexile.txt, worldofwarcraft style entries such as wargaming.net.txt, windowsupdates.txt and xboxlive.txt, alongside platform specific services like cityofheroes.txt, daybreak.txt, frontier.txt, neverwinter.txt, teso.txt and cod.txt, plus community lists like nexusmods.txt, renegadex.txt and arenanet.txt, and a test.txt used for checking the tooling.

The wide mix tells you the scope. The list is not only about game launchers; it covers operating system update traffic and community content sites, which is what a shared network at an event ends up pulling whether the organisers planned for it or not.

CDNs that only speak HTTPS are excluded on purpose

Not every CDN can be cached, and the project has a category for them. The README states that certain CDNs are not suitable for inclusion on this list because the content is entirely delivered over HTTPS and thus cannot be cached, and points to a list of currently identified uncacheable CDNs through the project's own issue tracker, filtered on an open issue label of https-cantfix.

This is the most important limitation for anyone sizing a cache. A cache that intercepts plain HTTP can serve those requests from disk, but an HTTPS request has its payload encrypted, so without terminating TLS at the cache there is nothing to store and serve. A DNS override of the hostname alone does not change that, because the certificate and the session belong to the original origin.

The consequence is that the list is a ceiling, not a floor. Even with every hostname in the repository redirected correctly, a large share of modern game traffic will bypass the cache, and the uncacheable set is tracked in issues rather than in the repository, which means the boundary moves with how publishers change their delivery.

The alternative approach to the same problem is to place a TLS terminating proxy in front of the cache, which is a different system with certificate management and a different threat model, and it is not something this project provides or documents.

A shared, moving list maintained by pull requests

The project is collaborative by design, and the README asks contributors to fork the repository and submit pull requests if they have extra hostnames or services to add, saying the goal is for the list to be definitive and collaborative.

The tooling around that reflects a maintained repository rather than a loose collection of files. There is a .mega-linter.yml configuration for a multi-linter setup, a .lefthook.yml for git hooks, an .editorconfig, a .github directory for issue and pull request templates, faq.md for the questions that the README does not answer, and a scripts directory containing the Squid conversion helper.

There is also a curated set of older issues kept as background, reached through a search for closed issues labelled for-reference-only, described as useful anecdotes on cache domains usage. The reasoning behind each entry, the deployment context it came from and the CDN behaviour that made it necessary tend to live there rather than in the README, and that is the first place to look when a service behaves unexpectedly.

There is no homepage and no release history, so the operational picture is the repository itself. A deployment takes the current contents of the branch, and the honest way to think about it is as a subscription you have to pull rather than a dependency you pin.

Editorial conclusion

cache-domains fits a network engineer running a LAN cache for a gaming event who needs the current set of CDN hostnames to redirect, and it does not fit a user who wants caching to happen without touching DNS or proxy configuration. Before adopting it, read faq.md, then confirm that the services you care about have a text file in the repository and that the wildcard entries survive the Squid reformatting the README describes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. uklans/cache-domains on GitHub