Adakah Vaultwarden Selamat? Panduan Pengukuhan Keselamatan

Adakah Vaultwarden selamat? Jawapan ringkas

Vaultwarden adalah selamat pada aspek yang paling penting, kerana setiap item dalam peti simpanan disulitkan pada peranti anda sebelum ia sampai ke pelayan. Pelayan hanya menyimpan data yang tidak boleh dibacanya. Sesiapa yang menyalin keseluruhan pangkalan data masih memerlukan kata laluan induk untuk mendapatkan sebarang maklumat berguna daripadanya.

Jawapan tersebut bergantung kepada banyak faktor, dan bahagian yang sering gagal adalah bahagian yang anda konfigurasi sendiri. Panel pentadbir yang dilindungi oleh token yang mudah diteka. Port kontena yang didedahkan kepada seluruh internet. config.json dalam bentuk teks biasa. Fail sandaran tarball yang dibiarkan dalam direktori rumah pada mesin yang sama. Tiada satu pun daripada perkara ini merupakan masalah kriptografi. Kesemuanya adalah punca peti simpanan yang dihoskan sendiri dicerobohi.

Segala maklumat di bawah mengandaikan anda sudah mempunyai pemasangan yang berfungsi. Jika anda belum mempunyainya, sediakan dahulu dengan panduan pemasangan Vaultwarden untuk VPS, kemudian kembali dan ikuti senarai ini mengikut urutan.

Apa yang sebenarnya disimpan oleh pelayan

Vaultwarden melaksanakan model data Bitwarden. Nama item vault, nama pengguna, kata laluan, nota dan URI disulitkan dengan kunci yang diterbitkan daripada kata laluan induk anda, di dalam klien, sebelum sebarang permintaan dihantar. Kandungan fail lampiran disulitkan dengan cara yang sama. Pelayan menerima data legap dengan UUID (pengecam unik sejagat) yang dilampirkan padanya.

Terdapat beberapa perkara yang bukan teks sifer, dan anda perlu tahu dengan tepat perkara tersebut:

• Alamat e-mel akaun anda, dalam teks biasa.
• Tetapan KDF (fungsi terbitan kunci) dan salt anda, kerana klien memerlukannya untuk membina semula kunci pada log masuk seterusnya.
• Hash sebelah pelayan bagi hash kata laluan induk yang dihantar oleh klien, digunakan untuk mengesahkan log masuk itu sendiri.
• Metadata: keahlian organisasi, nama peranti, masa log masuk terakhir.
• Rahsia untuk kaedah dua faktor yang mengawal log masuk Vaultwarden. Ia berada dalam jadual twofactor tanpa disulitkan, kerana pelayan perlu mengira kod yang dijangka untuk dibandingkan dengan kod anda. Ini tidak sama dengan rahsia TOTP (kata laluan sekali guna berasaskan masa) yang anda simpan di dalam item vault, yang disulitkan seperti mana-mana medan lain.

Folder data adalah kecil. Pada pemasangan Docker, ia adalah apa sahaja yang anda lekapkan pada /data.

sudo ls -l /vw-data/

db.sqlite3 menyimpan hampir semua keadaan. attachments/ menyimpan fail yang dimuat naik, satu untuk setiap UUID, dan ia merupakan satu-satunya kelas data penting yang tidak berada dalam jadual pangkalan data. sends/ menyimpan lampiran Send dan bertujuan untuk menjadi sementara. icon_cache/ adalah untuk data yang boleh dibuang. rsa_key.pem dan rakan-rakannya menandatangani JWT (token web JSON) pengguna yang log masuk, jadi salinan kunci peribadi itu boleh digunakan untuk memalsukan sesi log masuk vault. config.json hanya wujud sebaik sahaja anda mendayakan halaman admin, dan projek ini menyatakan secara terus terang mengenainya: ia menyimpan token admin dan kelayakan SMTP anda dalam teks biasa.

