Vaultwarden è sicuro? Guida all’hardening

Vaultwarden è sicuro? La risposta breve

Vaultwarden è sicuro nel punto più importante, perché ogni elemento del vault viene cifrato sul dispositivo prima di raggiungere il server. Il server memorizza dati binari che non può leggere. Anche chi copia l’intero database deve conoscere la password principale per ricavarne informazioni utili.

Questa risposta presuppone molte condizioni, e i problemi si verificano proprio nelle parti configurate dall’utente. Un pannello di amministrazione protetto da un token facilmente indovinabile. Una porta del container pubblicata sull’intera Internet. Un config.json in chiaro. Un archivio tar di backup lasciato nella home directory sullo stesso host. Nessuno di questi è un problema di crittografia. Sono tutti motivi per cui i vault self-hosted vengono svuotati.

Tutto ciò che segue presuppone un’installazione funzionante. Se non ne hai ancora una, configurala prima seguendo la guida all’installazione di Vaultwarden su un VPS, quindi torna qui e segui questo elenco dall’inizio alla fine.

Cosa archivia realmente il server

Vaultwarden implementa il modello dati di Bitwarden. Il nome, il nome utente, la password, le note e gli URI di un elemento del vault vengono cifrati nel client con una chiave derivata dalla password principale, prima dell'invio di qualsiasi richiesta. Anche il contenuto dei file allegati viene cifrato nello stesso modo. Il server riceve dati opachi associati a un UUID (identificatore univoco universale).

Alcuni dati non sono cifrati. È importante sapere esattamente quali:

• L'indirizzo email dell'account, in chiaro.
• Le impostazioni e il salt della KDF (funzione di derivazione della chiave), perché il client deve usarli per ricostruire la chiave al login successivo.
• Un hash lato server dell'hash della password principale inviato dal client, usato per autenticare il login.
• Metadati: appartenenza alle organizzazioni, nomi dei dispositivi, orari degli ultimi login.
• Il secret del metodo a due fattori che protegge il login a Vaultwarden. Si trova non cifrato nella tabella twofactor, perché il server deve calcolare il codice atteso e confrontarlo con il tuo. Non è lo stesso secret TOTP (password monouso basata sul tempo) che memorizzi all'interno di un elemento del vault, cifrato come qualsiasi altro campo.

La directory dei dati è di piccole dimensioni. In un'installazione Docker corrisponde al percorso montato in /data.

sudo ls -l /vw-data/

db.sqlite3 contiene quasi tutto lo stato. attachments/ contiene i file caricati, uno per UUID, ed è l'unica categoria importante di dati che non si trova nelle tabelle del database. sends/ contiene gli allegati di Send ed è destinata a contenuti temporanei. icon_cache/ contiene dati temporanei. rsa_key.pem e i file associati firmano i JWT (JSON Web Token) degli utenti autenticati. Una copia di quella chiave privata può quindi essere usata per falsificare una sessione di login al vault. config.json esiste solo dopo l'abilitazione della pagina di amministrazione e il progetto è esplicito al riguardo: contiene il token di amministrazione e le credenziali SMTP in chiaro.

Il modello pratico delle minacce riguarda quindi l'accesso al filesystem, non la crittografia di rete. L'accesso in lettura a quella sola directory espone gli indirizzi email di tutti gli utenti, i secret per la 2FA del login, una chiave con cui falsificare le sessioni e una copia offline di ogni vault, che può essere sottoposta ad attacchi senza limiti di tempo. Ogni passaggio seguente serve a impedire l'accesso non autorizzato a quella directory.

Correggere prima il token di amministrazione

/admin è un pannello di controllo completo: elenco utenti, inviti, eliminazione, ogni impostazione di runtime. È protetto da un unico segreto condiviso e nient'altro. Nessun nome utente. Nessuna autenticazione a due fattori per utente.

Le guide meno recenti suggeriscono di generare ADMIN_TOKEN con openssl rand -base64 48. Funziona, e scrive il segreto in chiaro in config.json e nel file compose. Vaultwarden accetta anche una stringa Argon2 PHC (password hashing competition), in modo che il valore memorizzato sia un hash. Generane una con un container in esecuzione:

docker exec -it vaultwarden /vaultwarden hash

Oppure senza toccare affatto il container in esecuzione:

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

Ti verrà chiesta una password due volte, dopodiché verrà stampata una riga che inizia con $argon2id$. Su un'installazione bare-metal, esegui ./vaultwarden hash. Se preferisci utilizzare direttamente la CLI argon2, il progetto documenta i parametri minimi OWASP:

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

