Czy Vaultwarden jest bezpieczny? Analiza zabezpieczeń

Czy Vaultwarden jest bezpieczny? Krótka odpowiedź

Vaultwarden jest bezpieczny w najważniejszym aspekcie, ponieważ każdy element bazy haseł jest szyfrowany na urządzeniu użytkownika, zanim trafi na serwer. Serwer przechowuje jedynie obiekty, których nie potrafi odczytać. Osoba, która skopiuje całą bazę danych, nadal potrzebuje hasła głównego, aby uzyskać z niej jakiekolwiek użyteczne informacje.

Ta odpowiedź pomija jednak wiele istotnych kwestii, a najsłabsze ogniwa wynikają z błędnej konfiguracji. Panel administracyjny zabezpieczony łatwym do odgadnięcia tokenem. Port kontenera wystawiony bezpośrednio do Internetu. Plik config.json zapisany w postaci jawnej. Archiwum kopii zapasowej pozostawione w katalogu domowym na tym samym serwerze. Żaden z tych problemów nie wynika z wad kryptografii. Wszystkie one są przyczynami, dla których samodzielnie hostowane bazy haseł zostają przejęte.

Wszystkie poniższe kroki zakładają działającą instalację. Jeśli jeszcze jej nie posiadasz, skonfiguruj ją najpierw zgodnie z przewodnikiem instalacji Vaultwarden na VPS, a następnie wróć tutaj i wykonaj listę zadań w podanej kolejności.

Co faktycznie przechowuje serwer

Vaultwarden implementuje model danych Bitwarden. Nazwa elementu sejfu, nazwa użytkownika, hasło, notatki oraz identyfikatory URI są szyfrowane kluczem wywiedzionym z hasła głównego po stronie klienta, zanim jakiekolwiek żądanie zostanie wysłane. Zawartość załączników jest szyfrowana w ten sam sposób. Serwer otrzymuje nieprzejrzyste dane z przypisanym do nich identyfikatorem UUID (universally unique identifier).

Niektóre elementy nie są szyfrogramami i należy dokładnie wiedzieć, które z nich:

• Adres e-mail konta, przechowywany jako tekst jawny.
• Ustawienia KDF (key derivation function) oraz sól, ponieważ klient potrzebuje ich do odtworzenia klucza przy kolejnym logowaniu.
• Skrót (hash) po stronie serwera, wyliczony z przesłanego przez klienta skrótu hasła głównego, używany do uwierzytelnienia samego logowania.
• Metadane: przynależność do organizacji, nazwy urządzeń, czasy ostatniego logowania.
• Sekret metody dwuskładnikowej (2FA) chroniącej logowanie do Vaultwarden. Znajduje się on w tabeli twofactor w postaci niezaszyfrowanej, ponieważ serwer musi obliczyć oczekiwany kod, aby porównać go z kodem użytkownika. Nie jest to tożsame z sekretem TOTP (time-based one-time password) przechowywanym wewnątrz elementu sejfu, który jest szyfrowany tak samo jak każde inne pole.

Folder danych jest niewielki. W instalacji Docker jest to katalog zamontowany w /data.

sudo ls -l /vw-data/

db.sqlite3 przechowuje niemal cały stan aplikacji. attachments/ przechowuje przesłane pliki, po jednym na każdy UUID, i jest to jedyna istotna klasa danych, która nie znajduje się w tabelach bazy danych. sends/ przechowuje załączniki funkcji Send i ma charakter tymczasowy. icon_cache/ zawiera dane tymczasowe. rsa_key.pem wraz z plikami towarzyszącymi służy do podpisywania tokenów JWT (JSON web tokens) zalogowanych użytkowników, więc kopia tego klucza prywatnego może zostać użyta do sfałszowania sesji logowania do sejfu. config.json powstaje dopiero po włączeniu strony administracyjnej, a projekt jasno informuje: przechowuje ona token administratora oraz dane uwierzytelniające SMTP w postaci tekstu jawnego.

