Client logs out frequently, sometimes requires multiple submissions of login info to connect

[jtruland]

nginx_access-bitwarden.log

Steps To Reproduce

1. Bitwarden client is logged in.
2. Wait some amount of time (longer than a few minutes is more likely) (Vault Timeout set to Never)
3. Attempt to access client
4. Bitwarden client returns to login screen
5. Complete Username / Password entry
6. Receive Unknown Error popup
7. Click to submit same username/password a second time
8. Access allowed to Bitwarden client

Expected Result

Bitwarden is able to maintain its connection status throughout use.

Actual Result

Connection disrupted frequently.

Client logs show:
15:45-15:47 attempt to Sync vault from client
16:36 open client, redirected to login screen, submit correct login, Unknown Error, resubmit same credentials, successful login

bitwarden.log
Bitwarden_console.log

Screenshots or Videos

No response

Additional Context

Self-hosted using the Docker Linux Standard Deployment - connecting via Cloudflare tunnel, Nginx Proxy Manager.

This problem spans Windows, Android, Chrome extension clients

Operating System

Windows

Operating System Version

Windows 11 Pro Build 26120

Installation method

Direct Download (from bitwarden.com)

Build Version

2025.2.0

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.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-18345

[pamperer562580892423]

@jtruland What is your server version?

[jtruland]

@jtruland What is your server version?

2025.1.4

This has been an ongoing issue for about the past 6-8 months. Sometimes it seems better than others.

[jtruland]

Examining my logs- I'm wondering if my replica Cloudflared sessions are the issue. One instance of Cloudflared is running on the same docker server as Bitwarden, the other is the 192.168 IP in the log files. Shutting down the secondary tunnel daemon does seem to improve the connection.

[Adedamola-Aina]

Similar issues: #10718