Oleh itu, model ancaman praktikal ialah akses sistem fail, bukan kriptografi rangkaian. Akses baca ke direktori tersebut memberikan alamat e-mel setiap pengguna, rahsia 2FA log masuk mereka, kunci yang memalsukan sesi, dan salinan luar talian setiap vault untuk diserang pada bila-bila masa. Setiap langkah di bawah wujud untuk menghalang orang lain daripada mengakses direktori tersebut.

Betulkan token pentadbir dahulu

/admin ialah panel kawalan penuh: senarai pengguna, jemputan, pemadaman, dan setiap tetapan masa jalan. Ia dilindungi oleh satu rahsia kongsi dan tiada yang lain. Tiada nama pengguna. Tiada pengesahan dua faktor bagi setiap pengguna.

Panduan lama memberitahu anda untuk menjana ADMIN_TOKEN dengan openssl rand -base64 48. Itu berfungsi, dan ia menulis rahsia tersebut dalam teks biasa ke dalam config.json dan ke dalam fail compose anda. Vaultwarden juga menerima rentetan Argon2 PHC (password hashing competition), jadi nilai yang disimpan adalah dalam bentuk hash. Jana satu terhadap container yang sedang berjalan:

docker exec -it vaultwarden /vaultwarden hash

Atau tanpa menyentuh container yang sedang berjalan sama sekali:

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

Ia meminta kata laluan sebanyak dua kali, kemudian mencetak baris yang bermula dengan $argon2id$. Pada pemasangan bare-metal, jalankan ./vaultwarden hash. Jika anda lebih suka menggunakan CLI argon2 secara terus, projek tersebut mendokumentasikan parameter minimum OWASP:

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

Sekarang perangkap yang membuang masa selama sejam. Rentetan PHC penuh dengan aksara $, dan Docker Compose menganggap $ sebagai interpolasi pemboleh ubah. Tampal ia tanpa escape ke dalam blok environment: dan nilai yang sampai ke container akan menjadi rosak, jadi /admin menolak token yang anda tahu adalah betul. Dua bentuk yang selamat. Dalam docker-compose.yml, gandakan setiap $:

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

Dalam fail .env, tiada escaping diperlukan, tetapi gunakan tanda petik tunggal:

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

Kemudian hadkan kadar panel dan pendekkan sesinya:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Tiga percubaan gagal dalam tempoh lima minit dan panel akan berhenti menjawab klien tersebut. Sesi pentadbir tamat selepas 20 minit tidak aktif.

Lebih baik daripada semua ini: matikan halaman tersebut. Kebanyakan instance memerlukannya sekali sahaja, untuk mengkonfigurasi SMTP dan menjemput pengguna pertama, dan tidak lagi selepas itu. Untuk menyahdayakannya, jangan tetapkan ADMIN_TOKEN mahupun DISABLE_ADMIN_TOKEN, alih keluar sebarang kunci "admin_token" daripada config.json, kemudian cipta semula container tersebut. Memadam kunci daripada fail adalah penting kerana halaman pentadbir menulis tetapan di sana, dan apa yang ada dalam config.json mengatasi persekitaran. Mengalih keluar pemboleh ubah sahaja akan membiarkan halaman tersebut terbuka.

Tutup pendaftaran sebelum sesiapa menemui domain anda

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED ditetapkan kepada true secara lalai. Biarkan tetapan tersebut dan sesiapa sahaja yang melayari domain anda boleh mendapatkan akaun, dan data mereka akan disimpan dalam db.sqlite3 yang sama dengan data anda. Tetapkan kepada false dan tambah pengguna melalui jemputan daripada halaman admin, yang memerlukan SMTP berfungsi. INVITATIONS_ALLOWED juga ditetapkan kepada true secara lalai dan membenarkan pemilik organisasi menjemput orang lain. Ini boleh diterima jika anda mempercayai pengguna anda, dan ia sepatutnya ditetapkan kepada false pada instans pengguna tunggal. Jika hanya domain tertentu yang dibenarkan mendaftar, SIGNUPS_DOMAINS_WHITELIST=example.com adalah lebih terhad berbanding pendaftaran terbuka tetapi jauh lebih lemah berbanding sistem jemputan.

