AI Tools Write

Open WebUI behind nginx: login works, then the chat shows connection errorsSolved

QuestionsDawson3 repliesThis topic is about open-webui/open-webui

3

Jump to the accepted answer

DawsonMember#1

Setting up Open WebUI on a small server, container on port 3000, nginx in front with TLS. The login page loads and the login succeeds, but the chat view then shows connection errors and model responses either never arrive or arrive all at once after a long wait. Directly on port 3000 everything works.

Current server block, trimmed:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

The browser console mentions websocket failures. I assume nginx is not passing the upgrade, but the examples I find online disagree about which headers are needed and whether a separate location for the socket path is required. What is the minimal correct config?

3 replies

Lewis ChengMember#2

Accepted answer

It is the upgrade. Open WebUI uses socket.io for live updates and streaming, and nginx does not forward the WebSocket upgrade unless told to. Minimal working version, one location is enough:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;
    proxy_buffering off;
}

proxy_http_version 1.1 plus the two headers is the part you were missing. proxy_buffering off is what fixes "the answer arrives all at once": nginx was holding the streamed response. The read timeout matters for long generations.

Also set WEBUI_URL=https://your.domain in the container's environment so the app knows its public address.

JudyMember#3

If you are not attached to nginx, Caddy does all of this with one line and gets the certificate for you:

your.domain {
    reverse_proxy 127.0.0.1:3000
}

WebSocket upgrades and streaming are handled by default. For a single-service box it removes the whole class of problem in this thread.

DawsonAuthorMember#4

In reply to Lewis Cheng (#2)

Three lines and proxy_buffering off. Streaming is streaming again. Accepted, and thanks for the Caddy note; next box.

The project behind this thread

More in Questions

Open-source projects

AI tools

Free browser tools

From the AI course

Alternatives lists

Topic hubs