# Space-to-Space requests to \*.hf.space return 503 from awselb (since Jul 8) **URL:** \ **Category:** Spaces\ **Created:** [July 9, 2026, 6:37am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607 "2026-07-09T06:37:58Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![minphak](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/minphak/32/61486_2.png) [@minphak](https://discuss.huggingface.co/u/minphak)\ **Post date:** [July 9, 2026, 6:37am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/1 "2026-07-09T06:37:58Z")
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? ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [July 9, 2026, 8:00am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/2 "2026-07-09T08:00:31Z")
> Is this an intentional policy change or a regression? I don’t know which one it is, but… > [@Persistent 503 Error Between Private Docker Spaces](https://discuss.huggingface.co/t/persistent-503-error-between-private-docker-spaces/177610/2): > > Personally, this (and [Space-to-Space requests to \*.hf.space return 503 from awselb (since Jul 8)](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607)) looks more like a regression to me. Details below: just in case, @hysts Direct answer: the general architecture does not appear to be inherently unsupported. Hugging Face documents Docker Spaces as suitable for [FastAPI and other API endpoints](https://huggingface.co/docs/hub/spaces-sdks-docker), documents authenticated access to private Space endpoints, and also documents [calling one Space from another Space](https://huggingface.co/docs/hub/spaces-api-endpoints). I could not find one official referenc… ---
**Author:** ![minphak](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/minphak/32/61486_2.png) [@minphak](https://discuss.huggingface.co/u/minphak)\ **Post date:** [July 9, 2026, 8:36am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/3 "2026-07-09T08:36:07Z")
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. ---
**Author:** ![hysts](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/hysts/32/32230_2.png) [@hysts](https://discuss.huggingface.co/u/hysts)\ **Post date:** [July 9, 2026, 8:48am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/4 "2026-07-09T08:48:26Z")
Thanks for reporting this. We’re aware of the issue and are currently waiting for the infra team to respond. ---
**Author:** ![hung319](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/hung319/32/61498_2.png) [@hung319](https://discuss.huggingface.co/u/hung319)\ **Post date:** [July 9, 2026, 2:37pm UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/5 "2026-07-09T14:37:05Z")
I also encountered that error. At first, I thought it was due to my code, but after a while, I found out the cause was huggingface. ---
**Author:** ![hysts](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/hysts/32/32230_2.png) [@hysts](https://discuss.huggingface.co/u/hysts)\ **Post date:** [July 10, 2026, 12:50am UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/6 "2026-07-10T00:50:32Z")
It’s fixed now. Thanks! ---
**Author:** ![system](https://us1.discourse-cdn.com/hellohellohello/original/2X/d/de4155eb4aa4108ecb32a1389d7cc37ae69f88b7.png) [@system](https://discuss.huggingface.co/u/system)\ **Post date:** [July 10, 2026, 12:50pm UTC](https://discuss.huggingface.co/t/space-to-space-requests-to-hf-space-return-503-from-awselb-since-jul-8/177607/7 "2026-07-10T12:50:36Z")
This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.