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

> Source: <https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607#post_3>
> Published: 2026-07-09 08:36:07+00:00

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.