Redes do Immich: como a descoberta, o DNS e o encaminhamento permitem a acessibilidade
A acessibilidade do Immich resulta de uma cadeia ordenada: seleção do endpoint, resolução DNS, encaminhamento de pacotes, reencaminhamento por proxy ou NAT e resposta da aplicação.
Um telemóvel pode aceder ao Immich através do IP local enquanto o mesmo nome de anfitrião falha na rede Wi-Fi, ou funcionar remotamente enquanto segue um caminho mais longo em casa. Estes resultados são produzidos por diferentes decisões de nome e rota, não por um único estado universal de “rede ativa”.
A acessibilidade começa pelo endpoint escolhido pelo cliente
Um cliente não pode encaminhar tráfego para o “Immich” enquanto serviço abstrato; utiliza um esquema, um nome de anfitrião ou endereço, uma porta e, por vezes, um caminho. As aplicações nativas, os navegadores, os marcadores e as ligações partilhadas podem guardar endpoints diferentes. A acessibilidade pode divergir antes de qualquer pacote chegar ao servidor.
Uma discussão da comunidade sobre expor o Immich local e remotamente descreve dificuldades quando um router não consegue fornecer um comportamento split-horizon e o cliente não dispõe de comutação automática para um endpoint local. O caso mostra que a seleção do endpoint e a capacidade do DNS local determinam em conjunto o caminho que um cliente doméstico tenta seguir.
Escreva o URL exato utilizado por cada cliente e indique se foi introduzido manualmente, descoberto através de uma ligação ou guardado anteriormente. Compare o esquema, o anfitrião, a porta e o caminho. Não reduza um IP local funcional e um nome de anfitrião público com falhas a um único resultado; são contratos de destino diferentes.
O DNS seleciona um endereço, não um serviço funcional
O DNS converte o nome de anfitrião selecionado num endereço. Os resolvedores públicos e locais podem devolver intencionalmente respostas diferentes, enquanto as caches antigas podem conservar o endereço de um router ou servidor anterior. Uma resposta correta apenas identifica um destino; não prova que a porta, o proxy, o certificado ou a aplicação estejam disponíveis nesse destino.
Um caso da comunidade Caddy descreve o funcionamento do Immich através do IP local, enquanto um caminho local baseado em DuckDNS falha e suscita questões sobre NAT loopback. Os detalhes são específicos de cada ambiente, mas demonstram que a resolução de nomes e os caminhos de retorno do router podem ser diferentes mesmo na mesma rede doméstica.
Consulte o nome de anfitrião a partir da rede do telemóvel ou navegador afetado e compare-o com o endereço local ou público esperado. Repita o teste através de dados móveis. Se as respostas diferirem intencionalmente, documente o DNS dividido. Se diferirem inesperadamente, corrija o registo autoritativo ou a cache antes de alterar os contentores do Immich.
O encaminhamento, o NAT e os proxies completam a cadeia de entrega
Depois do DNS, o cliente precisa de uma rota. O tráfego remoto pode atravessar um ISP, um router, um reencaminhamento de portas, um túnel ou um proxy inverso; o tráfego local pode seguir diretamente ou passar pelo perímetro público. Cada camada tem de entregar a porta correta e preservar o contexto do pedido esperado pela aplicação.
O artigo da ZimaSpace sobre o caminho de dados do Immich separa as dependências do cliente, da rede, da aplicação, da base de dados e dos conteúdos multimédia. Esse modelo por camadas evita um erro comum: reiniciar o Immich quando a aplicação já responde localmente e a primeira dependência com falhas está fora do contentor.
Siga o caminho por ordem: endereço, rota, porta em escuta, destino do proxy, nome TLS e resposta da aplicação. Um ping bem-sucedido não é suficiente, porque a porta Web ou da API pode continuar bloqueada. Do mesmo modo, uma página de destino do proxy não prova que os pedidos chegam ao serviço Immich.
Utilize um rastreio de acessibilidade por camadas
Crie duas colunas para a rede Wi-Fi doméstica e para os dados móveis. Em cada uma, registe o URL selecionado, a resposta DNS, a rota ou gateway, a ligação TCP, o resultado TLS, o estado HTTP e uma resposta autenticada da API do Immich. Utilize a mesma conta e o mesmo conteúdo para que a identidade ou as permissões não alterem a comparação de rede.
Um guia do Immich para servidores domésticos apresenta o encaminhamento DNS como pré-requisito antes das etapas de acesso ao certificado e à aplicação. A sua sequência sustenta a regra de diagnóstico: as camadas posteriores não podem compensar um mapeamento incorreto entre nome e endereço, enquanto um DNS correto, por si só, não valida o reencaminhamento nem o estado da aplicação.
Pare na primeira camada cujo valor observado seja diferente do caminho esperado. Corrija apenas essa camada e repita as duas colunas, porque uma correção remota pode quebrar o comportamento de NAT loopback local. A acessibilidade é confirmada quando ambos os caminhos previstos concluem o mesmo pedido à aplicação, não apenas quando um nome de anfitrião é resolvido.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Porque é que o Immich volta a processar os dados existentes depois de uma atualização?
O Immich pode voltar a processar recursos quando uma atualização invalida derivados, metadados, modelos ou o estado de tarefas anteriores; um processamento interminável e...
Que dependências definem mais frequentemente o verdadeiro limite de desempenho do Immich?
O Immich está limitado pela dependência mais lenta em cada caminho medido, pelo que o carregamento, a pesquisa, a navegação e a reprodução podem...
Immich para famílias: como a identidade e as permissões moldam a experiência
A utilização do Immich em família depende de identidades separadas, propriedade dos ativos, partilha intencional, administração limitada e revogação testada.
