[GH-ISSUE #1611] enhancement: better error handling #115879

New Issue

GiteaMirror · 2026-05-20T17:42:21-05:00

GiteaMirror commented

2026-05-20 17:42:21 -05:00

Originally created by @almostserious on GitHub (Apr 19, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/1611

Is your feature request related to a problem? Please describe.
I'm using this tool on CPU only, and with certain prompts I get some kind of timeout.
This usually happens when I upload a document to get a summary. I assume the context might be too long.
But I do not get any feedback in the UI.
Even when the CPU finished processing, the UI is stuck on this: (Image uploaded)

UI is kind of stuck. Opening and closing the thread just shows the initial prompt and no answer at all.

Describe the solution you'd like
I would love to get some kind of error message if the prompt cannot be resolved. Ideally with the steps needed to make it work.

Originally created by @almostserious on GitHub (Apr 19, 2024). Original GitHub issue: https://github.com/open-webui/open-webui/issues/1611 **Is your feature request related to a problem? Please describe.** I'm using this tool on CPU only, and with certain prompts I get some kind of timeout. This usually happens when I upload a document to get a summary. I assume the context might be too long. But I do not get any feedback in the UI. Even when the CPU finished processing, the UI is stuck on this: (Image uploaded) ![image](https://github.com/open-webui/open-webui/assets/14896478/1db8e070-73b9-4721-b7bd-a9662da75a71) UI is kind of stuck. Opening and closing the thread just shows the initial prompt and no answer at all. **Describe the solution you'd like** I would love to get some kind of error message if the prompt cannot be resolved. Ideally with the steps needed to make it work.

GiteaMirror added the enhancement help wanted labels 2026-05-20 17:42:22 -05:00

GiteaMirror closed this issue

2026-05-20 17:42:23 -05:00

GiteaMirror commented

2026-05-20 17:42:24 -05:00

@henry4711lp commented on GitHub (Apr 25, 2024):

Same problem here. An option to set a longer timeout or a bigger context window would be nice as well. I don't care if my small cpu needs 1h for a request if I know that it is still working on it

@henry4711lp commented on GitHub (Apr 25, 2024): Same problem here. An option to set a longer timeout or a bigger context window would be nice as well. I don't care if my small cpu needs 1h for a request if I know that it is still working on it

GiteaMirror commented

2026-05-20 17:42:25 -05:00

@earlyXbirdNG commented on GitHub (Apr 25, 2024):

Same problem here
But I have this even with no attachment uploaded. Only a little prompt and sometimes it's hanging. After page refresh and a new chat it's working

@earlyXbirdNG commented on GitHub (Apr 25, 2024): Same problem here But I have this even with no attachment uploaded. Only a little prompt and sometimes it's hanging. After page refresh and a new chat it's working

GiteaMirror commented

2026-05-20 17:42:26 -05:00

@tomazed commented on GitHub (May 12, 2024):

Same for me. Working on CPU only, some inference takes 2 to 10min to complete on ollama side. ollama does its work but it's never fowareded to open-webui

@tomazed commented on GitHub (May 12, 2024): Same for me. Working on CPU only, some inference takes 2 to 10min to complete on ollama side. ollama does its work but it's never fowareded to open-webui

GiteaMirror commented

2026-05-20 17:42:26 -05:00

@tomazed commented on GitHub (May 13, 2024):

Same for me. Working on CPU only, some inference takes 2 to 10min to complete on ollama side. ollama does its work but it's never fowareded to open-webui

I've done further investigation and the problem I had was with Cloudflare timeout that triggers at 100s. I've bypass cloudflare for serving open-webui and everything works fine (just tested with inference of 6 and a half minute.)
but maybe, having a better sequence with polling or even websocket to accomodate such long response would be an improvement.

@tomazed commented on GitHub (May 13, 2024): > Same for me. Working on CPU only, some inference takes 2 to 10min to complete on ollama side. ollama does its work but it's never fowareded to open-webui I've done further investigation and the problem I had was with Cloudflare timeout that triggers at 100s. I've bypass cloudflare for serving open-webui and everything works fine (just tested with inference of 6 and a half minute.) but maybe, having a better sequence with polling or even websocket to accomodate such long response would be an improvement.

GiteaMirror commented

2026-05-20 17:42:27 -05:00

@MatthK commented on GitHub (May 15, 2024):

I'm having the same problem. Open-WebUI and Ollama both run in a docker container on a CPU only system.

I haven't figured out yet a systematic rule to the issue, but more than half of my questions end up with that 504 error that is not passed on to the front-end. I assume that the model is too slow and in docker stats the Ollama container is still very busy, while I never get any feedback on the front-end.

I'm also not very concerned about the duration, but it would be helpful to know that I can give up waiting for a reply.

@MatthK commented on GitHub (May 15, 2024): I'm having the same problem. Open-WebUI and Ollama both run in a docker container on a CPU only system. I haven't figured out yet a systematic rule to the issue, but more than half of my questions end up with that 504 error that is not passed on to the front-end. I assume that the model is too slow and in docker stats the Ollama container is still very busy, while I never get any feedback on the front-end. I'm also not very concerned about the duration, but it would be helpful to know that I can give up waiting for a reply.

GiteaMirror commented

2026-05-20 17:42:27 -05:00

@ahmedsaed commented on GitHub (May 24, 2024):

If you are using a proxy make sure that it doesn't timeout or cache the responses. If you are using Nginx then add these lines to your config

proxy_connect_timeout 3000;
proxy_send_timeout    3000;
proxy_read_timeout    3000;
send_timeout          3000;

This configuration increases the timeout to 3000 seconds (50 minutes).

# Disable buffering
proxy_buffering off;
proxy_cache off;

This configuration disables caching and buffering.

More details are outlined here: https://github.com/open-webui/open-webui/discussions/2380#discussioncomment-9551560

@ahmedsaed commented on GitHub (May 24, 2024): If you are using a proxy make sure that it doesn't timeout or cache the responses. If you are using Nginx then add these lines to your config ```nginx proxy_connect_timeout 3000; proxy_send_timeout 3000; proxy_read_timeout 3000; send_timeout 3000; ``` This configuration increases the timeout to 3000 seconds (50 minutes). ```nginx # Disable buffering proxy_buffering off; proxy_cache off; ``` This configuration disables caching and buffering. More details are outlined here: https://github.com/open-webui/open-webui/discussions/2380#discussioncomment-9551560

GiteaMirror commented

2026-05-20 17:42:28 -05:00

@MatthK commented on GitHub (May 25, 2024):

If you are using a proxy make sure that it doesn't timeout or cache the responses. If you are using Nginx then add these lines to your config
More details are outlined here: #2380 (comment)

Thank you very much

@MatthK commented on GitHub (May 25, 2024): > If you are using a proxy make sure that it doesn't timeout or cache the responses. If you are using Nginx then add these lines to your config > More details are outlined here: [#2380 (comment)](https://github.com/open-webui/open-webui/discussions/2380#discussioncomment-9551560) Thank you very much

GiteaMirror commented

2026-05-20 17:42:29 -05:00

@Arakade commented on GitHub (Nov 20, 2024):

Seeing similar issue with using ComfyUI when generating an image with a long prompt taking a long time (5 minutes).
Shorter prompts that complete in shorter time seem to work fine. Beyond a TBD time, I see a toast message in the UI "Server connection failed".
Checking the ComfyUI I can see it's still working and completes later.

The Open-WebUI log doesn't show anything amazingly useful:

INFO  [open_webui.apps.images.utils.comfyui] WebSocket connection established.                                               
INFO  [open_webui.apps.images.utils.comfyui] Sending workflow to WebSocket server.                                           
INFO  [open_webui.apps.images.utils.comfyui] Workflow: {'6': {'inputs': {'text': "...", 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Positive Prompt)'}}, '8': {'inputs': {'samples': ['31', 0], 'vae': ['38', 2]}, 'class_type': 'VAEDecode', '_meta': {'title': 'VAE Decode'}}, '9': {'inputs': {'filename_prefix': 'ComfyUI', 'images': ['8', 0]}, 'class_type': 'SaveImage', '_meta': {'title': 'Save Image'}}, '27': {'inputs': {'width': 1024, 'height': 1024, 'batch_size': 1}, 'class_type': 'EmptySD3LatentImage', '_meta': {'title': 'EmptySD3LatentImage'}}, '31': {'inputs': {'seed': 6910836708924306687, 'steps': 4, 'cfg': 1, 'sampler_name': 'euler', 'scheduler': 'simple', 'denoise': 1, 'model': ['38', 0], 'positive': ['6', 0], 'negative': ['33', 0], 'latent_image': ['27', 0]}, 'class_type': 'KSampler', '_meta': {'title': 'KSampler'}}, '33': {'inputs': {'text': '', 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Negative Prompt)'}}, '38': {'inputs': {'ckpt_name': 'flux1-schnell-fp8.safetensors'}, 'class_type': 'CheckpointLoaderSimple', '_meta': {'title': 'Load Checkpoint'}}}                                                                                                                    
INFO  [open_webui.apps.images.utils.comfyui] queue_prompt

Then it loops the usual while waiting:

INFO:     192.168.1.186:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PD9c0r0&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK  
INFO:     192.168.1.186:0 - "POST /ws/socket.io/?EIO=4&transport=polling&t=PD9c6xl&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK

After a while we see the error in GUI : "Server connection failed"

Then a while later after a few more GET/POST status checks same as above (all 200):

INFO  [open_webui.apps.images.utils.comfyui] get_history
INFO  [open_webui.apps.images.utils.comfyui] get_image

I suspect these are the image being ready but the requester is no longer listening.
Checking ComfyUI, it generated fine -- just took too long! (5 minutes)

p.s. I'm using latest Open-WebUI 0.4.1 with latest ComfyUI. Both are running in Docker containers as is Ollama. OWUI contacts CUI via http://localhost:8002 (no Nginx AFAIK) although I am using Nginx for SSL proxy for OWUI. Probably not relevant but GPU is an AMD and it's correctly configured for acceleration through Docker.

@Arakade commented on GitHub (Nov 20, 2024): Seeing similar issue with using ComfyUI when generating an image with a long prompt taking a long time (5 minutes). Shorter prompts that complete in shorter time seem to work fine. Beyond a TBD time, I see a toast message in the UI "Server connection failed". Checking the ComfyUI I can see it's still working and completes later. The Open-WebUI log doesn't show anything amazingly useful: ``` INFO [open_webui.apps.images.utils.comfyui] WebSocket connection established. INFO [open_webui.apps.images.utils.comfyui] Sending workflow to WebSocket server. INFO [open_webui.apps.images.utils.comfyui] Workflow: {'6': {'inputs': {'text': "...", 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Positive Prompt)'}}, '8': {'inputs': {'samples': ['31', 0], 'vae': ['38', 2]}, 'class_type': 'VAEDecode', '_meta': {'title': 'VAE Decode'}}, '9': {'inputs': {'filename_prefix': 'ComfyUI', 'images': ['8', 0]}, 'class_type': 'SaveImage', '_meta': {'title': 'Save Image'}}, '27': {'inputs': {'width': 1024, 'height': 1024, 'batch_size': 1}, 'class_type': 'EmptySD3LatentImage', '_meta': {'title': 'EmptySD3LatentImage'}}, '31': {'inputs': {'seed': 6910836708924306687, 'steps': 4, 'cfg': 1, 'sampler_name': 'euler', 'scheduler': 'simple', 'denoise': 1, 'model': ['38', 0], 'positive': ['6', 0], 'negative': ['33', 0], 'latent_image': ['27', 0]}, 'class_type': 'KSampler', '_meta': {'title': 'KSampler'}}, '33': {'inputs': {'text': '', 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Negative Prompt)'}}, '38': {'inputs': {'ckpt_name': 'flux1-schnell-fp8.safetensors'}, 'class_type': 'CheckpointLoaderSimple', '_meta': {'title': 'Load Checkpoint'}}} INFO [open_webui.apps.images.utils.comfyui] queue_prompt ``` Then it loops the usual while waiting: ``` INFO: 192.168.1.186:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PD9c0r0&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK INFO: 192.168.1.186:0 - "POST /ws/socket.io/?EIO=4&transport=polling&t=PD9c6xl&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK ``` After a while we see the error in GUI : "Server connection failed" Then a while later after a few more GET/POST status checks same as above (all 200): ``` INFO [open_webui.apps.images.utils.comfyui] get_history INFO [open_webui.apps.images.utils.comfyui] get_image ``` I suspect these are the image being ready but the requester is no longer listening. Checking ComfyUI, it generated fine -- just took too long! (5 minutes) p.s. I'm using latest Open-WebUI 0.4.1 with latest ComfyUI. Both are running in Docker containers as is Ollama. OWUI contacts CUI via `http://localhost:8002` (no Nginx AFAIK) although I _am_ using Nginx for SSL proxy for OWUI. Probably not relevant but GPU is an AMD and it's correctly configured for acceleration through Docker.

GiteaMirror commented

2026-05-20 17:42:30 -05:00

@thedxt commented on GitHub (Nov 28, 2024):

Seeing similar issue with using ComfyUI when generating an image with a long prompt taking a long time (5 minutes). Shorter prompts that complete in shorter time seem to work fine. Beyond a TBD time, I see a toast message in the UI "Server connection failed". Checking the ComfyUI I can see it's still working and completes later.

The Open-WebUI log doesn't show anything amazingly useful:
INFO  [open_webui.apps.images.utils.comfyui] WebSocket connection established.                                               
INFO  [open_webui.apps.images.utils.comfyui] Sending workflow to WebSocket server.                                           
INFO  [open_webui.apps.images.utils.comfyui] Workflow: {'6': {'inputs': {'text': "...", 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Positive Prompt)'}}, '8': {'inputs': {'samples': ['31', 0], 'vae': ['38', 2]}, 'class_type': 'VAEDecode', '_meta': {'title': 'VAE Decode'}}, '9': {'inputs': {'filename_prefix': 'ComfyUI', 'images': ['8', 0]}, 'class_type': 'SaveImage', '_meta': {'title': 'Save Image'}}, '27': {'inputs': {'width': 1024, 'height': 1024, 'batch_size': 1}, 'class_type': 'EmptySD3LatentImage', '_meta': {'title': 'EmptySD3LatentImage'}}, '31': {'inputs': {'seed': 6910836708924306687, 'steps': 4, 'cfg': 1, 'sampler_name': 'euler', 'scheduler': 'simple', 'denoise': 1, 'model': ['38', 0], 'positive': ['6', 0], 'negative': ['33', 0], 'latent_image': ['27', 0]}, 'class_type': 'KSampler', '_meta': {'title': 'KSampler'}}, '33': {'inputs': {'text': '', 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Negative Prompt)'}}, '38': {'inputs': {'ckpt_name': 'flux1-schnell-fp8.safetensors'}, 'class_type': 'CheckpointLoaderSimple', '_meta': {'title': 'Load Checkpoint'}}}                                                                                                                    
INFO  [open_webui.apps.images.utils.comfyui] queue_prompt 
Then it loops the usual while waiting:
INFO:     192.168.1.186:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PD9c0r0&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK  
INFO:     192.168.1.186:0 - "POST /ws/socket.io/?EIO=4&transport=polling&t=PD9c6xl&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK 
After a while we see the error in GUI : "Server connection failed"

