[GH-ISSUE #15486] issue: Static assets and API requests fail when Open WebUI is hosted on a subpath #17576

New Issue

GiteaMirror · 2026-04-19T23:22:23-05:00

GiteaMirror commented

2026-04-19 23:22:23 -05:00

Originally created by @brianredbeard on GitHub (Jul 2, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15486

Check Existing Issues

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

Installation Method

Git Clone

Open WebUI Version

59ba21bdf

Ollama Version (if applicable)

No response

Operating System

N/A

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 Open WebUI is deployed behind a reverse proxy and served from a subpath (e.g., https://example.com/webui/), the application fails to load. This is due to two related issues:

1 Static asset URLs in src/app.html are hardcoded as root-relative paths, causing them to be requested from the domain root instead of the application's subpath.
2 The base URL for API requests, defined in src/lib/constants.ts, does not correctly resolve the subpath in a production environment. This affects all API calls and SvelteKit's ability to load its own JavaScript chunks.

The combination of these issues results in numerous 404 Not Found and NS_ERROR_CORRUPTED_CONTENT errors, preventing the application from initializing.

Actual Behavior

The application is unusable and fails to render. The browser's network inspector shows multiple failed requests:

• 404 Not Found errors for static assets like favicon.png and splash.png.
• NS_ERROR_CORRUPTED_CONTENT for SvelteKit's JavaScript chunks, which are incorrectly requested from the root /_app/ directory instead of the subpath.

Steps to Reproduce

1 Configure Open WebUI to be served from a subpath using a reverse proxy (e.g., /webui). (e.g. WEBUI_API_BASE_URL, WEBUI_BASE_URL)
2 Build and run the application in production mode.
3 Navigate to the application's URL (https://example.com/webui/).
4 Open the browser's developer tools and observe the Network tab.

Logs & Screenshots

Additional Information

Root Cause Analysis & Code Citations

1 Hardcoded Static Asset Paths in src/app.html
The primary HTML template at src/app.html uses root-relative paths for all static assets. These paths do not account for the application's base path when deployed on a subpath.
Code Citation (src/app.html):

   <link rel="icon" type="image/png" href="/static/favicon.png" />
   <link rel="stylesheet" href="/static/custom.css" />
   <script src="/static/loader.js" defer></script>
   ...
   <img
       id="logo"
       ...
       src="/static/splash.png"
   />

These paths should be prefixed with SvelteKit's base path variable, %sveltekit.paths.base%, to ensure they are resolved correctly relative to the deployment subpath.
2 Incorrect Base URL Construction in src/lib/constants.ts
The WEBUI_BASE_URL constant, which serves as the foundation for all API endpoints, is not correctly configured to use SvelteKit's base path in a production environment. The existing logic resolves to an empty string for the base path.
Code Citation (illustrating the faulty logic in src/lib/constants.ts): The WEBUI_BASE_URL logic for a production browser environment effectively becomes '' instead of incorporating the subpath provided by SvelteKit's $app/paths. This incorrect base
URL is then used to construct WEBUI_API_BASE_URL, causing all API requests to be sent to the wrong path. Furthermore, this misconfiguration prevents SvelteKit from correctly locating its own JavaScript modules, as seen by the failing requests to
/_app/immutable/....

Originally created by @brianredbeard on GitHub (Jul 2, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/15486 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version 59ba21bdf ### Ollama Version (if applicable) _No response_ ### Operating System N/A ### 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 Open WebUI is deployed behind a reverse proxy and served from a subpath (e.g., https://example.com/webui/), the application fails to load. This is due to two related issues: 1 Static asset URLs in src/app.html are hardcoded as root-relative paths, causing them to be requested from the domain root instead of the application's subpath. 2 The base URL for API requests, defined in src/lib/constants.ts, does not correctly resolve the subpath in a production environment. This affects all API calls and SvelteKit's ability to load its own JavaScript chunks. The combination of these issues results in numerous 404 Not Found and NS_ERROR_CORRUPTED_CONTENT errors, preventing the application from initializing. ### Actual Behavior The application is unusable and fails to render. The browser's network inspector shows multiple failed requests: • 404 Not Found errors for static assets like favicon.png and splash.png. • NS_ERROR_CORRUPTED_CONTENT for SvelteKit's JavaScript chunks, which are incorrectly requested from the root /_app/ directory instead of the subpath. ### Steps to Reproduce 1 Configure Open WebUI to be served from a subpath using a reverse proxy (e.g., /webui). (e.g. WEBUI_API_BASE_URL, WEBUI_BASE_URL) 2 Build and run the application in production mode. 3 Navigate to the application's URL (https://example.com/webui/). 4 Open the browser's developer tools and observe the Network tab. ### Logs & Screenshots ![Image](https://github.com/user-attachments/assets/5800e480-c33c-4aa4-9259-cd187c20738e) ### Additional Information Root Cause Analysis & Code Citations 1 Hardcoded Static Asset Paths in src/app.html The primary HTML template at src/app.html uses root-relative paths for all static assets. These paths do not account for the application's base path when deployed on a subpath. Code Citation ([src/app.html](https://github.com/open-webui/open-webui/blob/59ba21bdf8eb791a412db869a13ff76c6135b651/src/app.html#L26)): ``` <link rel="icon" type="image/png" href="/static/favicon.png" /> <link rel="stylesheet" href="/static/custom.css" /> <script src="/static/loader.js" defer></script> ... <img id="logo" ... src="/static/splash.png" /> ``` These paths should be prefixed with SvelteKit's base path variable, %sveltekit.paths.base%, to ensure they are resolved correctly relative to the deployment subpath. 2 Incorrect Base URL Construction in src/lib/constants.ts The WEBUI_BASE_URL constant, which serves as the foundation for all API endpoints, is not correctly configured to use SvelteKit's base path in a production environment. The existing logic resolves to an empty string for the base path. Code Citation (illustrating the faulty logic in src/lib/constants.ts): The WEBUI_BASE_URL logic for a production browser environment effectively becomes '' instead of incorporating the subpath provided by SvelteKit's $app/paths. This incorrect base URL is then used to construct WEBUI_API_BASE_URL, causing all API requests to be sent to the wrong path. Furthermore, this misconfiguration prevents SvelteKit from correctly locating its own JavaScript modules, as seen by the failing requests to /_app/immutable/....

GiteaMirror added the bug label 2026-04-19 23:22:23 -05:00

GiteaMirror closed this issue

2026-04-19 23:22:24 -05:00

GiteaMirror commented

2026-04-19 23:22:27 -05:00

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

PLEASE check for existing/previous issues and discussions, this will not be officially supported for the foreseeable future due to our bandwidth. With that being said, we may be more receptive to any PRs regarding this, but we'd be hesitant unless we're convinced that this won't open up a whole new can of worms.

@tjbck commented on GitHub (Jul 2, 2025): PLEASE check for existing/previous issues and discussions, this will not be officially supported for the foreseeable future due to our bandwidth. With that being said, we may be more receptive to any PRs regarding this, but we'd be hesitant unless we're convinced that this won't open up a whole new can of worms.

GiteaMirror referenced this issue

2026-04-20 00:32:52 -05:00

[GH-ISSUE #17576] issue: Open-web UI does not support openrouter preset, with the ability to leverage a single modell, and obtain openrouter diagnostics #18333

GiteaMirror referenced this issue

2026-04-25 07:44:27 -05:00

[GH-ISSUE #17576] issue: Open-web UI does not support openrouter preset, with the ability to leverage a single modell, and obtain openrouter diagnostics #33862

GiteaMirror referenced this issue

2026-05-05 20:23:16 -05:00

[GH-ISSUE #17576] issue: Open-web UI does not support openrouter preset, with the ability to leverage a single modell, and obtain openrouter diagnostics #56999

Sign in to join this conversation.