O Vaultwarden é seguro? Como reforçar a instalação

O Vaultwarden é seguro? A resposta curta

O Vaultwarden é seguro no ponto mais importante, porque cada item do cofre é encriptado no seu dispositivo antes de chegar ao servidor. O servidor armazena o conteúdo encriptado do cofre juntamente com metadados da conta em texto simples. Quem copiar a base de dados completa ainda precisa das chaves de encriptação do cofre para ler o conteúdo, mas obtém imediatamente os endereços de email das contas e as sugestões de palavras-passe.

Essa resposta depende de muitos fatores, e os problemas surgem nas partes que você configura. Um painel de administração protegido apenas por um token fácil de adivinhar. Uma porta do contentor publicada para toda a Internet. Um config.json em texto simples. Um ficheiro tar de backup guardado no diretório pessoal do mesmo servidor. Nenhum desses casos é um problema de criptografia. Todos explicam por que os cofres auto-hospedados acabam esvaziados.

Tudo abaixo pressupõe uma instalação funcional. Se ainda não tiver uma, configure-a primeiro com o guia de instalação do Vaultwarden para um VPS e depois siga esta lista pela ordem apresentada.

O que o servidor armazena efetivamente

O Vaultwarden implementa o modelo de dados do Bitwarden. O nome, nome de utilizador, palavra-passe, notas e URIs de um item do cofre são cifrados no cliente com uma chave de item gerada aleatoriamente antes de qualquer pedido ser enviado. Essa chave é protegida pela chave simétrica do utilizador ou da organização; a chave derivada da palavra-passe protege a chave simétrica do utilizador. O conteúdo dos ficheiros anexados usa uma chave de anexos separada, protegida pela chave do item. O servidor recebe dados opacos associados a um UUID (identificador universalmente único).

Alguns dados não são texto cifrado. Deve saber exatamente quais:

• O endereço de email da conta e a sugestão da palavra-passe principal, em texto simples.
• As definições da KDF (função de derivação de chaves) e o salt, porque o cliente precisa deles para reconstruir a chave no início do próximo login.
• Um hash no servidor do hash da palavra-passe principal enviado pelo cliente, usado para autenticar o próprio login.
• Metadados: pertença a organizações, nomes dos dispositivos e horas do último login.
• O segredo TOTP para o login de dois fatores baseado num autenticador. Fica na tabela twofactor sem cifragem, porque o servidor tem de calcular o código esperado para o comparar com o seu. Este não é o mesmo que um segredo TOTP (palavra-passe de uso único baseada no tempo) guardado dentro de um item do cofre, que é cifrado como qualquer outro campo.

A pasta de dados é pequena. Numa instalação Docker, corresponde ao caminho que montou em /data.

sudo ls -l /vw-data/

db.sqlite3 contém quase todo o estado. attachments/ contém os ficheiros carregados, organizados em diretórios UUID, fora das tabelas da base de dados. sends/ contém anexos do Send e destina-se a ser temporário. icon_cache/ pode ser eliminado. rsa_key.pem e os ficheiros associados assinam os JWTs (tokens Web JSON) dos utilizadores autenticados. Por isso, uma cópia dessa chave privada pode ser usada para forjar uma sessão de login no cofre. config.json armazena as definições guardadas através da página de administração, incluindo as credenciais SMTP em texto simples e o valor configurado do token de administração. Seguir as instruções de Argon2 abaixo faz com que seja armazenado um hash do token de administração, em vez da palavra-passe em texto simples.

Assim, o modelo de ameaça prático é o acesso ao sistema de ficheiros, não a criptografia da rede. O acesso de leitura a esse diretório fornece o endereço de email de cada utilizador, os respetivos segredos de 2FA de login, uma chave que permite forjar sessões e uma cópia offline de cada cofre para ataques posteriores. Cada passo abaixo existe para impedir o acesso de terceiros a esse diretório.

Corrija primeiro o token de administração

/admin é um painel de controlo completo: lista de utilizadores, convites, eliminação e todas as definições de execução. Está protegido apenas por um segredo partilhado. Não existe nome de utilizador. Não existe autenticação de dois fatores por utilizador.

Os guias antigos indicam gerar ADMIN_TOKEN com openssl rand -base64 48. Isso funciona, mas deixa o segredo em texto simples onde quer que o configure. O Vaultwarden também aceita uma string PHC do Argon2 (password hashing competition), pelo que o valor armazenado passa a ser um hash. Gere uma contra um contentor em execução:

docker exec -it vaultwarden /vaultwarden hash

Ou sem tocar no contentor em execução:

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