Ora la trappola che fa perdere un'ora. Una stringa PHC è piena di caratteri $, e Docker Compose interpreta $ come interpolazione di variabili. Se la incolli senza escape in un blocco environment:, il valore che raggiunge il container viene corrotto, quindi /admin rifiuta un token che sai essere corretto. Esistono due forme sicure. In docker-compose.yml, raddoppia ogni $:

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

In un file .env, non è necessario alcun escape, ma usa le virgolette singole:

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

Quindi limita la frequenza di accesso al pannello e riduci la durata della sessione:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Dopo tre tentativi falliti entro cinque minuti, il pannello smette di rispondere a quel client. La sessione di amministrazione scade 20 minuti dopo l'accesso, indipendentemente dal fatto che tu stia ancora utilizzando il pannello, poiché l'attività non ne estende la durata.

Meglio di tutto questo: disattiva la pagina. La maggior parte delle istanze ne ha bisogno una sola volta, per configurare SMTP e invitare i primi utenti, e mai più. Per disabilitarla, non impostare né ADMIN_TOKEN né DISABLE_ADMIN_TOKEN, rimuovi qualsiasi chiave "admin_token" da config.json, quindi ricrea il container. Eliminare la chiave dal file è importante perché la pagina di amministrazione vi scrive le impostazioni, e ciò che è presente in config.json prevale sull'ambiente. Rimuovere solo la variabile lascia la pagina aperta.

Chiudere le registrazioni prima che qualcuno trovi il dominio

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED è impostato su true per impostazione predefinita. Se lo lasci così, chiunque raggiunga il tuo dominio può creare un account e i suoi dati verranno salvati nello stesso db.sqlite3 dei tuoi. Impostalo su false e aggiungi le persone tramite inviti dalla pagina di amministrazione, che richiede un servizio SMTP funzionante. Anche INVITATIONS_ALLOWED è true per impostazione predefinita e consente agli amministratori dell'organizzazione di invitare altri utenti. Questo è accettabile quando ti fidi dei tuoi utenti, ma dovrebbe essere false su un'istanza a utente singolo. Se solo determinati domini devono poter effettuare la registrazione, SIGNUPS_DOMAINS_WHITELIST=example.com è più restrittivo rispetto all'iscrizione aperta, ma molto meno sicuro rispetto agli inviti.

SHOW_PASSWORD_HINT è false per impostazione predefinita e dovrebbe rimanere tale. Con questa opzione attiva e senza SMTP configurato, inserire un indirizzo email valido nel modulo di accesso restituisce il suggerimento per la master password di quell'account; ciò comporta sia la fuga del suggerimento che la conferma dell'esistenza dell'indirizzo.

Se la tua istanza è rimasta con le registrazioni aperte per un qualsiasi periodo di tempo, apri la pagina di amministrazione e controlla l'elenco degli utenti prima di dare per scontato di essere l'unico account presente.

La porta che non intendevi pubblicare

L'immagine Docker rimane in ascolto sulla porta 80 all'interno del container. Un'installazione bare-metal utilizza di default la ROCKET_PORT=8000. Il comando di esecuzione documentato la pubblica in questo modo:

--publish 127.0.0.1:8000:80

Il prefisso 127.0.0.1: è il punto cruciale. Scrivendo invece -p 8000:80, Docker esegue il bind su 0.0.0.0, operazione che avviene scrivendo regole DNAT (destination network address translation) nella tabella nat. Tali regole vengono valutate prima delle catene filter gestite da ufw; di conseguenza, ufw status segnala la porta come negata, mentre la porta risponde tranquillamente a Internet. Il meccanismo completo merita di essere approfondito nella guida alle porte Docker che aggirano ufw.

Verifica cosa è realmente in ascolto:

sudo ss -tlnp | grep 8000

Un risultato corretto è una singola riga associata a 127.0.0.1:8000. Una riga associata a 0.0.0.0:8000 indica che il vault è esposto direttamente. Correggi il mapping e ricrea il container, poiché il binding di una porta viene fissato al momento della creazione del container e docker compose restart non lo modificherà:

docker compose up -d --force-recreate

Un'ulteriore porta sopravvive nelle vecchie guide: 3012, la porta separata per i WebSocket. Il supporto per questa porta è stato rimosso in Vaultwarden 1.31.0, poiché il traffico delle notifiche è stato spostato sulla porta HTTP principale. WEBSOCKET_ENABLED e WEBSOCKET_PORT sono deprecate dalla versione 1.29.0 e vengono ignorate. L'opzione attuale è ENABLE_WEBSOCKET, che ha come valore predefinito true. Se il tuo firewall o il tuo file compose aprono ancora la porta 3012, chiudila.

