Seu loop de redirecionamento do Magento provavelmente não é a VPN

Você vê 302 no log de acesso, a loja não carrega pela VPN e a conclusão se escreve sozinha. Essa conclusão costuma estar errada de um jeito interessante. Uma resposta de redirecionamento registra um destino para onde o navegador foi mandado, e não diz nada sobre se o túnel, o certificado ou a aplicação produziram o problema. A linha do log é o começo da investigação, não o seu achado.

Um 302 diz para onde, não por quê

Uma entrada do log de acesso registra a requisição, o status e o tamanho, e costuma omitir o cabeçalho Location que importa. Um único redirecionamento pode ser totalmente normal: um nome de host canônico, uma normalização da barra final, uma troca para HTTPS. O que você precisa é a sequência, porque um salto e um loop são falhas diferentes com donos diferentes. Saltos repetidos entre esquemas apontam para o tratamento de URL e esquema. Já um salto para um nome que o navegador não consegue resolver aponta para um lugar completamente diferente.

Nada disso é evidência sobre a VPN. O túnel é um caminho; o redirecionamento é uma instrução que a aplicação escreveu.

Capture a cadeia, não a linha do log

Use a visualização de rede do navegador e anote quatro campos por salto: o URL solicitado, o status, o cabeçalho Location e o horário. Termine com a resposta final ou com o erro de conexão, porque o caso interessante é o salto que nunca se completa. Faça isso uma vez num caminho que funciona e outra no que falha, com a mesma conta e a mesma navegação. Comparar duas cadeias vale mais do que qualquer linha isolada de um log.

Mantenha esse registro em sigilo. Os URLs carregam identificadores de sessão, e um arquivo de navegador salvo carrega mais do que você espera. Remova as strings de consulta antes de colar qualquer coisa num ticket.

A ideia que a aplicação tem do próprio URL

O Magento gera URLs absolutos a partir da configuração, com escopo por site ou visualização de loja. bin/magento config:show web/secure/base_url imprime o valor em que a aplicação acredita, e ele costuma ser um nome de host que sobrou de uma compilação ou de uma migração em vez do que o navegador usou. Se ali estiver um host interno, o navegador é enviado a um lugar aonde não pode ir, e nenhuma mudança no túnel corrige isso.

Compare os URLs base seguro e não seguro com os nomes públicos à sua frente. Uma divergência em qualquer um dos dois produz exatamente o redirecionamento que você está encarando.

Cabeçalhos de proxy confiável são um contrato

Quando o TLS termina num balanceador de carga, a aplicação vê HTTP simples e precisa ser avisada do contrário. A configuração do cabeçalho de offloader nomeia o cabeçalho que o proxy define, como o protocolo encaminhado, e a aplicação confia nele nas decisões de esquema.

Essa confiança é um contrato com um proxy, não uma permissão geral. Aceitar o cabeçalho de clientes arbitrários permite que qualquer um reivindique um esquema, e por isso ele só pertence onde um proxy designado o define. Se o nome do cabeçalho e o comportamento do proxy não concordarem, a aplicação gera redirecionamentos para um esquema que o navegador nunca usou, e o loop se fecha. Verifique a configuração do proxy e a definição da aplicação juntas, e depois limpe o cache de configuração para que a mudança faça efeito.

Quando o loop é uma sessão, não uma rota

Uma cadeia que sempre volta ao login costuma ser um problema de cookie. Verifique se o cookie de sessão foi emitido para o nome de host que o navegador realmente usou, e se foi marcado como seguro numa conexão que o navegador considera segura. Um cookie associado ao domínio errado produz um loop de login que parece exatamente uma falha de roteamento.

Corrija a divergência comprovada no seu dono, seja o URL base, o domínio do cookie ou o contrato com o proxy, e depois teste novamente toda a navegação em vez de ver um único 302 desaparecer. Desativar os requisitos de HTTPS para quebrar o loop troca um redirecionamento por um problema pior. Quando a mudança estiver feita, verifique o túnel separadamente: peça um recurso privado conhecido e confirme que chega, para que o próximo redirecionamento tenha uma base limpa de comparação.