Then a while later after a few more GET/POST status checks same as above (all 200):
INFO  [open_webui.apps.images.utils.comfyui] get_history
INFO  [open_webui.apps.images.utils.comfyui] get_image
I suspect these are the image being ready but the requester is no longer listening. Checking ComfyUI, it generated fine -- just took too long! (5 minutes)

p.s. I'm using latest Open-WebUI 0.4.1 with latest ComfyUI. Both are running in Docker containers as is Ollama. OWUI contacts CUI via http://localhost:8002 (no Nginx AFAIK) although I am using Nginx for SSL proxy for OWUI. Probably not relevant but GPU is an AMD and it's correctly configured for acceleration through Docker.

I am seeing a similar issue. I can replicate the problem by loading up my VRAM then when ComfyUI loads the model it does a partial load then if the image generation takes just over 90 seconds it will come back with the server connection failed error.

What's interesting is there is no issue when I use Open WebUI directly. It only happens when there's NGINX in front of it.

I've set my NGIX setting to the following

    location = /  {
proxy_no_cache 1;
proxy_cache_bypass 1;
proxy_buffering off;
proxy_cache off;
proxy_request_buffering off;
send_timeout          3000;
proxy_read_timeout    3000;
proxy_send_timeout    3000;
proxy_connect_timeout 3000;
    }