SHOW_PASSWORD_HINT ditetapkan kepada false secara lalai dan harus dikekalkan sedemikian. Dengan tetapan ini diaktifkan, menaip alamat e-mel yang sah ke dalam borang log masuk akan memaparkan petunjuk kata laluan induk akaun tersebut, yang mendedahkan petunjuk itu serta mengesahkan bahawa alamat e-mel tersebut wujud.

Jika instans anda pernah beroperasi dengan pendaftaran terbuka untuk tempoh tertentu, buka halaman admin dan semak senarai pengguna sebelum anda menganggap bahawa anda adalah satu-satunya akaun yang ada.

Port yang tidak sepatutnya anda terbitkan

Imej Docker mendengar pada port 80 di dalam kontena. Pemasangan bare-metal menggunakan ROCKET_PORT=8000 sebagai lalai. Arahan run yang didokumentasikan menerbitkan port tersebut seperti berikut:

--publish 127.0.0.1:8000:80

Awalan 127.0.0.1: adalah tujuan utama arahan tersebut. Tulis -p 8000:80 sebaliknya dan Docker akan mengikat 0.0.0.0, dan ia melakukannya dengan menulis peraturan DNAT (destination network address translation) ke dalam jadual nat. Peraturan tersebut dinilai sebelum rantaian filter yang diuruskan oleh ufw, jadi ufw status melaporkan port tersebut sebagai dinafikan sedangkan port itu masih menjawab permintaan daripada internet dengan lancar. Mekanisme penuh ini wajar dibaca dalam panduan mengenai port Docker yang memintas ufw.

Semak apa yang sebenarnya sedang mendengar:

sudo ss -tlnp | grep 8000

Hasil yang sihat ialah satu baris yang terikat pada 127.0.0.1:8000. Baris yang terikat pada 0.0.0.0:8000 bermakna vault terdedah secara terus. Betulkan pemetaan, kemudian cipta semula kontena, kerana ikatan port ditetapkan semasa kontena dicipta dan docker compose restart tidak akan mengubahnya:

docker compose up -d --force-recreate

Satu lagi port masih wujud dalam panduan lama: 3012, iaitu port WebSocket yang berasingan. Sokongan untuknya telah dibuang dalam Vaultwarden 1.31.0, kerana trafik pemberitahuan telah dipindahkan ke port HTTP utama. WEBSOCKET_ENABLED dan WEBSOCKET_PORT telah diabaikan sejak versi 1.29.0. Suis semasa ialah ENABLE_WEBSOCKET, yang menggunakan true sebagai lalai. Jika firewall atau fail compose anda masih membuka port 3012, tutup port tersebut.

Tamatkan TLS pada reverse proxy, bukan dalam Rocket

Vaultwarden boleh menyediakan TLS (transport layer security) sendiri melalui Rocket, iaitu kerangka kerja webnya, namun pihak projek menasihatkan agar tidak berbuat demikian dalam persekitaran pengeluaran. TLS terbina dalam Rocket tidak mempunyai sokongan SNI (server name indication) yang ketat, itulah sebabnya nasihat pengukuhan sistem adalah untuk mengakses instans anda melalui hostname dan bukannya alamat IP. Julat IP awam diimbas secara berterusan, dan vault yang menjawab pada alamat IP adalah vault yang mudah ditemui.

Bahagian blok pelayan nginx yang penting:

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;
}

nginx menetapkan client_max_body_size secara lalai kepada 1 MB, jadi tanpa baris tersebut, muat naik lampiran akan gagal dengan ralat 413 Request Entity Too Large dalam log ralat nginx manakala Vaultwarden tidak mencatatkan apa-apa. Header Upgrade dan Connection membawa jabat tangan WebSocket ke /notifications/hub. Jika anda membuangnya, vault masih berfungsi, tetapi perubahan tidak akan muncul pada peranti anda yang lain sehingga anda memuat semula halaman secara manual.

