Space-to-Space requests to *.hf.space return 503 from awselb (since Jul 8)

Hugging Face Spaces are experiencing a service disruption where Space-to-Space requests to *.hf.space domains return 503 errors from an AWS ELB since July 8. The issue affects all traffic between Spaces regardless of SDK, visibility, or authentication, while external requests and other Hugging Face services remain functional.

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 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.