Download via Xet

Hugging Face's official documentation as of July 22, 2026, lists nine hostnames for downloads behind a proxy or firewall, including EU Xet endpoints and CDN/LFS endpoints, but omits cas-bridge.xethub.hf.co and cas.xethub.hf.co. The recommended change-resistant configuration is to allow hf.co and huggingface.co as suffixes covering all subdomains, as the hostnames may evolve with storage and CDN infrastructure changes.

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 “Downloading behind a proxy or firewall” table https://huggingface.co/docs/hub/models-downloading downloading-behind-a-proxy-or-firewall . 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.