Open WebUI is in Docker on version v0.4.6

I am using Nginx Proxy Manager v2.12.1 also in Docker.

Ollama and ComfyUI run directly on the VM with no docker.

I think the issue is something to do with NGINX and cache or something.

@thedxt commented on GitHub (Nov 28, 2024): > Seeing similar issue with using ComfyUI when generating an image with a long prompt taking a long time (5 minutes). Shorter prompts that complete in shorter time seem to work fine. Beyond a TBD time, I see a toast message in the UI "Server connection failed". Checking the ComfyUI I can see it's still working and completes later. > > The Open-WebUI log doesn't show anything amazingly useful: > > ``` > INFO [open_webui.apps.images.utils.comfyui] WebSocket connection established. > INFO [open_webui.apps.images.utils.comfyui] Sending workflow to WebSocket server. > INFO [open_webui.apps.images.utils.comfyui] Workflow: {'6': {'inputs': {'text': "...", 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Positive Prompt)'}}, '8': {'inputs': {'samples': ['31', 0], 'vae': ['38', 2]}, 'class_type': 'VAEDecode', '_meta': {'title': 'VAE Decode'}}, '9': {'inputs': {'filename_prefix': 'ComfyUI', 'images': ['8', 0]}, 'class_type': 'SaveImage', '_meta': {'title': 'Save Image'}}, '27': {'inputs': {'width': 1024, 'height': 1024, 'batch_size': 1}, 'class_type': 'EmptySD3LatentImage', '_meta': {'title': 'EmptySD3LatentImage'}}, '31': {'inputs': {'seed': 6910836708924306687, 'steps': 4, 'cfg': 1, 'sampler_name': 'euler', 'scheduler': 'simple', 'denoise': 1, 'model': ['38', 0], 'positive': ['6', 0], 'negative': ['33', 0], 'latent_image': ['27', 0]}, 'class_type': 'KSampler', '_meta': {'title': 'KSampler'}}, '33': {'inputs': {'text': '', 'clip': ['38', 1]}, 'class_type': 'CLIPTextEncode', '_meta': {'title': 'CLIP Text Encode (Negative Prompt)'}}, '38': {'inputs': {'ckpt_name': 'flux1-schnell-fp8.safetensors'}, 'class_type': 'CheckpointLoaderSimple', '_meta': {'title': 'Load Checkpoint'}}} > INFO [open_webui.apps.images.utils.comfyui] queue_prompt > ``` > > Then it loops the usual while waiting: > > ``` > INFO: 192.168.1.186:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=PD9c0r0&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK > INFO: 192.168.1.186:0 - "POST /ws/socket.io/?EIO=4&transport=polling&t=PD9c6xl&sid=6GwPxvoVzqkCBpg0AAAA HTTP/1.0" 200 OK > ``` > > After a while we see the error in GUI : "Server connection failed" > > Then a while later after a few more GET/POST status checks same as above (all 200): > > ``` > INFO [open_webui.apps.images.utils.comfyui] get_history > INFO [open_webui.apps.images.utils.comfyui] get_image > ``` > > I suspect these are the image being ready but the requester is no longer listening. Checking ComfyUI, it generated fine -- just took too long! (5 minutes) > > p.s. I'm using latest Open-WebUI 0.4.1 with latest ComfyUI. Both are running in Docker containers as is Ollama. OWUI contacts CUI via `http://localhost:8002` (no Nginx AFAIK) although I _am_ using Nginx for SSL proxy for OWUI. Probably not relevant but GPU is an AMD and it's correctly configured for acceleration through Docker. I am seeing a similar issue. I can replicate the problem by loading up my VRAM then when ComfyUI loads the model it does a partial load then if the image generation takes just over 90 seconds it will come back with the server connection failed error. What's interesting is there is no issue when I use Open WebUI directly. It only happens when there's NGINX in front of it. I've set my NGIX setting to the following ``` location = / { proxy_no_cache 1; proxy_cache_bypass 1; proxy_buffering off; proxy_cache off; proxy_request_buffering off; send_timeout 3000; proxy_read_timeout 3000; proxy_send_timeout 3000; proxy_connect_timeout 3000; } ``` Open WebUI is in Docker on version v0.4.6 I am using Nginx Proxy Manager v2.12.1 also in Docker. Ollama and ComfyUI run directly on the VM with no docker. I think the issue is something to do with NGINX and cache or something.

