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


### Additional Information
_No response_
GiteaMirror
added the bug label 2025-11-11 16:30:02 -06:00
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)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @priyadharsan1403 on GitHub (Jul 4, 2025).
Check Existing Issues
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
README.md.Expected Behavior
Description:
Hi team,
We are integrating Open WebUI into our platform via an
@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:
(but this is only one layer, there are more places/subsystems that can limit it, you need to refine)
@tjbck commented on GitHub (Jul 4, 2025):
Unable to reproduce from our end.