I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.
Installation Method
Other
Open WebUI Version
0.9.1 (LXC Container)
Ollama Version (if applicable)
No response
Operating System
Debian 13
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
OpenAI connector should connect to OpenAI.
Actual Behavior
Presents a "Network Error" after upgrade to 0.9.1.
Steps to Reproduce
Go in to Admin -> connectors and test connection with an OpenAI endpoint.
Logs & Screenshots
I am on the LXC container from community scripts. I have turned on debugging but nothing is reported to do with this issue.
Additional Information
I have two snapshots of the Open Web UI instance. Moving back to the old version allows OpenAI connector to work. I have also tested the OpenAI API with other applications (curl) and it is ok. Moving back to 0.9.1 shows the problem.
I have tried deleting the connector and re-creating.
All other (Anthropic and Google API) endpoints are ok.
Originally created by @carlvon1800 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23935
### 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 have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Other
### Open WebUI Version
0.9.1 (LXC Container)
### Ollama Version (if applicable)
_No response_
### Operating System
Debian 13
### 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
OpenAI connector should connect to OpenAI.
### Actual Behavior
Presents a "Network Error" after upgrade to 0.9.1.
### Steps to Reproduce
1. Go in to Admin -> connectors and test connection with an OpenAI endpoint.
### Logs & Screenshots
I am on the LXC container from community scripts. I have turned on debugging but nothing is reported to do with this issue.
### Additional Information
I have two snapshots of the Open Web UI instance. Moving back to the old version allows OpenAI connector to work. I have also tested the OpenAI API with other applications (curl) and it is ok. Moving back to 0.9.1 shows the problem.
I have tried deleting the connector and re-creating.
All other (Anthropic and Google API) endpoints are ok.
GiteaMirror
added the bug label 2026-04-25 09:48:20 -05:00
no cannot reproduce; works here. Likely network issue on your end.
<!-- gh-comment-id:4288600376 -->
@Classic298 commented on GitHub (Apr 21, 2026):
let me test....
no cannot reproduce; works here. Likely network issue on your end.
<!-- gh-comment-id:4288980077 -->
@carlvon1800 commented on GitHub (Apr 21, 2026):
Resolved as a dependency issue with the LXC container from Community Scripts.
If using: https://community-scripts.org/scripts/openwebui
uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python
sudo systemctl restart open-webui
<!-- gh-comment-id:4301927223 -->
@mascalx commented on GitHub (Apr 23, 2026):
> Resolved as a dependency issue with the LXC container from Community Scripts.
>
> If using: https://community-scripts.org/scripts/openwebui
>
> uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python sudo systemctl restart open-webui
Same issue. Solved using aiohttp v3.9.5
This is not a solution
When running uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python OIDC stops working correctly
<!-- gh-comment-id:4302203708 -->
@Externalnet commented on GitHub (Apr 23, 2026):
This is not a solution
When running uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python OIDC stops working correctly
third party install scripts are not supported by us @carlvon1800
@Classic298 our script installs Open WebUI via uv as per your documentation. Also, this is not how a issue is supposed to be handled. Its a one line install in bash. Not really sure how you're not supporting your official way of installing? Really strange.
<!-- gh-comment-id:4302416109 -->
@tremor021 commented on GitHub (Apr 23, 2026):
> third party install scripts are not supported by us [@carlvon1800](https://github.com/carlvon1800)
@Classic298 our script installs Open WebUI via `uv` as per your documentation. Also, this is not how a issue is supposed to be handled. Its a one line install in bash. Not really sure how you're not supporting your official way of installing? Really strange.
<!-- gh-comment-id:4302678007 -->
@Externalnet commented on GitHub (Apr 23, 2026):
Please reopen this ticket. Because this issue seems at Open-WebUI and not Proxmox Community scripts : https://github.com/community-scripts/ProxmoxVE/issues/13952
Worth clarifying why I'm not reopening this (for now): our Docker image pins Python 3.11.14 specifically because 3.12 has known compatibility quirks that surface in async/SSL paths, exactly the shape of what's being reported here (OpenAI fails, Anthropic/Google work, aiohttp downgrade changes the symptom).
Our docs specifically recommend uvx --python 3.11 for the same reason. The community script uses --python 3.12, which our pyproject permits but which we don't recommend for production and don't ship ourselves.
pyproject permits 3.12 because it mostly works, but we've learned there are edge cases we don't catch in CI, which is why we pin 3.11 in Docker and therefore recommend it in docs.
@tremor021 if you switch the script to --python 3.11 I'd expect this to resolve, and it would align with our documented install path. Happy to take another look if someone reproduces on a clean 3.11 uv install.
And RE: install scripts: Admittedly I did not take a look at your script specifically or what it does; Please do not misread my dismissal of third party install scripts specific to yours, but in general. We have seen many many weird third party install scripts that installed weird custom dependencies or made unsupported modifications and that obviously breaks things - and instead of reporting it to the script author these users usually come to us.
<!-- gh-comment-id:4303214394 -->
@Classic298 commented on GitHub (Apr 23, 2026):
Worth clarifying why I'm not reopening this (for now): our Docker image pins Python 3.11.14 specifically because 3.12 has known compatibility quirks that surface in async/SSL paths, exactly the shape of what's being reported here (OpenAI fails, Anthropic/Google work, aiohttp downgrade changes the symptom).
**Our docs specifically recommend uvx --python 3.11 for the same reason**. The community script uses --python 3.12, which our pyproject permits but which we don't recommend for production **and don't ship ourselves.**
pyproject permits 3.12 because it mostly works, but we've learned there are edge cases we don't catch in CI, which is why we pin 3.11 in Docker and therefore recommend it in docs.
@tremor021 if you switch the script to --python 3.11 I'd expect this to resolve, and it would align with our documented install path. Happy to take another look if someone reproduces on a clean 3.11 uv install.
And RE: install scripts: Admittedly I did not take a look at your script specifically or what it does; Please do not misread my dismissal of third party install scripts specific to yours, but in general. We have seen many many weird third party install scripts that installed weird custom dependencies or made unsupported modifications and that obviously breaks things - and instead of reporting it to the script author these users usually come to us.
Thank you very much for the explanation, I will ask the Proxmox Community Script makers to downgrade to 3.11
<!-- gh-comment-id:4303432461 -->
@Externalnet commented on GitHub (Apr 23, 2026):
Thank you very much for the explanation, I will ask the Proxmox Community Script makers to downgrade to 3.11
<!-- gh-comment-id:4303498980 -->
@Externalnet commented on GitHub (Apr 23, 2026):
Please comment on this https://github.com/community-scripts/ProxmoxVE/issues/13952#issuecomment-4303479257 It would be nice if this can be solved and better organised/communicated in the future
I downgraded and have the same issue with the OpenAI API with Python 3.11
<!-- gh-comment-id:4303522027 -->
@Externalnet commented on GitHub (Apr 23, 2026):
I downgraded and have the same issue with the OpenAI API with Python 3.11
I just tried to reproduce using pip - in 3.11 and 3.12 locally.. both works - i still cannot reproduce a connection verification error.
<!-- gh-comment-id:4303591978 -->
@Classic298 commented on GitHub (Apr 23, 2026):
I just tried to reproduce using pip - in 3.11 and 3.12 locally.. both works - i still cannot reproduce a connection verification error.
@silentoplayz do you have uv installed? I cant check anymore for now
Negative. It's not installed on my machine and hasn't been since Windows 11. 😅
<!-- gh-comment-id:4303706857 -->
@silentoplayz commented on GitHub (Apr 23, 2026):
> @silentoplayz do you have uv installed? I cant check anymore for now
Negative. It's not installed on my machine and hasn't been since Windows 11. 😅
<!-- gh-comment-id:4303734245 -->
@Externalnet commented on GitHub (Apr 23, 2026):
> i still cannot reproduce a connection verification
Be aware it is an OpenAI compatible API connection to Groq https://api.groq.com/openai/v1 and not OpenAI
It worked fine in Open WebUI ‧ v0.8.12
the original issue was about OpenAI connectivity verification. I do not see anything about Groq mentioned here in the issue. I also don't have a Groq account so I can't check since I receive an error for missing authentication when I do. but @silentoplayz i think has, can you cross check on your deployment even if it isn't uv?
<!-- gh-comment-id:4303753517 -->
@Classic298 commented on GitHub (Apr 23, 2026):
the original issue was about OpenAI connectivity verification. I do not see anything about Groq mentioned here in the issue. I also don't have a Groq account so I can't check since I receive an error for missing authentication when I do. but @silentoplayz i think has, can you cross check on your deployment even if it isn't uv?
You are correct, but I have exact the same issue but with Groq wich is an OpenAI compaitbel API
<!-- gh-comment-id:4303765970 -->
@Externalnet commented on GitHub (Apr 23, 2026):
You are correct, but I have exact the same issue but with Groq wich is an OpenAI compaitbel API
This resolves the issue. Is there a reason brotlicffi is not a dependency?
<!-- gh-comment-id:4303803694 -->
@tremor021 commented on GitHub (Apr 23, 2026):
@Classic298 there is definitely some kinks while running this via uv:
`uvx --python 3.11 open-webui@latest serve`
installs it fine, runs on port 8080, but the network issue mentioned persists because of this:
`Apr 23 12:39:14 openwebui uvx[8745]: Can not decode content-encoding: br`
So, the command i used is:
`uvx --python 3.11 --with brotlicffi open-webui@latest serve`
This resolves the issue. Is there a reason `brotlicffi` is not a dependency?
<img width="1629" height="418" alt="Image" src="https://github.com/user-attachments/assets/67737059-0d82-47aa-8071-5f28a1fe7c0d" />
No there's not a reason why it's not a dependency. We have seen quite a few cases in the past where the pip depdency resolver resolves all dependencies of the packages we depend on correctly and installs them - and where uv doesn't.
Uv, for some unknown reason, often requires explicit dependency lists even though open webui doesn't even use that dependency but only another package we use uses it.
Reopening for @tjbck to triage the dependency
<!-- gh-comment-id:4303946584 -->
@Classic298 commented on GitHub (Apr 23, 2026):
No there's not a reason why it's not a dependency. We have seen quite a few cases in the past where the pip depdency resolver resolves all dependencies of the packages we depend on correctly and installs them - and where uv doesn't.
Uv, for some unknown reason, often requires explicit dependency lists even though open webui doesn't even use that dependency but only another package we use uses it.
Reopening for @tjbck to triage the dependency
If adding brotlicffi as dependency solves all the issues, then downgrading our script to python 3.11 shouldn't be a problem.
The only reason we have it on python 3.12 is because of Debian Trixie iirc or some dependency issue we experienced.
<!-- gh-comment-id:4303972846 -->
@tremor021 commented on GitHub (Apr 23, 2026):
If adding `brotlicffi` as dependency solves all the issues, then downgrading our script to python 3.11 shouldn't be a problem.
The only reason we have it on python 3.12 is because of Debian Trixie iirc or some dependency issue we experienced.
If adding brotlicffi as dependency solves all the issues, then downgrading our script to python 3.11 shouldn't be a problem.
The only reason we have it on python 3.12 is because of Debian Trixie iirc or some dependency issue we experienced.
thats the reason for uv, you can use 3.9 - 3.15 with uv. Python 3.12 is only the build-in Python Version, but uv is the "Master" in this case.
<!-- gh-comment-id:4304035787 -->
@MickLesk commented on GitHub (Apr 23, 2026):
> If adding `brotlicffi` as dependency solves all the issues, then downgrading our script to python 3.11 shouldn't be a problem.
>
> The only reason we have it on python 3.12 is because of Debian Trixie iirc or some dependency issue we experienced.
thats the reason for uv, you can use 3.9 - 3.15 with uv. Python 3.12 is only the build-in Python Version, but uv is the "Master" in this case.
I thought I'd weigh in: I'm having this same issue on a fresh install of the latest version (v0.9.1) directly from pip install on debian 13, using a venv with python 3.11.11. Previous version connected to openAi just fine. New install can't connect, keeps throwing Can not decode content-encoding: br exactly as described above. pip shows brotlicffi is not installed.
Edit: installing brotlicffi fixed the problem, as mentioned by @tremor021.
<!-- gh-comment-id:4311672181 -->
@DrMechanica commented on GitHub (Apr 24, 2026):
I thought I'd weigh in: I'm having this same issue on a fresh install of the latest version (v0.9.1) directly from `pip install` on debian 13, using a venv with python 3.11.11. Previous version connected to openAi just fine. New install can't connect, keeps throwing `Can not decode content-encoding: br` exactly as described above. pip shows `brotlicffi` is not installed.
Edit: installing `brotlicffi` fixed the problem, as mentioned by @tremor021.
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 @carlvon1800 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23935
Check Existing Issues
Installation Method
Other
Open WebUI Version
0.9.1 (LXC Container)
Ollama Version (if applicable)
No response
Operating System
Debian 13
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
OpenAI connector should connect to OpenAI.
Actual Behavior
Presents a "Network Error" after upgrade to 0.9.1.
Steps to Reproduce
Logs & Screenshots
I am on the LXC container from community scripts. I have turned on debugging but nothing is reported to do with this issue.
Additional Information
I have two snapshots of the Open Web UI instance. Moving back to the old version allows OpenAI connector to work. I have also tested the OpenAI API with other applications (curl) and it is ok. Moving back to 0.9.1 shows the problem.
I have tried deleting the connector and re-creating.
All other (Anthropic and Google API) endpoints are ok.
@carlvon1800 commented on GitHub (Apr 21, 2026):
https://api.openai.com/v1 - Current endpoint setting.
@Classic298 commented on GitHub (Apr 21, 2026):
let me test....
no cannot reproduce; works here. Likely network issue on your end.
@Classic298 commented on GitHub (Apr 21, 2026):
@carlvon1800 commented on GitHub (Apr 21, 2026):
Resolved as a dependency issue with the LXC container from Community Scripts.
If using: https://community-scripts.org/scripts/openwebui
uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python
sudo systemctl restart open-webui
@Classic298 commented on GitHub (Apr 21, 2026):
third party install scripts are not supported by us @carlvon1800
@mascalx commented on GitHub (Apr 23, 2026):
Same issue. Solved using aiohttp v3.9.5
@Externalnet commented on GitHub (Apr 23, 2026):
This is not a solution
When running uv pip install "aiohttp==3.9.5" --python ~/.local/share/uv/tools/open-webui/bin/python OIDC stops working correctly
@tremor021 commented on GitHub (Apr 23, 2026):
@Classic298 our script installs Open WebUI via
uvas per your documentation. Also, this is not how a issue is supposed to be handled. Its a one line install in bash. Not really sure how you're not supporting your official way of installing? Really strange.@Externalnet commented on GitHub (Apr 23, 2026):
Please reopen this ticket. Because this issue seems at Open-WebUI and not Proxmox Community scripts : https://github.com/community-scripts/ProxmoxVE/issues/13952
@Classic298 commented on GitHub (Apr 23, 2026):
Worth clarifying why I'm not reopening this (for now): our Docker image pins Python 3.11.14 specifically because 3.12 has known compatibility quirks that surface in async/SSL paths, exactly the shape of what's being reported here (OpenAI fails, Anthropic/Google work, aiohttp downgrade changes the symptom).
Our docs specifically recommend uvx --python 3.11 for the same reason. The community script uses --python 3.12, which our pyproject permits but which we don't recommend for production and don't ship ourselves.
pyproject permits 3.12 because it mostly works, but we've learned there are edge cases we don't catch in CI, which is why we pin 3.11 in Docker and therefore recommend it in docs.
@tremor021 if you switch the script to --python 3.11 I'd expect this to resolve, and it would align with our documented install path. Happy to take another look if someone reproduces on a clean 3.11 uv install.
And RE: install scripts: Admittedly I did not take a look at your script specifically or what it does; Please do not misread my dismissal of third party install scripts specific to yours, but in general. We have seen many many weird third party install scripts that installed weird custom dependencies or made unsupported modifications and that obviously breaks things - and instead of reporting it to the script author these users usually come to us.
@Externalnet commented on GitHub (Apr 23, 2026):
Thank you very much for the explanation, I will ask the Proxmox Community Script makers to downgrade to 3.11
@Externalnet commented on GitHub (Apr 23, 2026):
Please comment on this https://github.com/community-scripts/ProxmoxVE/issues/13952#issuecomment-4303479257 It would be nice if this can be solved and better organised/communicated in the future
@Externalnet commented on GitHub (Apr 23, 2026):
I downgraded and have the same issue with the OpenAI API with Python 3.11
@Classic298 commented on GitHub (Apr 23, 2026):
I just tried to reproduce using pip - in 3.11 and 3.12 locally.. both works - i still cannot reproduce a connection verification error.
@Classic298 commented on GitHub (Apr 23, 2026):
@silentoplayz do you have uv installed? I cant check anymore for now
@silentoplayz commented on GitHub (Apr 23, 2026):
Negative. It's not installed on my machine and hasn't been since Windows 11. 😅
@Externalnet commented on GitHub (Apr 23, 2026):
Be aware it is an OpenAI compatible API connection to Groq https://api.groq.com/openai/v1 and not OpenAI
It worked fine in Open WebUI ‧ v0.8.12
@Classic298 commented on GitHub (Apr 23, 2026):
the original issue was about OpenAI connectivity verification. I do not see anything about Groq mentioned here in the issue. I also don't have a Groq account so I can't check since I receive an error for missing authentication when I do. but @silentoplayz i think has, can you cross check on your deployment even if it isn't uv?
@Externalnet commented on GitHub (Apr 23, 2026):
You are correct, but I have exact the same issue but with Groq wich is an OpenAI compaitbel API
@tremor021 commented on GitHub (Apr 23, 2026):
@Classic298 there is definitely some kinks while running this via uv:
uvx --python 3.11 open-webui@latest serveinstalls it fine, runs on port 8080, but the network issue mentioned persists because of this:
Apr 23 12:39:14 openwebui uvx[8745]: Can not decode content-encoding: brSo, the command i used is:
uvx --python 3.11 --with brotlicffi open-webui@latest serveThis resolves the issue. Is there a reason
brotlicffiis not a dependency?@Classic298 commented on GitHub (Apr 23, 2026):
No there's not a reason why it's not a dependency. We have seen quite a few cases in the past where the pip depdency resolver resolves all dependencies of the packages we depend on correctly and installs them - and where uv doesn't.
Uv, for some unknown reason, often requires explicit dependency lists even though open webui doesn't even use that dependency but only another package we use uses it.
Reopening for @tjbck to triage the dependency
@tremor021 commented on GitHub (Apr 23, 2026):
If adding
brotlicffias dependency solves all the issues, then downgrading our script to python 3.11 shouldn't be a problem.The only reason we have it on python 3.12 is because of Debian Trixie iirc or some dependency issue we experienced.
@Externalnet commented on GitHub (Apr 23, 2026):
If I can help with testing let me know
@MickLesk commented on GitHub (Apr 23, 2026):
thats the reason for uv, you can use 3.9 - 3.15 with uv. Python 3.12 is only the build-in Python Version, but uv is the "Master" in this case.
@DrMechanica commented on GitHub (Apr 24, 2026):
I thought I'd weigh in: I'm having this same issue on a fresh install of the latest version (v0.9.1) directly from
pip installon debian 13, using a venv with python 3.11.11. Previous version connected to openAi just fine. New install can't connect, keeps throwingCan not decode content-encoding: brexactly as described above. pip showsbrotlicffiis not installed.Edit: installing
brotlicffifixed the problem, as mentioned by @tremor021.