ThinkFacility

Error messages

Network Problem

The message

Network Problem
Open WebUI 0.11.4 read September 25, 2026Open WebUIWebSocketreverse proxy

What it means

A request from the browser got no readable answer. In chat that usually meant the WebSocket link to Open WebUI was blocked; next to a connection it means the provider couldn't be reached at all.

What to do

Open the site without your reverse proxy to see if the error goes away, then add WebSocket Upgrade headers to the proxy. For a connection toast, check the URL from wherever the request is made.

Open WebUI prints this in two places. In older releases it was a red toast under a chat message you'd just sent, with nothing else:

Network Problem

In the current code it's mostly a prefix job. Add or verify a connection in the admin settings and a failure reads OpenAI: Network Problem or Ollama: Network Problem. We read both paths in 0.11.4. The words are a fallback: the browser asked for something, and what came back didn't have an error message it could show, so it printed this instead. As of September 25, 2026 the project has 75 issues and 77 discussions quoting it.

Chats broke after 0.5.0: WebSockets

The big wave came with Open WebUI 0.5.0 in December 2024. Issue #8074, "Network Problem 0.5+", ran to 203 comments. The reporter's browser log had NS_ERROR_WEBSOCKET_CONNECTION_REFUSED on the /ws/socket.io/ address. A maintainer's first reply: "you need a proper websocket support going forward with 0.5.0+", and the likely culprit was "your reverse proxy." He added that the site would work without it, which makes a quick test.

The docs now say the same: "WebSocket support is required for Open WebUI v0.5.0 and later." For Nginx, their example passes the upgrade through:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

In Nginx Proxy Manager, a contributor in the thread fixed it by ticking the Websockets Support box and adding X-Forwarded-Scheme and X-Forwarded-Proto headers. The docs add a CORS setting: if the logs say a URL "is not an accepted origin", list every address people use to reach the instance in CORS_ALLOW_ORIGIN, separated by semicolons. Behind HAProxy 3.x, check their HTTP/2 note too.

Two more things from that thread. A maintainer made ENABLE_REALTIME_CHAT_SAVE off by default from 0.5.4, which helped some setups. And a team member told several people to clear cache and cookies after upgrading (old frontend files and a new backend don't mix well).

"OpenAI: Network Problem" on Verify connection

This version shows up on the admin Connections page. Clicking Verify sends the browser to Open WebUI's backend, which calls the provider. If the backend can't connect at all, it answers {"detail": "Open WebUI: Server Connection Error"}. That reply has no error.message field, so the toast falls back to "Network Problem." When the provider does answer with an OpenAI-style error, you see its real message after OpenAI: , like a bad key. So "Network Problem" here means nobody answered.

That usually comes down to where the URL is being tried from. In discussion #3350 a key that worked in curl on the host failed in Open WebUI's Docker container, and a reply fixed it with host.docker.internal. We walk through that address problem on the Open WebUI: Server Connection Error page. One exception: a direct connection (a per-user one) is fetched by your browser itself, so there the URL has to work from your own machine.

Is there still a plain "Network Problem" in chat?

We couldn't find one in 0.11.4. The chat completion helper's fallback text there is "Server connection failed," so a bare "Network Problem" under a message points to an older install (0.5.0 had it in that exact spot). Upgrade before digging further.

Other lines the same feature prints

Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.

  • OpenAI: Network Problem
  • Ollama: Network Problem
  • Openai: Network Problem
  • NS_ERROR_WEBSOCKET_CONNECTION_REFUSED