In this Article
Trabalhar com GitHub dentro de uma rede corporativa geralmente é um problema de configuração distribuído entre cinco ferramentas que não compartilham configurações. Um clone funciona e npm install falha; npm funciona e Docker não consegue baixar; tudo funciona na linha de comando e a IDE não consegue acessar nada.
Este guia aborda onde cada ferramenta lê suas configurações de proxy, por que SSH se comporta de forma diferente de HTTPS, como interpretar os quatro tipos de erro que você realmente verá e os dois atalhos que vale a pena recusar.
Fatos principais
- Cada ferramenta tem sua própria configuração de proxy. Git, npm, pip, Docker e seu shell leem configurações diferentes, por isso corrigir uma deixa as outras com problemas.
- SSH geralmente falha onde HTTPS funciona, porque a maioria dos proxies corporativos encaminha apenas HTTP CONNECT em portas padrão.
- Erros de certificado quase sempre significam inspeção TLS, e a solução é confiar na CA corporativa em vez de desativar a verificação.
- Nunca desative a verificação de certificado para fazer um clone funcionar. Isso transforma um problema visível de configuração em um problema invisível de segurança.
- Credenciais em uma URL de proxy vazam para logs e o histórico do shell, então use o armazenamento de credenciais da ferramenta.
Onde cada ferramenta lê as configurações de proxy?
Separadamente, e essa é a raiz da maior parte da confusão. Chamamos isso de modelo de cadeia de ferramentas em 4 partes.
| Ferramenta | Onde procura | Lacuna comum |
|---|---|---|
| 1. Git | Sua própria configuração, depois variáveis de ambiente | Remotos HTTPS funcionam, enquanto remotos SSH não |
| 2. Gerenciadores de pacotes | Seus próprios arquivos de configuração, depois variáveis de ambiente | Cada um precisa ser configurado separadamente; os registros podem diferir do GitHub |
| 3. Docker | Configuração do daemon, não apenas seu shell | As variáveis do shell não chegam ao daemon que baixa imagens |
| 4. IDEs e editores | Suas próprias configurações, às vezes o armazenamento do sistema | O terminal funciona, os recursos integrados não |
Portanto, uma configuração de github proxy que funciona significa cinco configurações, não uma. A ordem prática é definir variáveis de ambiente para o shell, depois configurar git, depois cada gerenciador de pacotes, depois o daemon Docker e incluir desde o início uma lista de no-proxy para hosts internos. Pular a última etapa é o que torna serviços internos inacessíveis após uma configuração bem-sucedida.
Por que SSH falha quando HTTPS funciona?
Porque são protocolos diferentes em portas diferentes, e a maioria dos proxies corporativos encaminha apenas HTTP CONNECT para um pequeno conjunto de portas.
Git via HTTPS é uma solicitação web comum que um proxy processa nativamente. Git via SSH usa a porta 22, que geralmente não é permitida pelo proxy. O resultado é que um repositório é clonado sem problemas com um remoto HTTPS e expira com um remoto SSH, e a mensagem de erro raramente explica o motivo.
Três soluções práticas, em ordem de preferência: mudar o remoto para HTTPS com um token, usar SSH pela porta HTTPS onde GitHub oferece suporte ou pedir à equipe de rede que permita SSH para hosts específicos. A primeira funciona em qualquer lugar e é a opção adotada pela maioria das equipes.
Como interpretar os erros?
| Erro | Use esta solução quando | Evite quando |
|---|---|---|
| Falha na verificação de certificado | Adicione a CA corporativa ao armazenamento de confiança da ferramenta | Nunca desative a verificação, pois isso oculta um risco real |
| Tempo limite de conexão em um remoto SSH | Mude para HTTPS ou use SSH pela porta HTTPS | Tentar novamente; a porta está bloqueada, não lenta |
| Autenticação de proxy necessária | Configure as credenciais no armazenamento da ferramenta | Colocá-las em uma URL, pois isso vaza para logs |
| Funciona no terminal, falha no Docker | Configure o daemon Docker, depois reinicie-o | Adicionar mais variáveis do shell, que o daemon nunca lê |
| Hosts internos inacessíveis após a configuração | Adicione-os à lista de no-proxy | Remover inteiramente a configuração de proxy |
A primeira linha é aquela sobre a qual vale ser firme. A inspeção TLS significa que um dispositivo intermediário está encerrando e reassinando suas conexões, e a resposta correta é confiar deliberadamente na CA da organização. Desativar a verificação faz o erro desaparecer e torna invisível toda interceptação futura.
Quando um proxy externo é a ferramenta certa?
Raramente para este problema, e vale deixar isso claro.
Um proxy corporativo é uma infraestrutura operada pela sua organização, e a solução para o acesso ao GitHub por trás dele é configuração, não um segundo proxy. Contornar um controle de rede que seu empregador colocou deliberadamente é uma questão de política antes de ser uma questão técnica.
O caso em que um proxy comercial realmente se aplica é outro tipo de trabalho que por acaso envolve GitHub: coletar dados públicos de repositórios em escala, verificar como uma página pública é exibida em outro país ou executar verificações automatizadas em várias regiões. Especificamente para coletar dados de repositórios, a API do GitHub com um token é a resposta certa primeiro, e ela é generosa o bastante para que fazer scraping da web raramente seja justificável.
Quando a coleta precisa de saídas distribuídas, os proxies residenciais DataImpulse cobrem 195 países por $1 por GB. Relacionados: proxies para web scraping, explicação sobre 403 Forbidden.
Perguntas frequentes
Como configuro git para usar um proxy?
Defina o proxy na própria configuração do git ou nas variáveis de ambiente padrão e, ao mesmo tempo, adicione hosts internos a uma lista de no-proxy. Git lê sua própria configuração separadamente de npm, pip e Docker, portanto cada ferramenta precisa ser configurada individualmente.
Por que git clone via SSH falha por trás de um proxy?
Porque SSH usa a porta 22 e a maioria dos proxies corporativos encaminha apenas HTTP CONNECT para portas web padrão. Remotos HTTPS funcionam porque são solicitações web comuns. Mudar o remoto para HTTPS com um token é a solução que funciona na maioria dos ambientes.
O que causa erros de certificado por trás de um proxy corporativo?
Inspeção TLS: um dispositivo intermediário encerra e reassina suas conexões com a própria autoridade certificadora da organização. A solução é adicionar essa CA ao armazenamento de confiança de cada ferramenta. Desativar a verificação de certificado remove o erro e remove sua capacidade de detectar uma interceptação real.
Por que Docker falha quando meu terminal funciona?
Porque o daemon Docker baixa imagens, não seu shell, e ele lê sua própria configuração em vez das suas variáveis de ambiente. Configure as definições de proxy do daemon e reinicie-o.
Devo usar um proxy comercial para acessar GitHub no trabalho?
Não. Um proxy corporativo é uma infraestrutura que sua organização opera deliberadamente, e a solução é configuração. Proxies comerciais se aplicam a outro tipo de trabalho, como coletar dados públicos de muitas regiões, e mesmo nesse caso a API do GitHub com um token geralmente é a melhor opção.
Quando o trabalho é coleta, não conectividade
Verificar como páginas públicas são exibidas em outras regiões ou coletar dados públicos em escala é um problema diferente da configuração de rede corporativa. Os proxies residenciais DataImpulse cobrem 195 países por $1 por GB. Crie uma conta quando esse for o trabalho.
Relacionado: proxies para web scraping · 403 Forbidden ao fazer web scraping · o que é um proxy web.
Última atualização: 17 de setembro de 2026.