Because this may change over time, I think the table in the current documentation is the most reliable reference:
As of July 22, 2026, the closest thing I can find to a current public answer is Hugging Face’s official “Down behind a proxy or firewall” table.
It currently lists the following hostnames, all over HTTPS / port 443:
huggingface.co
cas-server.xethub.hf.co
cas-server.xethub-eu.hf.co
transfer.xethub.hf.co
transfer.xethub-eu.hf.co
us.aws.cdn.hf.co
us.gcp.cdn.hf.co
cdn-lfs-us-1.hf.co
cdn-lfs-eu-1.hf.co
So, compared with the current documentation, your list is not complete: it is missing the EU Xet endpoints and the current CDN/LFS endpoints.
At the same time, two names in your list are not in the current documented table:
cas-bridge.xethub.hf.co
cas.xethub.hf.co
My practical interpretation would therefore be:
hf.co
and huggingface.co
suffixes at arbitrary subdomain depth.The documentation itself explicitly warns that the hostnames may change as the storage and CDN infrastructure evolves.
The simplest and most change-resistant configuration is to allow:
hf.co
huggingface.co
as suffixes covering all subdomains.
This is different from assuming that a single-label wildcard such as *.hf.co
matches every nested name. Some firewall and proxy products would match:
cdn-lfs-us-1.hf.co
but not deeper names such as:
cas-server.xethub.hf.co
us.aws.cdn.hf.co
Also:
*.xethub.hf.co
does not necessarily cover:
cas-server.xethub-eu.hf.co
transfer.xethub-eu.hf.co
because those are below xethub-eu.hf.co
, not xethub.hf.co
.
The exact behavior depends on whether the security product implements a true domain suffix rule, an RFC-style wildcard, or only one-label wildcard matching.
I would start with the nine hostnames from the current documentation and treat that page as the operational reference.
For a controlled enterprise environment, it may also be useful to record:
huggingface_hub
and hf_xet
being used;hf download
, from_pretrained
, Git, a browser, or another client;That makes it easier to distinguish a newly introduced endpoint from a TLS-inspection, proxy-routing, DNS, or client-specific problem.
The parts I think only Hugging Face can authoritatively confirm are:
cas-bridge.xethub.hf.co
can still appear on any currently supported path;cas.xethub.hf.co
is relevant to ordinary Hub downloads.One final caution: I would not rely on HF_HUB_DISABLE_XET=1
as the main firewall strategy.
It can be useful for diagnosing whether behavior differs between client paths, but it does not guarantee that all downloads remain on huggingface.co
or avoid the documented CDN hostnames. In at least one reported case, the non-Xet compatibility path still redirected to the same CDN endpoint.
So the default route I would use is:
hf.co
and huggingface.co
where policy permits.cas-bridge
lists as historical unless current traffic proves otherwise.