O comando pede a palavra-passe duas vezes e depois apresenta uma linha que começa por $argon2id$. Numa instalação bare-metal, execute ./vaultwarden hash. Se preferir usar diretamente a CLI argon2, o projeto documenta os parâmetros mínimos da OWASP:

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

Agora, o problema que pode custar uma hora. Uma string PHC contém muitos caracteres $, e o Docker Compose trata $ como interpolação de variáveis. Se a colar sem escape num bloco environment:, o valor que chega ao contentor fica alterado, pelo que /admin rejeita um token que sabe estar correto. Existem duas formas seguras. Em docker-compose.yml, duplique cada $:

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

Num ficheiro .env, não é necessário fazer escape, mas use aspas simples:

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

Depois, limite a taxa de pedidos ao painel e reduza a duração da sessão:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Isto permite uma rajada de três pedidos de início de sessão de administração por endereço IP do cliente. Depois, a disponibilidade é reposta à taxa de um pedido a cada cinco minutos. As palavras-passe corretas e incorretas contam, porque o limitador é executado antes da validação da palavra-passe. Os pedidos acima do limite recebem HTTP 429 com Too many requests, try again later. A sessão de administração expira 20 minutos depois do início de sessão, mesmo que ainda esteja a utilizar o painel, porque a atividade não prolonga a sessão.

Melhor do que tudo isto: desative a página. A maioria das instâncias precisa dela uma vez, para configurar o SMTP e convidar os primeiros utilizadores, e nunca mais. Para a desativar, não defina ADMIN_TOKEN nem DISABLE_ADMIN_TOKEN, remova qualquer chave "admin_token" de config.json e recrie o contentor. É importante remover a chave do ficheiro porque a página de administração escreve as definições nesse ficheiro, e o valor em config.json tem precedência sobre o ambiente. Remover apenas a variável deixa a página aberta.

Feche o registo antes que alguém encontre o domínio

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED é true por predefinição. Se deixar essa configuração, qualquer pessoa que aceda ao seu domínio pode criar uma conta, e os respetivos dados ficam no mesmo db.sqlite3 que os seus. Defina-a como false e adicione pessoas através de convites na página de administração; o SMTP envia o email de convite. Sem SMTP, o servidor regista um convite para esse endereço. INVITATIONS_ALLOWED também é true por predefinição e permite que os administradores das organizações convidem outras pessoas. Isso é aceitável quando confia nos seus utilizadores, mas deve ser false numa instância para um único utilizador. Se apenas determinados domínios devem poder efetuar registos, SIGNUPS_DOMAINS_WHITELIST=example.com é mais restrito do que o registo aberto e muito menos seguro do que os convites.

SHOW_PASSWORD_HINT é false por predefinição e deve permanecer assim. Com essa opção ativada e sem SMTP configurado, introduzir um endereço de email válido no formulário de início de sessão devolve a dica da palavra-passe principal dessa conta. Isto expõe a dica e confirma que o endereço existe.

Se a sua instância teve os registos abertos durante algum tempo, abra a página de administração e consulte a lista de utilizadores antes de presumir que é a única conta existente.

A porta que você não pretendia publicar

A imagem Docker escuta na porta 80 dentro do contentor. Uma instalação em bare metal usa ROCKET_PORT=8000 por predefinição. O comando de execução documentado publica essa porta da seguinte forma:

--publish 127.0.0.1:8000:80

O prefixo 127.0.0.1: é o objetivo principal. Se escrever -p 8000:80, o Docker associa 0.0.0.0 e faz isso escrevendo regras DNAT (tradução de endereços de rede de destino) na tabela nat. Essas regras são avaliadas antes das cadeias filter que o ufw gere. Por isso, ufw status indica que a porta foi negada, enquanto a porta continua a responder alegremente à Internet. Vale a pena consultar o mecanismo completo em guia sobre portas Docker que contornam o ufw.

Verifique o que está realmente a escutar:

sudo ss -tlnp | grep 8000

Um resultado correto contém uma única linha associada a 127.0.0.1:8000. Uma linha associada a 0.0.0.0:8000 significa que o vault está exposto diretamente. Corrija o mapeamento e recrie o contentor, porque a associação da porta é definida quando o contentor é criado e docker compose restart não a altera:

docker compose up -d --force-recreate

Há ainda outra porta presente em guias antigos: 3012, a porta separada do WebSocket. O suporte para essa porta foi removido no Vaultwarden 1.31.0, porque o tráfego de notificações passou para a porta HTTP principal. WEBSOCKET_ENABLED e WEBSOCKET_PORT estão obsoletos desde a versão 1.29.0 e são ignorados. A opção atual é ENABLE_WEBSOCKET, que usa true por predefinição. Se o firewall ou o ficheiro compose ainda abrir a porta 3012, feche-a.

