# FastAPI WebSocket returns HTTP 404 on Spaces

**URL:** <https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865>\
**Category:** Spaces\
**Created:** [June 19, 2025, 3:12am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865 "2025-06-19T03:12:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Efm-ua](https://avatars.discourse-cdn.com/v4/letter/e/f19dbf/32.png) [@Efm-ua](https://discuss.huggingface.co/u/Efm-ua)\
**Post date:** [June 19, 2025, 3:12am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865/1 "2025-06-19T03:12:37Z")

</div>

Hello,

I am experiencing a persistent issue with deploying a FastAPI application with a WebSocket endpoint on Hugging Face Spaces. All WebSocket connection attempts fail with server rejected WebSocket connection: HTTP 404, while standard HTTP GET requests to the same application work perfectly.

This suggests that the request is being blocked by the proxy before it reaches the application container.

Space URL: [https://efm-ua-docgem-stt-poc.hf.space/](https://efm-ua-docgem-stt-poc.hf.space/)

Problem Details:

- A GET request to [https://efm-ua-docgem-stt-poc.hf.space/](https://efm-ua-docgem-stt-poc.hf.space/) correctly returns a 200 OK with a JSON response.

- A WebSocket connection attempt to wss://efm-ua-docgem-stt-poc.hf.space/ws fails with a 404 error.

- The application logs show the successful GET request but never show any trace of the WebSocket connection attempt, confirming it does not reach the Uvicorn server.

- The issue persists regardless of the WebSocket endpoint path (/, /ws, /queue/join).

Here is a minimal reproducible example that demonstrates the problem:

1. Dockerfile  
FROM tiangolo/uvicorn-gunicorn:python3.12

ENV GRADIO\_SERVER\_PORT=7860  
ENV GRADIO\_SERVER\_NAME=0.0.0.0

WORKDIR /app

COPY requirements.txt .  
RUN pip install --no-cache-dir -r requirements.txt

COPY ./main.py .

EXPOSE 7860

CMD [“uvicorn”, “main:app”, “–host”, “0.0.0.0”, “–port”, “7860”, “–proxy-headers”]

1. requirements.txt  
fastapi  
uvicorn[standard]  
websockets

2. 

import logging  
from fastapi import FastAPI, WebSocket, WebSocketDisconnect

logging.basicConfig(level=logging.INFO)  
logger = logging.getLogger( **name** )

app = FastAPI()

@app.get(“/”)  
async def read\_root():  
logger.info(“Received GET request to root.”)  
return {“status”: “ok”, “message”: “Worker is running. WebSocket is at /ws”}

@app.websocket(“/ws”)  
async def websocket\_endpoint(websocket: WebSocket):  
logger.info(f"WebSocket connection attempt from {websocket.client}“)  
await websocket.accept()  
logger.info(“WebSocket connection accepted.”)  
try:  
while True:  
data = await websocket.receive\_text()  
await websocket.send\_text(f"Echo: {data}”)  
except WebSocketDisconnect:  
logger.info(“Client disconnected.”)

Could you please advise if there is a specific configuration required to allow WebSocket traffic on a non-Gradio FastAPI application?

---

<div class="post-metadata">

**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:** [June 19, 2025, 7:18am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865/2 "2025-06-19T07:18:41Z")

</div>

Perhaps this case?

> [@Chainlit WebSocket Issue on Hugging Face Spaces: Missing websockets in Requirements?](https://discuss.huggingface.co/t/chainlit-websocket-issue-on-hugging-face-spaces-missing-websockets-in-requirements/146755):
>
> I started using Hugging Face Spaces just a few hours ago and noticed that my simple Chainlit app wasn’t working correctly. The app itself is straightforward—it simply returns whatever the user inputs. However, it seems the WebSocket communication isn’t functioning properly, so the responses don’t display as expected (see attached image). After investigating, I found that specifying the websockets package in my requirements.txt file fixes the problem. With websockets installed, the res…

---

<div class="post-metadata">

**Author:** ![Efm-ua](https://avatars.discourse-cdn.com/v4/letter/e/f19dbf/32.png) [@Efm-ua](https://discuss.huggingface.co/u/Efm-ua)\
**Post date:** [June 19, 2025, 7:45am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865/3 "2025-06-19T07:45:31Z")

</div>

server rejected WebSocket connection: HTTP 404 🙁

---

<div class="post-metadata">

**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:** [June 19, 2025, 7:47am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865/4 "2025-06-19T07:47:36Z")

</div>

I wonder if this bug (?) is also occurring in FastAPI…🤔

> [@Persistent 404 on Docker Space - app\_port routing seems to be ignored (User: josejar)](https://discuss.huggingface.co/t/persistent-404-on-docker-space-app-port-routing-seems-to-be-ignored-user-josejar/159665):
>
> Hello Hugging Face community and team, I am writing to report a persistent and blocking issue with every Docker-based Space I create. I have tried all troubleshooting steps and I’m hoping someone can help. I am posting this without links due to the new user filter. The Problem: My Docker Spaces consistently return a 404 error on their public URL. The application logs confirm a successful startup on the correct internal port, so the core issue seems to be that the app\_port directive in my READ…

---

<div class="post-metadata">

**Author:** ![haixuantao](https://avatars.discourse-cdn.com/v4/letter/h/82dd89/32.png) [@haixuantao](https://discuss.huggingface.co/u/haixuantao)\
**Post date:** [September 18, 2025, 7:24am UTC](https://discuss.huggingface.co/t/fastapi-websocket-returns-http-404-on-spaces/159865/5 "2025-09-18T07:24:42Z")

</div>

FYI, I also had error with websocket and my mistake was to use ws:// instead of wss://