GiteaMirror commented

2026-05-20 17:42:30 -05:00

@thedxt commented on GitHub (Nov 28, 2024):

I am seeing a similar issue. I can replicate the problem by loading up my VRAM then when ComfyUI loads the model it does a partial load then if the image generation takes just over 90 seconds it will come back with the server connection failed error.

What's interesting is there is no issue when I use Open WebUI directly. It only happens when there's NGINX in front of it.

I've set my NGIX setting to the following
    location = /  {
proxy_no_cache 1;
proxy_cache_bypass 1;
proxy_buffering off;
proxy_cache off;
proxy_request_buffering off;
send_timeout          3000;
proxy_read_timeout    3000;
proxy_send_timeout    3000;
proxy_connect_timeout 3000;
    }
Open WebUI is in Docker on version v0.4.6

I am using Nginx Proxy Manager v2.12.1 also in Docker.

Ollama and ComfyUI run directly on the VM with no docker.

I think the issue is something to do with NGINX and cache or something.

I figured it out.

Loading up the VRAM had nothing to do with any of this. It just happened to line up with the timeout on my setup.

It seems that if you see lots of socket.io in your network log in DevTools things might not be working correctly.

Example: https://EXTERNAL-OPEN-WEBUI-URL/ws/socket.io/?EIO=4&transport=polling&t=RANDOM