Praktyczny model zagrożeń dotyczy zatem dostępu do systemu plików, a nie kryptografii sieciowej. Dostęp do odczytu tego jednego katalogu pozwala na przejęcie adresu e-mail każdego użytkownika, ich sekretów 2FA, klucza umożliwiającego fałszowanie sesji oraz kopii offline każdego sejfu w celu przeprowadzenia ataku w dowolnym czasie. Każdy krok opisany poniżej ma na celu uniemożliwienie osobom niepowołanym dostępu do tego katalogu.

Najpierw napraw token administratora

/admin to pełny panel sterowania: lista użytkowników, zaproszenia, usuwanie oraz wszystkie ustawienia środowiska uruchomieniowego. Jest on chroniony wyłącznie jednym współdzielonym kluczem (secret). Brak nazwy użytkownika. Brak uwierzytelniania dwuskładnikowego dla poszczególnych użytkowników.

Starsze poradniki zalecają wygenerowanie ADMIN_TOKEN za pomocą openssl rand -base64 48. To działa, ale zapisuje klucz w postaci jawnej w pliku config.json oraz w pliku compose. Vaultwarden akceptuje również ciąg Argon2 PHC (password hashing competition), dzięki czemu przechowywana wartość jest skrótem (hash). Wygeneruj go na działającym kontenerze:

docker exec -it vaultwarden /vaultwarden hash

Można to również zrobić bez ingerencji w działający kontener:

docker run --rm -it vaultwarden/server /vaultwarden hash

Narzędzie poprosi o dwukrotne podanie hasła, a następnie wyświetli linię zaczynającą się od $argon2id$. W przypadku instalacji bare-metal, uruchom ./vaultwarden hash. Jeśli wolisz użyć bezpośrednio CLI argon2, projekt dokumentuje minimalne parametry OWASP:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Oto pułapka, która kosztuje użytkowników godzinę pracy. Ciąg PHC zawiera wiele znaków $, a Docker Compose traktuje $ jako interpolację zmiennych. Wklejenie go bez odpowiedniego zabezpieczenia do bloku environment: spowoduje, że wartość przekazana do kontenera będzie uszkodzona, przez co /admin odrzuci poprawny token. Istnieją dwie bezpieczne metody. W docker-compose.yml należy podwoić każdy znak $:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

W pliku .env ucieczka znaków nie jest wymagana, ale należy użyć pojedynczego cudzysłowu:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Następnie ogranicz częstotliwość zapytań do panelu i skróć czas trwania sesji:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Trzy nieudane próby w ciągu pięciu minut spowodują, że panel przestanie odpowiadać na żądania danego klienta. Sesja administratora wygasa po 20 minutach bezczynności.

Lepszym rozwiązaniem od powyższych jest wyłączenie tej strony. Większość instancji potrzebuje jej tylko raz, aby skonfigurować SMTP i zaprosić pierwszych użytkowników, a później nigdy więcej. Aby wyłączyć panel, nie ustawiaj zmiennych ADMIN_TOKEN ani DISABLE_ADMIN_TOKEN, usuń klucz "admin_token" z config.json, a następnie zrestartuj kontener. Usunięcie klucza z pliku jest istotne, ponieważ panel administratora zapisuje tam ustawienia, a zawartość config.json ma pierwszeństwo przed zmiennymi środowiskowymi. Usunięcie samej zmiennej pozostawi stronę aktywną.

Zamknięcie rejestracji przed upublicznieniem domeny

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED domyślnie przyjmuje wartość true. Pozostawienie tego ustawienia sprawia, że każdy użytkownik, który trafi do domeny, może założyć konto, a jego dane zostaną zapisane w tej samej bazie db.sqlite3 co Twoje. Ustawienie wartości na false pozwala na dodawanie użytkowników wyłącznie poprzez zaproszenia wysyłane z panelu administratora, co wymaga poprawnej konfiguracji SMTP. Opcja INVITATIONS_ALLOWED jest również domyślnie true i pozwala właścicielom organizacji na zapraszanie innych osób. Jest to dopuszczalne w przypadku zaufanych użytkowników, jednak w instancjach jednoosobowych należy ustawić ją na false. Jeśli rejestracja ma być ograniczona tylko do określonych domen, opcja SIGNUPS_DOMAINS_WHITELIST=example.com jest bardziej restrykcyjna niż otwarta rejestracja, lecz znacznie słabsza niż system zaproszeń.

