I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
v0.6.34
Ollama Version (if applicable)
No response
Operating System
Rocky 9.6
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
When a custom header is defined in Open WebUI (e.g. X-API-Key: ),
the header should be included in the outgoing request to the configured API (e.g. /v1/models).
Kong should validate the key and return a successful 200 response.
Actual Behavior
Even after setting the custom header in Open WebUI v0.6.33,
requests to the API (e.g. /v1/models) return 401 Unauthorized from Kong.
Logs on the Kong side show that the expected authentication header is missing,
meaning the key–value pair wasn’t sent in the request.
Steps to Reproduce
Deploy an OpenAI-compatible API behind Kong, with the Key Authentication plugin enabled.
Configure Open WebUI v0.6.34 to use that API endpoint.
In the Open WebUI API settings, add a custom header (e.g. X-API-Key: test-key).
Go to main page, try to choose the new added model and see nothing
Logs & Screenshots
Additional Information
Hi, I encountered an issue when using custom headers together with Kong Key Authentication.
I usually deploy my OpenAI-format LLM API behind Kong, and require users to include a custom key–value pair in the request headers for authentication.
This allows us to track usage and control traffic per user.
Recently, I noticed that Open WebUI v0.6.33 introduced a feature to add custom headers when configuring OpenAI-compatible APIs.
I was hoping this would solve my previous issue — that Open WebUI couldn’t include my custom Kong key in the headers.
However, after testing, I still receive a 401 Unauthorized from Kong.
It seems the custom key–value pair is not actually being sent in the request headers, because the request to /v1/models fails authentication on Kong’s side.
I reviewed the code here
, and it looks like custom headers should indeed be merged into the request before calling /v1/models.
So I’m wondering — is there something preventing these custom headers from being applied in practice?
🧠 Summary
Kong behind Open WebUI uses Key Authentication
Added custom header in Open WebUI (v0.6.33)
Request to /v1/models still returns 401 Unauthorized
Expected: the custom key header should be included and authenticated correctly
💬 Question
Is there a known limitation or middleware stripping out custom headers before the request is sent?
Or is there a specific configuration required for the custom headers to take effect?
Originally created by @Stanleyluuuu on GitHub (Oct 22, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18509
### Check Existing Issues
- [x] I have searched for any existing and/or related issues.
- [x] I have searched for any existing and/or related discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.6.34
### Ollama Version (if applicable)
_No response_
### Operating System
Rocky 9.6
### 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
When a custom header is defined in Open WebUI (e.g. X-API-Key: <token>),
the header should be included in the outgoing request to the configured API (e.g. /v1/models).
Kong should validate the key and return a successful 200 response.
### Actual Behavior
Even after setting the custom header in Open WebUI v0.6.33,
requests to the API (e.g. /v1/models) return 401 Unauthorized from Kong.
Logs on the Kong side show that the expected authentication header is missing,
meaning the key–value pair wasn’t sent in the request.
### Steps to Reproduce
1. Deploy an OpenAI-compatible API behind Kong, with the Key Authentication plugin enabled.
2. Configure Open WebUI v0.6.34 to use that API endpoint.
3. In the Open WebUI API settings, add a custom header (e.g. X-API-Key: test-key).
4. Go to main page, try to choose the new added model and see nothing
### Logs & Screenshots
<img width="237" height="272" alt="Image" src="https://github.com/user-attachments/assets/5bdcecf6-e056-4e1c-bb94-176acdce97d3" />
### Additional Information
Hi, I encountered an issue when using custom headers together with Kong Key Authentication.
I usually deploy my OpenAI-format LLM API behind Kong, and require users to include a custom key–value pair in the request headers for authentication.
This allows us to track usage and control traffic per user.
Recently, I noticed that Open WebUI v0.6.33 introduced a feature to add custom headers when configuring OpenAI-compatible APIs.
I was hoping this would solve my previous issue — that Open WebUI couldn’t include my custom Kong key in the headers.
However, after testing, I still receive a 401 Unauthorized from Kong.
It seems the custom key–value pair is not actually being sent in the request headers, because the request to /v1/models fails authentication on Kong’s side.
I reviewed the code [here](https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/openai.py#L552)
, and it looks like custom headers should indeed be merged into the request before calling /v1/models.
So I’m wondering — is there something preventing these custom headers from being applied in practice?
🧠 Summary
Kong behind Open WebUI uses Key Authentication
Added custom header in Open WebUI (v0.6.33)
Request to /v1/models still returns 401 Unauthorized
Expected: the custom key header should be included and authenticated correctly
💬 Question
Is there a known limitation or middleware stripping out custom headers before the request is sent?
Or is there a specific configuration required for the custom headers to take effect?
GiteaMirror
added the bug label 2026-05-13 05:32:22 -05:00
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 @Stanleyluuuu on GitHub (Oct 22, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18509
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.34
Ollama Version (if applicable)
No response
Operating System
Rocky 9.6
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When a custom header is defined in Open WebUI (e.g. X-API-Key: ),
the header should be included in the outgoing request to the configured API (e.g. /v1/models).
Kong should validate the key and return a successful 200 response.
Actual Behavior
Even after setting the custom header in Open WebUI v0.6.33,
requests to the API (e.g. /v1/models) return 401 Unauthorized from Kong.
Logs on the Kong side show that the expected authentication header is missing,
meaning the key–value pair wasn’t sent in the request.
Steps to Reproduce
Logs & Screenshots
Additional Information
Hi, I encountered an issue when using custom headers together with Kong Key Authentication.
I usually deploy my OpenAI-format LLM API behind Kong, and require users to include a custom key–value pair in the request headers for authentication.
This allows us to track usage and control traffic per user.
Recently, I noticed that Open WebUI v0.6.33 introduced a feature to add custom headers when configuring OpenAI-compatible APIs.
I was hoping this would solve my previous issue — that Open WebUI couldn’t include my custom Kong key in the headers.
However, after testing, I still receive a 401 Unauthorized from Kong.
It seems the custom key–value pair is not actually being sent in the request headers, because the request to /v1/models fails authentication on Kong’s side.
I reviewed the code here
, and it looks like custom headers should indeed be merged into the request before calling /v1/models.
So I’m wondering — is there something preventing these custom headers from being applied in practice?
🧠 Summary
Kong behind Open WebUI uses Key Authentication
Added custom header in Open WebUI (v0.6.33)
Request to /v1/models still returns 401 Unauthorized
Expected: the custom key header should be included and authenticated correctly
💬 Question
Is there a known limitation or middleware stripping out custom headers before the request is sent?
Or is there a specific configuration required for the custom headers to take effect?