Termine o TLS num reverse proxy, não no Rocket

O Vaultwarden pode servir TLS (transport layer security) através do Rocket, o seu web framework, mas o projeto recomenda que não faça isso em produção. O TLS integrado do Rocket não tem suporte rigoroso para SNI (server name indication), razão pela qual as recomendações de hardening também indicam aceder à instância pelo hostname e nunca por um endereço IP isolado. Os intervalos de IP públicos são verificados continuamente, e um vault que responde num endereço IP é um vault que será encontrado.

As partes de um server block do nginx que são relevantes:

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

Por predefinição, o nginx define client_max_body_size como 1m. Sem uma substituição, apenas os corpos de pedido maiores do que esse limite falham. O nginx devolve HTTP 413 ao cliente e regista client intended to send too large body: ... bytes; o upload rejeitado não chega ao Vaultwarden. Os cabeçalhos Upgrade e Connection transportam o handshake WebSocket para /notifications/hub. Se os remover, o vault continua a funcionar, mas as notificações WebSocket deixam de chegar aos clientes de browser e desktop; os clientes móveis usam notificações push configuradas separadamente.

O Caddy requer menos configuração e obtém o certificado por si próprio:

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

Depois, indique isso ao Vaultwarden:

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

IP_HEADER já tem X-Real-IP como valor predefinido, por isso é necessário garantir que o proxy define efetivamente esse cabeçalho. O Vaultwarden também só aceita o cabeçalho a partir dos endereços listados em IP_HEADER_TRUSTED_PROXIES, que tem local como valor predefinido: qualquer endereço não global, incluindo um proxy no mesmo host ou na mesma rede de containers. Um proxy que estabeleça a ligação a partir de um endereço público tem de ser adicionado a essa lista. Se o cabeçalho estiver em falta ou vier de um endereço não confiável, cada linha do log e cada limite de taxa de login verá o endereço do próprio proxy. Isto faz com que as falhas de um atacante sejam contabilizadas contra todos os utilizadores da instância. Se usar IP_HEADER=X-Forwarded-For, a versão 1.37.4 usa o endereço mais à direita que não seja um proxy confiável. Por isso, liste todos os proxies da cadeia, incluindo uma CDN colocada à frente do nginx. Defina também DOMAIN como o URL https real, porque o Vaultwarden gera a partir dele os links de convite e de recuperação de conta, e as chaves de segurança WebAuthn ficam associadas a essa origem.

Há um detalhe que muitas pessoas ignoram: a ligação WebSocket transporta o token de sessão na query string, como /notifications/hub?access_token=[JWT]. Esse token aparece em texto simples no access log do proxy. Oculte o parâmetro access_token no formato do log ou garanta que esses logs não são enviados para nenhum local que não controle.

Bloquear ataques de força bruta no endpoint de login

