github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-22 17:42:18 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24872] issue: Azure OpenAI provider fails on custom URLs (verify error, no chat response) #123729

New Issue
Closed
opened 2026-05-21 03:12:27 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-21 03:12:27 -05:00
Owner
Copy Link

Originally created by @sergey-zinchenko on GitHub (May 18, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24872

Check Existing Issues

  • 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

Docker

Open WebUI Version

v0.9.5

Ollama Version (if applicable)

No response

Operating System

Windows

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 adding a new Azure OpenAI connection whose base URL uses a custom domain (not *.openai.azure.com or *.cognitive.microsoft.com — e.g. enterprise gateway, APIM, DIAL), and filling in endpoint URL, API key, API version, and deployment names as for a normal Azure setup:

  1. The connection saves with Azure settings applied.
  2. Verify connection shows a success message
  3. Sending a message in chat returns a normal assistant reply.

Actual Behavior

When adding a new Azure OpenAI connection with a non-standard domain (custom hostname without azure. / cognitive.microsoft.com), using the same fields (URL, API key, API version, deployment names):

  1. The connection saves without error; the form looks correct.
  2. Verify connection fails with “Network error” (or similar).
  3. Chat: the user sends a message → no assistant reply.

Steps to Reproduce

  1. Start Open WebUI and sign in as admin.
  2. Open Admin Panel → Settings → Connections → OpenAI → Add connection.
  3. Configure:
    • URL: https://<your-gateway-host> (base URL only; no deployment path)
    • Provider: Azure OpenAI
    • API Key: your key
    • API Version: your version
    • Model IDs: your deployment name(s)
  4. Click Save.
  5. Click Verify.
  6. Open New chat, select the model from this connection, send: Hello.

Example:
URL https://llms.mycompany.com · API version 2025-01-01-preview · Model ID qwen3-vl-235b-a22b-instruct

Logs & Screenshots

Image

docker-logs.txt

Additional Information

This flow is meant to cover Azure OpenAI on custom base URLs without relying on hostname auto-detection — the same scenario as #17121 (accept custom URL for Azure OpenAI): gateways such as Azure APIM, or private endpoints whose host does not contain azure. or cognitive.microsoft.com.

The product already exposes that via the Azure OpenAI entry in the connection Provider dropdown (AddConnectionModal.svelte), plus Azure-only fields (API version, deployment Model IDs, api-key on the backend). So the Provider → Azure OpenAI path is the intended manual “this is Azure” switch described in #17121 — not a missing feature, but a broken wiring between UI and backend.

How Azure mode is decided today

UI (AddConnectionModal.svelte): reactive azure is true when:

  • provider === 'azure', or
  • URL contains azure. / cognitive.microsoft.com and Provider is Default (empty).

On save / verify, the config was built as:

...(provider ? { provider } : azure ? { azure: true } : {})

So if the user picks Azure OpenAI, only provider: "azure" is stored — azure: true is omitted.
If the user leaves Provider Default but the URL matches azure.*, only azure: true is stored (no provider field).

Backend (routers/openai.py): routing uses api_config.get('azure', False) only (before fix), for example:

  • Verify: GET {url}/openai/models?api-version=... + api-key
  • Chat: POST {url}/openai/deployments/{model}/chat/completions?api-version=... + api-key

The bug

User action Saved config Backend sees Result
Provider = Azure OpenAI, custom host provider: "azure", api_version, model_ids azure: false Azure UI, non-Azure HTTP → verify / chat fail
Provider = Default, URL *.openai.azure.com azure: true Azure HTTP Works
Provider = Azure OpenAI, URL *.openai.azure.com provider: "azure" only (no azure: true) azure: false Can fail even on real Azure hosts

So the regression is: the Provider control and the azure flag are out of sync — the form shows Azure settings, but the proxy does not enable Azure URL/auth unless the hostname triggers auto-detection.

Why users see “Network error” and no chat reply

  1. Verify calls {url}/models instead of {url}/openai/models → connection check fails → UI toast (Network error).

Relation to other issues

  • #17121: This fix makes the existing Azure OpenAI provider behave as the requested toggle for custom URLs.
  • #24761: Separate topic (Azure AI Foundry /openai/v1 + Entra ID).
Originally created by @sergey-zinchenko on GitHub (May 18, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24872 ### 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 Docker ### Open WebUI Version v0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System Windows ### 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 adding a new **Azure OpenAI** connection whose **base URL uses a custom domain** (not `*.openai.azure.com` or `*.cognitive.microsoft.com` — e.g. enterprise gateway, APIM, DIAL), and filling in endpoint URL, API key, API version, and deployment names as for a normal Azure setup: 1. The connection saves with Azure settings applied. 2. **Verify connection** shows a **success** message 4. Sending a message in chat returns a **normal assistant reply**. ### Actual Behavior When adding a new **Azure OpenAI** connection with a **non-standard domain** (custom hostname without `azure.` / `cognitive.microsoft.com`), using the same fields (URL, API key, API version, deployment names): 1. The connection **saves** without error; the form looks correct. 2. **Verify connection** fails with **“Network error”** (or similar). 4. **Chat:** the user sends a message → **no assistant reply**. ### Steps to Reproduce 1. Start Open WebUI and sign in as **admin**. 2. Open **Admin Panel** → **Settings** → **Connections** → **OpenAI** → **Add connection**. 3. Configure: - **URL:** `https://<your-gateway-host>` *(base URL only; no deployment path)* - **Provider:** **Azure OpenAI** - **API Key:** your key - **API Version:** your version - **Model IDs:** your deployment name(s) 4. Click **Save**. 5. Click **Verify**. 6. Open **New chat**, select the model from this connection, send: `Hello`. **Example:** URL `https://llms.mycompany.com` · API version `2025-01-01-preview` · Model ID `qwen3-vl-235b-a22b-instruct` ### Logs & Screenshots <img width="2984" height="1482" alt="Image" src="https://github.com/user-attachments/assets/185aaec7-d017-4dc0-b122-c06fdccabfa7" /> [docker-logs.txt](https://github.com/user-attachments/files/27964065/docker-logs.txt) ### Additional Information This flow is meant to cover **Azure OpenAI on custom base URLs** without relying on hostname auto-detection — the same scenario as [#17121](https://github.com/open-webui/open-webui/issues/17121) (*accept custom URL for Azure OpenAI*): gateways such as **Azure APIM**, or private endpoints whose host does **not** contain `azure.` or `cognitive.microsoft.com`. The product already exposes that via the **Azure OpenAI** entry in the connection **Provider** dropdown (`AddConnectionModal.svelte`), plus Azure-only fields (API version, deployment **Model IDs**, `api-key` on the backend). So the **Provider → Azure OpenAI** path is the intended manual “this is Azure” switch described in #17121 — not a missing feature, but a **broken wiring** between UI and backend. ### How Azure mode is decided today **UI (`AddConnectionModal.svelte`):** reactive `azure` is true when: - `provider === 'azure'`, **or** - URL contains `azure.` / `cognitive.microsoft.com` and Provider is **Default** (empty). **On save / verify**, the config was built as: ```js ...(provider ? { provider } : azure ? { azure: true } : {}) ``` So if the user picks **Azure OpenAI**, only `provider: "azure"` is stored — **`azure: true` is omitted**. If the user leaves Provider **Default** but the URL matches `azure.*`, only `azure: true` is stored (no `provider` field). **Backend (`routers/openai.py`):** routing uses `api_config.get('azure', False)` only (before fix), for example: - Verify: `GET {url}/openai/models?api-version=...` + `api-key` - Chat: `POST {url}/openai/deployments/{model}/chat/completions?api-version=...` + `api-key` ### The bug | User action | Saved config | Backend sees | Result | |-------------|--------------|--------------|--------| | Provider = **Azure OpenAI**, custom host | `provider: "azure"`, `api_version`, `model_ids` | `azure: false` | Azure UI, **non-Azure HTTP** → verify / chat fail | | Provider = **Default**, URL `*.openai.azure.com` | `azure: true` | Azure HTTP | Works | | Provider = **Azure OpenAI**, URL `*.openai.azure.com` | `provider: "azure"` only (no `azure: true`) | `azure: false` | Can fail even on real Azure hosts | So the regression is: **the Provider control and the `azure` flag are out of sync** — the form shows Azure settings, but the proxy does not enable Azure URL/auth unless the hostname triggers auto-detection. ### Why users see “Network error” and no chat reply 1. **Verify** calls `{url}/models` instead of `{url}/openai/models` → connection check fails → UI toast (**Network error**). ### Relation to other issues - **[#17121](https://github.com/open-webui/open-webui/issues/17121):** This fix makes the existing **Azure OpenAI** provider behave as the requested toggle for custom URLs. - **[#24761](https://github.com/open-webui/open-webui/issues/24761):** Separate topic (Azure AI Foundry **`/openai/v1`** + Entra ID).
GiteaMirror added the bug label 2026-05-21 03:12:27 -05:00
GiteaMirror commented 2026-05-21 03:12:30 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 18, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #17121 feat: accept custom url for Azure Open AI
    This is the direct precursor feature request for manually supporting Azure OpenAI with custom base URLs / APIM gateways. The new issue appears to be the broken implementation of that requested behavior in the Azure OpenAI provider path.
    by fugabri97

  2. 🟣 #18075 issue: Azure OpenAI URL not working
    This issue reports Azure OpenAI URL handling failures and verify/model lookup errors when the base URL/version formatting is off. It is closely related to the same Azure connection wiring and custom URL/API-version behavior.
    by attilaolah · bug

  3. 🟣 #24190 issue: Azure OpenAI - Open WebUI: Server Connection Error
    This bug involves Azure OpenAI connections in Open WebUI returning a server connection error after the model is used. While the symptoms differ, it is another Azure OpenAI provider failure path and may share the same request-routing/authentication handling.
    by burkhat · bug

  4. 🟣 #24761 Issue #24761
    Although this one focuses on Azure AI Foundry and Entra ID, it is the most recent open Azure OpenAI-related issue and covers Azure endpoint/auth plumbing in the same router area. It may overlap if the custom URL flow is also hitting the newer Azure OpenAI endpoint logic.
    by unknown

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4478727377 --> @owui-terminator[bot] commented on GitHub (May 18, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#17121](https://github.com/open-webui/open-webui/issues/17121) **feat: accept custom url for Azure Open AI** *This is the direct precursor feature request for manually supporting Azure OpenAI with custom base URLs / APIM gateways. The new issue appears to be the broken implementation of that requested behavior in the Azure OpenAI provider path.* *by fugabri97* 2. 🟣 [#18075](https://github.com/open-webui/open-webui/issues/18075) **issue: Azure OpenAI URL not working** *This issue reports Azure OpenAI URL handling failures and verify/model lookup errors when the base URL/version formatting is off. It is closely related to the same Azure connection wiring and custom URL/API-version behavior.* *by attilaolah · `bug`* 3. 🟣 [#24190](https://github.com/open-webui/open-webui/issues/24190) **issue: Azure OpenAI - Open WebUI: Server Connection Error** *This bug involves Azure OpenAI connections in Open WebUI returning a server connection error after the model is used. While the symptoms differ, it is another Azure OpenAI provider failure path and may share the same request-routing/authentication handling.* *by burkhat · `bug`* 4. 🟣 [#24761](https://github.com/open-webui/open-webui/issues/24761) **Issue #24761** *Although this one focuses on Azure AI Foundry and Entra ID, it is the most recent open Azure OpenAI-related issue and covers Azure endpoint/auth plumbing in the same router area. It may overlap if the custom URL flow is also hitting the newer Azure OpenAI endpoint logic.* *by unknown* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-21 03:12:31 -05:00
Author
Owner
Copy Link

@sergey-zinchenko commented on GitHub (May 20, 2026):

Addressed in dev

<!-- gh-comment-id:4496060152 --> @sergey-zinchenko commented on GitHub (May 20, 2026): Addressed in dev
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#123729
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?