Git 403 com a VPN conectada: encontre quem responde
Um 403 é uma resposta, não um veredito sobre a VPN. Identifique qual componente recusou e depois compare uma variável por vez entre redes e registre o que mudou.
Funciona no Wi-Fi do escritório e falha no hotspot do telefone, com a VPN conectada nos dois casos. O Git retorna 403 e o erro tem três linhas. A tentação é tratar o hotspot como causa e mudar as configurações de rede até algo se mexer. HTTP 403 significa que um servidor entendeu a solicitação e a recusou, então a pergunta útil é qual servidor, e o próximo passo útil é uma comparação que muda uma coisa por vez.
Leia o status antes da rede
Um 403 não é uma consulta que falhou, um tempo limite de TCP nem um handshake TLS que nunca terminou. É uma decisão, tomada por algo que analisou sua solicitação.
Até você saber o que tomou essa decisão, toda mudança de rede que tentar é um palpite com uma história plausível anexada.
Quem pode responder com 403?
O aplicativo do repositório é apenas um candidato. Um proxy, um gateway ou um serviço de filtragem pode ficar na frente dele e responder primeiro, e o cliente vê o mesmo status de qualquer forma. Preserve o status, os cabeçalhos relevantes e um corpo de erro higienizado, e depois correlacione-os com os logs do serviço autorizado. A URL remota e o endpoint realmente alcançado também podem diferir por DNS ou configuração de proxy, então verifique o endereço configurado e o processo que faz a solicitação.
Se a recusa nunca chegou ao repositório, os logs dele ficarão em silêncio, e esse silêncio é evidência.
Compare uma variável por vez
A comparação com o hotspot é útil porque estreita o problema, não porque prova uma causa. Duas redes podem diferir em endereçamento, família de IP, proxy, negociação TLS e política de saída ao mesmo tempo.
Mude uma coisa por tentativa e registre o resto. A tabela abaixo é o mínimo que mantenho numa nota enquanto faço isso:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
Uma única linha que difere entre a execução que funciona e a que falha é onde vai passar a próxima hora.
Uma solução alternativa é evidência, não explicação
Forçar outra família de endereços pode mudar o destino, a rota ou o intermediário que é escolhido, então pode mudar o resultado sem provar que o IPv6 é incompatível com o repositório. Uma versão de TLS diferente negociada é uma observação na mesma categoria. Nenhuma das duas justifica desativar a verificação de certificados ou enfraquecer a conexão. Siga a política e os logs do componente que recusou até a decisão real, em vez de parar na primeira mudança que funciona.
Uma solução alternativa que você não consegue explicar vai falhar de novo em outro lugar.
Escreva um relatório que seja corrigido
Dê ao dono do componente que respondeu a mesma operação, dois caminhos e o componente que disse não. Remova cabeçalhos de autorização, credenciais embutidas e detalhes de repositório privado antes de compartilhar qualquer coisa.
O relatório útil é curto, reproduzível e nomeia a camada em vez do sintoma.
A verificação que faço, em ordem
Confirme a URL remota e o endpoint resolvido, e depois capture o status e os cabeçalhos de uma execução que falha. Repita a operação idêntica em uma segunda rede e compare os dois registros.
Depois leve essa diferença ao componente que respondeu:
- Configuração de proxy no cliente e na rede.
- Política de saída ou filtragem na frente do repositório.
- Escopo do token ou da conta, incluindo expiração e condições de SSO.
- Permissão do repositório para a identidade que o token representa.
A própria semântica do status está na RFC 9110, e vale citá-la quando você escrever o relatório.