O DNS é um provável culpado no Immich apenas quando o cliente que falha não consegue converter o nome de anfitrião exato do Immich no endereço que o deve servir, ou quando essa resposta muda consoante os resolvedores, as redes ou o momento.
Teste a resolução de nomes separadamente da acessibilidade da aplicação. Uma ligação bem-sucedida ao nível do IP pode mostrar que existe uma rota e uma porta, mas não prova que o HTTPS, o encaminhamento do proxy inverso, os certificados ou as regras baseadas no anfitrião funcionarão sem o nome de anfitrião. O fluxo de trabalho mais seguro regista o nome exato que falha, consulta-o a partir do cliente afetado, compara os resolvedores e repete a ação original do Immich depois de uma alteração na camada DNS.
Defina o Nome de Anfitrião Exato e o Caminho da Falha
Registe o nome de anfitrião que o cliente Immich afetado utiliza efetivamente, a rede em que se encontra, a hora da falha e se esta afeta a aplicação Web, a aplicação móvel ou ambas. Não comece com um teste genérico, como resolver um domínio público não relacionado, porque isso apenas prova que algum caminho DNS funciona.
Compare o mesmo nome de anfitrião a partir de um cliente funcional e do cliente afetado. Registe todas as respostas A e AAAA, o resolvedor que respondeu e se o cliente está dentro da rede doméstica, a utilizar dados móveis ou atrás de uma VPN. Respostas diferentes podem ser intencionais com DNS dividido, mas ainda assim têm de encaminhar cada cliente para um ponto final acessível.
Como controlo, teste se o endereço e a porta esperados do servidor estão acessíveis sem depender da consulta DNS normal. Trate isto apenas como um elemento de distinção do caminho de rede: os certificados HTTPS, o SNI, os proxies inversos e os anfitriões virtuais podem continuar a rejeitar um pedido baseado no IP, mesmo quando o serviço está saudável.
Consulte o DNS a Partir do Cliente Afetado, Não Apenas do Servidor
Execute uma consulta DNS no dispositivo ou ambiente que está efetivamente a falhar. Se o cliente Immich estiver atrás de uma VPN, de um perfil DNS privado, de um stub de contentor ou de um resolvedor fornecido pelo router, uma consulta feita a partir do próprio servidor pode utilizar um caminho de resolvedor diferente e ocultar o problema.
Consulte primeiro o nome de anfitrião que falha através do resolvedor predefinido do cliente; em seguida, consulte explicitamente um resolvedor de comparação conhecido ou o resolvedor interno pretendido. Uma consulta dig direcionada apresenta a resposta devolvida, o servidor que respondeu, o estado e o tempo da consulta, permitindo verificar se a falha acompanha um determinado resolvedor.
Repita a consulta várias vezes em vez de confiar num único sucesso. Registe NXDOMAIN, SERVFAIL, tempos limite, endereços obsoletos ou respostas A/AAAA inconsistentes. Uma resposta correta e estável afasta a suspeita da resolução DNS básica e aponta para o encaminhamento, o proxy, o TLS, a firewall ou a configuração da aplicação.
Compare os Resultados dos Resolvedores e os Tipos de Erro
Interprete o código de resposta antes de alterar as definições. NXDOMAIN significa que o nome consultado não existe na perspetiva desse resolvedor; SERVFAIL significa que a resolução não pôde ser concluída; um tempo limite significa que o resolvedor não respondeu a tempo. Uma resposta sintaticamente válida pode ainda estar errada se apontar para um endereço antigo do router ou para um ponto final inacessível.
As falhas de nome não encontrado e as falhas temporárias do resolvedor pertencem a ramos diferentes. Utilize as diferenças entre erros de resolução de nomes para decidir se deve corrigir um registo em falta, um resolvedor inacessível ou um caminho DNS instável, em vez de tratar todas as falhas de consulta como o mesmo problema.
Se apenas o resolvedor doméstico devolver o endereço antigo ou incorreto, enquanto outro resolvedor devolve o valor público pretendido, inspecione as substituições locais, os registos de DNS dividido, o DNS fornecido por DHCP, os serviços de filtragem e as caches. Se todos os resolvedores devolverem o mesmo endereço correto, pare de alterar o DNS e avance para o caminho do serviço.
Utilize um Desvio Controlado para Confirmar ou Excluir o DNS
Crie um controlo temporário e reversível que altere apenas a resolução de nomes do cliente afetado. Por exemplo, consulte diretamente um resolvedor diferente ou utilize temporariamente uma entrada no ficheiro hosts que associe o nome de anfitrião exato do Immich ao ponto final conhecido e pretendido. Preserve as definições originais para poder anular imediatamente o teste.
Se o fluxo de trabalho original do Immich começar a funcionar enquanto o nome de anfitrião permanece idêntico e apenas o respetivo caminho de resolução mudar, o DNS fica fortemente implicado. Se o mesmo nome de anfitrião continuar a falhar depois de resolver para o ponto final verificado, a falha está a jusante do DNS e deve inspecionar o encaminhamento do proxy, os certificados, o NAT, as regras da firewall ou o próprio serviço Immich.
Se uma única consulta limpa não conseguir reproduzir a janela de falha doméstica, compare ao longo do tempo o anfitrião, o contentor, o resolvedor local, o resolvedor a montante, o DHCP, a VPN e o estado da cache. Uma verificação de falhas DNS em várias camadas ajuda a detetar casos intermitentes que desaparecem durante um teste único.
Limpe a Cache Certa e Teste Novamente o Fluxo de Trabalho Original do Immich
Depois de corrigir um registo DNS, um resolvedor, uma opção DHCP, uma regra de DNS dividido ou uma substituição local, limpe apenas a cache relevante do cliente ou do resolvedor, quando tal for viável. Não limpe repetidamente todas as camadas sem registar o que mudou, pois isso pode tornar impossível explicar um sucesso temporário.
Volte a resolver o nome de anfitrião a partir do cliente afetado e verifique a resposta A/AAAA pretendida, o resolvedor e o tempo de resposta. Em seguida, abra o Immich através do nome de anfitrião normal, carregue recursos antigos, pesquise e faça um carregamento seguro ou outra ação de escrita, para que o teste cubra mais do que uma página de início de sessão.
Repita a verificação no estado de rede que originalmente falhou, como dados móveis, Wi-Fi doméstico, Wi-Fi ligado a uma VPN ou após uma renovação do router/DHCP. O DNS só é excluído como causa principal quando o nome de anfitrião normal permanece correto durante o evento que anteriormente provocava a falha; caso contrário, preserve as novas evidências e continue na camada de rede seguinte.
Suporte e Dicas
Mais para Ler

Como otimizar as ligações à base de dados do Immich para contentores simultâneos
Não aumente primeiro o valor de max_connections. Meça as sessões do Immich, some a procura total de cada contentor, preserve margem para o administrador...

Como evitar trabalhos ou importações duplicados no Immich
Separe os trabalhos repetidos dos recursos duplicados. Utilize um único caminho de ingestão canónico, controle as novas tentativas e as alterações de caminho e,...

Como reparar o Immich depois de o volume da base de dados ficar cheio
Nunca elimine o WAL do PostgreSQL para libertar espaço. Pare as escritas do Immich, preserve o estado da base de dados, adicione capacidade de...

