Najpierw chroń lokalne zmiany
Nie usuwaj danych aplikacji, nie reinstaluj jej i nie resetuj sejfu jako pierwszego kroku. Klient może zawierać niezsynchronizowane wpisy. Zapisz, na którym urządzeniu występuje problem i co działa w pozostałych klientach. Zachowaj dostęp do istniejącej zaufanej sesji.
Sprawdź połączenie
Tabela jest szersza od ekranu. Przewiń ją w poziomie.
| Objaw | Co sprawdzić | Czego unikać |
|---|---|---|
| Konto nie istnieje | Aktywny serwer i właściwy e-mail | Tworzenia nowych kont w przypadkowej chmurze. |
| Ostrzeżenie TLS | Nazwę domeny, ważność i łańcuch certyfikatu, czas urządzenia | Ignorowania ostrzeżenia certyfikatu. |
| Brak nowych wpisów | Konto, ręczną synchronizację, połączenie i działanie serwera | Czyszczenia lokalnej pamięci przed ochroną zmian. |
| Niepoprawny kod 2FA | Czas telefonu i wybraną metodę | Udostępniania QR lub kodu odzyskiwania. |
| Błąd po aktualizacji | Numery klienta i serwera, uwagi do wydania | Wymuszania starych obejść bez sprawdzenia. |
Porównaj web vault i klienta na fikcyjnym wpisie, jeśli masz bezpieczny dostęp. Pomyślne odblokowanie offline nie potwierdza sprawności logowania ani synchronizacji. Sprawdź awarię sieci, VPN i filtrów DNS bez wyłączania zabezpieczeń na stałe.
Przygotuj opis dla administratora
Zapisz system, przeglądarkę, numer klienta, wersję Vaultwarden, czas zdarzenia i zanonimizowany komunikat. Nie dołączaj hasła, plików sejfu, .env, sesji, cookies, tokenów, QR ani pełnych logów bez przeglądu. Adresy zapytań WebSocket mogą zawierać access_token.
Wiki zaleca ustalenie, czy problem leży po stronie klienta czy nieoficjalnego serwera, zanim zgłosisz go producentowi. Nie testuj prawdziwych danych na obcym serwerze. Korzystaj z repozytorium Vaultwarden i właściwego repozytorium klienta po anonimizacji oraz odtworzeniu usterki.