# Download via Xet > Source: > Published: 2026-07-22 12:28:07+00:00 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.