Opcja SHOW_PASSWORD_HINT jest domyślnie false i powinna tak pozostać. Przy włączonej opcji wpisanie poprawnego adresu e-mail w formularzu logowania powoduje wyświetlenie podpowiedzi do hasła głównego, co ujawnia treść podpowiedzi oraz potwierdza istnienie konta powiązanego z danym adresem.

Jeśli instancja była uruchomiona z otwartą rejestracją przez jakikolwiek czas, należy otworzyć panel administratora i przejrzeć listę użytkowników, zanim założysz, że jesteś jedynym użytkownikiem w systemie.

Port, którego nie zamierzano udostępniać

Obraz Docker nasłuchuje na porcie 80 wewnątrz kontenera. Instalacja typu bare-metal domyślnie korzysta z ROCKET_PORT=8000. Udokumentowane polecenie uruchomienia publikuje go w następujący sposób:

--publish 127.0.0.1:8000:80

Prefiks 127.0.0.1: stanowi istotę problemu. Zapisanie -p 8000:80 powoduje, że Docker wiąże port z 0.0.0.0, co realizowane jest poprzez wpisanie reguł DNAT (destination network address translation) do tablicy nat. Reguły te są sprawdzane przed łańcuchami filter zarządzanymi przez ufw, dlatego ufw status zgłasza port jako zablokowany, podczas gdy port w rzeczywistości odpowiada na zapytania z Internetu. Pełny mechanizm został opisany w przewodniku dotyczącym omijania ufw przez porty Docker.

Należy sprawdzić, co faktycznie nasłuchuje:

sudo ss -tlnp | grep 8000

Prawidłowy wynik to pojedyncza linia powiązana z 127.0.0.1:8000. Linia powiązana z 0.0.0.0:8000 oznacza, że vault jest wystawiony bezpośrednio. Należy poprawić mapowanie, a następnie odtworzyć kontener, ponieważ powiązanie portu jest ustalane w momencie tworzenia kontenera i docker compose restart nie zmieni tego ustawienia:

docker compose up -d --force-recreate

W starych poradnikach przetrwał jeszcze jeden port: 3012, czyli oddzielny port WebSocket. Obsługa tego portu została usunięta w Vaultwarden 1.31.0, ponieważ ruch powiadomień został przeniesiony na główny port HTTP. Parametry WEBSOCKET_ENABLED oraz WEBSOCKET_PORT są ignorowane od wersji 1.29.0. Obecny przełącznik to ENABLE_WEBSOCKET, którego domyślną wartością jest true. Jeśli firewall lub plik compose nadal otwierają port 3012, należy go zamknąć.

Terminacja TLS na reverse proxy, a nie w Rocket

Vaultwarden może samodzielnie obsługiwać TLS (transport layer security) za pośrednictwem Rocket, swojego frameworka webowego, jednak dokumentacja projektu odradza takie rozwiązanie w środowisku produkcyjnym. Wbudowana obsługa TLS w Rocket nie posiada ścisłego wsparcia dla SNI (server name indication), co jest również powodem, dla którego zaleca się uzyskiwanie dostępu do instancji wyłącznie przez nazwę hosta, a nigdy przez bezpośredni adres IP. Publiczne zakresy adresów IP są stale skanowane, a vault odpowiadający na adres IP to vault, który zostanie wykryty.

Kluczowe elementy bloku serwera nginx:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