Os limites de taxa estão ativos por predefinição (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Abrandam o atacante. Não o impedem. O fail2ban impede-o, mas precisa de ter os logins falhados do Vaultwarden num local que consiga ler. No Docker, a opção simples é usar um ficheiro de log, e o Vaultwarden não cria um por predefinição:

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

Um login com palavra-passe incorreta produz uma linha neste formato. Esta é a sequência que o filtro tem de detetar:

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

Escreva o filtro em /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

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

E o jail em /etc/fail2ban/jail.d/vaultwarden.local:

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

Se o Vaultwarden for executado como um serviço systemd, em vez de num contentor, pode ignorar LOG_FILE: a wiki do projeto sobre fail2ban lê o journal com backend = systemd e usa um journalmatch na unidade do Vaultwarden em vez de logpath.

Se manteve a página de administração, adicione um segundo jail cujo failregex seja ^.*Invalid admin token\. IP: <ADDR>.*$, porque as falhas de administração são registadas com uma mensagem diferente e o filtro de login nunca as detetará. Depois, verifique a configuração:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Um jail funcional lista o seu ficheiro de log em File list e indica Currently failed: 0. Introduza uma palavra-passe incorreta três vezes a partir de outra rede. O contador deve aumentar e o endereço deve aparecer em Banned IP list. Se o contador nunca aumentar, a causa habitual é logpath: tem de ser o caminho do ficheiro no host, não o caminho /data/... dentro do contentor. A segunda causa habitual é um X-Real-IP em falta ou não confiável, fazendo com que todos os bans tenham como destino o seu próprio proxy. O resto da configuração, incluindo o jail SSH que já deverá estar a executar, está no guia de fail2ban para Ubuntu 24.04.

A senha mestre continua a proteger todo o sistema

A encriptação no lado do cliente significa que a senha mestre protege a chave simétrica do utilizador. Uma senha mestre curta numa instância cuja base de dados foi copiada por um atacante não é protegida por nada neste artigo, porque o atacante pode executar ataques offline nessa cópia à velocidade permitida pelo próprio hardware. Nenhuma definição do servidor alcança a máquina do atacante.

PASSWORD_ITERATIONS=600000 pode ser interpretado incorretamente. Define o número de iterações do hash no lado do servidor aplicado ao hash de início de sessão enviado pelo cliente, e o modelo de configuração do projeto indica que uma alteração desse valor é aplicada aos utilizadores existentes no próximo início de sessão. Não altera o KDF no lado do cliente, que é a definição que determina o custo de um ataque offline ao cofre. Essa definição pertence a cada conta e é alterada em Settings, Security, Keys, no cofre web, o que volta a encriptar a chave. A documentação do Bitwarden indica que os seus clientes, desde 2026.2.1, aumentam automaticamente uma definição PBKDF2 inferior a 600,000 iterações quando o utilizador inicia sessão ou desbloqueia o cofre com a senha mestre. Em 10 October 2026, esse comportamento não está confirmado num servidor Vaultwarden e nunca altera as definições Argon2id. Por isso, alguém que criou a conta há vários anos pode ainda usar uma definição KDF mais antiga e inferior. Verifique essa definição e informe o utilizador, porque o servidor não pode fazê-lo por ele.

Em seguida, ative a autenticação de dois fatores para cada conta. Ela não protege o texto cifrado, porque não participa na encriptação do cofre. Impede que uma senha roubada seja suficiente para iniciar sessão e sincronizar uma cópia. Com o email configurado, REQUIRE_DEVICE_EMAIL=true torna obrigatório o email de início de sessão num novo dispositivo: se o envio falhar, o início de sessão falha. Se o serviço de email estiver totalmente desativado, esta definição não bloqueia os inícios de sessão em novos dispositivos.

Backups são onde os vaults self-hosted falham

Uma tar czf da pasta de dados, deixada num diretório home no mesmo VPS, anula todos os passos anteriores. Esse arquivo contém db.sqlite3 com o ciphertext de todos os utilizadores, rsa_key.pem que falsifica sessões de início de sessão e config.json com o valor configurado do token de administrador e a palavra-passe SMTP. Seguir as instruções do Argon2 armazena um hash da palavra-passe de administrador; a palavra-passe SMTP permanece em texto simples. O acesso de leitura a esse único ficheiro expõe metadados de contas, segredos do servidor e dados encriptados do vault.

Duas regras são suficientes. Retire o arquivo do servidor. Encripte-o antes de o retirar.

Também existe um problema de consistência. Copiar db.sqlite3 com cp enquanto o serviço está em execução pode produzir um ficheiro que está a ser escrito e não abre. Só descobrirá o problema durante o restauro. Use o snapshot nativo do SQLite:

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

O restauro, que é a parte que quase ninguém testa, é abordado no guia de backup e restauro do Vaultwarden.

O que deixa de ter face ao Bitwarden alojado

Contabilidade honesta. O serviço alojado do Bitwarden é operado por pessoas cujo trabalho a tempo inteiro é mantê-lo, com auditorias de terceiros publicadas. O self-hosting substitui isso pelo seu próprio ritmo de aplicação de patches.

O Vaultwarden distribui correções de segurança como releases normais, e elas são frequentes. Verificado em 2 November 2026 no feed de releases do projeto, o release atual é 1.37.5, publicado em 1 November 2026. As notas abrangem dois avisos de segurança de severidade Medium e recomendam vivamente a atualização assim que possível. Este release também é necessário para ativar ou desativar métodos de autenticação em dois passos no web vault 2026.7.1 e posteriores, e para assumir o controlo de uma conta através do acesso de emergência no 2026.9.0 e posteriores. O release anterior, 1.37.4, publicado em 5 October 2026, abrangia sete avisos de segurança, sendo o mais grave classificado como High. Foi o quarto release desde o 1.37.0, de 24 July 2026: o 1.37.1 foi lançado em 29 July, o 1.37.2 em 22 August (necessário para clientes da versão 2026.8.0 e posteriores) e o 1.37.3 em 13 September, que revoga os tokens de memorização de 2FA quando as credenciais ou a 2FA mudam e aplica limites de pedidos aos endpoints de prelogin e auth. Se executar organizações com administradores em quem não confia totalmente, as notas do 1.37.4 também sugerem a rotação da chave API de cada organização depois da atualização. O 1.37.4 também altera o endereço lido de X-Forwarded-For, descrito na secção anterior sobre reverse proxy. Uma instância configurada há um ano e esquecida está a executar código com um ano de idade. A tag latest não resolve o problema por si só: um container em execução mantém a image com que arrancou até executar docker compose pull e o recriar. Configure atualizações automáticas no Ubuntu para os pacotes do host e coloque a atualização do container num lembrete de calendário que irá realmente consultar.

A conclusão que um leitor deve tirar, de forma honesta, é esta: a criptografia segue o design do Bitwarden e é sólida, mas o risco operacional passa inteiramente para si. Se aplicar patches e mantiver uma cópia de segurança noutro local, uma instância Vaultwarden num VPS que controla é um local razoável para guardar as suas palavras-passe. Se não vai cumprir esses dois procedimentos, pague pelo serviço alojado e dedique a sua atenção a outra coisa. A comparação funcional detalhada está em Vaultwarden comparado com Bitwarden self-hosted.

Proteja o host subjacente ao contentor

O Vaultwarden é um processo num sistema Linux, e o root desse sistema pode ler /vw-data, independentemente do que a aplicação estiver configurada para fazer. Execute o contentor com um utilizador sem privilégios usando user: "1000:1000" no seu ficheiro compose, atribua a propriedade da pasta de dados de forma compatível e monte como somente leitura, com :ro, tudo aquilo em que o contentor não escreve. Depois feche a porta de entrada: Proteção do SSH num VPS aborda o início de sessão apenas com chaves e a desativação da autenticação por palavra-passe. É isso que impede o ataque básico que ultrapassa todas as medidas anteriores.

FAQ

Alguém pode ler as minhas palavras-passe se roubar a base de dados do Vaultwarden?

Não diretamente. Cada item do vault é encriptado no cliente com uma chave gerada aleatoriamente, protegida pela chave simétrica do utilizador ou da organização; a chave derivada da palavra-passe protege a chave simétrica do utilizador. db.sqlite3 contém o conteúdo encriptado do vault juntamente com os metadados da conta em texto simples. O atacante obtém imediatamente o endereço de e-mail e a sugestão de palavra-passe de cada conta, as definições do KDF, os metadados de início de sessão e dos dispositivos e os segredos TOTP de início de sessão na tabela twofactor, armazenados sem encriptação porque o servidor tem de calcular o código esperado. Também pode atacar offline o texto cifrado do vault durante o tempo que quiser. Por isso, o comprimento da palavra-passe principal é o fator que determina o resultado.

Devo usar ADMIN_TOKEN ou desativar completamente a página de administração?

Desative-a se puder, porque a maioria das instâncias precisa dela uma vez para configurar o SMTP e convidar utilizadores, mas nunca mais. Para a desativar, não defina ADMIN_TOKEN nem DISABLE_ADMIN_TOKEN, remova qualquer chave "admin_token" de config.json e recrie o contentor. Remover apenas a variável de ambiente não é suficiente, porque as definições gravadas pela página de administração ficam em config.json e têm precedência. Se mantiver a página, armazene o token como um hash Argon2 produzido por vaultwarden hash, em vez de uma cadeia aleatória em texto simples, e defina ADMIN_RATELIMIT_MAX_BURST=3.

O meu ADMIN_TOKEN está correto, mas /admin rejeita-o. O que está errado?

Quase sempre, trata-se de interpolação de $. Uma cadeia PHC Argon2 contém vários caracteres $, e o Docker Compose expande-os como variáveis dentro de um bloco docker-compose.yml environment:. Assim, o contentor recebe um valor alterado, embora o ficheiro pareça correto. Duplique cada $ para $$ no ficheiro compose ou mova o valor para um ficheiro .env entre aspas simples, onde não é necessário fazer escaping. Recrie o contentor depois disso, porque as alterações de ambiente não são aplicadas por um simples restart.

Ainda preciso de abrir a porta 3012 para as notificações?

Não. O suporte para tráfego WebSocket na porta 3012 foi removido no Vaultwarden 1.31.0 porque as notificações passaram a usar a porta HTTP principal, e WEBSOCKET_ENABLED e WEBSOCKET_PORT foram descontinuados desde 1.29.0 e são ignorados. A definição atual é ENABLE_WEBSOCKET, que é true por predefinição. Feche a porta 3012 na firewall e remova-a do ficheiro compose. Depois, confirme que o reverse proxy encaminha os cabeçalhos Upgrade e Connection, porque as notificações WebSocket no browser e no cliente desktop dependem deles. Os clientes móveis usam notificações push configuradas separadamente.