4. Troubleshoot Vaultwarden Docker/Web UI service

Step Contents

Let’s try accessing the web UI. Try accessing the Vaultwarden interface on https://vault.yourdomain.com .

Troubleshooting web UI reachability

In case the web UI is not coming up, we need to determine where the traffic got stuck. Here are the layers:

DNS – e.g. CloudFlare – is your DNS record set up? Does it point to the correct IP address?
OPNSense – do you have a firewall + NAT rule set up for forwarding traffic to a port that HAPRoxy is listening on?
HAProxy – is your public (front-end) service on and listening on the desired port? Have you attached your SSL certificate for decrypting traffic? Is your back-end pool forwarding traffic to the right host? Is your ‘real’ host configure on the right port?
Nginx on the VM – is nginx on and listening on the right port? Is the syntax of your virtual host for forwarding ok?
Docker – is the docker instance up? What do the logs say?
Galera DB Cluster – is it reachable for the web servers? Is the virtual IP operational? Is the DB up, esp. if you are reaching it on a virtual IP via OPNSense / pfSense?

Example issue no.1 – Web server not accepted by the DB server

The example below shows that the Docker instance is running but spent the last two hours in a crash loop due to incorrect DB details:

A troubleshooting option 1 - DB cannot be reached. — Issue no.1: DB cannot be reached

You may notice the IP 192.168.8.1 that points to the OPNSense host from which it is forwarded. This is because the Galera cluster is reachable on a virtual IP (192.168.8.70) provided by OPNSense. Such behavior is normal and expected.
The main issue that I simulated here was that the user was defined for the wrong subnet – after dropping the user and re-creating it with the correct GRANT privileges fixed the issue.

Example issue no.2 – No Docker container running

Let’s say you set up just one web server VM and were able to reach the web UI and then later, it stopped loading. You may wish you double check that the docker container is still up.

sudo docker container ps -a

Issue no.2: Docker container is not running (stuck in a reboot loop)

To fix it, go to the folder where your container is located and start it. Ensure that you set up Docker to start on boot.

cd /opt/vaultwarden
sudo docker compose up -d
sudo systemctl enable docker

Example issue no.3 – 401 Unauthorized” loops

If you log in successfully but are immediately logged out when refreshing or performing an action, your nodes likely have different signing keys.

The Cause: Vaultwarden generates RSA key pair files in /data on first startup. If web1 generated its own keys and web2 generated different ones, a login token signed by web1 will be rejected by web2.
The Fix: Ensure Syncthing is successfully syncing the rsa_key.pem, rsa_key.pub.pem, and rsa_key.der files. You may need to manually copy the keys from the “primary” node to the others once to establish a baseline, then let Syncthing handle future updates.

First login

Since we set SIGNUPS_ALLOWED=false in the config, you will need to temporarily change that to true in docker-compose.yml, run docker compose up -d to apply, create your accounts, and then flip it back to false and restart again. This is intentional as a matter of exercising how you can easily tweak settings with Docker Compose, esp. when applying updates in the future.

Your first step in the Web UI would be to create your account.