starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-03-02 22:57:18 -05:00

Broken relative URLs in Web-vault main page due to incorrect base URL path (DOMAIN=https://domain.tld/vw) #2393

New issue

Closed

opened 2026-02-20 08:17:28 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 08:17:28 -05:00

Owner

Originally created by @Delicates on GitHub (Sep 10, 2025).

Prerequisites

I have searched the existing Closed AND Open Issues AND Discussions
I have searched and read the documentation

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.34.3
Web-vault version: v2025.7.1
OS/Arch: linux/x86_64
Running within a container: false (Base: Not applicable)
Database type: SQLite
Database version: 3.50.2
Uses config.json: false
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true

Non-docker Gentoo ebuild with Haproxy.

Using DOMAIN=https://domain.tld/vw (URL with path) in the ENV config file as per template.

Issue

https://domain.tld/vw web page is broken - once HTML loads, all relative URLs (stylesheets, scripts, images, etc.) are being loaded from the / root URL as the <base> path instead of the correct /vw/ URL path.

https://domain.tld/vw/ web page works fine, all relative URLs load from the correct /vw/ base URL path .

This is aggravated by VW SMTP Test emails being sent with the https://domain.tld/vw broken web page URL.

I tried setting DOMAIN=https://domain.tld/vw/, but this has no effect neither on the web page, nor on the URLs in the VW SMTP Test emails.

Root cause

Obviously with the https://domain.tld/vw URL web browsers consider / as the site <base> directory and fail to load all relative URLs.
With https://domain.tld/vw/ URL they consider /vw/ as the site <base> directory and all relative URLs load fine.

Proxy Workaround

I had to work around this by baking a URL redirect from /vw to /vw/ into the Proxy config:

backend be_vaultwarden
  mode http
  acl good-path path_beg /vw/
  http-request redirect code 308 location /vw/ unless good-path
  option forwardfor
  http-request set-header X-Real-IP %[src]
  server vaultwarden 127.0.0.1:8000

Vaultwarden Build Version

1.34.3

Deployment method

OS Package (apt, yum/dnf, pacman, apk, nix, ...)

Custom deployment method

No response

Reverse Proxy

Haproxy 3.2.3

Host/Server Operating System

Linux

Operating System Version

Gentoo

Clients

Web Vault

Client Version

Firefox 142.0.1 - v2025.7.1

Steps To Reproduce

Open new tab
Open Web Developer Tools Network tab (F12)
Try to load https://domain.tld/vw URL.
Try to load https://domain.tld/vw/ URL.

Expected Result

Web page should load regardless of whether you use https://domain.tld/vw or https://domain.tld/vw/ URL.

Expectation 1

Web-vault should either (in order of decreasing preference):

Do automatic 308 HTTP redirect from https://domain.tld/path URL to https://domain.tld/path/, or
Explicitly set correct <base href="https://domain.tld/path/" /> in the main https://domain.tld/path web page, or
Load all resource files using full /path/file URLs instead of relative file URLs.

Expectation 2

All VW emails should also use the correct https://domain.tld/vw/ base URL path instead of the incorrect https://domain.tld/vw. The VW SMTP Test email should be fixed, and others checked.

Expectation 3

For accuracy the ENV template example should be changed from using incorrect base URL path:

## For public server (URL with path)
# DOMAIN=https://domain.tld/vw

to correct base URL path:

## For public server (URL with path)
# DOMAIN=https://domain.tld/vw/

Actual Result

Broken https://domain.tld/vw web page because it fails to load all resources (stylesheets, scripts, images, etc.) due to broken relative URLs.
Everything loads fine with https://domain.tld/vw/ URL.

Logs

Screenshots or Videos

Additional Context

No response

Originally created by @Delicates on GitHub (Sep 10, 2025). ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.34.3 * Web-vault version: v2025.7.1 * OS/Arch: linux/x86_64 * Running within a container: false (Base: Not applicable) * Database type: SQLite * Database version: 3.50.2 * Uses config.json: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true Non-docker Gentoo ebuild with Haproxy. Using `DOMAIN=https://domain.tld/vw` (URL with path) in the ENV config file as per template. ### Issue https://domain.tld/vw web page is broken - once HTML loads, all relative URLs (stylesheets, scripts, images, etc.) are being loaded from the `/` root URL as the `<base>` path instead of the correct `/vw/` URL path. https://domain.tld/vw/ web page works fine, all relative URLs load from the correct `/vw/` base URL path . This is aggravated by VW SMTP Test emails being sent with the https://domain.tld/vw broken web page URL. I tried setting `DOMAIN=https://domain.tld/vw/`, but this has no effect neither on the web page, nor on the URLs in the VW SMTP Test emails. ### Root cause Obviously with the https://domain.tld/vw URL web browsers consider `/` as the site `<base>` directory and fail to load all relative URLs. With https://domain.tld/vw/ URL they consider `/vw/` as the site `<base>` directory and all relative URLs load fine. ### Proxy Workaround I had to work around this by baking a URL redirect from `/vw` to `/vw/` into the Proxy config: ``` backend be_vaultwarden mode http acl good-path path_beg /vw/ http-request redirect code 308 location /vw/ unless good-path option forwardfor http-request set-header X-Real-IP %[src] server vaultwarden 127.0.0.1:8000 ``` ### Vaultwarden Build Version 1.34.3 ### Deployment method OS Package (apt, yum/dnf, pacman, apk, nix, ...) ### Custom deployment method _No response_ ### Reverse Proxy Haproxy 3.2.3 ### Host/Server Operating System Linux ### Operating System Version Gentoo ### Clients Web Vault ### Client Version Firefox 142.0.1 - v2025.7.1 ### Steps To Reproduce 1. Open new tab 2. Open Web Developer Tools Network tab (F12) 3. Try to load https://domain.tld/vw URL. 5. Try to load https://domain.tld/vw/ URL. ### Expected Result Web page should load regardless of whether you use https://domain.tld/vw or https://domain.tld/vw/ URL. #### Expectation 1 Web-vault should either (in order of decreasing preference): * Do automatic 308 HTTP redirect from https://domain.tld/path URL to https://domain.tld/path/, or * Explicitly set correct `<base href="https://domain.tld/path/" />` in the main https://domain.tld/path web page, or * Load all resource files using full `/path/file` URLs instead of relative `file` URLs. #### Expectation 2 All VW emails should also use the correct https://domain.tld/vw/ base URL path instead of the incorrect https://domain.tld/vw. The VW SMTP Test email should be fixed, and others checked. #### Expectation 3 For accuracy the ENV template example should be changed from using incorrect base URL path: ``` ## For public server (URL with path) # DOMAIN=https://domain.tld/vw ``` to correct base URL path: ``` ## For public server (URL with path) # DOMAIN=https://domain.tld/vw/ ``` ### Actual Result * Broken https://domain.tld/vw web page because it fails to load all resources (stylesheets, scripts, images, etc.) due to broken relative URLs. * Everything loads fine with https://domain.tld/vw/ URL. ### Logs ```text ``` ### Screenshots or Videos <img width="1377" height="712" alt="Image" src="https://github.com/user-attachments/assets/a6694b06-ce30-4cdd-8330-61826b9cfdb1" /> ### Additional Context _No response_

deekerman

2026-02-20 08:17:28 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-20 08:17:29 -05:00

Author

Owner

@BlackDex commented on GitHub (Oct 14, 2025):

I'm afraid we can't fix this on the server side.
The same issue applies to both sub-path or no sub-path, but we can not determine if someone used a / at the end or not when there is no sub-path defined.

Having two different ways of working for reverse proxies will make it only difficult and inconsistent.
I have checked again, but we are just not able to get the specific details at the lowest level possible for us to see if non-sub-path's were requested with or without a /.

So, the only way to fix this is by using the reverse proxy to either redirect it self or some other way to fix that.

For haproxy you can also do this in the frontend.

frontend http_frontend
# Your default config here
acl is_missing_slash path_reg ^\/(vw)$

http-request redirect code 301 prefix / append-slash if is_missing_slash

@BlackDex commented on GitHub (Oct 14, 2025): I'm afraid we can't fix this on the server side. The same issue applies to both sub-path or no sub-path, but we can not determine if someone used a `/` at the end or not when there is no sub-path defined. Having two different ways of working for reverse proxies will make it only difficult and inconsistent. I have checked again, but we are just not able to get the specific details at the lowest level possible for us to see if non-sub-path's were requested with or without a `/`. So, the only way to fix this is by using the reverse proxy to either redirect it self or some other way to fix that. For haproxy you can also do this in the frontend. ```haproxy frontend http_frontend # Your default config here acl is_missing_slash path_reg ^\/(vw)$ http-request redirect code 301 prefix / append-slash if is_missing_slash ```