issue: nly One User at a Time Can Access "Direct Connection" Feature When Using Open WebUI in Multi-User Environment #5696

New Issue

GiteaMirror · 2025-11-11T16:30:02-06:00

GiteaMirror commented

2025-11-11 16:30:02 -06:00

Originally created by @priyadharsan1403 on GitHub (Jul 4, 2025).

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.3.11

Ollama Version (if applicable)

No response

Operating System

ubuntu 22.04

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Description:

Hi team,

We are integrating Open WebUI into our platform via an

Originally created by @priyadharsan1403 on GitHub (Jul 4, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.3.11 ### Ollama Version (if applicable) _No response_ ### Operating System ubuntu 22.04 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Description: Hi team, We are integrating Open WebUI into our platform via an <iframe>. Our setup includes: Deployment: Docker container on AWS EC2 Reverse Proxy: Configured with Nginx Domain: Custom domain with HTTPS Authentication: Using a custom authentication middleware that injects a trusted header to identify and onboard users User Base: 100+ users accessing Open WebUI through our platform Problem We’ve enabled the "Direct Connection" feature on the admin side to allow users to connect with an OpenAI-compatible server (such as LiteLLM). However, we are experiencing the following issue: Only one user at a time is able to access the "Direct Connection" settings and use it. When a second user logs in, they can successfully access Open WebUI, but the Direct Connection feature is missing from their settings. This behavior persists across different browsers and sessions. Expected Behavior Each user should be able to: Log in through our platform via the trusted header Access their own Direct Connection settings independently Connect to their preferred OpenAI-compatible backend (like LiteLLM) Current Behavior Only the first user who logs in can access the Direct Connection settings. Subsequent users do not see the feature in their settings at all. Additional Notes We are using Open WebUI with the default Docker image. We’ve confirmed the trusted header is being passed correctly for all users. We suspect the issue may relate to how Open WebUI handles multi-user configurations or shared settings. Screenshots / Logs / Config Snippets (Attach any if needed) Environment: Open WebUI version: [please fill] Deployment: Docker on AWS EC2 Reverse Proxy: Nginx open ai compatible : LiteLLM proxy server Authentication: trusted header docker file : services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: nexus-chat-webui ports: - "3001:8080" environment: - WEBUI_AUTH=true - ENABLE_PERSISTENT_CONFIG=false - ENABLE_DIRECT_CONNECTIONS=true - WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-User-Email - WEBUI_AUTH_TRUSTED_NAME_HEADER=X-User-Name - WEBUI_AUTH_TRUSTED_ROLE_HEADER=X-User-Role - WEBUI_AUTH_TRUSTED_USER_ID_HEADER=X-User-ID - DEFAULT_USER_ROLE=user - MAX_USER_CONNECTIONS=100 - OPENAI_API_BASE_URL=https://apidev.navigatelabsai.com - https_proxy=https://chatdev.navigatelabsai.com - WEBUI_URL=https://chatdev.navigatelabsai.com - DATA_DIR=/app/backend/data volumes: - open-webui:/app/backend/data nginx config:cat chatdev.navigatelabsai.com server { listen 80; listen [::]:80; server_name chatdev.navigatelabsai.com; # Security headers add_header X-Content-Type-Options nosniff always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header X-Frame-Options "ALLOWALL" always; add_header Content-Security-Policy "frame-ancestors *" always; # 1. AUTH VERIFICATION ENDPOINT (INTERNAL) location = /auth-verify { internal; proxy_pass http://127.0.0.1:5000/verify; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; proxy_set_header Cookie $http_cookie; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_send_timeout 10s; proxy_read_timeout 10s; access_log /var/log/nginx/verify_access.log; error_log /var/log/nginx/verify_error.log debug; } # 2. MAIN APPLICATION - Open WebUI (AUTH REQUIRED) location / { auth_request /auth-verify; # Propagate session cookie from auth service auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie always; # Extract user details from auth service response headers auth_request_set $user_id $upstream_http_x_user_id; auth_request_set $user_email $upstream_http_x_user_email; auth_request_set $user_name $upstream_http_x_user_name; auth_request_set $openai_api_key $upstream_http_x_openai_api_key; auth_request_set $user_role $upstream_http_x_user_role; proxy_pass http://127.0.0.1:3001; # Standard proxy headers 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; proxy_set_header X-Forwarded-Host $host; proxy_set_header Cookie $http_cookie; # Trusted headers for Open WebUI auto-login proxy_set_header X-User-ID $user_id; proxy_set_header X-User-Email $user_email; proxy_set_header X-User-Name $user_name; proxy_set_header X-User-Role $user_role; proxy_set_header X-OpenAI-API-Key $openai_api_key; # WebSocket support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # SSE support for streaming responses proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; proxy_send_timeout 300s; # Connection pooling proxy_set_header Connection ""; # Debug headers (remove in production) add_header X-Debug-User-Email $user_email always; add_header X-Debug-User-ID $user_id always; add_header X-Debug-API-Key-Set $openai_api_key always; add_header X-Debug-Session-Cookie $auth_cookie always; } # 3. HEALTH CHECK ENDPOINT location = /health { access_log off; return 200 "Nexus Chat Gateway OK"; add_header Content-Type text/plain; } } Request: We would appreciate any guidance on: Supporting multi-user access to the Direct Connection feature Ensuring user-specific configuration isolation Thanks for your amazing work on Open WebUI! Looking forward to your support ### Actual Behavior all users are unable to see the connections setting at the same time but one at a time ### Steps to Reproduce i have provided the config file above ### Logs & Screenshots ![Image](https://github.com/user-attachments/assets/7115c46f-1ba8-4d6e-8b3e-f092ff8d6798) ![Image](https://github.com/user-attachments/assets/00e0272c-e4df-4d5b-b843-9db098420b66) ### Additional Information _No response_

GiteaMirror added the bug label 2025-11-11 16:30:02 -06:00

GiteaMirror closed this issue

2025-11-11 16:30:02 -06:00

GiteaMirror commented

2025-11-11 16:30:04 -06:00

@rgaricano commented on GitHub (Jul 4, 2025):

It seem that this could be a problem with your proxy, or related, you have to debug where is the breakdown or the connection limitation.

maybe you can try to add in your nginx something like:

    limit_conn perip 20;
    limit_conn perserver 500;

(but this is only one layer, there are more places/subsystems that can limit it, you need to refine)

@rgaricano commented on GitHub (Jul 4, 2025): It seem that this could be a problem with your proxy, or related, you have to debug where is the breakdown or the connection limitation. maybe you can try to add in your nginx something like: ``` limit_conn perip 20; limit_conn perserver 500; ``` (but this is only one layer, there are more places/subsystems that can limit it, you need to refine)

GiteaMirror commented

2025-11-11 16:30:04 -06:00

@tjbck commented on GitHub (Jul 4, 2025):

Unable to reproduce from our end.

@tjbck commented on GitHub (Jul 4, 2025): Unable to reproduce from our end.

GiteaMirror referenced this issue

2026-04-19 20:34:11 -05:00

[GH-ISSUE #5696] can't run normally #14089

GiteaMirror referenced this issue

2026-04-25 03:58:41 -05:00

[GH-ISSUE #5696] can't run normally #29617

GiteaMirror referenced this issue