Porque é que o Immich parece mais rápido na LAN do que em ligações remotas?

O Immich costuma parecer mais rápido na LAN porque os clientes locais percorrem um caminho mais curto e com menor latência, com menos gateways e sem a ligação à Internet doméstica como estrangulamento.

A utilização remota pode acrescentar limites de carregamento do ISP, redes móveis ou de hotéis, DNS, terminação TLS, um proxy inverso, uma VPN ou sobreposição de rede e, por vezes, um relay. Esses elementos não tornam todos os pedidos lentos da mesma forma: miniaturas, consultas de metadados, transferências de originais, carregamentos e chamadas de pesquisa sobrecarregam partes diferentes do caminho. Por isso, compare ações idênticas antes de concluir que o «Immich remoto» corresponde a um único modo de desempenho.

A LAN Elimina a Maioria da Variabilidade do Caminho WAN

Numa LAN com fios ou com Wi-Fi forte, o cliente e o servidor estão normalmente separados por apenas alguns saltos locais de comutação ou encaminhamento. O tempo de ida e volta é baixo e a família controla a maior parte do caminho, pelo que pequenas chamadas à API e muitos pedidos de miniaturas podem ser concluídos com pouca espera de rede.

O modelo direto versus relay na travessia de NAT ajuda a explicar o contraste. Um cliente remoto pode chegar ao mesmo servidor através de um túnel WAN direto ou por um relay, enquanto o cliente na LAN simplesmente utiliza a rota local. O endpoint da aplicação pode ser idêntico, mesmo quando as condições de transporte não o são.

Uma LAN mais rápida não prova que o servidor está saudável em todas as cargas de trabalho. A baixa latência local pode ocultar pedidos ineficientes ou armazenamento lento, porque a espera de rede é reduzida. Mantenha as métricas do servidor na comparação para que um diagnóstico do caminho remoto não desculpe um estrangulamento no backend que afeta ambas as rotas.

O Upload Doméstico Torna-se Capacidade de Download Remoto

Quando alguém fora de casa abre fotografias de um servidor doméstico, o servidor envia os dados através da direção de carregamento da ligação à Internet da residência. Muitas ligações residenciais têm uma capacidade de upstream muito inferior à da Ethernet ou do Wi-Fi local, pelo que os originais remotos e as pré-visualizações grandes podem ficar limitados pela largura de banda, mesmo quando a navegação na LAN é instantânea.

Um tópico da comunidade sobre acesso remoto para famílias mostra por que motivo as famílias avaliam mais do que a conectividade: o caminho também tem de ser simples e fiável para utilizadores não técnicos. O desempenho, a autenticação e a experiência do utilizador fazem todos parte do caminho remoto prático.

A largura de banda não é a explicação correta quando pequenos controlos de metadados, filtros ou operações de início de sessão são lentos, enquanto as transferências grandes atingem a velocidade esperada. Esse padrão aponta mais fortemente para latência, encaminhamento de pedidos, comportamento do proxy, DNS ou tempo de resposta do servidor.

Os Proxies e Túneis Acrescentam Limites de Processamento e Configuração

Um pedido remoto pode terminar o TLS num proxy, atravessar outra rede de contentores ou viajar através de uma sobreposição encriptada antes de chegar ao Immich. Camadas bem configuradas podem acrescentar pouca sobrecarga, mas cada camada introduz outro ponto onde o armazenamento temporário, o tratamento de cabeçalhos, a política de tempos limite, a seleção de caminho ou problemas de MTU podem afetar pedidos específicos.

Um relato de utilizador do Immich de 2026 sobre atrasos em filtros remotos identificou finalmente um problema de configuração do caminho do endpoint, depois de também ter sido considerada a possibilidade de problemas de desempenho do relay. O exemplo é útil porque dois mecanismos distintos produziram sintomas semelhantes de «o acesso remoto é lento».

Não troque de tecnologia de acesso remoto com base no carregamento de uma única página. Primeiro, identifique se a operação que falha é uma transferência, um pedido à API, uma autenticação ou o estabelecimento de uma ligação. Um proxy inverso não pode resolver um upstream doméstico saturado, e um túnel mais rápido não pode corrigir uma consulta lenta à base de dados.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

O Armazenamento em Cache Pode Tornar Desiguais os Testes na LAN e Remotos

Um telefone na LAN pode já ter miniaturas, o estado da sessão, respostas DNS ou recursos acedidos recentemente armazenados em cache, enquanto o teste remoto pode começar num estado mais vazio. Comparar essas duas execuções pode exagerar a diferença de rede, porque um dos clientes está a pedir menos dados ao servidor.

A explicação da ZimaSpace sobre latência do armazenamento reforça a necessidade de controlar o estado da cache e da carga de trabalho ao comparar o desempenho. A mesma disciplina aplica-se aos testes de rotas: utilize, sempre que possível, a mesma conta, o mesmo conjunto de recursos, o mesmo cliente e a mesma condição de cache.

O mecanismo LAN versus WAN deixa de explicar uma discrepância que permanece quando ambos os testes são forçados a utilizar a mesma rota ou quando o próprio tempo de resposta do servidor aumenta de forma idêntica. Nesse momento, inspecione a aplicação ou o anfitrião em vez de continuar a otimizar a topologia da rede.

Crie uma Comparação de Rotas com a Mesma Ação

Escolha quatro ações: carregar o mesmo álbum, abrir a mesma fotografia grande, executar a mesma pesquisa conhecida e carregar o mesmo ficheiro de teste. Registe o tempo observado pelo cliente, o tempo do pedido no servidor quando disponível, a latência de ida e volta, o débito da transferência e se o caminho remoto é direto, utiliza proxy ou passa por um relay.

Compare as execuções na LAN e remotas a partir de um estado de cache conhecido e, em seguida, altere apenas uma variável da rota de cada vez. A discussão da Tailscale sobre ligações diretas e através de relay fornece um modelo útil para classificar caminhos. Se apenas as transferências grandes melhorarem, a largura de banda é o limite mais provável.

Aceite o diagnóstico quando a alteração da rota melhorar a operação prevista pelo mecanismo, sem alterar a carga de trabalho do servidor. Mantenha o design remoto mais simples que cumpra os objetivos de acesso e desempenho da família; camadas adicionais de proxy, túnel ou relay devem existir por um motivo claro de acessibilidade ou segurança.