Guia completo para configurar proxy no Ubuntu 26.04 LTS

Por que a configuração de proxy no Ubuntu Linux é complicada

-v

-sp

set

zsh

fish

~/.*rc

~/.zshrc

~/.bash_profile

curl --noproxy "*"

Connected to proxyhost

Connected to example.com

~/.config/fish/config.fish

set -x no_proxy "localhost,127.0.0.1"

export no_proxy="localhost,127.0.0.1"

set -x http_proxy "http://proxyhost:port"

set -x https_proxy "http://proxyhost:port"

sudo systemctl show docker --property=Environment

sudo -E curl -x $http_proxy https://httpbin.org/ip

sudo systemctl show myservice --property=Environment

curl -v -x http://proxyhost:port https://example.com

curl -x http://proxyhost:port https://httpbin.org/ip

sudo apt update -o Acquire::http::proxy="http://proxyhost:port"

Você acabou de instalar o Ubuntu. Você digita http_proxy no terminal, curl google.com funciona, mas sudo apt update falha. Bem-vindo à configuração de proxy no Linux.

O Ubuntu (e o Linux em geral) não possui uma configuração de proxy única e sistêmica que todos os aplicativos respeitam. Diferente do Windows ou macOS, onde você pode configurar um proxy nas preferências do sistema e a maioria dos aplicativos o usará, o Ubuntu depende de uma abordagem fragmentada, sem uma chave central de proxy.

Cada ferramenta ou:

1. Ignora completamente as variáveis de ambiente, ou
2. Usa‑as apenas sob condições específicas, ou
3. Requer sua própria configuração separada.

Configurar um proxy no Ubuntu significa, de fato, configurar múltiplas ferramentas de forma independente.

Neste guia detalhado, cobriremos apt, curl, wget, git, pip, npm, Docker, Snap e systemd com exemplos de configuração funcionais.

Você aprenderá sobre diferentes tipos de proxy e exatamente onde configurar cada ferramenta, para que finalmente possa configurá‑lo uma vez e ter tudo funcionando.

Entendendo os tipos de proxy

Antes de configurar qualquer coisa, você precisa saber com que tipo de proxy está trabalhando. Diferentes tipos de proxy se comportam de forma diferente, e escolher o tipo errado pode causar falhas de conexão.

Proxies de datacenter

Proxies de datacenter vêm de servidores hospedados em datacenters. Eles são rápidos e baratos, mas sites frequentemente podem detectá‑los e bloqueá‑los porque seus endereços IP não parecem conexões reais de internet residencial.

Por isso, funcionam melhor para tarefas de alto volume e baixo risco (como raspar dados públicos, monitorar sua própria infraestrutura ou teste de carga) onde a velocidade importa mais do que passar despercebido.

Proxies residenciais

Proxies residenciais usam endereços IP que provedores de internet reais (ISPs) atribuem a dispositivos domésticos reais. Por isso, os sites tratam o tráfego de proxies residenciais como tráfego de um usuário comum.

Isso os torna muito úteis para web scraping, testes geográficos e tarefas onde IPs de datacenter são bloqueados.

Proxies HTTP vs HTTPS

Um proxy HTTP lida com tráfego web padrão. Um proxy HTTPS adiciona criptografia à conexão entre seu dispositivo e o servidor proxy, o que significa que suas credenciais e metadados de requisição permanecem protegidos de qualquer pessoa observando sua rede local. A maioria das configurações modernas de proxy usa HTTPS, então sempre verifique qual protocolo seu provedor suporta.

Para uma explicação técnica mais profunda de como proxies HTTP e HTTPS funcionam no nível de protocolo, incluindo como o método CONNECT cria túneis e o que arquivos PAC fazem, o MDN Web Docs cobre isso detalhadamente.

Proxies SOCKS5

Proxies SOCKS5 funcionam em um nível mais baixo que proxies HTTP/HTTPS. Diferente de proxies HTTP que lidam apenas com tráfego web, SOCKS5 roteia todo o tráfego de rede, incluindo UDP, FTP e protocolos não HTTP, o que o torna a escolha mais flexível e amigável à privacidade. Muitas ferramentas no Ubuntu suportam SOCKS5 nativamente, incluindo curl, ssh e a maioria dos clientes torrent.

Agora que você entende os tipos, vamos à configuração real.

Método 1XQPROTECTED0297QXZ Variáveis de ambiente

Variáveis de ambiente são a coisa mais próxima que o Ubuntu tem de uma configuração universal de proxy. Muitas ferramentas de linha de comando verificam essas variáveis automaticamente, então configurá‑las é sempre o melhor lugar para começar.

As variáveis‑chave

O Ubuntu reconhece estas variáveis de ambiente de proxy padrão:

http_proxy      # Proxy for HTTP traffic
https_proxy     # Proxy for HTTPS traffic
ftp_proxy       # Proxy for FTP traffic
no_proxy        # Comma-separated list of hosts to bypass
ALL_PROXY       # Fallback proxy for tools that ignore the others