Domyślna wartość client_max_body_size w nginx wynosi 1 MB, więc bez tej linii przesyłanie załączników kończy się niepowodzeniem z błędem 413 Request Entity Too Large w dzienniku błędów nginx, podczas gdy Vaultwarden nie rejestruje żadnych informacji. Nagłówki Upgrade oraz Connection przekazują uzgadnianie WebSocket do /notifications/hub. Ich pominięcie sprawi, że vault nadal będzie działał, ale zmiany przestaną pojawiać się na innych urządzeniach do momentu ręcznego odświeżenia strony.

Konfiguracja Caddy jest krótsza i automatycznie pobiera certyfikat:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Następnie należy poinformować o tym Vaultwarden:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER domyślnie przyjmuje wartość X-Real-IP, więc zadaniem administratora jest upewnienie się, że proxy faktycznie ustawia ten nagłówek. Jeśli tego nie zrobi, każda linia logu i każdy limit prób logowania będzie widział 127.0.0.1, czyli samo proxy, co oznacza, że nieudane próby jednego atakującego będą przypisywane wszystkim użytkownikom instancji. Ustaw również DOMAIN na właściwy adres URL https, ponieważ Vaultwarden generuje na jego podstawie linki do zaproszeń i resetowania hasła, a klucze bezpieczeństwa WebAuthn są powiązane z tym źródłem.

Szczegół, który często bywa pomijany: połączenie WebSocket przekazuje token sesji w ciągu zapytania jako /notifications/hub?access_token=[JWT]. Trafia on do logów dostępu proxy w postaci jawnej. Należy usunąć parametr access_token z formatu logów lub upewnić się, że logi te nie są wysyłane w miejsca, nad którymi nie sprawujesz kontroli.

Blokowanie ataków brute force na punkcie końcowym logowania