If you dig into the socket.io documentation you find that they mention some extra settings for NGINX specifically they say to use the following

    location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;

      proxy_pass http://localhost:3000;

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

Once you set that it seems to almost completely eliminate the socket.io connections in the network log.

That didn't fully fix my issue as I was still seeing the timeout at about 90 seconds.

I also noticed that when the error message showed up in Open WebUI the URL for /images/api/v1/generations in the network log would flip to a status code of 504 Gateway Timeout.

I tried setting what @Ahmedsaed and other have said about setting the send, read, and connect timeouts to 3000 seconds to force Open WebUI to wait longer.

I adding the following

 send_timeout          3000;
 proxy_read_timeout    3000;
 proxy_send_timeout    3000;
 proxy_connect_timeout 3000;

After adding that the image generation started working for me. I suspect that if the image generation takes longer to 3000 second it will fail again.

I was curious which setting was actually needed so I set them to 3 seconds to make it fail fast to find the exact setting.

The end result is that the proxy_read_timeout setting is the key.

the final settings that are working for me are

location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_pass http://INTERNAL-OPEN-WEBUI-IP:3000;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_read_timeout    3000;
    }

@thedxt commented on GitHub (Nov 28, 2024): > I am seeing a similar issue. I can replicate the problem by loading up my VRAM then when ComfyUI loads the model it does a partial load then if the image generation takes just over 90 seconds it will come back with the server connection failed error. > > What's interesting is there is no issue when I use Open WebUI directly. It only happens when there's NGINX in front of it. > > I've set my NGIX setting to the following > > ``` > location = / { > proxy_no_cache 1; > proxy_cache_bypass 1; > proxy_buffering off; > proxy_cache off; > proxy_request_buffering off; > send_timeout 3000; > proxy_read_timeout 3000; > proxy_send_timeout 3000; > proxy_connect_timeout 3000; > } > ``` > > Open WebUI is in Docker on version v0.4.6 > > I am using Nginx Proxy Manager v2.12.1 also in Docker. > > Ollama and ComfyUI run directly on the VM with no docker. > > I think the issue is something to do with NGINX and cache or something. I figured it out. Loading up the VRAM had nothing to do with any of this. It just happened to line up with the timeout on my setup. It seems that if you see lots of socket.io in your network log in DevTools things might not be working correctly. Example: https://EXTERNAL-OPEN-WEBUI-URL/ws/socket.io/?EIO=4&transport=polling&t=RANDOM If you dig into the [socket.io documentation](https://socket.io/docs/v4/reverse-proxy/) you find that they mention some extra settings for NGINX specifically they say to use the following ``` location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://localhost:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ``` Once you set that it seems to almost completely eliminate the socket.io connections in the network log. That didn't fully fix my issue as I was still seeing the timeout at about 90 seconds. I also noticed that when the error message showed up in Open WebUI the URL for `/images/api/v1/generations` in the network log would flip to a status code of 504 Gateway Timeout. I tried setting what @Ahmedsaed and other have said about setting the send, read, and connect timeouts to 3000 seconds to force Open WebUI to wait longer. I adding the following ``` send_timeout 3000; proxy_read_timeout 3000; proxy_send_timeout 3000; proxy_connect_timeout 3000; ``` After adding that the image generation started working for me. I suspect that if the image generation takes longer to 3000 second it will fail again. I was curious which setting was actually needed so I set them to 3 seconds to make it fail fast to find the exact setting. The end result is that the `proxy_read_timeout` setting is the key. the final settings that are working for me are ``` location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://INTERNAL-OPEN-WEBUI-IP:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3000; } ```