Caddy lebih ringkas dan memperoleh sijil secara automatik:

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

Kemudian maklumkan kepada Vaultwarden mengenainya:

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

IP_HEADER secara lalai ditetapkan kepada X-Real-IP, jadi tugas anda adalah memastikan proxy benar-benar menetapkan header tersebut. Jika tidak, setiap baris log dan setiap had kadar log masuk akan melihat 127.0.0.1, iaitu proxy itu sendiri, yang bermaksud kegagalan seorang penyerang akan dikira terhadap setiap pengguna pada instans tersebut. Tetapkan DOMAIN kepada URL https yang sebenar juga, kerana Vaultwarden membina pautan jemputan dan tetapan semula kata laluan daripadanya, dan kunci keselamatan WebAuthn terikat pada origin tersebut.

Satu perincian yang sering terlepas pandang: sambungan WebSocket menghantar token sesi dalam rentetan pertanyaan, sebagai /notifications/hub?access_token=[JWT]. Ini akan terpapar dalam log akses proxy anda dalam bentuk teks jelas. Sembunyikan parameter access_token dalam format log, atau pastikan log tersebut tidak dihantar ke mana-mana lokasi yang tidak berada di bawah kawalan anda.

Sekat serangan brute force pada endpoint log masuk

Had kadar (rate limit) diaktifkan secara lalai (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Ia melambatkan penyerang tetapi tidak menghentikannya sepenuhnya. fail2ban mampu melakukannya, namun Vaultwarden perlu menulis fail log terlebih dahulu, dan ia tidak melakukan perkara tersebut secara lalai:

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

Kegagalan log masuk akan menghasilkan tepat satu baris, dan ini adalah rentetan yang perlu dipadankan oleh penapis anda:

[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.

Tulis penapis ke /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

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

Dan jail ke /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

Jika anda mengekalkan halaman admin, tambah jail kedua yang failregex-nya adalah ^.*Invalid admin token\. IP: <ADDR>.*$, kerana kegagalan log masuk admin direkodkan dengan mesej yang berbeza dan penapis log masuk tidak akan mengesannya. Kemudian semak kerja anda:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Jail yang berfungsi akan menyenaraikan fail log anda di bawah File list dan melaporkan Currently failed: 0. Taip kata laluan yang salah sebanyak tiga kali dari rangkaian yang berbeza dan pembilang tersebut akan meningkat, kemudian alamat tersebut akan muncul di bawah Banned IP list. Jika pembilang tidak berubah, punca lazimnya ialah logpath: ia mestilah laluan fail pada hos, bukan laluan /data/... di dalam kontena. Punca lazim kedua ialah ketiadaan X-Real-IP, yang menyebabkan setiap sekatan menyasarkan proksi anda sendiri. Selebihnya persediaan, termasuk jail SSH yang sepatutnya sudah anda jalankan, terdapat dalam panduan fail2ban untuk Ubuntu 24.04.

Kata laluan induk masih merupakan kunci keseluruhan sistem

Penyulitan di sisi klien bermakna kata laluan induk adalah kuncinya. Kata laluan induk yang pendek pada instans yang pangkalan datanya telah disalin oleh penyerang tidak dilindungi oleh apa-apa dalam catatan ini, kerana mereka menyerang salinan tersebut secara luar talian pada kadar yang dibenarkan oleh perkakasan mereka. Tiada tetapan pelayan yang dapat mencapai mesin penyerang sendiri.

PASSWORD_ITERATIONS=600000 ialah kiraan lelaran KDF yang diberikan kepada klien apabila mereka mencipta akaun baharu. Akaun sedia ada mengekalkan nilai yang digunakan semasa ia dicipta, jadi menaikkannya tidak mengubah apa-apa bagi pengguna yang mendaftar tahun lepas. Mereka perlu mengubahnya sendiri dalam tetapan keselamatan peti simpanan web, yang akan menyulitkan semula kunci mereka. Beritahu mereka, kerana tiada apa-apa dalam antara muka yang akan melakukannya.

Kemudian, aktifkan pengesahan dua faktor bagi setiap akaun. Ia tidak melindungi teks sifer, memandangkan kunci peti simpanan datang daripada kata laluan induk sahaja. Ia menghalang kata laluan yang dicuri daripada mencukupi untuk log masuk dan menyegerakkan salinan. REQUIRE_DEVICE_EMAIL=true menambah langkah pengesahan e-mel pada kali pertama akaun log masuk daripada peranti yang tidak dikenali.

Sandaran adalah punca kegagalan peti simpanan (vault) yang dihoskan sendiri

tar czf bagi folder data yang ditinggalkan dalam direktori home pada VPS yang sama akan membatalkan setiap langkah di atas. Arkib tersebut mengandungi db.sqlite3 dengan teks sifer setiap pengguna, rsa_key.pem yang memalsukan sesi log masuk, dan config.json dengan token admin serta kata laluan SMTP dalam teks biasa. Akses baca kepada satu fail itu bermakna akses baca kepada keseluruhan peti simpanan.

Dua peraturan merangkumi perkara ini. Keluarkan arkib dari pelayan tersebut. Sulitkan ia sebelum ia dipindahkan.

Terdapat juga masalah ketepatan. Menyalin db.sqlite3 dengan cp semasa servis sedang berjalan boleh menghasilkan fail yang sedang dalam proses penulisan dan tidak akan dapat dibuka, dan anda tidak akan mengetahuinya sehingga proses pemulihan dilakukan. Gunakan snapshot milik SQLite sendiri sebaliknya:

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

Bahagian pemulihan, iaitu separuh daripada proses yang jarang diuji oleh sesiapa, diterangkan dalam panduan sandaran dan pemulihan Vaultwarden.

Apa yang anda korbankan berbanding Bitwarden yang dihoskan

Perakaunan yang jujur. Perkhidmatan Bitwarden yang dihoskan dikendalikan oleh individu yang tugas sepenuh masa mereka adalah mengendalikannya, dengan audit pihak ketiga yang diterbitkan dan kakitangan yang bersedia dipanggil pada pukul 3 pagi. Self-hosting menggantikan perkara tersebut dengan rentak tampalan (patch) anda sendiri.

Vaultwarden mengeluarkan pembetulan keselamatan sebagai release biasa. Versi 1.37.0, yang dikeluarkan pada 24 Julai 2026, adalah versi semasa setakat Ogos 2026, dan nota keluarannya meminta pengguna untuk mengemas kini secepat mungkin. Instans yang anda sediakan setahun lalu dan dilupakan sedang menjalankan kod berusia setahun. Tag latest tidak membantu dengan sendirinya: kontena yang sedang berjalan mengekalkan imej yang digunakan semasa ia bermula sehingga anda menjalankan docker compose pull dan menciptanya semula. Sediakan unattended upgrades pada Ubuntu untuk pakej hos, dan letakkan kemas kini kontena pada peringatan kalendar yang akan anda baca.

Kesimpulan yang harus dibuat oleh pembaca yang jujur: kriptografi di sini adalah reka bentuk Bitwarden dan ia kekal utuh, manakala risiko operasi beralih sepenuhnya kepada anda. Jika anda menampalnya dan membuat sandaran di tempat lain, instans Vaultwarden pada VPS yang anda kawal adalah tempat yang munasabah untuk menyimpan kata laluan anda. Jika dua tabiat tersebut tidak akan dilakukan, bayar untuk perkhidmatan yang dihoskan dan tumpukan perhatian di tempat lain. Perbandingan ciri demi ciri terdapat dalam Vaultwarden berbanding Bitwarden yang dihoskan sendiri.

Keraskan hos di bawah kontena

Vaultwarden merupakan satu proses pada mesin Linux, dan root pada mesin tersebut boleh membaca /vw-data tidak kira bagaimana aplikasi itu dikonfigurasikan. Jalankan kontena sebagai pengguna tanpa keistimewaan (unprivileged) dengan user: "1000:1000" dalam fail compose anda, dengan folder data dimiliki oleh pengguna yang sepadan, dan lekapkan (mount) apa-apa yang tidak ditulis oleh kontena sebagai baca-sahaja (read-only) dengan :ro. Kemudian tutup pintu masuk: Pengerasan SSH pada VPS merangkumi log masuk berasaskan kunci sahaja dan melumpuhkan pengesahan kata laluan, yang merupakan langkah untuk menghentikan serangan biasa yang melepasi semua perkara di atas.

FAQ

Adakah seseorang boleh membaca kata laluan saya jika mereka mencuri pangkalan data Vaultwarden?

Tidak secara terus. Setiap item dalam peti simpanan disulitkan pada klien menggunakan kunci yang diterbitkan daripada kata laluan induk, jadi db.sqlite3 mengandungi teks sifer (ciphertext). Apa yang mereka peroleh serta-merta ialah alamat e-mel setiap akaun, tetapan KDF, metadata log masuk dan peranti, serta rahsia dua faktor dalam jadual twofactor, yang disimpan tanpa penyulitan kerana pelayan perlu mengira kod yang dijangkakan. Mereka juga boleh menyerang teks sifer peti simpanan secara luar talian selama mana yang mereka mahu, itulah sebabnya panjang kata laluan induk adalah angka yang menentukan hasilnya.

Patutkah saya menggunakan ADMIN_TOKEN atau melumpuhkan halaman admin sepenuhnya?

Lumpuhkan halaman tersebut jika boleh, kerana kebanyakan instans hanya memerlukannya sekali untuk mengkonfigurasi SMTP dan menjemput pengguna, dan tidak lagi selepas itu. Untuk melumpuhkannya, jangan tetapkan ADMIN_TOKEN mahupun DISABLE_ADMIN_TOKEN, buang sebarang kunci "admin_token" daripada config.json, kemudian cipta semula kontena tersebut. Membuang pemboleh ubah persekitaran sahaja tidak mencukupi, kerana tetapan yang ditulis oleh halaman admin disimpan dalam config.json dan mempunyai keutamaan lebih tinggi. Jika anda mengekalkan halaman tersebut, simpan token sebagai hash Argon2 yang dihasilkan oleh vaultwarden hash dan bukannya rentetan rawak teks biasa, serta tetapkan ADMIN_RATELIMIT_MAX_BURST=3.

ADMIN_TOKEN saya betul tetapi /admin menolaknya. Apa yang salah?

Hampir selalu disebabkan oleh interpolasi $. Rentetan PHC Argon2 mengandungi beberapa aksara $, dan Docker Compose mengembangkannya sebagai pemboleh ubah di dalam blok docker-compose.yml environment:, jadi kontena menerima nilai yang rosak walaupun fail anda kelihatan betul. Gandakan setiap $ kepada $$ dalam fail compose, atau pindahkan nilai tersebut ke dalam fail .env yang dibalut dengan tanda petik tunggal, di mana tiada pelarian (escaping) diperlukan. Cipta semula kontena selepas itu, kerana perubahan persekitaran tidak diambil kira melalui proses but semula (restart).

Adakah saya masih perlu membuka port 3012 untuk pemberitahuan?

Tidak. Sokongan untuk trafik WebSocket pada port 3012 telah dibuang dalam Vaultwarden 1.31.0 kerana pemberitahuan telah dipindahkan ke port HTTP utama, dan WEBSOCKET_ENABLED serta WEBSOCKET_PORT telah diabaikan sejak versi 1.29.0. Tetapan semasa ialah ENABLE_WEBSOCKET, yang ditetapkan kepada true secara lalai. Tutup port 3012 dalam firewall dan padamkannya daripada fail compose anda, kemudian pastikan reverse proxy anda memajukan header Upgrade dan Connection, kerana itulah perkara yang sebenarnya diperlukan oleh penyelarasan masa nyata sekarang.