A small suggestion that exists with the default Vaultwarden Docker container is that it expects HTTPs traffic over port 80 when port 80 is defined by IANA as a HTTP port only and the correct port for HTTPs is 443 (RFC6335 / RFC9110).
One would think this is not a problem, right? The port in this case is just a TCP socket on the lower levels but this problem manages to throw the Traefik reverse-proxy off and the container must be labeled such that Traefik accepts to start TLS/SSL over port 80 or through the custom exposed port.
It would be standards-compliant for Vaultwarden to start its HTTPs listener on port 443, even internal to the Docker container because reverse-proxies like Traefik hook into the internal network, or to pick any non-reserved port for SSL traffic. Some other software behaves the same; Firefox is also thrown off if a server responds with a TLS/SSL session request over 80, it does not even proceed, it just throws an error at the user claiming that a website tried to initiate HTTPs over HTTP.
I am just mentioning this because it's not a difficult issue to debug, but due to the non-standards-compliant behavior some clients might be thrown off by default depending on how seriously they take the port assignment definitions.
Originally created by @cxtal on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6401
### 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
N/A
### Vaultwarden Build Version
v1.34.0
### Deployment method
Official Container Image
### Custom deployment method
_No response_
### Reverse Proxy
traefik 3.4.4
### Host/Server Operating System
Linux
### Operating System Version
_No response_
### Clients
Web Vault
### Client Version
_No response_
### Steps To Reproduce
- Connect with SSL client to port 80.
### Expected Result
- Vaultwarden loads.
### Actual Result
- Vaultwarden doesn't load.
### Logs
```text
```
### Screenshots or Videos
_No response_
### Additional Context
Thank you for the wonderful project.
A small suggestion that exists with the default Vaultwarden Docker container is that it expects HTTPs traffic over port 80 when port 80 is defined by IANA as a HTTP port only and the correct port for HTTPs is 443 (RFC6335 / RFC9110).
One would think this is not a problem, right? The port in this case is just a TCP socket on the lower levels but this problem manages to throw the Traefik reverse-proxy off and the container must be labeled such that Traefik accepts to start TLS/SSL over port 80 or through the custom exposed port.
It would be standards-compliant for Vaultwarden to start its HTTPs listener on port 443, even internal to the Docker container because reverse-proxies like Traefik hook into the internal network, or to pick any non-reserved port for SSL traffic. Some other software behaves the same; Firefox is also thrown off if a server responds with a TLS/SSL session request over 80, it does not even proceed, it just throws an error at the user claiming that a website tried to initiate HTTPs over HTTP.
I am just mentioning this because it's not a difficult issue to debug, but due to the non-standards-compliant behavior some clients might be thrown off by default depending on how seriously they take the port assignment definitions.
GiteaMirror
added the bug label 2026-07-13 20:10:53 -05:00
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 @cxtal on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6401
Prerequisites
Vaultwarden Support String
N/A
Vaultwarden Build Version
v1.34.0
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
traefik 3.4.4
Host/Server Operating System
Linux
Operating System Version
No response
Clients
Web Vault
Client Version
No response
Steps To Reproduce
Expected Result
Actual Result
Logs
Screenshots or Videos
No response
Additional Context
Thank you for the wonderful project.
A small suggestion that exists with the default Vaultwarden Docker container is that it expects HTTPs traffic over port 80 when port 80 is defined by IANA as a HTTP port only and the correct port for HTTPs is 443 (RFC6335 / RFC9110).
One would think this is not a problem, right? The port in this case is just a TCP socket on the lower levels but this problem manages to throw the Traefik reverse-proxy off and the container must be labeled such that Traefik accepts to start TLS/SSL over port 80 or through the custom exposed port.
It would be standards-compliant for Vaultwarden to start its HTTPs listener on port 443, even internal to the Docker container because reverse-proxies like Traefik hook into the internal network, or to pick any non-reserved port for SSL traffic. Some other software behaves the same; Firefox is also thrown off if a server responds with a TLS/SSL session request over 80, it does not even proceed, it just throws an error at the user claiming that a website tried to initiate HTTPs over HTTP.
I am just mentioning this because it's not a difficult issue to debug, but due to the non-standards-compliant behavior some clients might be thrown off by default depending on how seriously they take the port assignment definitions.