GiteaMirror commented

2026-05-20 17:42:31 -05:00

@Arakade commented on GitHub (Nov 28, 2024):

@thedxt, @Ahmedsaed: you're talking about nginx as a proxy. Can I ask where you're using it:

User --nginx--> OWUI --> Comfy
User --nginx--> OWUI --nginx--> Comfy
User --> OWUI --nginx--> Comfy

I believe I have (1) but I think you have (2) or (3) which is why adding settings to nginx to affect timeouts affects interactions between OWUI and Comfy. (Right?)

I say ”believe” because while I haven't set-up nginx between them myself, it occurs you might be talking about it because it's already there and I just haven't realised. Is that the case? (A simple ”yes, look in path, dummy” would be awesome so I can 🤦)

If not, either nginx between OWUI and Comfy is not the only cause or maybe there's a way to apply similar timeout settings to OWUI directly?

Thanks (and please feel free to correct any misunderstandings I have ☺️)

@Arakade commented on GitHub (Nov 28, 2024): @thedxt, @Ahmedsaed: you're talking about nginx as a proxy. Can I ask where you're using it: 1. User --nginx--> OWUI --> Comfy 2. User --nginx--> OWUI --nginx--> Comfy 3. User --> OWUI --nginx--> Comfy I _believe_ I have (1) but I think you have (2) or (3) which is why adding settings to nginx to affect timeouts affects interactions between OWUI and Comfy. (Right?) I say ”_believe_” because while I haven't set-up nginx between them myself, it occurs you might be talking about it because it's already there and I just haven't realised. Is that the case? (A simple ”yes, look in path, dummy” would be awesome so I can 🤦) If not, either nginx between OWUI and Comfy is not the only cause or maybe there's a way to apply similar timeout settings to OWUI directly? Thanks (and please feel free to correct any misunderstandings I have ☺️)

