Download via Xet

Beginners
2

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.

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:

  1. Treat the current documentation table as the best available exact-FQDN allowlist.
  2. Do not assume that it is a permanent infrastructure contract.
  3. If possible, allow the hf.co and huggingface.co suffixes at arbitrary subdomain depth.
  4. If your policy requires exact FQDNs, manage the documented list as a configuration that may need updating.
  5. Only Hugging Face can confirm future endpoints, deprecation guarantees, and whether there is an official change-notification process.

The documentation itself explicitly warns that the hostnames may change as the storage and CDN infrastructure evolves.

Recommended configuration

If arbitrary-depth suffix matching is permitted

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.

If only exact FQDN entries are permitted

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:

  • the date on which the list was approved;
  • the version of huggingface_hub and hf_xet being used;
  • whether downloads use hf download, from_pretrained, Git, a browser, or another client;
  • the rejected hostname from the firewall or proxy log;
  • whether the failure occurred before the download started or partway through it.

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:

  • whether the documentation table should be treated as the canonical exact-FQDN list;
  • whether there is a changelog or notification channel for additions and removals;
  • whether any additional download endpoints are already planned;
  • whether cas-bridge.xethub.hf.co can still appear on any currently supported path;
  • whether cas.xethub.hf.co is relevant to ordinary Hub downloads.
Why older allowlists differ from the current documentation

There is a useful historical reason for the conflicting lists found in older forum posts.

The older entries were not necessarily incorrect when they were posted. Hugging Face’s download infrastructure changed during the migration from LFS-backed storage to Xet-backed storage.

A simplified timeline is:

Date Publicly documented or reported change
October 2024 HF staff listed regional LFS CDN names such as cdn-lfs-us-1.hf.co and cdn-lfs-eu-1.hf.co.
February 2025 HF staff explained that cas-bridge.xethub.hf.co had become part of the download path during the LFS-to-Xet migration.
April 2025 The Xet-aware client path added cas-server.xethub.hf.co and transfer.xethub.hf.co.
July 2026 Hugging Face added a dedicated proxy/firewall hostname table to the official Hub documentation.
July 16, 2026 A follow-up documentation change aligned the model and dataset lists and removed cas-bridge.* and several older LFS names as legacy endpoints.

The earlier history can be seen in the long-running HF Forum thread “How to get a list of all Huggingface download redirections to whitelist?”.

The documentation history is also visible in:

That is why an older working corporate allowlist may contain names that are no longer shown in the current table.

cas-bridge.xethub.hf.co

This hostname was explicitly recommended by HF staff during the earlier migration period, so seeing it in older answers is expected.

However, the July 16 documentation update classifies cas-bridge.* among the legacy endpoints removed from the current list.

I would therefore not present it as a currently required hostname based only on historical forum answers.

On the other hand, if it appears in a current firewall deny log during a real download, that is useful evidence to give HF staff. Documentation changes describe the intended current list, but an observed production redirect could reveal a compatibility path or transition case that is still active.

cas.xethub.hf.co

I could not find this hostname in the current Hub download allowlist.

The public Xet authentication documentation shows the Hub returning a casUrl, with the example:

{
  "casUrl": "https://cas-server.xethub.hf.co"
}

See Xet authentication and authorization.

For that reason, I would not add cas.xethub.hf.co to a normal Hub-download allowlist solely because it resembles the documented CAS hostname.

If it was obtained from an actual current request, redirect, or deny log, the exact client and operation would matter: download, upload, Git/Xet, or a lower-level Xet API may not use the same endpoint set.

Why several hostname classes are required

A Hub download is not necessarily a single HTTPS request to huggingface.co.

At a high level, the traffic can involve several layers:

huggingface.co
    |
    |  repository metadata, authentication,
    |  download redirect, and Xet token/casUrl
    v
cas-server...
    |
    |  Xet reconstruction information
    |  containing data-fetch locations
    v
transfer... / us.*.cdn... / cdn-lfs-...
    |
    |  actual file or chunk transfer
    v
local cache / application

The exact internal flow depends on the client and the repository, but it is useful to distinguish:

Layer Purpose Examples
Hub/control plane Repository metadata, permissions, redirects and Xet token discovery huggingface.co
Xet CAS service Reconstruction and Xet protocol operations cas-server.xethub.hf.co
Xet transfer/data plane Fetching file chunks or reconstructed data transfer.xethub.hf.co
CDN/LFS delivery Regional or compatibility delivery paths us.aws.cdn.hf.co, cdn-lfs-us-1.hf.co

The Xet protocol documentation describes the Hub returning both an access token and a casUrl; the client then uses that CAS endpoint for Xet operations. See Authentication and Authorization.

Hugging Face also documents an LFS bridge for backward compatibility with older clients in Using Xet Storage.

This layering explains why:

  • allowing only huggingface.co may let metadata requests succeed while the large file transfer still fails;
  • the download may begin successfully and then time out when it reaches a blocked storage hostname;
  • two clients may expose different hostnames;
  • a browser or older client may not follow exactly the same route as a current hf_xet client.

It also means that a successful trace from one machine does not prove that the same small set covers every region, client, repository type and egress network.

A recent, now-closed xet-core issue reported different chunk-delivery hostnames being returned from different egress environments. That issue should not be treated as evidence of a current outage, but it is a concrete example of why one packet capture may not demonstrate global completeness.

A low-cost way to validate an exact-FQDN deployment

I would validate the configuration through a real download rather than treating the HTTP status from each bare hostname as the test.

For example, requesting only:

https://huggingface.co/hf-xet-transfer/

may legitimately return 403, while requesting only:

https://cas-server.xethub.hf.co/

may return 404.

Those services normally expect a particular path, token, signed URL, range request, or reconstruction identifier. A bare-root 403 or 404 proves that an HTTPS response was received; it does not by itself show that the hostname is blocked or that a real signed download will work.

A practical interpretation flow is:

Real model/tokenizer download fails
|
+-- DNS resolution fails
|     -> DNS or proxy name-resolution branch
|
+-- TCP/443 connection times out
|     -> firewall, routing, or egress-policy branch
|
+-- TLS certificate verification fails
|     -> corporate TLS inspection / CA trust branch
|
+-- Metadata/config downloads, but a large file times out
|     -> likely storage/CDN hostname or data-plane branch
|
+-- Bare service URL returns 403/404
|     -> not conclusive; test the actual download flow
|
+-- An undocumented hostname appears in the deny log
      -> record the hostname, client/version and operation,
         then ask HF whether it is current, legacy or unexpected

The most useful evidence is usually:

Exact blocked hostname:
Client command/API:
huggingface_hub version:
hf_xet version:
Repository and filename:
Xet enabled or disabled:
Proxy or direct egress:
Error type:
Request ID, if present:

This is enough information for HF staff to compare the observed path with the intended infrastructure without requiring a full packet capture.

If the environment uses an explicit HTTP proxy

Firewall allowlisting and proxy configuration are related but separate.

If the Python process reaches huggingface.co through a custom HTTP client, that does not necessarily mean the Rust-based hf_xet transfer client is using the same proxy configuration.

The standard first check is whether the process environment provides:

HTTP_PROXY
HTTPS_PROXY

as appropriate for the network.

There has been a huggingface_hub issue where a custom Python client factory affected the Python HTTP path but did not configure hf_xet; using the proxy environment variables made the Xet path work.

That does not mean every timeout is a proxy-configuration bug, but it is a useful separate branch when:

  • API or metadata calls succeed;
  • Xet transfers fail;
  • and the organization requires an explicit outbound proxy.

Similarly, an SSL: CERTIFICATE_VERIFY_FAILED error is not automatically evidence that another hostname is missing from the allowlist. It may instead mean that corporate TLS inspection is presenting a certificate chain that the Python or Rust trust store does not accept.

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:

  1. Start from the current official nine-host table.
  2. Prefer full suffix rules for hf.co and huggingface.co where policy permits.
  3. Otherwise maintain the nine exact FQDNs and inspect real deny logs for changes.
  4. Treat older cas-bridge lists as historical unless current traffic proves otherwise.
  5. Ask Hugging Face to confirm the canonical-list and change-notification questions, because those cannot be guaranteed from outside their infrastructure.