Since between Jul 8–9 2026, HTTP requests made from INSIDE a Space container to ANY .hf.space host return 503 with body {“data”:[]} and header server: awselb/2.0. The AWS load balancer answers directly; the request never reaches the target.
Space (no x-proxied- headers). The same URLs return 200 from outside HF.
Verified: happens against multiple of my own Spaces AND against gradio spaces; identical with and without a valid PRO token; reproduced from two different container egress IPs; DNS is identical inside and outside.
This breaks the documented pattern of calling a ZeroGPU Space from another Space
via gradio_client.
Is this an intentional policy change or a regression? If intentional, what is the
supported way for one Space to call another Space’s API?
Thanks,
Our setup is different from the once you ping me: a CPU Docker Space calling ZeroGPU Gradio Spaces via gradio_client, which supports the conclusion that this affects ALL Space-to-Space traffic regardless of SDK, visibility, or auth. It worked for us just a day ago before getting the issues.
Summary of the controls we ran, they are same-minute probes from inside a Space container and from outside:
Same URL, same DNS IPs: outside → 200 (server: uvicorn, x-proxied-* headers present), inside → 503 {“data”:} (server: awselb/2.0, no proxy headers, so the request never reaches the target Space).
Identical result with a valid PRO token, an invalid token, and no token.
Also 503 against a public third-party Gradio Space from insid, not account- or Space-specific.
Reproduced from three different container egress IPs.
One data point that may help HF narrow it down: from inside the SAME container and in the SAME probe, https://huggingface.co/api/whoami-v2 returns 200 (authenticated) and general egress works fine. Only *.hf.space hosts are rejected. So this looks specific to the *.hf.space load balancer listener for traffic originating from Space containers, not container networking/DNS/egress.