Limity szybkości (rate limits) są domyślnie włączone (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Spowalniają one atakującego, ale go nie zatrzymują. Do tego służy fail2ban, jednak Vaultwarden musi najpierw zapisywać plik dziennika, czego nie robi w konfiguracji domyślnej:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Nieudana próba logowania generuje dokładnie jedną linię; jest to ciąg znaków, który musi dopasować filtr:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Zapisz filtr w /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Oraz jail w /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Jeśli zachowano dostęp do strony administratora, należy dodać drugi jail, którego failregex to ^.*Invalid admin token\. IP: <ADDR>.*$, ponieważ błędy logowania administratora są rejestrowane z innym komunikatem i filtr logowania ich nie wykryje. Następnie sprawdź poprawność konfiguracji:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Poprawnie działający jail wyświetla plik dziennika w sekcji File list i raportuje Currently failed: 0. Wprowadź błędne hasło trzy razy z innej sieci; licznik powinien wzrosnąć, a adres IP pojawi się w Banned IP list. Jeśli licznik nie rośnie, najczęstszą przyczyną jest logpath: musi to być ścieżka do pliku na hoście, a nie ścieżka /data/... wewnątrz kontenera. Drugą częstą przyczyną jest brak X-Real-IP, co powoduje, że każde zablokowanie dotyczy własnego proxy. Reszta konfiguracji, w tym jail dla SSH, który powinien być już uruchomiony, znajduje się w przewodniku po fail2ban dla Ubuntu 24.04.

Hasło główne pozostaje fundamentem całego systemu

Szyfrowanie po stronie klienta oznacza, że hasło główne stanowi klucz. Krótkie hasło główne w instancji, której bazę danych skopiował atakujący, nie jest chronione przez żadne z ustawień opisanych w tym artykule. Atakujący może przeprowadzić atak offline na taką kopię z dowolną szybkością, na jaką pozwala jego sprzęt. Żadne ustawienie serwera nie wpływa na maszynę atakującego.

PASSWORD_ITERATIONS=600000 to liczba iteracji KDF przekazywana klientom podczas tworzenia nowego konta. Istniejące konta zachowują wartość, z którą zostały utworzone, więc jej zwiększenie nie zmienia niczego dla użytkowników, którzy zarejestrowali się w ubiegłym roku. Muszą oni samodzielnie zmienić tę wartość w ustawieniach bezpieczeństwa web vault, co spowoduje ponowne zaszyfrowanie ich klucza. Należy ich o tym poinformować, ponieważ interfejs nie zawiera żadnych powiadomień w tej kwestii.

Następnie należy włączyć uwierzytelnianie dwuskładnikowe dla każdego konta. Nie chroni ono szyfrogramu, ponieważ klucz skarbca pochodzi wyłącznie z hasła głównego. Zapobiega jednak sytuacji, w której skradzione hasło wystarcza do zalogowania się i zsynchronizowania kopii danych. REQUIRE_DEVICE_EMAIL=true dodaje krok potwierdzenia e-mail przy pierwszym logowaniu do konta z nierozpoznanego urządzenia.

Kopie zapasowe to punkt, w którym zawodzi bezpieczeństwo własnych instancji

tar czf folderu z danymi, pozostawiona w katalogu domowym na tym samym serwerze VPS, niweczy wszystkie powyższe kroki. To archiwum zawiera db.sqlite3 z szyfrogramami wszystkich użytkowników, rsa_key.pem, które pozwala na fałszowanie sesji logowania, oraz config.json z tokenem administratora i hasłem SMTP zapisanymi otwartym tekstem. Dostęp do odczytu tego jednego pliku oznacza dostęp do odczytu całego skarbca.

Obowiązują dwie zasady. Przenieś archiwum poza serwer. Zaszyfruj je przed wysłaniem.

Istnieje również problem poprawności danych. Kopiowanie db.sqlite3 za pomocą cp w trakcie działania usługi może spowodować utworzenie pliku w trakcie zapisu, którego nie da się otworzyć, a błąd ten zostanie wykryty dopiero podczas przywracania. Zamiast tego należy użyć wbudowanej funkcji migawki SQLite:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Proces przywracania, czyli połowa operacji, której nikt nie testuje, został opisany w przewodniku tworzenia i przywracania kopii zapasowych Vaultwarden.

Z czego rezygnujesz w porównaniu z hostowanym Bitwarden

Uczciwe zestawienie. Hostowana usługa Bitwarden jest obsługiwana przez osoby, których pracą na pełen etat jest jej utrzymanie, z opublikowanymi audytami zewnętrznymi i personelem dostępnym pod telefonem o 3 nad ranem. Samodzielne hostowanie zamienia to na własny harmonogram aktualizacji.

Vaultwarden udostępnia poprawki bezpieczeństwa jako zwykłe wydania. Wersja 1.37.0, wydana 24 lipca 2026, jest aktualna na sierpień 2026, a jej notatki zalecają użytkownikom jak najszybszą aktualizację. Instancja skonfigurowana rok temu i zapomniana działa na rocznym kodzie. Znacznik latest sam w sobie nie pomaga: uruchomiony kontener zachowuje obraz, z którego wystartował, dopóki nie uruchomisz docker compose pull i nie utworzysz go ponownie. Skonfiguruj automatyczne aktualizacje na Ubuntu dla pakietów hosta, a aktualizację kontenera ustaw w przypomnieniu w kalendarzu, które faktycznie będziesz czytać.

Wniosek, jaki powinien wyciągnąć uczciwy czytelnik: zastosowana tutaj kryptografia to projekt Bitwarden i jest ona solidna, natomiast ryzyko operacyjne przechodzi całkowicie na Ciebie. Jeśli instalujesz poprawki i wykonujesz kopie zapasowe w innej lokalizacji, instancja Vaultwarden na kontrolowanym przez Ciebie VPS jest rozsądnym miejscem do przechowywania haseł. Jeśli te dwa nawyki nie będą praktykowane, zapłać za usługę hostowaną i poświęć uwagę czemuś innemu. Porównanie funkcji znajduje się w Vaultwarden w porównaniu z samodzielnie hostowanym Bitwarden.

Zabezpieczanie hosta pod kontenerem

Vaultwarden jest pojedynczym procesem w systemie Linux, a użytkownik root na tym hoście może odczytać /vw-data niezależnie od konfiguracji samej aplikacji. Uruchom kontener jako użytkownik bez uprawnień, używając user: "1000:1000" w pliku compose, ustaw odpowiedniego właściciela folderu z danymi oraz zamontuj elementy, do których kontener nie zapisuje, w trybie tylko do odczytu za pomocą :ro. Następnie zabezpiecz dostęp: Zabezpieczanie SSH na VPS opisuje logowanie wyłącznie przy użyciu kluczy oraz wyłączenie uwierzytelniania hasłem, co skutecznie powstrzymuje ataki typu brute-force, które omijają wszystkie powyższe zabezpieczenia.

FAQ

Czy ktoś może odczytać moje hasła, jeśli ukradnie bazę danych Vaultwarden?

Nie bezpośrednio. Każdy element skarbca jest szyfrowany po stronie klienta za pomocą klucza wywiedzionego z hasła głównego, więc db.sqlite3 zawiera jedynie tekst zaszyfrowany. Atakujący natychmiast uzyskuje dostęp do adresów e-mail kont, ustawień KDF, metadanych logowania i urządzeń oraz sekretów uwierzytelniania dwuskładnikowego w tabeli twofactor. Są one przechowywane w postaci niezaszyfrowanej, ponieważ serwer musi wyliczyć oczekiwany kod. Atakujący może również przeprowadzać ataki offline na zaszyfrowaną zawartość skarbca przez dowolnie długi czas, dlatego to długość hasła głównego decyduje o bezpieczeństwie danych.

Czy powinienem użyć ADMIN_TOKEN, czy całkowicie wyłączyć stronę administratora?

Jeśli to możliwe, należy ją wyłączyć, ponieważ większość instancji wymaga jej tylko raz do konfiguracji SMTP i zaproszenia użytkowników, a później nie jest już potrzebna. Aby ją wyłączyć, nie ustawiaj ani ADMIN_TOKEN, ani DISABLE_ADMIN_TOKEN, usuń klucz "admin_token" z config.json, a następnie zrekonstruuj kontener. Usunięcie samej zmiennej środowiskowej nie wystarczy, ponieważ ustawienia zapisane przez stronę administratora znajdują się w config.json i mają wyższy priorytet. Jeśli zdecydujesz się zachować stronę, przechowuj token jako skrót Argon2 wygenerowany przez vaultwarden hash zamiast zwykłego ciągu znaków i ustaw ADMIN_RATELIMIT_MAX_BURST=3.

Mój ADMIN_TOKEN jest poprawny, ale /admin go odrzuca. Co jest nie tak?

Prawie zawsze przyczyną jest interpolacja $. Ciąg Argon2 PHC zawiera kilka znaków $, a Docker Compose rozwija je jako zmienne wewnątrz bloku docker-compose.yml environment:. W rezultacie kontener otrzymuje uszkodzoną wartość, mimo że w pliku wygląda ona poprawnie. Podwój każdy znak $ na $$ w pliku compose lub przenieś wartość do pliku .env ujętego w pojedyncze cudzysłowy, gdzie nie jest wymagane żadne znakowanie. Po tej operacji zrekonstruuj kontener, ponieważ zmiany w środowisku nie są uwzględniane przy zwykłym restarcie.

Czy nadal muszę otwierać port 3012 dla powiadomień?

Nie. Obsługa ruchu WebSocket na porcie 3012 została usunięta w Vaultwarden 1.31.0, ponieważ powiadomienia zostały przeniesione na główny port HTTP, a WEBSOCKET_ENABLED oraz WEBSOCKET_PORT są ignorowane od wersji 1.29.0. Obecne ustawienie to ENABLE_WEBSOCKET, które domyślnie jest true. Zamknij port 3012 w zaporze sieciowej i usuń go z pliku compose, a następnie upewnij się, że Twój reverse proxy przekazuje nagłówki Upgrade oraz Connection, ponieważ to od nich zależy teraz synchronizacja w czasie rzeczywistym.