Terminare TLS su un reverse proxy, non in Rocket

Vaultwarden può gestire TLS (transport layer security) direttamente tramite Rocket, il suo framework web, ma il progetto sconsiglia questa pratica in produzione. Il supporto TLS integrato in Rocket non gestisce correttamente SNI (server name indication); per questo motivo, le linee guida di sicurezza raccomandano di raggiungere l'istanza tramite hostname e mai tramite indirizzo IP. Gli intervalli di IP pubblici sono scansionati costantemente: un vault che risponde a un indirizzo IP è un vault che viene individuato.

Le parti rilevanti di un blocco server 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;
}

nginx imposta client_max_body_size a 1 MB per impostazione predefinita; senza questa riga, il caricamento di un allegato fallisce con 413 Request Entity Too Large nel log degli errori di nginx, mentre Vaultwarden non registra nulla. Gli header Upgrade e Connection gestiscono l'handshake WebSocket verso /notifications/hub. Se vengono omessi, il vault continua a funzionare, ma le modifiche non appaiono sugli altri dispositivi finché non si ricarica la pagina manualmente.

Caddy è più conciso e ottiene il certificato autonomamente:

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

Successivamente, è necessario configurare Vaultwarden:

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

IP_HEADER è impostato di default su X-Real-IP; il compito principale è assicurarsi che il proxy imposti correttamente tale header. Vaultwarden accetta l'header solo da indirizzi elencati in IP_HEADER_TRUSTED_PROXIES, che di default è local: qualsiasi indirizzo non globale, il che include un proxy sullo stesso host o sulla stessa rete Docker. Un proxy che si connette da un indirizzo pubblico deve essere aggiunto a tale lista. Se l'header manca o proviene da un indirizzo non attendibile, ogni riga di log e ogni limite di frequenza (rate limit) per il login vedrà l'indirizzo del proxy stesso; ciò significa che i tentativi falliti di un attaccante verranno conteggiati contro ogni utente dell'istanza. Se si utilizza IP_HEADER=X-Forwarded-For, la versione 1.37.4 seleziona l'indirizzo più a destra che non sia un proxy attendibile; pertanto, è necessario elencare ogni proxy nella catena, inclusa una eventuale CDN davanti a nginx. Impostare DOMAIN sull'URL https reale, poiché Vaultwarden lo utilizza per generare i link di invito e di reset della password, e le chiavi di sicurezza WebAuthn sono vincolate a tale origine.

Un dettaglio spesso trascurato: la connessione WebSocket trasmette il token di sessione nella query string, come /notifications/hub?access_token=[JWT]. Questo dato finisce in chiaro nel log degli accessi del proxy. È necessario oscurare il parametro access_token nel formato di log, oppure assicurarsi che tali log non vengano inviati in posizioni non controllate.

Bloccare il brute force sull'endpoint di login

