Por que alguns sites falham só quando a VPN está ligada?

Que um único site falhe enquanto tudo o resto carrega prova que o túnel transporta tráfego, o que delimita o problema mais do que a maioria espera. Três observações ordenam o resto: se recebeu uma resposta HTTP, se o nome do host resolveu para um endereço e se os pedidos pequenos passam enquanto os grandes ficam parados. Adivinhar a VPN antes de ter essas respostas costuma deslocar a falha em vez de a resolver.

Trabalhe as observações por ordem, porque um site que respondeu não pode também ter falhado a resolução. Se nada carregar de todo, está no ramo errado e valem as verificações de ligado mas sem Internet.

Deixe a mensagem de erro escolher o ramo

Uma recusa, um desafio antibot ou uma página de erro significam que o serviço respondeu, logo os pacotes chegaram a uma aplicação e voltaram. Isso desloca a questão para a política de acesso do site, que pode pesar o endereço de saída, a conta ou padrões de pedido que não publica. Uma falha de resolução de nomes nunca chegou ao site, e o endereço é a primeira coisa a inspecionar. Um tempo limite fica entre os dois: algo foi enviado e nada o confirmou.

Os avisos de certificado pertencem a um quarto ramo. Significam que a ligação foi respondida por algo cuja identidade o navegador não conseguiu verificar, ou seja, um proxy do seu lado ou uma discrepância real que não deve contornar com um clique. Trate isso como uma questão de confiança, não de encaminhamento.

Um site que responde não provou um túnel quebrado

Quando a resposta é uma página de bloqueio, compare a mesma página por uma segunda saída mantendo o navegador e a máquina inalterados. Se o resultado seguir o endereço de saída, o site trata esse endereço de forma diferente, e nenhuma configuração do cliente o fará mudar de ideias. Se o bloqueio seguir antes o seu navegador, a causa está numa extensão, num proxy guardado ou numa definição do resolvedor. Duas passagens separam essas explicações a baixo custo.

As falhas só do navegador são suficientemente comuns para serem testadas cedo. Uma página que carrega num navegador suportado e falha noutro aponta para o estado do perfil, um bloqueador de conteúdo ou DNS cifrado configurado dentro do próprio navegador. As orientações do Chrome sobre DNS seguro mostram onde fica essa definição, e alterá-la pelo controlo suportado é melhor do que repor o dispositivo.

Quando só as transferências grandes param, olhe para o tamanho dos pacotes

Uma página que desenha o cabeçalho e depois fica parada tem uma assinatura diferente de uma página que nunca arranca. Respostas pequenas podem passar enquanto uma carga de tamanho completo é descartada algures que não consegue sinalizar ao emissor, e é assim que uma falha de MTU de caminho se vê a partir de um navegador. Compare um pedido minúsculo e um grande para o mesmo host antes de teorizar sobre filtragem. A descoberta de MTU de caminho deve aprender o menor tamanho de ligação ao longo do caminho, e depende de respostas ICMP que as redes filtradas descartam rotineiramente.

Teste essa hipótese com uma varredura de tamanhos em vez de um único ping. Uma falha que começa num tamanho de carga consistente é prova forte, enquanto uma falha que se desloca não é.

Confirme a correção no pedido que falhou

Teste de novo a operação original, não a página inicial, porque uma casca em cache pode desenhar-se enquanto a chamada à API por trás de um início de sessão continua a falhar. Os comandos abaixo separam a resolução de nomes, um pedido pequeno e um grande para o mesmo host. Substitua o nome do host e o caminho pelos do pedido que realmente quebrou.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Se a resposta do dig diferir da que o navegador usou, o resolvedor é a variável, e a definição DNS do próprio navegador é o sítio a olhar. Se o pedido pequeno devolver um estado enquanto o grande fica parado, trabalhe o ramo do tamanho dos pacotes. Se ambos expirarem, o caminho de saída e o tratamento do site para esse endereço voltam à mesa.

Mantenha a alteração que fez o pedido original ter sucesso e desfaça o resto. Uma pilha de alterações simultâneas no navegador, no resolvedor e no cliente deixa-o incapaz de dizer qual delas contou.