GiteaMirror commented

2026-05-20 17:42:31 -05:00

@thedxt commented on GitHub (Nov 28, 2024):

@Arakade I'm doing User --nginx--> OWUI --> Comfy

Users access OWUI via Nginx. I am using Nginx Proxy Manager. No extra tweaks are made to Comfy.

It's possible the Comfy also runs Nginx but I've made 0 changes to Comfy after installing it.

The issue for me only seems to happen once I put Nginx in front of OWUI.

If you watch the network log on OWUI when you access it directly without Nginx you'll see very few of the socket.io connections but the moment you put Nginx in front of OWUI and watch the network log for Nginx you see lots of the socket.io connections. Which made me focus on Nginx instead of OWUI.

Once you tweak the Nginx settings to have what Socket.io says to use then there are very few socket.io calls just like when you access OWUI directly. But the error still happened until I added the proxy_read_timeout setting to Nginx.

I think the root cause is that it's an Nginx issue as everything works perfectly when I removed Nginx from the equation. However the error message in OWUI wasn't clear and made me think that the issue was a setting on the OWUI side.

@thedxt commented on GitHub (Nov 28, 2024): @Arakade I'm doing User --nginx--> OWUI --> Comfy Users access OWUI via Nginx. I am using [Nginx Proxy Manager](https://nginxproxymanager.com/). No extra tweaks are made to Comfy. It's possible the Comfy also runs Nginx but I've made 0 changes to Comfy after installing it. The issue for me only seems to happen once I put Nginx in front of OWUI. If you watch the network log on OWUI when you access it directly without Nginx you'll see very few of the socket.io connections but the moment you put Nginx in front of OWUI and watch the network log for Nginx you see lots of the socket.io connections. Which made me focus on Nginx instead of OWUI. Once you tweak the Nginx settings to have what Socket.io says to use then there are very few socket.io calls just like when you access OWUI directly. But the error still happened until I added the `proxy_read_timeout` setting to Nginx. I think the root cause is that it's an Nginx issue as everything works perfectly when I removed Nginx from the equation. However the error message in OWUI wasn't clear and made me think that the issue was a setting on the OWUI side.

GiteaMirror commented

2026-05-20 17:42:32 -05:00

@Arakade commented on GitHub (Nov 28, 2024):

@thedxt oh! Wow, thanks. I'll update mine with your changes later and see if that helps! Thanks again!

@Arakade commented on GitHub (Nov 28, 2024): @thedxt oh! Wow, thanks. I'll update mine with your changes later and see if that helps! Thanks again!

GiteaMirror commented

2026-05-20 17:42:33 -05:00

@bughunter2 commented on GitHub (Apr 8, 2025):

👉 Suggestion: make Open WebUI show a clear error when WebSockets are failing.

Just stumbled upon issues similar to those reported here. Needed to add this to my Nginx reverse proxy config in order for WebSockets to work properly:

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

