NGINX proxy config hostname collision

[vipergts450]

Steps To Reproduce

1. Deploy another docker container or stack outside of Bitwarden which has a container named "web"
2. Deploy standard configuration via ./bitwarden.sh start
3. Attempt to access vault via browser

Expected Result

Vault login website should appear.

Actual Result

Browser responds with 502 error page from nginx.

Screenshots or Videos

No response

Additional Context

Searching the nginx error logs within bwdata folder shows

[warn] 48#48: *210 upstream server temporarily disabled while connecting to upstream ...
[error] 48#48: *210 connect() failed (111: Connection refused) while connecting to upstream ...

Upstream server in the logs is listed with IP address of the other, already running docker container with the name web despite that container being in another Docker network.

It seems to be caused by the following line in nginx's default.conf file:

 location / {
    proxy_pass http://web:5000/;
    ...
  }

I believe this could be remedied by having bitwarden.sh generate the file and appending the bitwarden_internal network domain to all of the hosts in default.conf rather than relying on Docker's DNS system to resolve the correct IP with only the hostname.

ex:

 location / {
    proxy_pass http://web.bitwarden_internal:5000/;
    ...
  }

Build Version

2025.4.1

Environment

Self-Hosted

Environment Details

• Operating System: Debian 12 (bookworm)
• Environment: Docker

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[jtodddd]

Hi there,

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[vipergts450]

For more context, I have a shared overlay network for NGINX Proxy Manager called npm, and both the Bitwarden stack's bitwarden-nginx container and the separate stack's web container are members of this overlay network so that NPM can direct traffic to each without either stack needing to expose ports to the host. Maybe this can help you replicate the issue.