O início de sessão do Immich falha após o reinício do proxy inverso
Se o início de sessão no Immich falhar apenas depois de o proxy inverso reiniciar, verifique primeiro se o percurso através do proxy foi interrompido, enquanto a aplicação Immich e a conta continuam a funcionar diretamente.
Um reinício pode revelar endereços upstream obsoletos, a ausência de adesão à rede partilhada, alterações nos cabeçalhos, problemas com cookies ou um processo de proxy que voltou a iniciar antes de as respetivas dependências estarem acessíveis. Teste a mesma conta através do endpoint local do Immich e do hostname público habitual; em seguida, siga a primeira camada em que os dois percursos divergem.
Utilize o acesso direto para distinguir a autenticação de uma falha do proxy
Teste uma conta conhecida no servidor Immich através de um percurso local fidedigno que contorne o proxy inverso. Se o início de sessão direto for bem-sucedido, enquanto o hostname público fica a carregar, redireciona ou devolve um erro upstream, o registo do utilizador e o percurso de autenticação principal estão provavelmente intactos. Mantenha a investigação no proxy, no TLS, no encaminhamento e no estado do navegador.
Um caso da comunidade em que o acesso direto funcionava, mas o início de sessão através do proxy falhava ilustra este método de isolamento. O relato é específico de uma versão; utilize-o para justificar a comparação entre percursos, não para presumir a mesma causa principal.
Se tanto o início de sessão direto como o efetuado através do proxy falharem, pare de alterar as definições do proxy. Verifique antes o estado do serviço Immich, a conectividade à base de dados, o estado da conta e os registos do servidor. Um reinício do proxy ocorrido perto da falha pode ser uma coincidência; o teste sem proxy evita transformar essa coincidência temporal num diagnóstico sem fundamento.
Verifique se o proxy consegue alcançar o upstream atual do Immich
Depois de o proxy reiniciar, confirme que consegue resolver e ligar-se ao upstream do Immich a partir do seu próprio espaço de nomes de rede. No Docker, um upstream baseado no nome do serviço numa rede definida pelo utilizador e partilhada é geralmente mais estável do que um endereço IP de contentor copiado manualmente, que muda quando um contentor é recriado.
Uma discussão sobre uma interrupção do proxy que envolvia a conectividade entre o proxy e o Immich demonstra por que motivo a acessibilidade do upstream e o suporte de proxy compatível com WebSocket devem ser verificados antes da recuperação da conta. Considere a configuração exata como evidência anedótica, não como um modelo para todos os proxies.
Reinicie apenas o proxy duas vezes e observe se o upstream é resolvido para o mesmo serviço em ambas as ocasiões. O teste é bem-sucedido quando ocorre uma ligação imediata sem editar endereços. Se a resolução de nomes, a adesão à rede ou a porta de destino mudar após a recriação, corrija a definição da rede no Compose em vez de reiniciar repetidamente a pilha.
Inspecione os cabeçalhos encaminhados, o TLS e o comportamento dos cookies
O início de sessão pode falhar mesmo quando o proxy devolve a página do Immich, porque a autenticação depende de todo o percurso HTTP. Compare a configuração do proxy antes e depois do reinício, incluindo o encaminhamento do host e do esquema, a terminação HTTPS, os redirecionamentos, qualquer reescrita de cookies e a possibilidade de um segundo proxy ou túnel também estar a modificar a resposta.
Uma discussão da comunidade do Immich documenta um caso de cookies duplicados em que o tratamento de cookies do proxy fez com que o início de sessão ficasse bloqueado. Esse é um caso específico, mas serve de lembrete para inspecionar a resposta e os cookies no navegador, em vez de presumir que credenciais válidas garantem uma sessão através do proxy.
Não elimine todas as contas nem reponha a base de dados porque uma sessão do navegador parece bloqueada. Utilize uma janela privada ou um segundo navegador depois de registar os cookies e a resposta originais. Se um cliente limpo funcionar, limpe apenas o estado do site afetado e corrija a regra do proxy que criou o cookie ou redirecionamento incorreto.
Leia os registos de acesso e de erros do proxy no momento do pedido falhado
Reproduza uma tentativa de início de sessão e registe a hora exata, o hostname público, o cliente e o estado devolvido. Em seguida, inspecione os registos de acesso e de erros do proxy em torno desse pedido. Distinga entre um pedido que nunca chegou ao proxy, um erro 4xx ou 5xx gerado pelo proxy, uma falha de ligação ao upstream e um pedido que chegou ao Immich, mas recebeu uma resposta da aplicação.
O fluxo de resolução de problemas dos registos do NGINX demonstra como o estado, os erros do upstream, o tempo dos pedidos e os registos direcionados fornecem um sinal muito mais fiável do que atualizar repetidamente a página de início de sessão. Aplique o mesmo princípio ao Caddy, ao Traefik ou a outro proxy.
Se o registo do proxy mostrar uma resposta upstream bem-sucedida enquanto o navegador não consegue concluir o início de sessão, inspecione os redirecionamentos, os cookies, o TLS e o estado do cliente. Se o proxy não conseguir ligar-se ao upstream, corrija o encaminhamento ou a disponibilidade do serviço. Se for o próprio Immich a devolver o erro, siga o registo do servidor correspondente em vez de considerar o proxy como a causa.
Confirme que a correção sobrevive ao reinício que originalmente causou a falha
Depois de corrigir a causa confirmada, repita exatamente o fator desencadeador: reinicie apenas o proxy inverso, aguarde pela verificação de estado e inicie sessão através do hostname público. Em seguida, abra um recurso existente, carregue um ficheiro pequeno e mantenha a sessão ativa durante tempo suficiente para verificar o tráfego normal da API.
O guia da ZimaSpace sobre percursos de acesso remoto controlados estabelece o enquadramento mais amplo: o proxy é apenas uma camada do acesso remoto, pelo que o DNS, o TLS, a autenticação e o upstream privado devem permanecer intencionais e observáveis.
Considere o teste bem-sucedido apenas quando o início de sessão sobreviver a dois reinícios do proxy e a mesma configuração arrancar corretamente após um reinício completo da pilha. Reverta as alterações recentes do proxy se uma nova regra de cabeçalho ou cookie tiver criado a falha. Ao pedir ajuda, inclua a diferença da configuração do proxy, o estado do pedido, o erro do upstream, o momento registado no servidor e o resultado do teste direto versus através do proxy.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Como adequar as políticas de reinício do Docker a bases de dados, processos de trabalho e aplicações Web
Faça corresponder a política de reinício ao ciclo de vida e à semântica de saída do serviço. Combine-a com verificações de estado e prontidão;...
Como configurar os IDs de utilizador dos contentores em várias partilhas NAS
Mapeie o UID/GID de cada contentor para as partilhas do seu NAS, utilize grupos partilhados ou ACLs quando necessário e considere PUID/PGID específicos de...
Como configurar perfis do Docker Compose para serviços opcionais no servidor doméstico
Deixe os serviços necessários sem perfil e use perfis para ferramentas opcionais. Teste os destinos diretos e as dependências em vez de presumir que...