Sempre use nomes de variáveis em minúsculas. As versões em maiúsculas (HTTP_PROXY, HTTPS_PROXY) têm uma vulnerabilidade de segurança conhecida em ambientes CGI chamada httpoxy (VU#797896).

Um atacante pode enviar um cabeçalho de requisição HTTP Proxy: manipulado que um servidor web CGI promove para a variável de ambiente HTTP_PROXY, que então redireciona o tráfego de saída do seu aplicativo para o servidor do atacante.

Variáveis em minúsculas não são afetadas por este ataque porque a especificação CGI (RFC 3875) apenas promove cabeçalhos de requisição HTTP para variáveis de ambiente em maiúsculas. Então, embora ambos os casos funcionem na maioria das situações, minúsculas é o padrão mais seguro e o que você deve sempre usar.

Observe também a variável ALL_PROXY: muitas ferramentas, incluindo curl, git e várias bibliotecas Python, recorrem a ALL_PROXY quando não encontram uma variável específica de protocolo. Incluí‑la torna sua configuração mais robusta com muito pouco esforço extra.

Definir variáveis apenas para a sessão atual

Se você quiser testar seu proxy rapidamente sem fazer alterações permanentes, execute estes comandos no terminal:

export http_proxy="http://proxyhost:port"
export https_proxy="http://proxyhost:port"
export ftp_proxy="http://proxyhost:port"
export ALL_PROXY="http://proxyhost:port"
export no_proxy="localhost,127.0.0.1,::1"

Substitua proxyhost pelo endereço IP real ou hostname do seu servidor proxy e port pelo número da porta. Essas configurações desaparecem assim que você fecha a janela do terminal, então são perfeitas para testes rápidos.

Tornar variáveis permanentes para sua conta de usuário

Para manter as configurações de proxy toda vez que você abrir um terminal, adicione as linhas export ao seu arquivo ~/.bashrc:

nano ~/.bashrc

Role até o final e adicione:

# Proxy settings
export http_proxy="http://proxyhost:port"
export https_proxy="http://proxyhost:port"
export ftp_proxy="http://proxyhost:port"
export ALL_PROXY="http://proxyhost:port"
export no_proxy="localhost,127.0.0.1,::1"

Salve com Ctrl+O, pressione Enter, depois saia com Ctrl+X. Recarregue imediatamente:

source ~/.bashrc

Tornar variáveis sistêmicas para todos os usuários

Se você precisa que todos os usuários da máquina usem o mesmo proxy, você tem duas boas opções.

Opção 1XQPROTECTED0297QXZ /etc/environment

Esta é a abordagem mais simples. É um arquivo de valores‑chave estático que o PAM lê no login e aplica a cada usuário e cada sessão:

sudo nano /etc/environment

Adicione estas linhas no final. Note que /etc/environment não usa a palavra‑chave export e não suporta expansão de variáveis. Você não pode referenciar $HOME ou outras variáveis dentro dele:

http_proxy="http://proxyhost:port"
https_proxy="http://proxyhost:port"
ftp_proxy="http://proxyhost:port"
ALL_PROXY="http://proxyhost:port"
no_proxy="localhost,127.0.0.1,::1"

Salve e reinicie para que as alterações se apliquem a todos os usuários.

Opção 2XQPROTECTED0297QXZ /etc/profile.d/proxy.sh

Esta é a melhor escolha quando você precisa de lógica dinâmica — por exemplo, se seu endereço de proxy depende de uma variável de ambiente, uma consulta de hostname ou uma condição. Diferente de /etc/environment, scripts shell em /etc/profile.d/ suportam sintaxe bash completa:

sudo nano /etc/profile.d/proxy.sh

Adicione:

#!/bin/bash
# System-wide proxy settings
PROXY_HOST="proxyhost"
PROXY_PORT="port"
export http_proxy="http://${PROXY_HOST}:${PROXY_PORT}"
export https_proxy="http://${PROXY_HOST}:${PROXY_PORT}"
export ftp_proxy="http://${PROXY_HOST}:${PROXY_PORT}"
export ALL_PROXY="http://${PROXY_HOST}:${PROXY_PORT}"
export no_proxy="localhost,127.0.0.1,::1"

Torne‑o executável:

sudo chmod +x /etc/profile.d/proxy.sh

Este script é executado para todo shell de login interativo no sistema. É a abordagem preferida para administradores gerenciando servidores multi‑usuário.

Nota importante: Mesmo que variáveis de ambiente funcionem para muitas ferramentas CLI, apt, sudo, serviços systemd e pacotes Snap as ignoram. Cada um desses precisa de sua própria configuração dedicada, que as seções abaixo cobrem em detalhes.

Método 2XQPROTECTED0297QXZ Configuração de proxy do APT

APT tem seu próprio sistema de proxy. Ele não lê suas variáveis de ambiente. Portanto, mesmo se você configurar http_proxy corretamente, o APT ainda ignorará o proxy a menos que você o configure diretamente.

A maneira correta de configurar o proxy do APT

Crie um arquivo de configuração de proxy dedicado para o APT:

sudo nano /etc/apt/apt.conf.d/proxy.conf

Este arquivo não existe por padrão, então você está criando um novo. Adicione estas linhas:

Acquire::http::Proxy "http://proxyhost:port";
Acquire::https::Proxy "http://proxyhost:port";
Acquire::ftp::Proxy "ftp://proxyhost:port";

Salve o arquivo e saia. A partir deste ponto, todo comando apt roteará automaticamente através do seu proxy. Você não precisa reiniciar nada.

Testar se o APT está usando o proxy

Execute uma atualização simples para confirmar que o proxy está funcionando:

sudo apt update

Se o APT conectar e baixar as listas de pacotes sem erros, sua configuração de proxy está correta.

Desabilitar o proxy do APT para hosts específicos

Às vezes você quer que o APT ignore o proxy para certos servidores internos:

Acquire::http::Proxy {
"internal.server.local" DIRECT;
};

Isso diz ao APT para conectar diretamente a internal.server.local enquanto ainda roteia todo o resto através do proxy.

Remover o proxy do APT

Para parar o APT de usar o proxy, delete o arquivo de configuração:

sudo rm /etc/apt/apt.conf.d/proxy.conf

Método 3XQPROTECTED0297QXZ curl

curl é uma das ferramentas de linha de comando mais usadas no Ubuntu. Configurá‑lo para usar um proxy é direto, mas entender como ele lê arquivos de configuração economiza muito tempo de depuração.

Usar um proxy para um único comando curl

Adicione a flag -x:

curl -x http://proxyhost:port https://example.com

Tornar o proxy permanente para seu usuário

Salve suas configurações de proxy no arquivo de configuração do usuário de curl:

nano ~/.curlrc

Adicione:

proxy = http://proxyhost:port

A partir de agora, todo comando curl que você executar usará automaticamente este proxy. O curl procura por este arquivo em $CURL_HOME/.curlrc, depois $XDG_CONFIG_HOME/.curlrc, depois ~/.curlrc.

Tornar curl usar o proxy sistemicamente

curl não tem um caminho de arquivo de configuração sistêmico padrão no Linux. A maneira mais confiável de fazer curl usar um proxy para todos os usuários no sistema é configurar as variáveis de ambiente em /etc/profile.d/proxy.sh (coberto no Método 1). curl lê http_proxy e https_proxy automaticamente no nível de precedência mais baixo, então variáveis de ambiente sistêmicas são a abordagem correta aqui.

Se você precisar sobrescrever o proxy para um usuário ou script específico, você pode apontar curl para qualquer arquivo de configuração com a flag -K:

curl -K /path/to/curlconfig https://example.com

Sobrescrever o proxy para um único comando

curl --noproxy "*" https://internal.server.local

Considerações sobre certificados SSL

Se sua organização usa um proxy de interceptação que inspeciona tráfego HTTPS, curl lançará erros de certificado SSL. Nunca use -k (modo inseguro) em produção. Ele desabilita toda verificação de certificado. Em vez disso, instale o certificado CA raiz da sua organização no repositório de confiança do Ubuntu. Isso será coberto na seção de Certificados CA Corporativos em detalhes.

Método 4XQPROTECTED0297QXZ wget

wget tem seu próprio arquivo de configuração e não herda as configurações de proxy do APT.

Usar um proxy para um único comando wget

wget -e use_proxy=yes -e http_proxy=http://proxyhost:port https://example.com

Tornar o proxy permanente para seu usuário

nano ~/.wgetrc

Adicione:

http_proxy = http://proxyhost:port
https_proxy = http://proxyhost:port
ftp_proxy = ftp://proxyhost:port
use_proxy = on

Tornar o proxy sistêmico para todos os usuários

sudo nano /etc/wgetrc

Encontre as linhas relacionadas ao proxy (elas estão comentadas por padrão). Remova o # de cada uma e preencha com os detalhes do seu proxy:

http_proxy = http://proxyhost:port
https_proxy = http://proxyhost:port
ftp_proxy = ftp://proxyhost:port
use_proxy = on

Ignorar o proxy para domínios específicos

Adicione uma linha no_proxy ao ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.internal.company.com

Método 5XQPROTECTED0297QXZ Configurações de desktop do GNOME

O Ubuntu 26.04 vem com o GNOME 50 como ambiente de desktop padrão. O GNOME inclui um painel de proxy embutido que é fácil de usar, mas vem com uma limitação crítica.

Como acessar as configurações de proxy do GNOME

1. Abra Configurações no menu de aplicativos ou na bandeja do sistema no canto superior direito
2. Clique em Rede na barra lateral esquerda
3. Role para baixo até Proxy e clique no ícone de engrenagem

Na próxima janela, ative o interruptor "Network proxy" para a posição ON. E então, escolha "Manual" na seção Configuration.

Defina endereços de proxy para HTTP, HTTPS, FTP e SOCKS individualmente.

A limitação crítica das configurações de proxy do GNOME

As configurações de proxy do GNOME se aplicam apenas a aplicativos GNOME. Seu navegador, aplicativo Arquivos e outros aplicativos GUI respeitarão essas configurações. Mas seu terminal, apt, curl, wget, git e todas as outras ferramentas de linha de comando as ignoram completamente.

Esta é uma fonte muito comum de confusão. Muitas pessoas configuram o proxy nas Configurações do GNOME, abrem um terminal e depois descobrem que curl ainda conecta diretamente. A solução é sempre combinar as Configurações do GNOME com variáveis de ambiente para cobertura completa.

Quando as Configurações do GNOME são suficientes

Se você só precisa de suporte a proxy para seu navegador web e aplicativos de desktop, as Configurações do GNOME sozinhas são suficientes. Caso contrário, use‑as junto com os métodos neste guia.

Método 6XQPROTECTED0297QXZ Git

Quase todo desenvolvedor e administrador usa Git (link: https://ostechnix.com/what-is-git-and-how-to-install-git-in-linux/?). O Git usa libcurl internamente para lidar com todas as conexões de rede (tanto HTTP quanto HTTPS), o que significa que ele tem sua própria configuração de proxy separada das variáveis de ambiente do sistema.

Definir um proxy global do Git

A chave de configuração http.proxy do Git cobre ambas as conexões HTTP e HTTPS. Você só precisa configurar uma chave:

git config --global http.proxy http://proxyhost:port

Verifique se a configuração foi salva:

git config --global --list | grep proxy

Definir um proxy para um único repositório

Se você só precisa do proxy para um repositório específico, execute isto dentro do diretório desse repositório:

git config http.proxy http://proxyhost:port

Ignorar o proxy para servidores Git internos

Se você tem um servidor GitLab ou Gitea interno que deve conectar diretamente, diga ao Git para pular o proxy para essa URL específica:

git config --global http.https://gitlab.internal.company.com.proxy ""

Remover o proxy do Git

git config --global --unset http.proxy

Onde o Git armazena essas configurações

O Git escreve as configurações de proxy em ~/.gitconfig. Você também pode editar este arquivo diretamente:

nano ~/.gitconfig

Ele se parecerá com isto:

[http]
proxy = http://proxyhost:port

Nota: A chave http.proxy do Git cobre tanto URLs de repositório HTTP quanto HTTPS porque o Git usa libcurl internamente para toda transferência. Você não precisa (e não deve configurar) uma chave https.proxy separada, pois não é uma opção de configuração documentada do Git.

Método 7XQPROTECTED0297QXZ pip (Python)

O gerenciador de pacotes do Python pip (link: https://ostechnix.com/manage-python-packages-using-pip/?) tem sua própria configuração de proxy. Embora pip leia as variáveis de ambiente http_proxy e https_proxy, um arquivo pip.conf permanente é mais confiável e funciona independentemente de como o ambiente shell está configurado.

Definir um proxy para um único comando pip

pip install requests --proxy http://proxyhost:port

Tornar o proxy permanente para seu usuário

Crie o diretório e arquivo de configuração do pip:

mkdir -p ~/.config/pip
nano ~/.config/pip/pip.conf

Adicione:

[global]
proxy = http://proxyhost:port

Tornar o proxy sistêmico para todos os usuários

pip verifica /etc/pip.conf para configurações globais no Linux:

sudo nano /etc/pip.conf

Adicione o mesmo conteúdo:

[global]
proxy = http://proxyhost:port

pip dentro de um ambiente virtual

Se você usa ambientes virtuais Python, o proxy do seu arquivo pip.conf global ou de usuário ainda se aplica. No entanto, se você precisar de um proxy diferente por projeto, crie um pip.conf dentro do ambiente virtual:

nano /path/to/venv/pip.conf

Adicione o mesmo bloco [global] com o proxy específico do projeto.

Método 8XQPROTECTED0297QXZ npm (Node.js)

npm (link: https://ostechnix.com/install-node-js-linux/?) armazena sua configuração de proxy separadamente das variáveis de ambiente do sistema. Você a configura com o comando npm config, que escreve em ~/.npmrc.

Definir o proxy do npm

npm config set proxy http://proxyhost:port
npm config set https-proxy http://proxyhost:port

Verificar as configurações de proxy do npm

npm config get proxy
npm config get https-proxy

Remover o proxy do npm

npm config delete proxy
npm config delete https-proxy

Proxy sistêmico do npm

Para aplicar o proxy a todos os usuários na máquina, edite o arquivo npmrc global:

sudo npm config set proxy http://proxyhost:port --global
sudo npm config set https-proxy http://proxyhost:port --global

Problemas de certificado SSL com npm

Se npm lançar erros SSL atrás de um proxy de interceptação, aponte npm para o pacote CA do sistema do Ubuntu após instalar seu certificado corporativo (veja a seção CA Certificates para detalhes):

npm config set cafile /etc/ssl/certs/ca-certificates.crt

Método 9XQPROTECTED0297QXZ Docker

Docker precisa de configuração de proxy em dois lugares separados, e confundi-los é um dos erros mais comuns. Uma configuração controla o daemon Docker em si (para baixar imagens). A outra controla operações do cliente Docker, incluindo builds.

Parte 1XQPROTECTED0297QXZ Proxy para o daemon Docker (baixando imagens)

O daemon Docker executa como um serviço systemd, então precisa de um arquivo drop-in do systemd. A documentação oficial do Docker recomenda criar um arquivo com nome específico:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

Adicione:

[Service]
Environment="HTTP_PROXY=http://proxyhost:port"
Environment="HTTPS_PROXY=http://proxyhost:port"
Environment="NO_PROXY=localhost,127.0.0.1,.internal.company.com"

Alternativamente, sudo systemctl edit docker cria a mesma estrutura de diretório com um arquivo chamado override.conf. Ambas as abordagens funcionam de forma idêntica porque o systemd lê todos os arquivos .conf no diretório.

Salve e saia, então recarregue e reinicie o Docker:

sudo systemctl daemon-reload
sudo systemctl restart docker

Confirme que as variáveis de ambiente estão ativas:

sudo systemctl show --property=Environment docker

Parte 2XQPROTECTED0297QXZ Proxy para o cliente Docker (builds, pulls e mais)

A configuração de proxy do cliente Docker em ~/.docker/config.json controla como as configurações de proxy são passadas durante operações da CLI do Docker — incluindo docker build, docker pull e contêineres que precisam de acesso a proxy em tempo de execução. Configure aqui:

nano ~/.docker/config.json

Adicione ou mescle este bloco:

{
"proxies": {
"default": {
"httpProxy": "http://proxyhost:port",
"httpsProxy": "http://proxyhost:port",
"noProxy": "localhost,127.0.0.1,.internal.company.com"
}
}
}

O Docker automaticamente passa esses valores como argumentos de build para todo comando docker build. Você não precisa adicionar --build-arg manualmente.

Nota: As configurações de proxy em ~/.docker/config.json se aplicam a operações do cliente Docker CLI. Elas são injetadas como ARGs em tempo de build durante docker build, e configuram variáveis de ambiente para operações que as respeitam. No entanto, elas não configuram automaticamente variáveis de ambiente dentro de contêineres de longa duração iniciados com docker run. Esses contêineres precisam de suas próprias flags -e explícitas ou sua própria configuração de proxy em nível de aplicação.

Método 10XQPROTECTED0297QXZ Pacotes Snap

O Ubuntu 26.04 fornece muitos aplicativos como pacotes Snap. O Snap ignora completamente variáveis de ambiente do sistema, /etc/environment e tudo mais coberto até agora. Ele tem seu próprio sistema de proxy gerenciado através de snapd.

Definir o proxy do Snap

sudo snap set system proxy.http="http://proxyhost:port"
sudo snap set system proxy.https="http://proxyhost:port"

Verificar o proxy do Snap

sudo snap get system proxy

Você deve ver uma saída como:

Key           Value
proxy.http    http://proxyhost:port
proxy.https   http://proxyhost:port

Remover o proxy do Snap

sudo snap unset system proxy.http
sudo snap unset system proxy.https

Reiniciar snapd após alterações

Após configurar o proxy, reinicie o serviço snapd para que as alterações entrem em vigor imediatamente:

sudo systemctl restart snapd

Método 11XQPROTECTED0297QXZ Serviços Systemd

Qualquer aplicativo executando como um serviço systemd (um servidor web, um daemon scraper, uma tarefa agendada) não herdará configurações de proxy de /etc/environment, ~/.bashrc ou qualquer configuração de nível de usuário.

Os serviços systemd executam em seu próprio ambiente isolado. Isso surpreende muitos administradores na primeira vez que encontram.

A abordagem correta é um arquivo de substituição drop-in do systemd, que mantém suas alterações separadas do arquivo de unidade original para que atualizações de pacote não as sobrescrevam.

Criar uma substituição drop-in para qualquer serviço

Substitua servicename pelo nome real do serviço (por exemplo, nginx, myapp ou scraper):

sudo systemctl edit servicename

Isso cria um arquivo de substituição em /etc/systemd/system/servicename.service.d/override.conf. Adicione:

[Service]
Environment="http_proxy=http://proxyhost:port"
Environment="https_proxy=http://proxyhost:port"
Environment="no_proxy=localhost,127.0.0.1,.internal.company.com"

Salve e saia, então recarregue o systemd e reinicie o serviço:

sudo systemctl daemon-reload
sudo systemctl restart servicename

Verificar se o serviço tem o ambiente correto

sudo systemctl show servicename --property=Environment

Aplicar proxy a todos os serviços de uma vez

Se você quiser que todo serviço systemd na máquina use o mesmo proxy, crie um arquivo de ambiente global que o systemd leia:

sudo nano /etc/systemd/system.conf

Encontre a seção [Manager] e adicione ou descomente:

DefaultEnvironment="http_proxy=http://proxyhost:port" "https_proxy=http://proxyhost:port"

Então recarregue o systemd:

sudo systemctl daemon-reload

Use esta abordagem com cuidado. Ela aplica o proxy a todo serviço na máquina, o que raramente é o que você deseja.

Lidando com autenticação de proxy

Muitos servidores proxy, especialmente proxies residenciais e corporativos, exigem um nome de usuário e senha. Adicionar credenciais à sua URL de proxy é simples, mas há alguns casos extremos a serem tratados com cuidado.

Formato de autenticação básica

http://username:password@proxyhost:port

Por exemplo:

export http_proxy="http://john:[email protected]:8080"

Para uso temporário em scripts sem armazenar credenciais permanentemente:

read -sp "Proxy password: " PROXY_PASS
export http_proxy="http://username:${PROXY_PASS}@proxyhost:port"
unset PROXY_PASS  # Clear after use

Caracteres especiais em senhas

Se sua senha contém caracteres especiais como @, :, / ou #, você deve codificá‑los em URL (URL-encode). Caso contrário, a URL do proxy quebra porque esses caracteres têm significado especial dentro de uma URL.

Por exemplo, se sua senha é p@ss:word, escreva‑a como p%40ss%3Aword na URL do proxy.

Proteger suas credenciais

Armazenar uma senha em texto simples dentro de .bashrc ou /etc/environment é um risco de segurança. Aqui estão duas abordagens melhores:

Opção 1XQPROTECTED0297QXZ Restringir permissões de arquivo

Crie um arquivo separado que contenha apenas suas credenciais de proxy:

nano ~/.proxy_credentials

Adicione:

export http_proxy="http://username:password@proxyhost:port"
export https_proxy="http://username:password@proxyhost:port"
export ALL_PROXY="http://username:password@proxyhost:port"

Proteja o arquivo para que apenas seu usuário possa lê‑lo:

chmod 600 ~/.proxy_credentials

Então importe‑o do seu .bashrc:

source ~/.proxy_credentials

Opção 2XQPROTECTED0297QXZ Usar um gerenciador de segredos

Para servidores de produção, considere ferramentas como pass (o gerenciador de senhas padrão do Unix) ou HashiCorp Vault para armazenar e injetar credenciais de proxy em tempo de execução. Esta abordagem mantém as credenciais fora dos arquivos de configuração completamente e é a escolha certa para qualquer servidor com múltiplos usuários ou implantações automatizadas.

Instalando certificados CA corporativos

Em ambientes corporativos e empresariais, servidores proxy frequentemente usam inspeção TLS. Eles interceptam suas conexões HTTPS e as re‑assinam com seu próprio certificado raiz. Toda ferramenta CLI lançará erros SSL até que você instale esse certificado raiz no repositório de confiança do sistema Ubuntu.

Esta é a correção permanente e adequada. Nunca use -k no curl ou --no-check-certificate no wget como solução alternativa. Essas flags desabilitam toda verificação de certificado e expõem você a ataques man‑in‑the‑middle de qualquer fonte, não apenas do seu proxy.

Passo 1XQPROTECTED0297QXZ Obter o certificado CA corporativo

Peça à sua equipe de TI ou rede o arquivo de certificado CA raiz. Ele estará tipicamente no formato .crt ou .pem. Se você não conseguir o arquivo diretamente, pode exportá‑lo de um navegador que já confia no proxy.

Passo 2XQPROTECTED0297QXZ Copiar o certificado para o local correto

sudo cp your-corporate-ca.crt /usr/local/share/ca-certificates/

O arquivo deve ter uma extensão .crt. Se seu certificado estiver no formato .pem, renomeie‑o primeiro:

sudo cp your-corporate-ca.pem /usr/local/share/ca-certificates/your-corporate-ca.crt

Passo 3XQPROTECTED0297QXZ Reconstruir o pacote CA do sistema

sudo update-ca-certificates

Você deve ver uma saída confirmando que o certificado foi adicionado:

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Após isso, curl, wget, apt, git, pip, npm e a maioria das outras ferramentas confiarão automaticamente no certificado do seu proxy corporativo. Você não precisa configurar cada ferramenta individualmente.

Passo 4XQPROTECTED0297QXZ Verificar se o certificado é confiável

Teste com uma simples requisição curl através do seu proxy:

curl -x http://proxyhost:port https://example.com

Se você não vir mais erros SSL, a instalação do certificado funcionou corretamente.

Repositórios SSL do Java e Python

Note que Java e algumas bibliotecas Python mantêm seus próprios repositórios de certificado separados e não leem o pacote do sistema Ubuntu automaticamente.

Para Java, a localização do arquivo cacerts depende de qual versão JVM você tem instalada. Encontre‑a primeiro, depois importe:

# Step 1 — Find your Java cacerts file
find /usr/lib/jvm -name "cacerts" 2>/dev/null
# Step 2 — Import your corporate CA (replace the path with the one found above)
sudo keytool -import -alias corporate-ca \
-file /usr/local/share/ca-certificates/your-corporate-ca.crt \
-keystore /usr/lib/jvm/java-21-openjdk-amd64/lib/security/cacerts \
-storepass changeit -noprompt

O comando find é essencial porque o caminho muda com cada versão JVM e método de instalação. Usar um caminho fixo falhará silenciosamente se sua JVM estiver instalada de forma diferente.

O problema do sudo que todo administrador enfrenta

Esta é a falha de proxy mais comum no Ubuntu, e afeta até administradores experientes.

Quando você executa qualquer comando com sudo, o sudo remove suas variáveis de ambiente por padrão como medida de segurança. Isso significa que http_proxy, https_proxy e todas as outras variáveis de proxy que você configurou simplesmente desaparecerão para aquele comando, mesmo que estejam perfeitamente configuradas no seu shell.

Então, quando você configura variáveis de ambiente e depois executa sudo apt update, o APT não está ignorando seu proxy porque o APT ignora variáveis de ambiente (o que ele faz). A questão mais profunda é que sudo já as removeu antes mesmo do APT iniciar.

Correção rápida: Usar sudo -E para um único comando

A flag -E diz ao sudo para preservar suas variáveis de ambiente:

sudo -E curl https://example.com
sudo -E pip install requests

No entanto, isso só funciona para aquele comando, e não corrige apt já que o APT tem sua própria configuração de proxy de qualquer forma.

Correção permanente: Configurar sudoers para manter variáveis de proxy

A solução permanente adequada é dizer ao sudo quais variáveis preservar para todos os comandos. Edite o arquivo sudoers com segurança usando visudo:

sudo visudo

Encontre a seção Defaults e adicione esta linha:

Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy ALL_PROXY HTTP_PROXY HTTPS_PROXY NO_PROXY"

Salve e saia. A partir deste ponto, o sudo preservará suas variáveis de ambiente de proxy para todo comando.

Verificar se sudo preserva as variáveis

Teste se funciona:

export http_proxy="http://proxyhost:port"
sudo printenv http_proxy

Se você vir o endereço do proxy impresso, o sudo está agora preservando a variável corretamente.

Nota de segurança: Preservar variáveis de ambiente de proxy no sudoers é seguro na maioria dos ambientes. No entanto, esteja ciente de que em sistemas altamente sensíveis, variáveis de proxy poderiam teoricamente ser manipuladas para redirecionar tráfego privilegiado. Nesses casos, configure cada ferramenta privilegiada (APT, pip de nível de sistema, etc.) com seu próprio arquivo de configuração dedicado em vez de depender de variáveis de ambiente herdadas.

Verificando se seu proxy realmente funciona

Há uma diferença importante entre verificar se uma variável está configurada e confirmar que o proxy está realmente roteando seu tráfego.

Executar echo $http_proxy apenas confirma que a variável existe no seu shell. Não lhe diz nada sobre se o proxy está acessível ou funcionando.

Use estes comandos para confirmar a conectividade real do proxy.

Verificar qual IP o mundo vê

Este é o teste mais confi

Entendendo a precedência de variáveis

Quando múltiplas configurações de proxy existem ao mesmo tempo (uma variável de ambiente, um arquivo de configuração de ferramenta e uma flag de linha de comando), qual vence? Entender a ordem previne horas de depuração quando uma configuração parece não ter efeito.

Precedência do curl (Maior para Menor)

Uma flag de linha de comando sempre vence. Se você configurar um proxy em ~/.curlrc mas depois executar curl --noproxy "*", a flag sobrescreve o arquivo de configuração completamente. Note que curl não tem arquivo de configuração sistêmico no Linux — variáveis de ambiente são o mecanismo sistêmico.

Precedência do wget (Maior para Menor)

Precedência do git (Maior para Menor)

Precedência do pip (Maior para Menor)

A conclusão prática é esta: flags de linha de comando sempre vencem, variáveis de ambiente sempre perdem. Se uma ferramenta não está pegando seu proxy, verifique se um arquivo de configuração em algum lugar está sobrescrevendo sua variável de ambiente com uma configuração diferente.

Guia de formato do no_proxy

A variável no_proxy diz às ferramentas quais hosts alcançar diretamente, ignorando o proxy. No entanto, diferentes ferramentas a interpretam de forma diferente. E se você errar o formato, você roteará tráfego interno através do proxy ou ignorará o proxy para hosts que deveriam usá‑lo.

O formato mais compatível

Este formato funciona corretamente na maioria das ferramentas:

export no_proxy="localhost,127.0.0.1,::1,.company.internal,10.0.0.0/8,192.168.0.0/16"

Regras‑chave:

• Use vírgulas para separar entradas — sem espaços após vírgulas na maioria das ferramentas
• Use um ponto inicial (.company.internal) para corresponder a um domínio e todos os seus subdomínios. Sem o ponto, a maioria das ferramentas corresponde apenas ao hostname exato
• Você pode incluir notação CIDR para faixas de IP, mas nem todas as ferramentas a suportam — curl e wget suportam; ferramentas mais antigas podem não
• Sempre inclua localhost e 127.0.0.1 explicitamente

Diferenças específicas de ferramentas

Erro comum: Ponto inicial faltando

Sem o ponto inicial, company.internal apenas ignora o proxy para o hostname exato company.internal. Subdomínios como gitlab.company.internal ainda passarão pelo proxy. Sempre use .company.internal para cobrir o domínio e todos os seus subdomínios.

Solução de problemas comuns

Mesmo após configuração cuidadosa, às vezes as coisas dão errado. Aqui estão os problemas mais comuns e suas soluções.

1. Meu proxy funciona no navegador mas não no terminal.

As configurações de proxy do GNOME se aplicam apenas a aplicativos GUI. Abra ~/.bashrc e adicione as variáveis de ambiente de proxy como mostrado no Método 1. Depois execute source ~/.bashrc.

2. Configurei as variáveis de ambiente mas o APT ainda falha.

O APT ignora variáveis de ambiente por design. Crie /etc/apt/apt.conf.d/proxy.conf como descrito no Método 2.

3. Configurei variáveis de ambiente mas comandos sudo ainda ignoram o proxy.

sudo remove variáveis de ambiente por padrão. Use sudo -E para comandos individuais, ou adicione as variáveis de proxy à lista env_keep em /etc/sudoers usando sudo visudo. Veja a seção sudo Problem acima.

4. curl funciona mas wget não.

Eles usam arquivos de configuração separados. Adicione seu proxy ao ~/.wgetrc como descrito no Método 4.

5. Configurei tudo mas conexões HTTPS ainda falham com erros SSL.

Você está atrás de um proxy de interceptação que re‑assina certificados. Instale o certificado CA raiz da sua organização usando os passos na seção de Certificados CA. Nunca use -k ou --no-check-certificate como correção permanente.

6. Meu serviço systemd ainda ignora o proxy.

Serviços não herdam variáveis de ambiente. Use sudo systemctl edit servicename para criar uma substituição drop‑in com linhas Environment= explícitas. Veja o Método 11.

7. Aplicativos Snap ignoram minhas configurações de proxy.

Snap tem seu próprio sistema de proxy. Execute sudo snap set system proxy.http="http://proxyhost:port" e sudo snap set system proxy.https="...", depois reinicie snapd. Veja o Método 10.

8. Git clone falha mesmo que curl funcione bem.

Git não herda variáveis de ambiente do sistema de forma confiável para uso de proxy. Defina o proxy explicitamente com git config --global http.proxy http://proxyhost:port. Note que esta única chave cobre ambas as conexões HTTP e HTTPS. Veja o Método 6.

9. pip install falha atrás do proxy.

Crie ~/.config/pip/pip.conf e adicione uma linha [global] proxy = .... Veja o Método 7.

10. Docker não consegue baixar imagens.

O daemon Docker é um serviço systemd, então precisa de seu próprio arquivo drop‑in. Veja o Método 9, Parte 1. Isso é separado da configuração do cliente Docker em ~/.docker/config.json.

11. Minhas variáveis de ambiente desaparecem após eu sair.

Variáveis configuradas com export no terminal duram apenas para aquela sessão. Adicione‑as ao ~/.bashrc para seu usuário, ou /etc/environment ou /etc/profile.d/proxy.sh para todos os usuários.

12. Minhas configurações de proxy funcionam mas alguns servidores internos estão inacessíveis.

Verifique sua variável no_proxy. Certifique‑se de que hostnames internos tenham um ponto inicial (.company.internal) e que você incluiu as faixas de IP relevantes. Veja o Guia de Formato do no_proxy acima.

13. Estou recebendo erros de autenticação mesmo que minhas credenciais estejam corretas.

Verifique se há caracteres especiais em sua senha. Codifique em URL (URL-encode) quaisquer caracteres @, :, / ou #. Veja a seção de Autenticação acima.

Tabela de referência rápida

Aqui está um resumo completo de cada ferramenta coberta neste guia.

Resumo final

Configurar um proxy no Ubuntu 26.04 dá mais trabalho do que a maioria das pessoas espera, mas o padrão é consistente uma vez que você o entende: cada ferramenta gerencia seu próprio proxy, e variáveis de ambiente são apenas um ponto de partida, não uma solução completa.

As coisas mais importantes a levar deste guia são:

• Comece com variáveis de ambiente em ~/.bashrc e /etc/environment. Elas cobrem a maior variedade de ferramentas com o menor esforço.
• Sempre configure o APT separadamente. Ele nunca lê variáveis de ambiente.
• Lembre‑se que sudo remove seu ambiente. Use sudo -E ou configure env_keep no sudoers.
• Serviços systemd e pacotes Snap têm sistemas de proxy completamente separados que ignoram todo o resto.
• Instale o certificado CA da sua organização no repositório de confiança do Ubuntu uma vez, e a maioria dos problemas HTTPS desaparece em todas as ferramentas de uma vez.
• Sempre use nomes de variáveis de proxy em minúsculas. Eles são amplamente suportados e evitam a vulnerabilidade de segurança httpoxy.
• A chave http.proxy do Git cobre ambas as conexões HTTP e HTTPS. Você só precisa configurá‑la uma vez.
• curl não tem arquivo de configuração sistêmico no Linux; use variáveis de ambiente via /etc/profile.d/proxy.sh para proxy sistêmico do curl.

Com a configuração correta em cada camada da pilha, sua máquina Ubuntu roteará o tráfego exatamente onde você quer, toda vez.

Este guia ajudou você? Compartilhe com um colega administrador Linux que está lidando com as mesmas dores de cabeça com proxy.