mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-21 00:52:24 -05:00
[GH-ISSUE #8074] infra: Network Problem 0.5+ #14986
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#14986
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Simi5599 on GitHub (Dec 25, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/8074
https://github.com/open-webui/open-webui/releases/tag/v0.5.0
Bug Report
Installation Method
Docker
Environment
Open WebUI Version: 0.5.0
Operating System: Windows 11
Browser (if applicable): Firefox 133.0.3
Confirmation:
Expected Behavior:
When asking something to the LMM it should answer normally
Actual Behavior:
The LMM gives an error "Network Problem".
Reproduction Details
Steps to Reproduce:
Logs and Screenshots
Browser Console Logs:
`submitPrompt Hello!!!! Chat.svelte:1168:10
destroy MessageInput.svelte:331:10
RichTextInput.svelte:129:10
saveSessionSelectedModels
Array [ "gpt-4o-mini-2024-07-18" ]
["gpt-4o-mini-2024-07-18"] Chat.svelte:176:10
[tiptap warn]: Duplicate extension names found: ['codeBlock']. This can lead to issues. index.js:1158:20
modelId gpt-4o-mini-2024-07-18 Chat.svelte:1338:12
GET
wss://myurl.it/ws/socket.io/?EIO=4&transport=websocket
NS_ERROR_WEBSOCKET_CONNECTION_REFUSED
Firefox non può stabilire una connessione con il server wss://myurl.it/ws/socket.io/?EIO=4&transport=websocket. websocket.js:43:26
connect_error Error: websocket error
xe transport.js:7
onError transport.js:38
onerror websocket.js:69
addEventListeners websocket.js:69
doOpen websocket.js:50
open transport.js:46
open socket.js:170
b socket.js:111
open manager.js:108
n manager.js:328
setTimeout handlerreconnect manager.js:321
n manager.js:331
r manager.js:123
h manager.js:137
setTimeout handleropen manager.js:135
n manager.js:328
setTimeout handlerreconnect manager.js:321
n manager.js:331
r manager.js:123
h manager.js:137
setTimeout handleropen manager.js:135
n manager.js:328
setTimeout handler*reconnect manager.js:321
n manager.js:331
r manager.js:123
emit index.js:136
onError socket.js:541
emit index.js:136
onError transport.js:38
onerror websocket.js:69
addEventListeners websocket.js:69
doOpen websocket.js:50
open transport.js:46
open socket.js:170
b socket.js:111
open manager.js:108
n manager.js:328
+layout.svelte:62:11
Network Problem Chat.svelte:1527:11
null Chat.svelte:1536:10`
Docker Container Logs:
ERROR [asyncio] Unclosed client session client_session: <aiohttp.client.ClientSession object at 0x7fa5fc8d9a90> ERROR [asyncio] Unclosed connector connections: ['deque([(<aiohttp.client_proto.ResponseHandler object at 0x7fa5f43038c0>, 365892.936776659)])'] connector: <aiohttp.connector.TCPConnector object at 0x7fa5f7669650>Screenshots/Screen Recordings (if applicable):
@tjbck commented on GitHub (Dec 25, 2024):
Related: https://github.com/open-webui/open-webui/discussions/8073
As mentioned in the changelogs, you need a proper websocket support going forward with 0.5.0+
I'll make a educated guess here and say you have a network misconfiguration (most likely your reverse proxy) that's blocking the webui from properly communicating with the backend. You'll notice without the reverse proxy, the webui will work as intended (let me know if this is not the case for you). The recommended course of action would be to ask questions directly in the respective reverse proxy community.
Keep us updated with your troubleshooting journey!
Update
If you directly access the webui via localhost, you should not encounter this issue.
@Blygf commented on GitHub (Dec 25, 2024):
I had the same problem and after about an hour of trying to fix it i just reverted to v0.4.8.
@Simi5599 commented on GitHub (Dec 25, 2024):
Thanks to @tjbck for your hint; I was able to fix this.
Basically, I am using Apache on my server as a proxy to my Docker container, and I had the following lines:
I simply changed them to:
PROOF:
For now everything is working fine!
@ArakiSatoshi commented on GitHub (Dec 25, 2024):
I'm experiencing the same issue after upgrading to 0.5.0.
In the console, I keep seeing these INFO warnings popping up every second:
I can send messages to chatbots and receive responses, however, there's an
'session_id'error underneath every new bot's message.If relevant, my nginx config looks like this:
And my open-webui is deployed via the pip method.
@tjbck commented on GitHub (Dec 25, 2024):
@Simi5599 Thanks for the update, let's keep this issue open for other users to find your solution!
@Simi5599 commented on GitHub (Dec 25, 2024):
Try to add another line with ws://127.0.0.1:8081
@Simi5599 commented on GitHub (Dec 25, 2024):
@tjbck don't know if this is related but title generation is not working anymore. Should i open a new issue?
@tjbck commented on GitHub (Dec 25, 2024):
@Simi5599 Unable to reproduce on my end, but yes feel free to open a new issue post with relevant backend/browser logs!
@ArakiSatoshi commented on GitHub (Dec 25, 2024):
Nginx considers another
proxy_passline as a duplicate, as far as I know it should handlews://traffic by default as long as you already have anhttp://proxy_pass.I attempted making a more excessive nginx configuration:
The app seems to function correctly now, the titles do generate as well. However, I'm still getting the INFO messages in the console, suggesting that something is probably still not functioning correctly:
This time it's my client's IP instead of 127.0.0.1.
I don't have enough knowledge about networking to troubleshoot it further.
Edit: It appears that my older tabs were stuck in some kind of a loop sending requests to the server, after closing them and opening a fresh tab with open-webui I no longer see the INFO messages. The issue is resolved for me now, but maybe the project needs official nginx/apache/traefik/caddy configurations for people who use open-webui on a remote system.
@Simi5599 commented on GitHub (Dec 26, 2024):
In my case, the titles weren't auto-generating due to an issue with the OpenAI API requests, so this was not related. #8075
@PhilosophiMoonbeam commented on GitHub (Dec 26, 2024):
Issue: WebSocket Connections Failing Through Nginx Reverse Proxy
Problem
When using Nginx as a reverse proxy for a Dockerized app (exposed on
localhost:3000), WebSocket connections fail. This is due to incorrect or missing headers in Nginx’s configuration, which are required to handle WebSocket protocol upgrades (ConnectionandUpgradeheaders).Solution: Update Nginx Configuration for WebSocket Support
Core Changes:
Modify your Nginx HTTPS (
443) server block to include WebSocket-specific headers. Here's the updated configuration:Optional: Add an HTTP (
80) server block to redirect traffic to HTTPS:Steps to Fix
Edit the Nginx Configuration:
Update your Nginx file, typically located in
/etc/nginx/sites-available/<your-config>.Test the Changes:
Validate configuration syntax:
Reload Nginx:
Apply the updated configuration:
Validate WebSocket Connections:
F12→ Network → WS).curlto test WebSocket headers:Results
This configuration enables Nginx to properly handle WebSocket traffic by passing upgrade headers between the frontend and backend while maintaining SSL encryption. If issues persist, verify Docker container binding (
0.0.0.0:3000), network accessibility, or check Nginx logs:@guangzhaoli commented on GitHub (Dec 26, 2024):
For
This problem is obviously that your nginx reverse proxy has not added the websocket configuration and correctly handles the handshake and data transmission of the WebSocket protocol.
You just need to add in nginx configuration:
location / {
......
WebSocket
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
@ccinoo commented on GitHub (Dec 26, 2024):
Great, this method works.
@chrismahoney commented on GitHub (Dec 26, 2024):
On a related note, this same issue arises while utilizing CloudFlare tunnels and there doesn't seem to be a clear fix for that compared to these adjustments to nginx for allowing websockets. I'll create a new issue for that, but in case anyone has some tips there that would be awesome.
@chenm1xuexi commented on GitHub (Dec 26, 2024):
I deployed the latest version 0.5.1 using docker, and the ng configuration supports web socket, but the system log prompt is
INFO: xx.xx.xx.xx:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG23yFx HTTP/1.1" 400 Bad Request
When I roll back to version 0.4.8,
the log is:
INFO: xx.xx.xx.xx:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG24X9C&sid=ncdWl4JHRt0k4D4zAAAC HTTP/1.1" 200 OK
A new sid field has been added. I don't know if the official lack of this field caused the current problem. Please explain
@luzhao2 commented on GitHub (Dec 26, 2024):
I deployed version 0.5.1 using Docker and also configured Nginx to support WebSocket, but it still doesn’t work. The logs are the same as above.
@xmengnet commented on GitHub (Dec 26, 2024):
add this resolved
···
location /ws {
proxy_pass http://127.0.0.1:4000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_read_timeout 3600; # 设置读取超时时间为3600秒
proxy_send_timeout 3600; # 设置发送超时时间为3600秒
}
···
@chenm1xuexi commented on GitHub (Dec 26, 2024):
I tried it, still the same error
this is my nginx config:
server {
listen 80;
server_name xxx.xxx.com;
}
@Mushy-Snugglebites-badonkadonk commented on GitHub (Dec 26, 2024):
Same boat here and wanted to chime in. Let me know if you find anything in CloudFlare’s console. I’ll post any findings here in the morning when I go to troubleshoot.
A quick search on DDG yields:
https://developers.cloudflare.com/network/websockets/
@luzhao2 commented on GitHub (Dec 26, 2024):
I have added the above content and finally it works normally, but it didn't work properly before.
However, the logs still show some issues, although it doesn't affect my basic usage for now. But does this meet the project's expectations?
The logs are as follows:
open-webui | INFO: x.x.x.x:0 - "POST /api/v1/tasks/auto/completions HTTP/1.0" 400 Bad Request
open-webui | INFO: x.x.x.x:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG2NmkG HTTP/1.1" 400 Bad Request
open-webui | INFO: x.x.x.x:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG2NoBw HTTP/1.1" 400 Bad Request
open-webui | INFO: x.x.x.x:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG2Npfa HTTP/1.1" 400 Bad Request
open-webui | INFO: x.x.x.x:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG2Nr7T HTTP/1.1" 400 Bad Request
@liucoj commented on GitHub (Dec 26, 2024):
I'm running OWUI installed locally on my machine via pip, no docker or nginix
INFO: 127.0.0.1:54424 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PG2e3k- HTTP/1.1" 400 Bad Request
same error as above
@littlelucky commented on GitHub (Dec 26, 2024):
I used LM Studio and encountered the same problem, and modifying the Nginx configuration did not work.
After testing, I found that LM Studio may not support this calling method.
The latest 0.5.1does not solve this problem.
@qdii commented on GitHub (Dec 26, 2024):
my nginx proxy configuration looks fine, websocket work.
Besides, the 400 error code from the backend.
@fawwazanvilen commented on GitHub (Dec 26, 2024):
i can confirm that this works, the chat title automatically generates, no
'session_id'errors appearing (it appeared when i just added these lines in the block below)but also i can confirm that i still get some errors much like what @ArakiSatoshi encounters
@qdii commented on GitHub (Dec 26, 2024):
I think there are two distinct problems introduced in 0.5.0:
/ws/socket.io/returning 400 status code.The first problem is solved, let's keep this thread open for the second
@oldskewlcool commented on GitHub (Dec 26, 2024):
One additional step needed to solve the nginx configuration issue was to add \ in front of all the $ variables if nginx was installed using docker / docker compose.
Without this step nginx would not start and instead threw the following:
nginx: [emerg] invalid number of arguments in "proxy_set_header" directive in /etc/nginx/conf.d/reverse-proxy.conf:14
The solution given here worked fine when the variables were changed to $http_upgrade, $host etc..
@Mushy-Snugglebites-badonkadonk commented on GitHub (Dec 26, 2024):
@tjbck REQUEST: Please disable streaming response by default.
@knguyen298 commented on GitHub (Dec 26, 2024):
Encountered something similar which turned out to be a pretty silly fix:
I'm using Open-WebUI behind Traefik, which has websocket support standard, so no need for extra headers. However, I was still getting the
/ws/socket.io/?EIO=4&transport=polling&t=[SESSION_ID] HTTP/1.1" 400 Bad Requesterror showing up in console. The error had the IP address from my home's public IP, but accessing my instance from work yielded no errors. I tried disabling CloudFlare proxying, as I know it can cause issues with websockets.Turns out, I still had an Open-WebUI instance open on my home computer from before the 0.5.0 update which was causing the error. After closing it the window, the errors went away.
@glsup commented on GitHub (Dec 27, 2024):
I also got the "GET /ws/socket.io... 400 Bad Request "logs + "session_id" + can't chat anymore (complained about previous answer) after updating to both 0.5.0 and 0.5.1, from 0.4.8.
I use the git install (git pull origin main) and starting the server, in Windows, with ./backend/start_windows.bat
So I did a "checkout" to the 0.4.8 version (that used to work fine), and now it works fine (no logs nor errors and can chat again).
For some reason 0.5.x don't work for me.
@martin-rizzo commented on GitHub (Dec 27, 2024):
I'm having the exact same problem. I'm using Fedora and I install open-webui directly from the repository. I run it as a regular user on my system (no Docker). I can't use version 0.5.0 or any later versions because of the 400 Bad Request errors and the "session_id" issues described in this thread. Since I don't have much experience with server administration, I'm not sure if version 0.5.0 and newer now require me to install nginx, change firewall settings, or configure some other service. Any help or guidance on how to fix this issue would be greatly appreciated.
@cangming commented on GitHub (Dec 27, 2024):
I'm experiencing a similar issue after upgrade to 0.5.1 from 0.4.7. I'm confident that the Nginx reverse proxy is correctly configured with the necessary headers for WebSocket support.
nginx config would be as following.
I try to disable nginx web socket proxy header and will get logs as following
It's not only show transport=polling but also transport=websocket failed too.
But if I enable header again, I can get the info log which say WebSocket connection open.
I checked the debug tool in the Chrome browser and confirmed that data was indeed being transmitted via the WebSocket connection. However, the byte count sent through the WebSocket is very low each time, and the frequency is extremely low, resulting in a very slow response on the UI. I'm not sure if this is related to the issue.
Unable to tolerate it any longer, I eventually reverted back to version 0.4.8, and fortunately, all functions are working properly, and the UI response speed has returned to normal.
@gaby commented on GitHub (Dec 27, 2024):
@PhilosophiMoonbeam Solutions works great, it should be included in the docs and an example.
@liucoj commented on GitHub (Dec 27, 2024):
After updating to 0.52 (manual install, no docker) and cleaning browser caches issue is gone.
('127.0.0.1', 50358) - "WebSocket /ws/socket.io/?EIO=4&transport=websocket" [accepted]
Note:
version 0.52 at first run gave me the same error (400) but I noticed that version info on Settings was still 0.48, so I cleaned browser's caches and restart OWui and it showed the correct version and issue is gone.
@Raxel01 commented on GitHub (Dec 27, 2024):
For any one faced The Same error with the setup of : docker-docker/compose + nginx
You will just need to enable nginx websockets support using this two lines :
@ItsTino commented on GitHub (Dec 27, 2024):
Anyone had any chance solving this issue using caddy as a reverse proxy for the openwebui docker? With cloudflare too
@martin-rizzo commented on GitHub (Dec 27, 2024):
I fixed the problem by doing a fresh install (I'm not using Docker, I'm running open-webui directly from the repo). After deleting all the old files and doing a clean git clone, I reinstalled the backend dependencies and did a full frontend build. This fixed all the problems I was having with version 0.5.2. It looks like something on my end wasn't updated properly. Hopefully this helps anyone else having the same issues. Thanks!
@ItsTino commented on GitHub (Dec 27, 2024):
For caddy I fixed by adding the following option to the reverse_proxy. Assuming you are using docker or another setup where reverse_proxy is appropriate. I think my websockets were never working and it only became a problem recently
@dylanarmstrong commented on GitHub (Dec 28, 2024):
I tried this, but it didn't fix it for me unfortunately. Getting a 400 on the wss request and unsure how to really debug it. Will downgrade to 0.4.8.
@arsaboo commented on GitHub (Dec 29, 2024):
Is anyone able to fix this in Nginx Proxy Manager? I tried the following:
But that does not work. Any suggestions?
@toniexly commented on GitHub (Dec 29, 2024):
go to the details tab and activate the websocket support. leave the custom config tab empty. this should work, but still the response time of 0.5.2 is way too slow(don't know why). i think i'll roll back to 0.4.8 for now...for better performance.
@tjbck commented on GitHub (Dec 29, 2024):
@toniexly Related: https://github.com/open-webui/open-webui/discussions/8088
tl;dr: you should able to disable
ENABLE_REALTIME_CHAT_SAVEwith env var starting from 0.5.3+ (w/ some compromises)@SergioMendolia commented on GitHub (Dec 29, 2024):
@arsaboo I could fix it in NPM with
proxy_set_header X-Forwarded-Scheme $forward_scheme; proxy_set_header X-Forwarded-Proto $forward_scheme;@oatmealm commented on GitHub (Dec 29, 2024):
I'm not sure if this is related, but conversation with external services seems to never close automatically. This doesn't happen with ollama only with external providers. I need to manually stop the conversation even though streaming stopped.
@arsaboo commented on GitHub (Dec 29, 2024):
Thanks @SergioMendolia looks like that is working. Finally, I added the following four directives:
@ben-vargas commented on GitHub (Dec 29, 2024):
If you use the nginx web configurator, this is as simple as making sure the "Websockets Support" is toggled on for the proxy host you've added for Open WebuUI.
My Open WebUI had stopped working after the recent update, but I didn't have websockets enabled on the proxy host; doing so resolved the issue without any manual file changes. You can then also use the "Advanced" tab if you need to change any parameters such as timeout, but OpenWeb UI started working after simply enabling web sockets and restarting the docker container.
@Davester34 commented on GitHub (Dec 30, 2024):
I'm really new to Open WebUI but I just updated, noticed things were slow, checked the logs to see what was happening and I get
INFO: 172.17.0.1:60294 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PGNhoIy HTTP/1.1" 400 Bad Request
every second or so.
Not sure if the following is relevant:
I don't think I'm using ngix anything, i just have a default install from docker. When I updated the docker from command line, I used the docker line for Nvidia cards, the line with ALL GPUs or whatever.
The initial installation I used the first docker command that says 'if you have ollama installed on this computer'
I'm thinking this is related to my issue. probably a network config line somewhere but I'm not sure where to start. I can go to the terminal # prompt in docker but i don't know where to find the network configuration files. Hoping someone can help?
Sample snip from log...
INFO: 172.17.0.1:33762 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PGOaJrw HTTP/1.1" 400 Bad Request
INFO: 172.17.0.1:33778 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PGOaJ-2 HTTP/1.1" 400 Bad Request
INFO: 172.17.0.1:35120 - "POST /api/v1/images/generations HTTP/1.1" 200 OK
INFO: 172.17.0.1:35120 - "POST /api/v1/chats/229899fa-dbfd-4f4c-9031-83331a4e427c HTTP/1.1" 200 OK
INFO: 172.17.0.1:33790 - "GET /cache/image/generations/f8db7fbc-7abd-4a4c-b198-225db608be4b.png HTTP/1.1" 200 OK
INFO: 172.17.0.1:35120 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 OK
INFO: 172.17.0.1:33806 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PGOaLCa HTTP/1.1" 400 Bad Request
INFO: 172.17.0.1:33806 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PGOaLCw HTTP/1.1" 400 Bad Request
@bash-bandicoot commented on GitHub (Dec 30, 2024):
Confirming works with open-web-ui docker wrapped with Apache.
Thanks a ton, @Simi5599 and @tjbck!
@Davester34 commented on GitHub (Dec 30, 2024):
That fixes it for him using Apache server. I'm not using Apache server and have this error, so do I create a new issue for my problems? (New to all this, sorry if this is a noob question)
I have my details posted in this thread ( https://github.com/open-webui/open-webui/issues/8074#issuecomment-2565471713 )
@Simi5599 commented on GitHub (Dec 30, 2024):
Are you using Nginx? There are some people above who were successful with their configurations
@elharony commented on GitHub (Dec 31, 2024):
I had the same issue today after upgrading to v0.5.2 on AWS EC2 + Docker with Nginx as a reverse proxy, and I fixed it by adding WebSocket support to the Nginx configuration.
Steps to Fix:
1. Open your Nginx configuration file:
2. Replace the old server block with this updated configuration:
Save and quit Vim (
:wq).**3. Test the Nginx configuration for syntax errors:
You should see:
nginx: configuration file /etc/nginx/nginx.conf test is successful4. Reload Nginx to apply the changes:
And it works perfectly now! 🚀
@debeetle commented on GitHub (Dec 31, 2024):
Turning off the title auto-generation works for me
@adri-k commented on GitHub (Dec 31, 2024):
I have the same 400 bad request issue on web socket calls.
I am not using an nginx proxy or apache, just a docker installtation of open webui 0.5.2.
The same error also existed in version 0.5 and 0.5.1.
@yoavain commented on GitHub (Dec 31, 2024):
I have the same issue with 0.5+ and only when using my external hostname. I use my NAS's reverse proxy.
When using
localhostit works.Works fine on 0.4.8.
Setup:
Windows 11
Docker (running with
--add-host=host.docker.internal:host-gateway)@cangming commented on GitHub (Jan 1, 2025):
After upgrading to v0.5.3 and setting the Docker environment variable ENABLE_REALTIME_CHAT_SAVE to False, the issue of slow UI response speed has been successfully resolved. Thank you very much.
@krishkumar commented on GitHub (Jan 1, 2025):
I encountered a similar issue since upgrading OpenWebUI on my CapRover instance. I managed to resolve it by enabling "WebSocket support" through the CapRover dashboard settings.
@danielj23 commented on GitHub (Jan 1, 2025):
I was getting this since the same build.
Using Nginx proxy manager, I enabled Websockets Support under Details, and http2 support under SSL tab and my problem was resolved.
@MattariOnline commented on GitHub (Jan 1, 2025):
Also having this issue, but adding the various headers, http2, and even the portion commented as "security" didn't work (added them incrementally). Doesn't work from either of my two domains, nor through my CloudFlare connection. Only works with a LAN address.
Desperate for help if anyone can. (Replaced domains with DOMAIN1 and DOMAIN2, and replaced API port with a generic example, for security.)
@MattariOnline commented on GitHub (Jan 1, 2025):
Alright as an update, I started looking into enabling HTTP/2 (in case it wasn't) using this guide: https://sslinsights.com/how-to-enable-http2-on-nginx-web-server/
Made changes to nginx.conf and now the first domain, cname to IP, is working, though I had to test with private browser.
Just gotta work on getting the CloudFlare one to work, which currently still fails.
Update:
Fixed the CloudFlare side as well. If you have CloudFlare pointing in and it doesn't work on the cloudflare side, but you have SSL and HTTP/2 working on your Nginx, you may want to ensure you have full SSL encryption mode enabled and not flexible.
Go manage your domain in CloudFlare, then go to SSL/TLS > Overview > SSL/TLS encryption > Configure.
Ensure the option is set to Full (unless you choose to install CloudFlare's cert or have a publicly trusted cert, in which case select the appropriate option), and Save.
@T-Shilov commented on GitHub (Jan 1, 2025):
Can you tell me which reverse proxy is best suited for working with socks for the Open Web UI ?
Upd. Lighttpd
@danielj23 commented on GitHub (Jan 1, 2025):
@T-Shilov I don't know if there is a "best suited" because it can be situational based on someone's hardware and connection situation. If someone is using Caddy, or Traefik, etc., its very likely because they just like that product, not because its better or worse than another.
I use 'Nginx proxy manager' and my basic installation with no special config has worked (with cloudflare proxy included) since the first time I set it up. Since this .5 issue came up, simply enabling HTTP/2 in NPM config - has me back up and running just fine.
I use NPM for almost everything and I don't like Caddy. But that is just me.
@skarabaraks commented on GitHub (Jan 2, 2025):
I also experienced the "Network error" after updating my WebUI, but only when using the reverse proxy on my Synology NAS.
The issue was resolved by enabling websockets on the Synology DSM Reverse Proxy - surprisingly, default settings worked right away.
Thanks to Matthias' guide for making it easy: https://mlohr.com/websockets-for-synology-dsm/
@T-Shilov commented on GitHub (Jan 2, 2025):
danielj23
Taste preferences is, of course, an important argument :-)
But it seems to me that choosing a proxy server should not create problems in the future.
Nginx worked fine with Open Web UI versions 0.4x.
However, with versions 0.5x, o created an unexpected issue with web sockets, and it required an adjustment to the config file.
It's bad. Therefore, we need a proxy server that does not create problems in the future and does not depend on the version of the Open Web UI.
@thekryz commented on GitHub (Jan 2, 2025):
While I also have the issue with nginx, I disagree that the proxy server should be exchanged. We need a stable configuration for nginx. And of course it would be great to include at least a couple of the most used proxy servers in open-webui testing in the future.
@yoavain commented on GitHub (Jan 2, 2025):
Found the solution for Synology reverse-proxy (with the help of copilot)
@rasodu commented on GitHub (Jan 2, 2025):
I am using Traefik v3. Does anyone know which config needs to be adjusted to make it work with OpenWebUI 5+? I tried Upgrading to OpenWebUI 5.2 but ended up downloading 4.8 because of the issue.
@T-Shilov commented on GitHub (Jan 2, 2025):
Adding explicit use of web sockets to the Nginx config helped me:
@scottrbaxter commented on GitHub (Jan 2, 2025):
It seems that haproxy, at least the pfsense implementation, isn't playing nice with the networking changes in 0.5+
Until
0.5.3, i had to revert back to0.4.8just to have any reasonably quick responses. It was often so slow that ollama's 5 min timeout would end well before the response was finished writing to the open-webui session. Starting with0.5.3, settingENABLE_REALTIME_CHAT_SAVE=Falsewill at least speed up the token response time very similarly to what it was prior to0.5+, however, i still get a ton of these bad request messages, e.g.POST /api/v1/tasks/auto/completions HTTP/1.1" 400 Bad RequestNote:
Autocomplete GenerationandTags Generationare disabled in the Admin Panel, still trying to track down what causes this bad request.i think this change around websockets could benefit from some additional documentation and guidelines for (at least) the most common reverse proxy solutions around. far as i can tell, haproxy should already have websocket support... so i'm not sure why i'd need to set
ENABLE_REALTIME_CHAT_SAVE=Falseas is.. ideally would prefer not to require this, but it's not a problem if that must persist. for now, though, and since nginx seems to be covered pretty well above, could someone please chime in and thoroughly explain exactly what settings are necessary for users with haproxy?@tjbck commented on GitHub (Jan 2, 2025):
ENABLE_REALTIME_CHAT_SAVEwill be set toFalseby default going forward with 0.5.4+https://docs.openwebui.com/getting-started/advanced-topics/env-configuration#enable_realtime_chat_save
@PiHiker commented on GitHub (Jan 4, 2025):
Confirmed working for me as well!
@AntraXClown commented on GitHub (Jan 5, 2025):
I use Nginx Reverse Proxy and i had the same problem (Network Problem) . So i solve enabling the WebSockets Support as image bellow:
@evilalmus commented on GitHub (Jan 6, 2025):
I use Nginx Proxy Manager (which is what that screenshot is from) and enabling Websockets Support does NOT fix this issue for me.
@danielj23 commented on GitHub (Jan 6, 2025):
enable http/2 under SSL and see if that resolves it.
@zeus123456 commented on GitHub (Jan 6, 2025):
To get mine to work with nginx, I had to add the websocket support as shown in the examples in this thread directly below location / proxy pass and not just anywhere nor at the bottom of your /etc/nginx/sites-available/your_conf_file_name.conf :
__
Edit:
Had to rollback to open-webui:v0.4.8 as I was getting method not allowed error during call mode and 'session_id' errors in regular chats. (since everything works in 0.4.8 perhaps we can request nginx to be added as a feature in future versions?)
I tried updating nginx and allowing http/2, adding the websockets and some of the extras folks mentioned above, all without luck. I am thinking about trying to switch to nginx proxy manager next as that seems to show quite a bit of success for this issue.
I am running WSL ubuntu 22.04.5 and suspect my issue might be with my opnsense Firewall: NAT: Port Forward from my public IP to my private IP (enabling NAT reflection did not help either). I'd like to test on the private network, but call mode won't work without https.
Any ideas, things to look at, troubleshooting recommendations or suggestions from anyone?
@mophead64 commented on GitHub (Jan 6, 2025):
snap. I have a custom nginx container for reverse proxying http traffic, this did it also :)
@universam1 commented on GitHub (Jan 7, 2025):
In our case the WS error
connection rejected (400 Bad Request)was due to large request header, specifically caused by cookies in the request. Apparently the implementation has a limit.We solved it by dropping the cookies on the
/wspath, like this for Skipper Ingress.@taoi11 commented on GitHub (Jan 8, 2025):
My work VPN causes use with web-socket traffic. this is present for other services and sites that use web sockets as well like perplexity.ai.
perhaps a back up communication method can be can be looked at....
personally I am okay without streaming outputs as a GPU poor user I often switch to other tabs during generation anyway.
I am using cloudfare tunnel to expose on my personal domain. Both tunnel and OpenWebUI are in containers
sorry I dont have more technical way to explain this issue.
@firestrife23 commented on GitHub (Jan 8, 2025):
It has served my family so well for a long time until now it's broken... I came here looking for a solution for Traefik.
@gravgaard commented on GitHub (Jan 8, 2025):
I experience this issue on localhost.
All new agents a repsonded only once and then wrote 'Session Id' in.
From there it was unresponsive.
a ´docker restart´ for me fixed it, and i have not seen the problem for at least a dusin prompts now.
@Classic298 commented on GitHub (Jan 8, 2025):
I have the same issue with 400 errors. OpenWebUI works normally, but every second 400 errors show up in the logs.
Running on pip
Version 0.5.4 (didn't use the prior versions, last version I used was 0.4.8)
I already had websocket support all this time in my nginx (with exactly the same config as written in this thread many times).
I also added http2 and tried debugging the issue myself but it does seem like openwebui does not handle the requests properly and that's why I get 400 errors.
When I access it locally (not through nginx) using curl I get "Invalid Transport"
curl -i http://127.0.0.1:8080/ws/socket.io/?EIO=4&transport=websocket
Or
curl -i http://127.0.0.1:8080/ws/socket.io/?EIO=4&transport=polling&t=PH5ESUI
Both return 400 Bad Request and Invalid transport
@nyawox commented on GitHub (Jan 8, 2025):
i'm in a weird situation. iOS safari, pwa work just fine without any "sessionid" errors. but neither Firefox nor Chromium work on my linux desktop. always the Network Problem and
Firefox can’t establish a connection to the server at wss://<redacted>/ws/socket.io/?EIO=4&transport=websocket. websocket.js:43:26error. i'm certain websocket always has been working (should be ootb when using caddy) on my setup, and i can easily confirm that with bitwarden extension.@wk222 commented on GitHub (Jan 8, 2025):
I'm using the following Nginx configuration file, and while I can access my website without errors, the response time seems slower compared to accessing it directly via the IP address
`
server_name
}`
@Classic298 commented on GitHub (Jan 8, 2025):
Update to my issue, sometimes a weird red error 'session-id' pops up at the top of openwebui and renders it totally unusable
Only bypass is logging out and logging back in multiple times and deleting browser cache and cookies and then it works again for the most part.
So something is not working 100%... Hmm
@JingbiaoMei commented on GitHub (Jan 8, 2025):
If you are using npm, the simplest way is to enable websockets supports.
@Classic298 commented on GitHub (Jan 8, 2025):
Who did you talk to (or who did you mean to reply to)?
For me: I use pip.
@danielj23 commented on GitHub (Jan 8, 2025):
@Classic298 I honestly don't think your issue is in any way related to this topic.
@Classic298 commented on GitHub (Jan 8, 2025):
@danielj23 from my understanding, and I read the entire thread, it fits perfectly into it.
I get the weird session-id errors in the UI and the exact 400 error messages show up in the logs repeatedly as many have reported here.
Both these things, the users in this thread have discussed this entire time, so why would it not fit to this issue?
@wainage commented on GitHub (Jan 8, 2025):
For anyone using OrbStack instead of Docker, visit https://open-webui.orb.local instead of localhost (or find your specific DNS domain name in the container info section).
Chromium browsers have issues upgrading secure web sockets from http. Firefox seems to have no beef and works fine on http://localhost:3000.
If you are having issues with OrbStack DNS, check the following:
and make sure they are both selected. You should be able to access it on https://<container-name>.orb.local without the port.
@feuler commented on GitHub (Jan 9, 2025):
I have the same issue with Traefik v3 (versions tried: 3.2.3 & 3.3.1) when using openwebui functions. I tried to add a middleware with "X-Forwarded-Proto=https", but it didn't solve the problem.
Generally websocket connection is working when i test it e.g. via curl.
My current traefik config for the openwebui docker container (via labels)
labels:
- "traefik.enable=true"
- "traefik.http.routers.openwebui.rule=Host(
mydomain.example.com)"- "traefik.http.routers.openwebui.entrypoints=websecure"
- "traefik.http.routers.openwebui.tls=true"
- "traefik.http.services.openwebui.loadbalancer.server.port=8080"
- "traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto=https"
- "traefik.http.routers.openwebui.middlewares=sslheader"
@firestrife23 commented on GitHub (Jan 9, 2025):
Your configuration is similar to mine, I guess I'm not the only one either.
@nwhobart commented on GitHub (Jan 9, 2025):
Has anyone resolved this issue for running on k8s?
server-snippetsand add:ENABLE_REALTIME_CHAT_SAVEtofalsestill can't get past the "Network Problem" message on every chat.
this app is dead in the water to me at the moment and I frustrated this issue isn't better documented for all common use cases.
@kim-gtek commented on GitHub (Jan 9, 2025):
@tjbck
Polling error
INFO: "GET /ws/socket.io/?EIO=4&transport=polling&t=PHC5cDm HTTP/1.1" 400 Bad RequestThe error is being thrown by the following middleware.
The docker container is correctly receiving the WebSocket connection, but the following code is denying it due to the headers sent out.
layout.svelte
I believe this is the client side that sets up the connection.
@nwhobart commented on GitHub (Jan 9, 2025):
this makes no difference in my case.
@feuler commented on GitHub (Jan 9, 2025):
Thanks for the effort ! You think setting fixed request headers with Traefik labels could solve the issue ? Like:
But, according from what i've read the "Upgrade: websocket" should normally be initiated from the client/browser side, right ?
@kim-gtek commented on GitHub (Jan 9, 2025):
I am unsure, I spent a few hours today digging to find the source of the error, but I have not looked at any solutions yet as I have never dealt with web sockets before.
If I have time tomorrow I will look into that, it could work!
@feuler commented on GitHub (Jan 9, 2025):
I just tried the labels and unfortunately they didn't fix the problem. Also the "Upgrade=websocket" header produced a "Missing Sec-WebSocket-Key" error.
@zeus123456 commented on GitHub (Jan 9, 2025):
__
How tough would it be for a feature to be added for the ability to toggle websockets required on or off?
Then folks could enable/disable to help test/troubleshoot, but still be on a newer version.
As accessing via localhost is not what users using a reverse proxy are looking for.
Another suggestion is to add nginx and potentially other reverse proxies as a feature, similar to how we can choose for images:
Automatic1111
CumfyUI
@feuler commented on GitHub (Jan 10, 2025):
I saw that there was an env option "ENABLE_WEBSOCKET_SUPPORT=true/false" added here https://github.com/open-webui/open-webui/pull/5270/files
I tried both true and false, but it didn't solve the problem.
@kim-gtek commented on GitHub (Jan 10, 2025):
It was a caching problem.
I disabled cache in google chrome dev tools networking tab - reloaded, and no more errors.
@dh1tw commented on GitHub (Jan 10, 2025):
setting the environment variable ENABLE_WEBSOCKET_SUPPORT=0 disables websockets.
@aquananu commented on GitHub (Jan 10, 2025):
i solved same using below config on NGINX
server {
listen 80;
server_name llm.DOMAIN.com; # change it your domain name
}
server {
listen 443 ssl http2;
server_name llm.DOMAIN.com; # change it your domain name
}
Hope this will be helpful for people
@nwhobart commented on GitHub (Jan 10, 2025):
THANK YOU!
@zeus123456 commented on GitHub (Jan 11, 2025):
After trying many of the recommendations from above, I finally got it working by disabling nginx and deploying the Nginx Proxy Manager container by just following the Quick Setup from https://nginxproxymanager.com/guide/ .
Via a nice gui menu I just added a proxy host and put under Domain Names my public fqdn, for scheme selected http, forward hostname/ip is my open webui private IP, port 8080, enable websockets toggle, then went to the ssl tab and added ssl cert for let's encrypt with my fqdn and it got a new cert and everything works perfectly now via https externally :).
It would be nice to know what the Nginx Proxy Manager conf is so I could know what was wrong with my previous config trying to add websocket,
__
I just uncommented these 2 lines in the docker-compose.yaml:
DB_SQLITE_FILE: "/data/database.sqlite"
DISABLE_IPV6: 'true'
__
sudo docker-compose up -d
@loglux commented on GitHub (Jan 12, 2025):
Rolled back to v0.5.3 after finding v0.5.4 unusable.
The
Network error, freezing, and constant disconnections from Ollama made it impossible to use. If you're on v0.5.4, consider rolling back using:@tjbck commented on GitHub (Jan 12, 2025):
@loglux Please avoid spamming and make use of the edit feature when necessary. Excessive posting goes against the code of conduct and could lead to a ban. Keep in mind that this thread has many participants—thank you for understanding!
@ayyazzafar commented on GitHub (Jan 12, 2025):
Facing same issue. I am rolling back to previous version
@loglux commented on GitHub (Jan 12, 2025):
I found that the previous version still has the same problem. After encountering a 'Network error,' it's necessary to press 'Regenerate' because the chat doesn't allow you to continue. Last night, I was forced to use 'Regenerate' 10 times, and each time I received the same 'Network error.'
This issue is completely intolerable, as it makes OpenWebUI unusable.
@ayyazzafar commented on GitHub (Jan 12, 2025):
for me network issue is also on 0.5.3 version. is it working fine for you on 0.5.3 ?
@loglux commented on GitHub (Jan 12, 2025):
No, it's not working fine for me on 0.5.3 either. It seems like this is an ongoing issue persisting from version to version.
@ayyazzafar commented on GitHub (Jan 12, 2025):
Yes you are right. I tried all versions one by one and it works upto v0.4.8 version. Above this version it does not work.
@loglux commented on GitHub (Jan 12, 2025):
Thank you. I was thinking about it. Rolling back to v0.4.8 right now. I worked long time on v0.4.3 and regret that started to follow updates.
P.S.
Works
OKon v0.4.8@seadogger commented on GitHub (Jan 13, 2025):
I am not sure but it is something to due with caching. If you go the "About" page in user settings and the if the OpenWebUI Version is not showing the updated version you installed (e.g. v0.5.4) your session will give you this error after the first LLM response.
You have to clear this as it must be tied to the session id and validation of the user authentication. I am not sure what clears this and actually forces it to update to the version you have installed. Might have to clear browser cache as also make sure you are logged out of course. It eventually works for me. I did have this setup as a home page shortcut on my iPhone and I had to delete it and rebuild it by logging back in thru Safari and recreating the home page bookmark.
@ayyazzafar commented on GitHub (Jan 13, 2025):
Hi @seadogger thank you so much for your message. You were right. Its some kind of cache / cache issue. I cleared it and now everything is working smoothly. Thanks a lot.
@pgbezerra commented on GitHub (Jan 13, 2025):
I understand the problem was a proxy misconfiguration.
However, we could extract something good from it. The error message is not very clear. We could add that the socket connection was rejected, at least for admin users.
@Classic298 commented on GitHub (Jan 13, 2025):
Wow same for me, the error disappeared after refreshing a bunch of times and logging out and back in and clearing cache and cookies, something like this made all the error messages in the logs go away.
But then I am still wondering why it was sending broken websocket requests every second that were answered with 400 Bad Request...
@jersam commented on GitHub (Jan 14, 2025):
this worked for me for the moment.
@vdb1be commented on GitHub (Jan 15, 2025):
Was anyone using IIS as reverse proxy able to fix this?
@jersam commented on GitHub (Jan 15, 2025):
NPMplus user here
On Tue, Jan 14, 2025, 10:55 PM vdb1be @.***> wrote:
@loglux commented on GitHub (Jan 15, 2025):
I remain sceptical about a simple fix with Refresh. I tried and used it for a while, and the same issue remained the same, even though I cleaned up the working directory and installed clean v0.5.4
@firestrife23 commented on GitHub (Jan 15, 2025):
I hope you're joking, because I hardly come across those in my line of work as they are being phased out in favor of nginx, traefik, httpd, and npm. Except for those who are stuck in the Microsoft Camp. LOL
@finnaGIT commented on GitHub (Jan 16, 2025):
Here to report that I experience this issue in my implementation of HAProxy. However, per HAProxy documentation, Websockets are supported by default.
WebSocket
There is almost nothing needed to proxy WebSocket connections, other than to set timeouts and enable connection closing. The load balancer knows how to upgrade an HTTP connection to a WebSocket connection and once that happens, messages will travel back and forth through a WebSocket tunnel.
Is there something else going on here?
@linux-y commented on GitHub (Jan 17, 2025):
I started OpenWebUI using the official Docker command, so how should I resolve this network issue?
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
@loglux commented on GitHub (Jan 17, 2025):
I modified it before, and it didn't help. Moreover, it doesn't explain why the same error is present without a proxy.
@nvandenkolk commented on GitHub (Jan 17, 2025):
@Jeremy-Developer-Page commented on GitHub (Jan 22, 2025):
Hi this is a guide to fix Reverse Proxy Bad Request error and HTTPS Bad Request error.
This GUIDE works on 5.5 and 5.6 (that is the latest at the time of the post.)
To fix the problem do this in the reverse proxy:
Add WebSocket support
If you use Synology reverse proxy there is a Setting dedicated to WebSocket that compiles automatically all.
Then if your reverse proxy is an HTTPS connection I suggest 2 fixes:
Change all connection to HTTP
Change the connection of OpenWebUI in https connection.
To do this second option go in backend/start.sh file (if you are running it on linux or macOS) and change the last line in:
Replacing the folder key and cert with the correct folder (if you haven’t a certificate you can create one with the openssl command).
Same is for Windows but the command change a little bit to adapt at the start_windows.bat file.
In this way the localhost run in https, and same is for local networks connections so you can have a full HTTPS connection without problems or limitation.
I hope this help to solve all problems related to this issue.
@loglux commented on GitHub (Jan 23, 2025):
I got the 'Network Problem' error using OpenWebUI directly through the local IP address without Nginx proxy, etc.
v0.5.6
The version comes one after another, and the bug still exists.
So, let's concentrate on the real issue.
@Classic298 commented on GitHub (Jan 23, 2025):
Did you delete cache and cookies and then try again?
Please do cuz it's necessary after updates.
If yes, pls show some logs of the issue.
@Jeremy-Developer-Page commented on GitHub (Jan 23, 2025):
Even in local IP it works for me, but my browser clean automatically cache and data after the reboot, so please do that and then show us some error logs or configuration that you think can generate issues.
Because without information is really difficult help someone.
Thanks 😄
@glsup commented on GitHub (Jan 23, 2025):
In my case, (Windows 10, installed via miniconda and then cloning the repo) I still get the same as 0.5.0:
This is from the powershell were I run the "start_windows.bat":
/ _ \ _ __ ___ _ __ \ \ / /| | | | | |_ |
| | | | ' \ / _ \ '_ \ \ \ /\ / / _ \ '_ | | | || |
| || | |) | / | | | \ V V / / |) | || || |
_/| ./ _|| || _/_/ _|./ _/|_|
||
v0.5.6 - building the best open-source AI user interface.
https://github.com/open-webui/open-webui
Fetching 30 files: 100%|███████████████████████████████████████████████████████████████████████| 30/30 [00:00<?, ?it/s]
C:\ProgramData\miniconda3\envs\open-webui\Lib\site-packages\transformers\tokenization_utils_base.py:1601: FutureWarning:
clean_up_tokenization_spaceswas not set. It will be set toTrueby default. This behavior will be depracted in transformers v4.45, and will be then set toFalseby default. For more details check this issue: https://github.com/huggingface/transformers/issues/31884warnings.warn(
INFO: Started server process [12044]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)
Invalid transport (further occurrences of this error will be logged with level INFO)
ERROR [engineio.server] Invalid transport (further occurrences of this error will be logged with level INFO)
INFO: 127.0.0.1:60503 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCD8C HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60506 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCDbq HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60507 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCEyI HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60504 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCF50 HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60508 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCGAQ HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60515 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCGY- HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60508 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCHP3 HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60516 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCI0b HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60508 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCIdB HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60523 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCJUJ HTTP/1.1" 400 Bad Request
INFO: 127.0.0.1:60525 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PIKCJrr HTTP/1.1" 400 Bad Request
And then the "'session_id'" message in a browser that never used for this or in private windows of other browsers that I did use, after clearing the cache.
For me, the issue still remains the same.
Except for 0.4.8 which still works fine.
@Krishnacore commented on GitHub (Jan 23, 2025):
I was finally able to fix this problem! Nothing worked with https until I looked at the documentation carefully. This worked for me!
https://docs.openwebui.com/tutorials/integrations/redis#configuring-open-webui
@vdb1be commented on GitHub (Jan 24, 2025):
I got it to work by disabeling websocket support. I used a pip install and set the env variable in powershell using
$env:ENABLE_WEBSOCKET_SUPPORT = 0Also in IIS set the ARR > proxy settings > Reverse rewrite host in response headers to false
And last make sure the url rewrite action points to your local ip address and not localhost.
@wyl2000 commented on GitHub (Jan 25, 2025):
The latest version using the default 0.0.0.0:8080 to access the dialog will appear Network Problem prompt, please change to 127.0.0.1:8080 to access and dialog, so it is normal, I do not know why this is the case, but I access this way it is normal, I was in windows 11 using conda to build a virtual environment created! The project normally uses the v2ray automatic system agent. After successful installation can be used without proxy, but the latest 0.5.7 version to use 127.0.0.1:8080 to normal use!
@shreyanshsaha commented on GitHub (Jan 26, 2025):
I had a similar problem
I updated the ip address to
host.docker.internalThis is my setup:
Here, I updated the OLLAMA Base URL to
http://host.docker.internal:11434Only
host.docker.internalworks, for the other endpoints I only see the UI but its not able to connect to the model.PS
I also have docker desktop installed on windows. The docker desktop can also manage containers installed on WSL 2
I have tried multiple other things, updating the OLLAMA Base URL, setting docker network as bridge or host, updating netsh to allow port communication. None of these steps worked.
@XGhozt commented on GitHub (Jan 27, 2025):
I'm on rockylinux with apache over ssl, this was the config that worked for me. I'm also not using docker. I've replaced the domain, obviously, so don't just copy paste this into your config without editing it.
/etc/httpd/conf.d/ai.conf@loglux commented on GitHub (Jan 27, 2025):
Answering the question about cleaning up cookies. No, it doesn't help to eliminate this 'network error' bug.
@son12710 commented on GitHub (Jan 27, 2025):
Hi Guys, apparently i noticed that i had this issue today since i normally use it internally without going through NPM. When i tried to use it this morning outside of my home, i saw the same network error that people are talking about.
After reading all the comment in this article this morning, i noticed that the same solution doesnt work for everyone which indicate that something is probably causing an issue. I then look at my Cloudflare setup and bam, there it is, in Cloudflare -> your domain -> Network -> WebSocket was disabled. I enabled it and bam, no more network error
To sum up, there are 2 things I had to do to fix the issue i am having:
1 - Enable WebSocket in NGINX Proxy Manager
2 - Enable WebSocket on Cloudflare (if you are using it)
@pr0fsmith commented on GitHub (Jan 27, 2025):
This config works for me for 0.5.6. Didn't work on 0.5.7. Thanks for keeping this open.
@Classic298 commented on GitHub (Jan 28, 2025):
@pr0fsmith did you delete cache after upgrading?
@pr0fsmith commented on GitHub (Jan 28, 2025):
No I didn't. I will try it now. The solution didn't work for me for the versions I listed before. It worked for one inquiry of the LLM then I got the same network error aftwards. I will update the results after I clear the cache.
@pr0fsmith commented on GitHub (Jan 28, 2025):
@Classic298 Clearing the cache didn't work for me.
This is my config for nginx
`server {
security
}
`
@doodlebro commented on GitHub (Jan 29, 2025):
Does anyone have a working solution to this using NGINX proxy manager? Websocket support is enabled, but I have all sorts of issues, even after clearing all browser data and caching.
Most of the provided solutions are very hard to integrate with NPM. This shouldn't be such a boon!
@mattdrum commented on GitHub (Jan 29, 2025):
I use PFsense and HAProxy and was experiencing these network issues. Was able to resolve by setting the request the HAProxy timeout to 5 minutes instead of the default 30s. This was a problem because the first time I would load a model would take longer than 30 seconds.
@scottrbaxter commented on GitHub (Jan 30, 2025):
@mattdrum Just FYI, I've also run this through haproxy on pfsense, and have not needed to change any timeouts from the defaults. Where it's great that you have found a resolution for your issue, it is unrelated to this network problem introduced in
0.5.@jamesoram commented on GitHub (Jan 30, 2025):
I was seeing this issue after upgrading my local deployment through pip and it went away after clearing the browser cache (not saying this will solve the issue for more complex deployments but googling the error led me here).
@witten commented on GitHub (Jan 31, 2025):
I had a similar but related solution work for me. I'm using HAProxy with Traefik, and I was getting the dreaded "Network Problem"s—not when loading a model but during a chat session. What apparently fixed it was setting the following in my
haproxy.cfg:This sets the WebSocket/tunnel timeout and doesn't impact other timeouts (
connect,client,server).@paulwababu commented on GitHub (Feb 1, 2025):
We solved this issue by updating our Apache config to support websockets. We enabled
proxy_wstunneland added a rewrite rule for websocket upgrades. For example:This resolved our websocket issues with Open WebUI 0.5.0+. Hope it helps!
@lamteteeow commented on GitHub (Feb 1, 2025):
@paulwababu you might wanna delete the comment and submit it again because I can still see your domain from old edits :P
@jmasclef commented on GitHub (Feb 2, 2025):
Using a Synology NAS reverse proxy, I had to activate websocket in custom header settings. Now it is working fine.
@arno608rw commented on GitHub (Feb 2, 2025):
Good fixed
@joonsoome commented on GitHub (Feb 3, 2025):
I used Ollama on two different computers (one with lower parameters for low-end hardware, and one with moderate parameters). Occasionally, I encountered a "Network Problem" issue, which became even more frequent when Websearch was handled through SearXNG. Therefore, I created an Nginx GUI recipe that addresses both the problem mentioned in this thread and the WebSocket timeout issue. So far, it seems to be working without any problems.
@scooter7 commented on GitHub (Feb 3, 2025):
Hi, I'm having this network problem error when trying to use web search. My instance is hosted on Railway from a dockerized template. Do you know how I can fix this? Thanks!
@ticpu commented on GitHub (Feb 3, 2025):
The most aggravating part in this problem is that when this issue happens, it sticks.
The conversation is stuck with this message and can't be resumed, not even after a refresh.
The second part is that there's no retry once it says network problems, even after the AI responded.
I get the notification that the AI completed, I see the text appear as a notification and in the chatbox but that error remains, killing the conversation.
@joecarpita commented on GitHub (Feb 4, 2025):
@bear8203 Is this Nginx GUI recipe for Ollama or for SearXNG?
@nyawox commented on GitHub (Feb 4, 2025):
@kim-gtek was right. for users encountering the
NS_ERROR_NET_INTERRUPTissue with proper reverse proxy configuration, (it only worked on iOS for me) here’s a quick patch that mitigates it.To verify websocket functionality, check if
Active Users: 1appears in the bottom left menu.ENABLE_WEBSOCKET_SUPPORT=falsealso works the performance penalty was too significant for me@joonsoome commented on GitHub (Feb 4, 2025):
This is for both, the proxy header for Open-webui 0.5+ (for Websocket), and Ollama(especially slow one) & SearXNG has more strict timing because of Websocket. so I make it more time to look. I made the reverse proxy at Open-webui, and the ollama & searxng at another nodes with local network to Open-webui
@shegman6000 commented on GitHub (Feb 4, 2025):
I know some people have had issues when running this with an nginx ingress controller on EKS.
To clarify - if you are installing via helmchart, then add this to the ingress section of the helm chart:
(The above is done in CDK but will also apply to flat yaml files!)
This will result in the annotations on your ingress resource containing:
Then the nginx config will update.
@scooter7 commented on GitHub (Feb 4, 2025):
Hi @tjbck , Is this issue something that will be fixed in a future release? Thanks!
@nwhobart commented on GitHub (Feb 4, 2025):
no dice here
@nwhobart commented on GitHub (Feb 4, 2025):
This issue is incredibly frustrating. To try to mitigate we've:
values.yamlfile (We use a Helm chart for AWS EKS 1.29)nginxannotationsWe still see the networking issues error and are unable to run multiple replicas and use OIDC at the same time. I'm not sure how unique our situation is or if others have a similar set up.
Would love to use this more and contribute when able but right now this does not feel production ready.
@ticpu commented on GitHub (Feb 4, 2025):
The core issue remains, and this ticket is becoming cloud provider, deployment and helm support hub and discussion. Can we please focus on the issue?
It breaks and times out after a while or on reload with pure Nginx. Any cloud, GUI or abstraction to Nginx will continue to fail until the core issue is resolved.
Even with HTTP upgrade to websocket and long timeouts setup, the Network Error still present itself after a while or after an AI has been reasoning for too rong, killing the conversation.
Does it affect Apache, Nginx and HaProxy equally? Maybe we can test this out first?
@gaibz commented on GitHub (Feb 5, 2025):
Just using nginx with this Config and it works with docker container and my current workflow :
@ticpu commented on GitHub (Feb 5, 2025):
Yet, this one fails to work correctly when o3 is reasoning for too long and I still get Network Error.
I'm using Nginx especially for HTTPS so this is my use-case. I'm willing to try Apache if it works better but I've been using Nginx for years. I have WebSocket configured for Grafana and Jellyfin as well without issue using a very similar config (in fact the SSL stuff is a snippet).
@May-Yaha commented on GitHub (Feb 5, 2025):
upstream chat_service_main {
server 127.0.0.1:8023;
}
upstream chat_service_ollama_api {
server 127.0.0.1:11434;
}
server {
listen 8999 ;
server_name xxx;
# 定义location块
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket 相关配置
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://chat_service_main;
break;
}
location /ollama_api/ {
if ($host = chat.flyaha.top) {
rewrite ^/ollama_api/(.*)$ /$1 break;
proxy_pass http://chat_service_ollama_api;
}
}
}
@jmtatsch commented on GitHub (Feb 5, 2025):
For me it was the firewall blocking the communication.
Look in your syslog for entries like this one:
[UFW BLOCK] IN=br-790ac8044c00 OUT= MAC=02:42:e6:8b:06:0e:02:42:ac:1a:00:03:08:00 SRC=172.26.0.3 DST=172.17.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8522 DF PROTO=TCP SPT=40372 DPT=11434 WINDOW=64240 RES=0x00 SYN URGP=0The you can just whitelist the source ip as follows:
sudo ufw allow proto tcp from 172.26.0.3@i0ntempest commented on GitHub (Feb 6, 2025):
Anyone getting
Execution Time Limit Exceededin code intepreter when using a reverse proxy? I have nginx as a https proxy in front of the webui, and I getExecution Time Limit Exceededwhen trying to execute any code. Connecting without the proxy and it works fine.EDIT: Figured it out, Content-Security-Policy settings in nginx config blocked it
@Jarome07 commented on GitHub (Feb 7, 2025):
If you use frp，You can add the following configuration to the last line of frpc.toml
@cbartol commented on GitHub (Feb 7, 2025):
For anyone using Synology for a reverse proxy.
I just added these custom headers to the Reverse Proxy Rules and it fixed it
(you can also click Create > WebSocket for it to be automatically created)
@spammenotinoz commented on GitHub (Feb 11, 2025):
You need to increase your timeouts, the below are the defaults, you need to increase and manage as appropriate;
client_body_timeout: 60 seconds. This specifies the maximum time for reading the client request body
client_header_timeout: 60 seconds. This defines the maximum time for reading the client request header
keepalive_timeout: 75 seconds. This sets the time an idle connection to a client remains open
proxy_read_timeout: 60 seconds. This is the time NGINX waits for a response from a proxied server after a connection is established
proxy_connect_timeout: 60 seconds.
send_timeout: 60 seconds.
@apunkt commented on GitHub (Feb 11, 2025):
me,
what exactly is required to fix it @i0ntempest ?
@i0ntempest commented on GitHub (Feb 12, 2025):
Delete any Content-Security-Policy lines in your nguni config
@InventoCasa commented on GitHub (Feb 12, 2025):
Unfortunately that ist not working with my config. Can you share your complete nginx.conf ?
@rsugumar commented on GitHub (Feb 13, 2025):
I'm using nginx-proxy-manager. Is there any such fix for nginx-proxy-manager? (BTW, this error doesn't exist in the old v0.4.8, so I'm going back to this version instead of latest) Thanks!
@ciprianveg commented on GitHub (Feb 13, 2025):
The problem is that you need a proper websocket support going forward with 0.5.0+. Instead of a lot of people reverting to 0.4.8, couldn't be added an option in the settings to use the previous transfer mode for the ones that can not use the new websocket transfer mode?
@DuckyBlender commented on GitHub (Feb 15, 2025):
I'm getting Error 403 for XHRPOST /api/v1/audio/transcriptions any ideas? This is my nginx config
edit: the issue is with cloudflare. it's returning the "just a moment..." page, still have no idea why
@doodlebro commented on GitHub (Feb 19, 2025):
How many times can an issue be referenced before we acknowledge that more can be done?
@firestrife23 commented on GitHub (Feb 19, 2025):
Eh, there are no cut and dry answers. As far as I can tell, a couple of containers running on my machine have no issues with WebSockets while sitting behind Traefik, but for some reason, OpenWeb-UI is the only one having this issue.
@XGhozt commented on GitHub (Feb 20, 2025):
I'm surprised this issue is still on-going. The ironic part is most of you here could post your config to your local AI and have it update it for you. I was able to update my config and pass the websocket packets on through my reverse proxy. There isn't really anything openwebui needs to do here.
There isn't one answer for everyone because it depends on your environment. Apache, nginx, caddy, cloudflare, ssl vs non-ssl, domain or sub domain, etc... (An aside with cloudflare, you have to actually enabled it first).
On my servers I'm using apache with let's encrypt for the SSL cert. I posted my apache config earlier. Below is a rough example, you can use this to google/search the rest or use AI to assist in building the config for your own setup.
You're adding support for websockets, you must have any related modules for your website enabled and installed (most likely you already have them by default). The below would be part of your config specifically for the web socket connection. We just need the "/ws/socket.io" to connect, you don't need web sockets setup at the root of the config.
For apache, you need something like this:
The nginx equivalent this this is something like:
For caddy:
Side notes;
If I am missing something I'd be curious what about my setup is so unique that it works fine for me. I'm not using docker, just building from source and booting it up from a service I setup. I have noticed that sometimes if I leave the page open too long I get a json error message, but refreshing or clicking the regenerate button works the second time. I'm not sure if this is a web socket problem though.
Good luck everyone, hope this helps some of you.
Edit: This is an excellent post for people using docker:
https://github.com/open-webui/open-webui/issues/8074#issuecomment-2562061337
@firestrife23 commented on GitHub (Feb 20, 2025):
@XGhozt thank you for the suggestions, I will definitely give it a try. I have not updated since 0.47 and hopefully it should be fixed, if not I will just add an environment to disable websocket on the openweb-ui container.
@ciprianveg commented on GitHub (Feb 20, 2025):
Is there an env var to disable ws?
@nyawox commented on GitHub (Feb 20, 2025):
alright, please ignore the nonsense i posted above. i figured out either caddy or firefox was having connectivity issue with websocket over http/2. apparently safari don't support websocket over http/2 and fallback to http/1.1 which explains why i didn't face this issue there. all i had to do is, just enable quic or disable http/2. that's it. nothing to do with the project, but i wanted to correct.
@likeablob commented on GitHub (Feb 21, 2025):
Just for anyone else running into this, in my case, the problem probably stems from a bug in Brave: https://github.com/brave/brave-browser/issues/15410
For the
SyntaxError: Unexpected token...error, whensession_id: $socket?.idbecomesundefinedbecause of an unconnected WS,POST /api/chat/completionsresponds withcontent-type: text/event-stream, and thusres.json()fails. So, perhaps an appropriate fallback would be nice?@Cnily03 commented on GitHub (Feb 25, 2025):
Same problem met here.
For nginx, we need to support websocket. it's easy to resolve it by googling:
I met this issue when hosting CDN. we have to ensure that the cdn can process websocket request properly. maybe disable http/2 is a good try as websocket is only for http 1.1.
@jaapdh commented on GitHub (Feb 27, 2025):
In our case we also needed to enable the mod_proxy_wstunnel in Apache before this would work.
@mcfool12 commented on GitHub (Feb 27, 2025):
Having no luck on NPM with the .5.x versions. I have gone through the above posts and following some of them, no matter what it will work for a question or two before it just spins and gives the error "SyntaxError: Unexpected token '<', "<html> <h"... is not valid JSON". I am wondering if anyone else on NPM has gotten it to be stable. The attached photos show the error in the search and then the config in NPM. I was testing with the second and third pic when I noticed the message at the bottom of the advanced tab "Please note, that any add_header or set_header directives added here will not be used by nginx. You will have to add a custom location '/' and add the header in the custom config there." and moved it under a secondary location of /.
Aside from that when I am able to directly connect via IP, the direct connection method to the server hosting the LM is working as expected and does not freeze up/break. That leads into the next issue though where it has been throwing up 500: Internal Error now with a direct connection and only loading when going through NPM. It was working fine yesterday and appears to have broken after updating to 0.5.17.
Edit. Just failed back to 0.5.16 and can confirm local connection, ie connecting at ip:port, is working again along with being able to access behind NPM. It is still answering only a few questions before failing.
@FreakErn commented on GitHub (Feb 28, 2025):
For everyone trying this with ISPConfig and Apache2. Do not use the ISPConfig menu option to configure the reverse proxy. Instead use the suggestion from @Simi5599. in Apache Directives
If you still want your letsencrypt to work you might have to exclude .well-known from the proxy with something like this:
A simple
ProxyPass /.well-known !didn't work for me.I moved the http ProxyPass into the location so my entire Apache-Directives look like this:
@junjieyuan commented on GitHub (Mar 7, 2025):
If you enable http/https proxy for open webui backend (in container), it will makes nginx proxy_pass fail and return 502, please disable http/https proxy for open webui.
My nginx config, it works:
@pnjacket commented on GitHub (Mar 7, 2025):
I have been having weird issues with WS not working correctly for days and finally figured out.
In my case, it was something to do with DNS records returning external ipv6 address that is not accessible from my internal network.
Assuming my open webui server has the domain name 'chat.mydomain.com', and the name was served by my local DNS server, but my dns server is only designed to server ipv4. All ipv6 requests were forwarded to the external dns server. I have exposed my open webui to the internet through cloud tunnel, which added a random ipv4 and ipv6 addresses to the cloud providers tunnel server.
When I am using it in the local network, it is trying to work with v6 address and timing out.
To prevent from v6 address to be resolved when I am in the local, I had to create a dummy dns record pointing to the internal reverse proxy address and add CNAME record which directs 'chat.mydomain.com' to the dummy one. That solved my specific issue. No fancy settings in nginx, just three lines to enable websocket.
I hope this will help someone.
@mcfool12 commented on GitHub (Mar 8, 2025):
I have figured out the issue I was running into. I had forgotten to mention that I was hosting the LLM through LM Studio on another machine. After updating the NGINX config in NPM to allow for WebSockets it was working but then would break after 1 - 3 questions. This was due to a CORS issue in modern browsers not working over ws and requiring wss. With this I created another proxy pointing to the ip of the server hosting LM Studio. With that made and https enabled with a cert, I updated the server address in Open WebUI and used https. No more CORS errors and chats will run on as long as needed.
NGINX config for the proxy pointing to OpenWebUI (Will not paste properly into code format for some reason)
location / {
proxy_pass http://openwebui:8080/;
}
NGINX config for the proxy pointing to LM Studio Server
location / { proxy_pass http://lmsutdio:12345/; rewrite ^/(models.*)$ /api/v0/$1 break; }and
location /api/v0/ {
proxy_pass http://lmstudio:12345/; # LM Studio backend (HTTP only)
}
With the HTTPS connection made to cover CORS over WSS, it is now working. The connection in Open WebUI, like I said earlier, is now https instead of http and the path is now just /v1 instead of /api/v0 or /api/v1. The direct connection method is also working should there be an issue with the routed connection method in the future which is nice. Now to test with some onboarded users.
@readonly-git-velsof commented on GitHub (Mar 10, 2025):
For me this solution worked. Definitely the help from the answers above is the reason for this solution:
How to Fix WebSocket Issues with Open WebUI Behind Apache Proxy
I was having issues with WebSocket connections (seeing errors like "WebSocket connection failed" and "Network Problem" in the browser console). Here's the solution that worked for me:
Step 1: Enable Required Apache Modules
Step 2: Update Apache Virtual Host Configuration
Step 3: Restart Apache
Step 4: Update Docker Compose Configuration (if needed)
Make sure your docker-compose.yml includes these settings:
The key fix is adding both regular HTTP proxying and WebSocket proxying for the same root location. This ensures that the WebSocket connections used by Open WebUI for real-time communication work properly through the Apache proxy.
After making these changes, you may need to clear your browser cache or try in an incognito window.
@firestrife23 commented on GitHub (Mar 10, 2025):
LOL, regurgitating ChatGPT solution... Sorry, Apache just makes me vomit too.
@Someguitarist commented on GitHub (Mar 10, 2025):
I'm sorry, I'm way to dumb for this. I've been trying all week to get this to work with Nginx Proxy Manager and copy and pasting all kinds of things listed above, plus more Googling and ChatGPT to figure this out. I have 'Enable Web Sockets' selected and tried setting custom location stuff based on the above but I still get "SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data" when accessed through reverse proxy, but not when accessed locally.
Can someone please put simple instructions for the idiots like me for how to access via reverse proxy with NPM? Literally every other self hosted app I have works and this worked great before the V5 upgrade. For now I'm going to roll back to an earlier version or move to something else, but I'd really like to get this resolved.
@mcfool12 commented on GitHub (Mar 10, 2025):
@Someguitarist Post what your current config is and someone might be able to get it for ya. If you are hosting the LLM on a seperate machine, you can see my post a few up on how to configure NPM for Open WebUI and then also the LLM host. In my case it is coming from LM Studio but would work for others if they are passing traffic over WS/HTTP instead of WSS/HTTPS.
@Someguitarist commented on GitHub (Mar 10, 2025):
Thanks! I just figured it out. I forgot I had it behind Authentik as a reverse proxy. Removing that, and now it works. I guess I could just use the SSO feature instead of reverse proxying it. But works now!
@vood commented on GitHub (Mar 11, 2025):
For anyone struggling to run on localhost with
open-webui serve, make sure you try bothhttp://127.0.0.1:8080andhttp://localhost:8080. For the the former worked while the latter didn't.@TurboTechieSystems commented on GitHub (Mar 16, 2025):
Does anyone know how to fix this when using IIS as a reverse proxy? Been trying to get this working for a few days now. Open-WebUI works fine locally and using static IP address's. We unfortunately use IIS as the reverse proxy server for our applications. The site is ssl enabled through lets encrypt. Security certificate works just fine and Open-WebUI loads just fine. Only problem is when submitting a chat get the same error as everyone else about json parse error.
I have noticed that instead of returning a JSON for the completions, data is returned as a stream-event instead. This only happens when accessing through the IIS proxy and not through direct IP address.
Web-Sockets are setup and appear to be working as shown.
Am I missing something or does anyone have an idea on how to get this working with IIS as a reverse proxy.
By the way using Cortex as my LLM server that is also proxied through IIS and works just fine when connecting to Open-WebUI via local or static IP. Using Automatic1111 as my image generator and works fine through IIS proxy when connecting to Open-WebUI via local or static IP.
Logs in Cortex show that Cortex receives the request and processes it and provides a response as it should.
So simply put I have Cortex, Open-WebUI, and Automatic1111 as seperete services on a Ubuntu machine. All three are Proxied and secured with SSL through IIS. Using Open-WebUI over the local or static IP works just fine with Cortex and Automatic1111 responding properly over https domain name and SSL. Open-WebUI is the issue.
@Eisaichen commented on GitHub (Mar 19, 2025):
Glad to see
ENABLE_WEBSOCKET_SUPPORTis now set toFalseby default. Enabling WebSocket without proper preparation is really easy to bring down the service.I believe many people put their servers behind Cloudflare, and if they are free-tier users, Cloudflare has a very limited quota for WebSocket connections. Because of that, even if they configured their reverse proxy correctly, they can still be experiencing fail to connect or unstable service. When v0.5.0 first came out, I had to expose my server from Cloudflare to make it work again.
@spammenotinoz commented on GitHub (Mar 21, 2025):
Understood, but over the internet that is pretty much impossible. The way around is to implement keep-alives, the current implementation stops keep-alives during the streaming phase.
Without proper keep-alives, if either the user or server uses Cloudflare as an example then this issue exists during any pause "eg: large image upload, thinking response, backend llm delay"
@spammenotinoz commented on GitHub (Mar 21, 2025):
True but also don't forget the client. Cloudflare has a timeout of 100 seconds, which is actually higher than many other providers\network devices. Remember every single network device, service, proxy, firewall from the client to the server will need a much longer timeout period say 5-7minutes to support some of the thinking models. Realistically that's not going to happen, so another approach would be required.
@Papierkorb commented on GitHub (Mar 24, 2025):
So I'm also having this issue and it caused me to not be able to use openwebui for months. It's hosted behind a traefik instance in my kubernetes cluster. I can see in the Network Tab that often times no websocket connection is even made, and after a while the UI complains that it received broken JSON.
However, the Playground works just fine. Also, when I access my models through their respective API endpoints directly they have no issue responding, with and without streaming.
Open-Webui isn't the only WebSocket-using application I host like this, but it's the only having issues. With
ENABLE_WEBSOCKET_SUPPORTset toFalseit does work again, although I'd still prefer proper WebSocket support.It did work after I cleared all caches and data of its domain. This isn't hosted behind/through any CDN, it's Computer -> LAN -> traefik -> open-webui. Traefik doesn't have special configuration, except for TLS.
@firestrife23 commented on GitHub (Mar 24, 2025):
I use Traefik too. I'm wondering, do you have HTTP3 enabled on yours? Because I suspect it's HTTP3 since it only does WebSocket over QUIC protocol. Im not entirely sure that’s the culprit…. I’m still investigating too.
@Papierkorb commented on GitHub (Mar 24, 2025):
@firestrife23
Just checked, it's using HTTP/2 - According to the Network dev tool and traefiks config. Maybe I'll try tomorrow if enabling HTTP/3 helps. I get from your comment that you have HTTP/3 enabled and are facing issues too?
@zeus123456 commented on GitHub (Mar 24, 2025):
Here is my config with Nginx Proxy Manager which I switched to from nginx on my ubuntu wsl after the websockets requirement caused me issue (I suspect I did not need to switch and it might have just been caching issues as reported by others).
However, I did have some issues with another open webui version recently that caused calls to drop, turned out is was my ios beta version, so try testing your issue from other devices/browsers/etc. (I tried another iphone without beta),
Domain Names *
mydomain.com
http
Forward Hostname / IP*
192.168.my_private_IP
Forward Port *
8080
Websockets support (enabled)
Access List
Publicly Accessible
I did not enable http/2 and don't seem to have http/3 as an option (might need to upgrade)
@ticpu commented on GitHub (Mar 24, 2025):
From what I understand from all of these comments with tips and tricks on how to fix this, I understand that the core issue is OpenWebUI assuming websocket connections can't fail, are always connected and have unlimited timeout. Which is only true on localhost.
I guess that's the real issue to address.
Maybe add keepalive, reconnections and a way to restore the state after failure?
@firestrife23 commented on GitHub (Mar 25, 2025):
More of hits and misses, most of the time it seems to work well. Whenever I get code 500, a hard reload with the browser usually makes it go away. It seems more noticeable with Safari than third-party browsers.