I rate limit sono attivi per impostazione predefinita (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Rallentano un attaccante, ma non lo fermano. fail2ban lo fa, ma necessita di leggere i tentativi di accesso falliti di Vaultwarden da qualche parte. In Docker la via più semplice è un file di log, che Vaultwarden non scrive nativamente:

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

Un login fallito genera esattamente una riga; questa è la stringa che il filtro deve intercettare:

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

Scrivi il filtro in /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

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

E la jail in /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

Se Vaultwarden è eseguito come servizio systemd anziché in un container, puoi saltare LOG_FILE: la wiki di fail2ban del progetto legge il journal con backend = systemd e un journalmatch sull'unità Vaultwarden al posto di logpath.

Se hai mantenuto la pagina di amministrazione, aggiungi una seconda jail il cui failregex sia ^.*Invalid admin token\. IP: <ADDR>.*$, poiché i fallimenti dell'amministratore vengono registrati con un messaggio diverso e il filtro di login non li vedrebbe mai. Verifica quindi il lavoro:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Una jail funzionante elenca il tuo file di log sotto File list e riporta Currently failed: 0. Digita una password errata tre volte da una rete diversa: il contatore aumenterà e l'indirizzo apparirà sotto Banned IP list. Se il contatore non si muove, la causa abituale è logpath: deve essere il percorso del file sull'host, non il percorso /data/... interno al container. La seconda causa comune è un X-Real-IP mancante o non attendibile, che fa sì che ogni ban colpisca il tuo proxy. Il resto della configurazione, inclusa la jail SSH che dovresti già avere attiva, si trova nella guida a fail2ban per Ubuntu 24.04.

La master password rimane il fulcro dell'intero sistema

La crittografia lato client implica che la master password sia la chiave. Una master password breve su un'istanza di cui un attaccante ha copiato il database non è protetta da quanto descritto in questo post, poiché l'attaccante può colpire tale copia offline alla velocità consentita dal proprio hardware. Nessuna impostazione del server ha effetto sulla macchina dell'attaccante.

PASSWORD_ITERATIONS=600000 è facile da interpretare erroneamente. Imposta le iterazioni per l'hash lato server dell'hash di login inviato dal client, e il template di configurazione del progetto indica che un valore modificato viene applicato agli utenti esistenti al loro login successivo. Non influisce sul KDF lato client, che è l'impostazione che determina quanto sia oneroso un attacco offline al vault. Tale parametro appartiene a ogni singolo account e viene modificato in Impostazioni, Sicurezza, Chiavi nel web vault, operazione che riesegue la cifratura della chiave. La documentazione di Bitwarden afferma che i suoi client, a partire dalla versione 2026.2.1, aumentano automaticamente le impostazioni PBKDF2 inferiori a 600.000 iterazioni quando l'utente effettua l'accesso o sblocca il vault con la master password. Al 10 ottobre 2026 tale comportamento non è confermato su un server Vaultwarden e non modifica mai le impostazioni Argon2id. Pertanto, chi si è registrato anni fa potrebbe avere ancora un'impostazione KDF obsoleta e inferiore. Verificate e informate gli utenti, poiché il server non può farlo per loro.

Abilitate quindi l'autenticazione a due fattori per ogni account. Questa non protegge il testo cifrato, poiché la chiave del vault deriva esclusivamente dalla master password. Impedisce tuttavia che una password rubata sia sufficiente per accedere e sincronizzare una copia. REQUIRE_DEVICE_EMAIL=true rende obbligatoria l'email di notifica per l'accesso da nuovi dispositivi: se Vaultwarden non è in grado di inviarla, il login fallisce, garantendo che un accesso da un dispositivo non riconosciuto non passi mai inosservato. È necessario un servizio SMTP funzionante, altrimenti ogni tentativo di login da un nuovo dispositivo verrà rifiutato.

Dove i backup dei vault self-hosted presentano problemi

Una tar czf della directory dei dati, lasciata nella home directory dello stesso VPS, annulla tutti i passaggi precedenti. L'archivio contiene db.sqlite3 con il testo cifrato di ogni utente, rsa_key.pem che consente di falsificare le sessioni di accesso e config.json con il token amministrativo e la password SMTP in chiaro. L'accesso in lettura a quel file equivale all'accesso in lettura al vault.

Sono sufficienti due regole. Trasferire l'archivio fuori dal server. Crittografarlo prima del trasferimento.

Esiste anche un problema di integrità. Copiare db.sqlite3 con cp mentre il servizio è in esecuzione può produrre un file in fase di scrittura che non potrà essere aperto. Questo problema potrebbe emergere soltanto durante il ripristino. Usare invece lo snapshot nativo di SQLite:

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

La procedura di ripristino, che spesso non viene mai verificata, è descritta nella guida al backup e al ripristino di Vaultwarden.

Cosa si perde rispetto al servizio Bitwarden in hosting

Un'analisi onesta. Il servizio in hosting di Bitwarden è gestito da personale il cui lavoro a tempo pieno è la manutenzione, con audit di terze parti pubblicati e reperibilità garantita anche alle 3 del mattino. L'hosting in proprio sostituisce tutto ciò con il tuo piano di aggiornamento.

Vaultwarden rilascia le patch di sicurezza come normali release, e lo fa spesso. Verificato il 10 ottobre 2026 tramite il feed delle release del progetto, la versione corrente è la 1.37.4, pubblicata il 5 ottobre 2026. Le note includono sette avvisi di sicurezza, il più grave dei quali classificato come High, e raccomandano vivamente di aggiornare il prima possibile. Si tratta della quarta release dopo la 1.37.0 del 24 luglio 2026: la 1.37.1 è seguita il 29 luglio, la 1.37.2 il 22 agosto (necessaria per i client versione 2026.8.0 e successive) e la 1.37.3 il 13 settembre, che revoca i token di "ricorda 2FA" quando le credenziali o il 2FA vengono modificati e impone limiti di rate limiting agli endpoint di prelogin e di richiesta autenticazione. Se gestisci organizzazioni con amministratori di cui non ti fidi pienamente, le note della 1.37.4 suggeriscono anche di ruotare la chiave API di ogni organizzazione dopo l'aggiornamento. La 1.37.4 modifica inoltre l'indirizzo letto da X-Forwarded-For, trattato nella sezione sul reverse proxy qui sopra. Un'istanza configurata un anno fa e dimenticata sta eseguendo codice vecchio di un anno. Il tag latest non è d'aiuto da solo: un container in esecuzione mantiene l'immagine con cui è stato avviato finché non esegui docker compose pull e lo ricrei. Implementa aggiornamenti automatici su Ubuntu per i pacchetti dell'host e imposta un promemoria sul calendario per l'aggiornamento del container che leggerai effettivamente.

La conclusione che un lettore onesto dovrebbe trarre: la crittografia qui è quella progettata da Bitwarden e rimane solida, mentre il rischio operativo ricade interamente su di te. Se applichi le patch ed esegui backup altrove, un'istanza Vaultwarden su una VPS sotto il tuo controllo è un luogo ragionevole dove conservare le tue password. Se non intendi adottare queste due abitudini, paga per il servizio in hosting e dedica le tue attenzioni ad altro. Il confronto funzione per funzione è disponibile in Vaultwarden a confronto con Bitwarden self-hosted.

Rafforza la sicurezza dell'host sottostante al container

Vaultwarden è un processo in esecuzione su un sistema Linux e l'account root di quel sistema può leggere /vw-data, indipendentemente dalla configurazione dell'applicazione. Esegui il container con un utente senza privilegi usando user: "1000:1000" nel file compose e assegna la proprietà della cartella dei dati in modo coerente. Monta quindi in sola lettura tutto ciò che il container non deve modificare, usando :ro. Chiudi infine il punto di accesso principale: la guida Rafforzare SSH su un VPS descrive l'accesso basato esclusivamente su chiavi e la disattivazione dell'autenticazione tramite password. In questo modo impedisci l'attacco più semplice, che altrimenti potrebbe aggirare tutte le misure precedenti.

FAQ

Qualcuno può leggere le mie password se ruba il database di Vaultwarden?

Non direttamente. Ogni elemento del vault viene cifrato nel client con una chiave derivata dalla master password, quindi db.sqlite3 contiene solo testo cifrato. Ciò che un attaccante ottiene immediatamente sono l'indirizzo email di ogni account, le impostazioni KDF, i metadati di login e dei dispositivi, e i secret per la doppia autenticazione nella tabella twofactor, che sono memorizzati in chiaro poiché il server deve calcolare il codice atteso. L'attaccante può inoltre tentare di forzare il testo cifrato del vault offline per tutto il tempo che desidera; ecco perché la lunghezza della master password è il fattore che determina l'esito.

Dovrei usare ADMIN_TOKEN o disabilitare completamente la pagina di amministrazione?

Disabilitala se puoi, dato che la maggior parte delle istanze ne ha bisogno una sola volta per configurare SMTP e invitare gli utenti, e mai più. Per disabilitarla, non impostare né ADMIN_TOKEN né DISABLE_ADMIN_TOKEN, rimuovi qualsiasi chiave "admin_token" da config.json, quindi ricrea il container. Rimuovere solo la variabile d'ambiente non è sufficiente, perché le impostazioni scritte dalla pagina di amministrazione risiedono in config.json e hanno la precedenza. Se decidi di mantenere la pagina, memorizza il token come hash Argon2 prodotto da vaultwarden hash invece di una stringa casuale in chiaro, e imposta ADMIN_RATELIMIT_MAX_BURST=3.

Il mio ADMIN_TOKEN è corretto ma /admin lo rifiuta. Cosa c'è che non va?

Quasi sempre si tratta di un problema di interpolazione di $. Una stringa Argon2 PHC contiene diversi caratteri $ e Docker Compose li espande come variabili all'interno di un blocco docker-compose.yml environment:; di conseguenza, il container riceve un valore corrotto anche se il tuo file sembra corretto. Raddoppia ogni $ in $$ nel file compose, oppure sposta il valore in un file .env racchiuso tra virgolette singole, dove non è necessario alcun escape. Ricrea il container dopo la modifica, poiché i cambiamenti alle variabili d'ambiente non vengono recepiti con un semplice riavvio.

Devo ancora aprire la porta 3012 per le notifiche?

No. Il supporto per il traffico WebSocket sulla porta 3012 è stato rimosso in Vaultwarden 1.31.0 poiché le notifiche sono state spostate sulla porta HTTP principale; inoltre, WEBSOCKET_ENABLED e WEBSOCKET_PORT sono deprecati dalla versione 1.29.0 e vengono ignorati. L'impostazione attuale è ENABLE_WEBSOCKET, che è true per impostazione predefinita. Chiudi la porta 3012 nel firewall ed eliminala dal tuo file compose, quindi assicurati che il tuo reverse proxy inoltri gli header Upgrade e Connection, poiché è da questi che dipende ora la sincronizzazione in tempo reale.