If I prompted a model (asked a question), Open WebUI would show an error related to the JSON response (from Ollama) being invalid (it appeared that it couldn't read the response, hence a parsing error occurred). The precise error was: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data.

With the above snippet added inside a location block in the Nginx reverse proxy config, Open WebUI appeared to work fine. 🙂

@bughunter2 commented on GitHub (Apr 8, 2025): 👉 **Suggestion**: make Open WebUI show a clear error when WebSockets are failing. Just stumbled upon issues similar to those reported here. Needed to add this to my Nginx reverse proxy config in order for WebSockets to work properly: ``` proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; ``` If I prompted a model (asked a question), Open WebUI would show an error related to the JSON response (from Ollama) being **invalid** (it appeared that it couldn't read the response, hence a parsing error occurred). The precise error was: `SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data`. With the above snippet added inside a `location` block in the Nginx reverse proxy config, Open WebUI appeared to work fine. 🙂

GiteaMirror commented

2026-05-20 17:42:33 -05:00

@viba1 commented on GitHub (Apr 29, 2025):

Same issue here: CPU only configuration, ollama 0.6.6 and webui 0.6.5.
Use-case to reproduce : webui request with web search.
Sometimes (rarely) the result appears with "SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data"
More frequently, no results are displayed immediately after the web search ends.

I don’t see any difference between the changes made to the reverse proxy configuration, as previously proposed.

I see the display problem with gemma3:1b or gemma3:4b yet fast to run, while I have the display + json error with phi4:14b which is much longer to run, so I doubt the relevance of the timeout track.

The operation is correct and without error message with llama3.2 or qwen3

I think it's more of a webui problem, due to random behavior depending on the choice of model but reproducible for the same model.

@viba1 commented on GitHub (Apr 29, 2025): Same issue here: CPU only configuration, ollama 0.6.6 and webui 0.6.5. Use-case to reproduce : webui request with web search. Sometimes (rarely) the result appears with "SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data" More frequently, no results are displayed immediately after the web search ends. I don’t see any difference between the changes made to the reverse proxy configuration, as previously proposed. I see the display problem with gemma3:1b or gemma3:4b yet fast to run, while I have the display + json error with phi4:14b which is much longer to run, so I doubt the relevance of the timeout track. The operation is correct and without error message with llama3.2 or qwen3 I think it's more of a webui problem, due to random behavior depending on the choice of model but reproducible for the same model.

GiteaMirror commented

2026-05-20 17:42:34 -05:00

@lemassykoi commented on GitHub (May 9, 2025):

I have this problem with qwen3 (with web search enabled and disabled):

Yesterday, all was working fine without errors. I was in 0.6.6 (not 100% sure about that)

Now with 0.6.7 qwen3 is KO

edit: an other thinking model not working:

@lemassykoi commented on GitHub (May 9, 2025): I have this problem with qwen3 (with web search enabled and disabled): ![Image](https://github.com/user-attachments/assets/5a2d8ecf-10d4-427f-bc20-287ccd7c7331) ![Image](https://github.com/user-attachments/assets/23ef90ae-c9df-482b-9cef-9a6b8b7711b0) Yesterday, all was working fine without errors. I was in 0.6.6 (not 100% sure about that) ![Image](https://github.com/user-attachments/assets/4b676fcc-819c-4c47-96f8-4726f1f34aaf) Now with 0.6.7 qwen3 is KO edit: an other thinking model not working: ![Image](https://github.com/user-attachments/assets/90a75d71-ef22-49c1-baa3-db5bd25d01ae)

GiteaMirror commented

2026-05-20 17:42:34 -05:00

@ivanbaldo commented on GitHub (May 9, 2025):

I had that error also with non-thinking models, sometimes websockets have issues.
Try to clean the Redis data or disable websockets with ENABLE_WEBSOCKET_SUPPORT: False and see if you can still reproduce the error, to confirm it's actually something with the model and not with websockets.
Thanks!!!

@ivanbaldo commented on GitHub (May 9, 2025): I had that error also with non-thinking models, sometimes websockets have issues. Try to clean the Redis data or disable websockets with `ENABLE_WEBSOCKET_SUPPORT: False` and see if you can still reproduce the error, to confirm it's actually something with the model and not with websockets. Thanks!!!

GiteaMirror commented

2026-05-20 17:42:35 -05:00

@lemassykoi commented on GitHub (May 9, 2025):

Thanks. As indeed I was not able to chat with any model, I closed my browser tab and went to something else.
When I get notified about your answer, I logged in on my open-webui to search about redis data.
One first thing I noticed is that the "active users: 1" is now displayed, whereas it was not when I wrote my post, despite multiple page refresh (too lazy to logout/login).
Then I tried again my failed queries from post time, and now it's ok.

Is it related to websockets?

@lemassykoi commented on GitHub (May 9, 2025): Thanks. As indeed I was not able to chat with any model, I closed my browser tab and went to something else. When I get notified about your answer, I logged in on my open-webui to search about redis data. One first thing I noticed is that the "active users: 1" is now displayed, whereas it was not when I wrote my post, despite multiple page refresh (too lazy to logout/login). Then I tried again my failed queries from post time, and now it's ok. Is it related to websockets?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#115879