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.
Hopefully it’s transient and gets fixed soon.