Sumário do artigo

O Docker há tempos virou padrão para rodar parsers, bots, automações de anúncios e pequenos serviços. Mas os contêineres têm uma particularidade: eles vivem em um ambiente isolado e não sabem nada sobre os proxies que você configurou no seu computador. Resultado: o script dentro do contêiner sai para a internet com o seu IP real, enquanto você pensa que está trabalhando por um proxy móvel. Este guia resolve essa lacuna de uma vez por todas.

Introdução: o que você vai conseguir e para quem serve este guia

Depois de concluir este tutorial, você vai saber configurar proxy no Docker nos três níveis possíveis: para um contêiner individual via variáveis de ambiente, para todo o cliente e daemon do Docker via arquivos de configuração, e também no nível de rede através de um contêiner-gateway separado. Você vai entender a diferença entre esses níveis, quando usar cada um e como confirmar que o tráfego realmente passa pelo proxy, e não desvia dele.

Para quem é este guia passo a passo

  • Profissionais de marketing e redes sociais que rodam no Docker serviços de postagem automática, análise ou monitoramento e querem que cada ferramenta trabalhe com seu próprio IP móvel.
  • Afiliados de tráfego com dezenas de contêineres com trackers, parsers de ofertas e serviços de espionagem, cada um precisando de um geo diferente.
  • Desenvolvedores que precisam testar uma aplicação de outra região ou rodar testes de integração através de um proxy.
  • Donos de negócio cujos colaboradores ou terceirizados fazem deploy de infraestrutura em contêineres, e que precisam entender como funciona o trabalho com proxy ali dentro.

O que você precisa saber de antemão

Não pressupomos conhecimentos avançados. Basta que você saiba abrir o terminal, copiar um comando e ler o que ele retornou. Se você nunca trabalhou com Docker, não se assuste: na seção de conceitos básicos explicamos todos os termos em linguagem simples. Kubernetes, orquestração de clusters e plataformas de nuvem ficam de fora de propósito: é um assunto à parte, e aqui permanecemos estritamente no nível do Docker.

Quanto tempo vai levar

A conclusão completa com as verificações leva de 60 a 120 minutos. Se você precisa de apenas um cenário, por exemplo proxy para um contêiner único, 15 minutos bastam. Se o Docker ainda não estiver instalado, acrescente 20–30 minutos de instalação.

Preparação inicial: ferramentas, acessos e requisitos de sistema

Antes de configurar o proxy no Docker, reúna tudo o que vai precisar. Assim você não vai se distrair procurando um login ou instalando utilitários no meio do processo.

O que vai ser necessário

  1. Um computador ou servidor com Docker. Serve Linux (Ubuntu 22.04 ou 24.04, Debian 12), macOS com Docker Desktop ou Windows 10/11 com Docker Desktop e WSL2. Em 2026, estão atuais o Docker Engine versão 27 ou superior e o Docker Compose v2, chamado pelo comando docker compose (com espaço, sem hífen).
  2. Dados do proxy móvel. Você precisa de quatro coisas: endereço do host (IP ou domínio), porta, login e senha. Você encontra isso no painel do provedor. Confirme também qual protocolo está disponível: HTTP ou SOCKS5. A maioria dos provedores de proxy móvel, incluindo a mobileproxy.space, tem as duas opções em portas diferentes.
  3. Terminal. No Linux e no macOS ele é nativo. No Windows, use o PowerShell ou o terminal do WSL2 (a segunda opção é mais prática, porque os comandos ficam idênticos aos do Linux).
  4. Editor de texto. Qualquer um: nano, vim, VS Code, Notepad++. Necessário para editar os arquivos de configuração.
  5. Utilitário curl. Normalmente já vem instalado. Ele ajuda a verificar por qual IP o tráfego está saindo.

Requisitos de sistema

  • No mínimo 2 GB de memória RAM e 10 GB de espaço livre em disco para o Docker e as imagens.
  • Permissões de administrador: no Linux, acesso ao sudo; no Windows e macOS, conta de administrador para instalar o Docker Desktop.
  • Conexão estável de internet para baixar as imagens.

Backups

No processo vamos editar arquivos de configuração do Docker. Um erro neles pode impedir o Docker de iniciar. Portanto, antes de mexer em qualquer arquivo, faça uma cópia. No Linux é um único comando:

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

O mesmo vale para o arquivo ~/.docker/config.json. Se o arquivo ainda não existir, não é preciso criar backup, mas anote que você o criou do zero: nesse caso, para reverter, basta apagá-lo.

Dica: Crie um arquivo de texto com um modelo dos seus dados de proxy no formato protocol://login:password@host:port. Você vai colar essa linha muitas vezes, e um modelo pronto evita erros de digitação.

Conceitos básicos: como o Docker funciona e onde o proxy vive nele

Para que a configuração de proxy no Docker não vire mágica, vamos esclarecer os termos. Se você já trabalha com contêineres com confiança, passe rápido pela seção, mas preste atenção na subseção sobre os três níveis de proxy: é ali que mora a maioria dos erros.

Termos-chave em linguagem simples

  • Imagem (image) — é um modelo, um conjunto "congelado" de arquivos e programas. Por exemplo, uma imagem com Python ou uma imagem com navegador.
  • Contêiner (container) — é uma cópia em execução da imagem. De uma imagem você pode rodar quantos contêineres quiser, e cada um ficará isolado dos demais.
  • Daemon do Docker (daemon, dockerd) — serviço em segundo plano que cria contêineres, baixa imagens e gerencia redes. É o daemon que vai à internet buscar imagens quando você digita docker pull.
  • Cliente do Docker (docker CLI) — o comando docker no terminal. Ele envia suas ordens ao daemon.
  • Variáveis de ambiente (environment variables) — valores nomeados disponíveis para os programas dentro do contêiner. Por exemplo, HTTP_PROXY=http://user:pass@host:port. Muitos programas leem essas variáveis automaticamente e passam a sair pelo proxy indicado.
  • Rede Docker (network) — rede virtual que conecta os contêineres. Contêineres na mesma rede personalizada se enxergam pelo nome.
  • Docker Compose — ferramenta que descreve vários contêineres, suas variáveis e redes em um único arquivo YAML e os sobe com um comando só.

Os três níveis de proxy no Docker

Esta é a parte mais importante da teoria. Quando falam em "proxy no Docker", podem estar se referindo a três coisas completamente diferentes, e cada uma se configura de um jeito.

  1. Proxy para o daemon. Necessário para que o próprio Docker baixe imagens por um proxy. É sobre os comandos docker pull e docker build quando eles puxam imagens base. No tráfego das suas aplicações dentro dos contêineres esse nível não influencia.
  2. Proxy para os contêineres via variáveis de ambiente. Dentro do contêiner são passadas HTTP_PROXY, HTTPS_PROXY e NO_PROXY, e a aplicação decide sozinha se vai usá-las ou não. É a forma mais popular e simples, mas funciona apenas com programas que respeitam essas variáveis.
  3. Proxy no nível de rede. O tráfego do contêiner é direcionado através de outro contêiner-gateway ou de uma rede configurada especialmente. A aplicação dentro pode nem saber que existe proxy. É mais confiável, mas exige mais configuração.

O que é importante entender antes de começar

Variáveis de ambiente com proxy são apenas uma recomendação para o programa. O utilitário curl, o gerenciador de pacotes pip, a biblioteca requests em Python, o Node.js com o pacote global-agent, o wget, o apt — todos leem HTTP_PROXY. Já navegadores em modo headless, algumas aplicações em Go e muitos utilitários binários podem ignorar as variáveis. Por isso, depois de configurar, sempre verifique o IP externo de fato, em vez de confiar que a variável está definida.

Outro detalhe é o uso de maiúsculas e minúsculas. Historicamente, alguns programas leem http_proxy em minúsculas, outros HTTP_PROXY em maiúsculas. A prática confiável é definir as duas versões ao mesmo tempo. A variável NO_PROXY lista endereços para os quais o proxy não deve ser usado: localhost, 127.0.0.1, domínios internos, nomes de contêineres vizinhos.

Por fim, o formato do endereço do proxy. Para proxy HTTP, a string fica http://login:password@host:port. Para SOCKS5 — socks5://login:password@host:port ou socks5h://login:password@host:port. A letra h no final significa que as consultas DNS também saem pelo proxy, o que para proxies móveis costuma ser preferível: assim o site de destino não vê o resolvedor DNS do seu provedor.

Passo 1: Verificamos o Docker e preparamos os dados do proxy

Objetivo da etapa: confirmar que o Docker funciona e que seus dados de proxy estão corretos e acessíveis a partir deste computador. Sem essa checagem, você corre o risco de passar meia hora procurando um erro na configuração quando o problema era um erro de digitação na senha.

Verificação do Docker

  1. Abra o terminal.
  2. Digite o comando docker --version e pressione Enter. Você deve ver uma linha do tipo Docker version 27.x.x. Se o terminal disser que o comando não foi encontrado, o Docker não está instalado: instale o Docker Desktop (Windows, macOS) ou o Docker Engine (Linux) pela documentação oficial e volte aqui.
  3. Digite docker compose version. Saída esperada: Docker Compose version v2.x.x.
  4. Digite docker run --rm hello-world. O Docker vai baixar uma imagem de teste minúscula e mostrar a saudação com as palavras Hello from Docker. Isso significa que o daemon está funcionando e você tem permissão para rodar contêineres.

Dica: Se no Linux o comando docker exigir sudo, adicione-se ao grupo docker: sudo usermod -aG docker $USER, depois faça logout e login de novo. A partir daí, todos os comandos do guia funcionarão sem sudo.

Verificação do proxy a partir do host

Antes de levar o proxy para dentro do contêiner, vamos verificar se ele responde. Substitua os dados do exemplo pelos seus. Nos exemplos, usaremos o endereço 185.10.10.10, porta 1050 para HTTP e 1051 para SOCKS5, login user123 e senha secret. No seu caso, é claro, os valores serão outros.

  1. Primeiro descubra seu IP normal sem proxy: curl -s ifconfig.me. Anote ou memorize o resultado.
  2. Agora uma requisição via proxy HTTP: curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
  3. Se você usa SOCKS5: curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
  4. Compare o resultado com o do passo 1. O IP deve ser diferente e pertencer a uma operadora móvel.

Caracteres especiais na senha

Se o login ou a senha tiverem os caracteres @, :, /, #, ? ou espaço, eles precisam ser codificados em formato URL, senão a string do proxy quebra. O caractere @ vira %40, : vira %3A, / vira %2F, # vira %23, ? vira %3F, espaço vira %20. Por exemplo, a senha pa@ss na string do proxy fica pa%40ss.

✅ Verificação: O comando curl via proxy retornou um IP diferente do seu IP residencial, e a resposta chegou em um a três segundos. Se recebeu erro 407, confira login e senha. Se aparecer Connection refused ou timeout — confira host, porta e se o seu IP atual está na lista de permissões no painel do provedor (em alguns planos a autenticação por IP já vem ativada por padrão).

Passo 2: Configuramos proxy para um contêiner via variáveis de ambiente

Objetivo da etapa: rodar um contêiner cujo tráfego HTTP inteiro passe por um proxy móvel, e confirmar isso pelo IP externo. É o cenário básico, com o qual todo mundo deveria começar: ele não mexe nas configurações do sistema e é fácil de desfazer.

Execução com a flag -e

A flag -e (ou --env) do comando docker run passa uma variável de ambiente para dentro do contêiner. Vamos passar quatro variáveis de uma vez: proxy para HTTP, para HTTPS e as exceções, cada uma em dois registros de maiúsculas/minúsculas.

  1. Copie o comando abaixo no editor e substitua os dados de proxy pelos seus.
  2. Execute o comando no terminal. Ele vai iniciar um contêiner temporário com curl, que fará uma requisição e encerrará.
docker run --rm -e HTTP_PROXY=http://user123:secret@185.10.10.10:1050 -e HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 -e http_proxy=http://user123:secret@185.10.10.10:1050 -e https_proxy=http://user123:secret@185.10.10.10:1050 -e NO_PROXY=localhost,127.0.0.1 -e no_proxy=localhost,127.0.0.1 curlimages/curl -s ifconfig.me

Note: para HTTPS_PROXY também usamos http:// no início. Não é erro. Assim se define o proxy pelo qual as requisições HTTPS vão passar, e a conexão com o próprio servidor de proxy é comum. O esquema https:// no valor de HTTPS_PROXY significaria que a conexão até o proxy precisa ser via TLS, o que a maioria dos provedores não suporta.

Arquivo de variáveis em vez de comando longo

O comando ficou enorme. O Docker sabe ler variáveis de um arquivo com a flag --env-file. Isso é mais prático e mais seguro: a senha não fica no histórico do terminal.

  1. Crie o arquivo proxy.env na pasta de trabalho: nano proxy.env
  2. Escreva nele as linhas, uma variável por linha, sem aspas e sem espaços em volta do sinal de igual:
HTTP_PROXY=http://user123:secret@185.10.10.10:1050 HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 http_proxy=http://user123:secret@185.10.10.10:1050 https_proxy=http://user123:secret@185.10.10.10:1050 NO_PROXY=localhost,127.0.0.1 no_proxy=localhost,127.0.0.1

No arquivo real, cada variável deve ficar em sua própria linha. Salve o arquivo (no nano, isso é Ctrl+O, Enter e depois Ctrl+X) e rode o contêiner:

docker run --rm --env-file proxy.env curlimages/curl -s ifconfig.me

Verificação de dentro de um contêiner em execução

Muitas vezes é preciso ver o que um contêiner de longa duração está enxergando. Vamos rodar o Alpine Linux em modo interativo e verificar as variáveis.

  1. Execute docker run -it --rm --env-file proxy.env alpine sh. Você vai estar dentro do contêiner, e o prompt muda para o cerquilha ou o cifrão.
  2. Digite env | grep -i proxy. Você verá a lista das suas variáveis.
  3. Digite apk add --no-cache curl. O gerenciador de pacotes apk vai capturar https_proxy sozinho e baixar o pacote pelo proxy.
  4. Digite curl -s ifconfig.me e confirme que o IP é móvel.
  5. Digite exit para sair. O contêiner será removido automaticamente graças à flag --rm.

Dica: Para verificar o IP, além do ifconfig.me, é útil usar serviços que devolvem JSON com informações de país, cidade e provedor. Assim você vê imediatamente que o IP pertence a uma operadora móvel da região certa, e não só que "é outro IP".

✅ Verificação: As duas execuções com curl retornaram o IP do proxy móvel. O comando env dentro do contêiner mostrou as variáveis HTTP_PROXY e HTTPS_PROXY com seus dados.

Possíveis problemas nesta etapa

  • O IP não mudou. A aplicação dentro do contêiner ignora as variáveis de ambiente. Com o curl isso não acontece; então, se o curl mostra o IP móvel e a sua aplicação não, passe para o método de rede do passo 6.
  • Erro invalid reference format. Normalmente é um espaço extra ou uma quebra de linha no comando. Monte o comando em uma única linha.
  • As variáveis não aparecem. No arquivo env-file não pode haver aspas em volta dos valores: o Docker as passaria literalmente, e o endereço do proxy ficaria inválido.

Passo 3: Configuramos proxy para o cliente Docker, para que as variáveis sejam passadas automaticamente

Objetivo da etapa: fazer com que cada novo contêiner e cada build de imagem recebam automaticamente as variáveis de proxy, sem flags -e. Isso economiza tempo se você vive rodando contêineres diferentes através do mesmo proxy móvel.

Como isso funciona

O cliente Docker lê o arquivo config.json na pasta ~/.docker (no Windows, a pasta .docker no perfil do usuário). Se nele houver a seção proxies, o cliente adiciona as variáveis indicadas no contêiner a cada docker run e docker build. O daemon não é afetado, então o docker pull continua indo direto.

Configuração passo a passo

  1. Verifique se o arquivo existe: cat ~/.docker/config.json. Se o arquivo existir e já tiver configurações (por exemplo, auths com dados de login no registro), faça uma cópia: cp ~/.docker/config.json ~/.docker/config.json.bak
  2. Abra o arquivo no editor: nano ~/.docker/config.json. Se o arquivo não existir, o editor o cria.
  3. Adicione a seção proxies. Se o arquivo estava vazio, seu conteúdo inteiro será assim:
{ "proxies": { "default": { "httpProxy": "http://user123:secret@185.10.10.10:1050", "httpsProxy": "http://user123:secret@185.10.10.10:1050", "noProxy": "localhost,127.0.0.1,*.local" } } }

Se o arquivo já tinha outras chaves, adicione proxies como mais uma chave de nível superior, separada por vírgula, sem remover as existentes. Cuide do pareamento de chaves e aspas: JSON não perdoa uma vírgula esquecida.

  1. Salve o arquivo.
  2. Verifique a sintaxe. No Linux e no macOS, é prático assim: python3 -m json.tool ~/.docker/config.json. Se a saída repetir seu arquivo formatado com boa indentação, está tudo certo. Se aparecer um erro com número de linha, corrija.
  3. Rode um contêiner de teste sem nenhuma flag: docker run --rm curlimages/curl -s ifconfig.me. O IP deve ser móvel.
  4. Veja as variáveis de qualquer contêiner: docker run --rm alpine env. Na saída vão aparecer HTTP_PROXY, HTTPS_PROXY, NO_PROXY e suas versões em minúsculas: o Docker adiciona os dois registros sozinho.

⚠ Atenção: A seção proxies no config.json afeta todos os contêineres que você executa com esse usuário, incluindo bancos de dados, servidores web locais e tudo mais. Se algum serviço conversa com uma API externa que não está acessível pelo seu proxy, ele quebra. Adicione esses endereços ao noProxy ou remova a seção temporariamente.

Proxies diferentes para conexões diferentes

A chave default se aplica a todas as conexões com o daemon. Se você gerencia vários hosts Docker via contextos ou pela variável DOCKER_HOST, no lugar de default você pode indicar o endereço de um daemon específico, por exemplo tcp://192.168.1.50:2376, e o proxy será aplicado só a ele. Para trabalho local, default basta.

Proxy na construção de imagens

As configurações do config.json também são passadas ao docker build como argumentos de build. Isso significa que os comandos RUN apt-get install ou RUN pip install dentro do Dockerfile passarão pelo proxy. Ponto importante: essas variáveis não são salvas na imagem final, o que é bom do ponto de vista de segurança: a senha do proxy não vaza para quem você entregar a imagem.

Dica: Se quiser passar o proxy apenas para um build específico, sem mexer no config.json, use as flags docker build --build-arg HTTP_PROXY=http://user123:secret@185.10.10.10:1050 --build-arg HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 . O Docker entende esses argumentos predefinidos sem declarar ARG no Dockerfile.

✅ Verificação: O contêiner rodado sem flags -e sai para a internet com o IP do proxy. O comando docker run --rm alpine env mostra as variáveis de proxy.

Como reverter

Remova a seção proxies do config.json ou restaure o arquivo a partir do backup: cp ~/.docker/config.json.bak ~/.docker/config.json. Não é preciso reiniciar, as mudanças valem para a próxima execução de contêiner.

Passo 4: Configuramos proxy para o daemon Docker, para baixar imagens pelo proxy

Objetivo da etapa: fazer o próprio Docker (o daemon) buscar imagens por um proxy. Isso é necessário quando o acesso direto ao registro de imagens a partir do seu servidor está limitado por política corporativa, lento, ou quando você quer que toda a atividade de rede do servidor passe por um único canal. Para tarefas de marketing essa etapa muitas vezes não é necessária, mas vale conhecê-la: erros de nível de daemon são frequentemente confundidos com erros de nível de contêiner.

Método 1: arquivo daemon.json (Linux, Docker 23 ou superior)

  1. Faça uma cópia: sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (se o arquivo não existir, o comando dará erro, isso é normal).
  2. Abra o arquivo: sudo nano /etc/docker/daemon.json
  3. Adicione a seção proxies:
{ "proxies": { "http-proxy": "http://user123:secret@185.10.10.10:1050", "https-proxy": "http://user123:secret@185.10.10.10:1050", "no-proxy": "localhost,127.0.0.1" } }

Note que aqui as chaves são escritas com hífen e em minúsculas: isso é diferente do config.json do cliente, onde as chaves são no estilo httpProxy. Confundir os dois é um erro clássico.

  1. Salve o arquivo e reinicie o daemon: sudo systemctl restart docker
  2. Verifique se o daemon subiu: sudo systemctl status docker. Na saída deve aparecer active (running).
  3. Verifique a aplicação: docker info | grep -i proxy. Você verá as linhas HTTP Proxy e HTTPS Proxy com o seu endereço, e a senha na saída será ocultada por asteriscos.

Método 2: arquivo drop-in do systemd (Linux, qualquer versão)

Este é o jeito clássico, que funciona até em versões antigas do Docker.

  1. Crie a pasta: sudo mkdir -p /etc/systemd/system/docker.service.d
  2. Crie o arquivo: sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
  3. Escreva o conteúdo, cada diretiva em sua própria linha:
[Service] Environment="HTTP_PROXY=http://user123:secret@185.10.10.10:1050" Environment="HTTPS_PROXY=http://user123:secret@185.10.10.10:1050" Environment="NO_PROXY=localhost,127.0.0.1"
  1. Salve, depois releia a configuração do systemd: sudo systemctl daemon-reload
  2. Reinicie o Docker: sudo systemctl restart docker
  3. Verifique: sudo systemctl show --property=Environment docker. Na saída estarão suas variáveis.

⚠ Atenção: Não configure o proxy do daemon pelos dois métodos ao mesmo tempo. Se tanto o daemon.json quanto o arquivo systemd tiverem endereços diferentes, o comportamento fica imprevisível e a depuração vira sofrimento. Escolha um método e mantenha-o.

Método 3: Docker Desktop (Windows e macOS)

  1. Abra o Docker Desktop e clique no ícone de engrenagem no canto superior direito.
  2. No menu à esquerda, selecione Resources, depois Proxies.
  3. Ative o botão Manual proxy configuration.
  4. Nos campos Web Server (HTTP) e Secure Web Server (HTTPS), cole o endereço do proxy no formato http://user123:secret@185.10.10.10:1050.
  5. No campo Bypass proxy settings for these hosts, escreva localhost,127.0.0.1.
  6. Clique em Apply and restart. O Docker Desktop vai reiniciar, isso leva de 30 a 60 segundos.

O Docker Desktop aplica essas configurações tanto ao daemon quanto aos contêineres ao mesmo tempo, então editar o config.json separadamente nesses sistemas muitas vezes não é necessário.

Verificação do resultado

  1. Remova alguma imagem pequena, se existir: docker rmi alpine
  2. Baixe de novo: docker pull alpine. O download deve ocorrer sem problemas.
  3. Se o proxy tiver estatísticas de tráfego (no painel da mobileproxy.space tem), você verá que o volume de tráfego consumido aumentou alguns megabytes.

✅ Verificação: docker info mostra o endereço do proxy, docker pull baixa imagens sem erro, o serviço docker está em estado active.

Possíveis problemas

  • O Docker não inicia depois de editar o daemon.json. Quase sempre a culpa é da sintaxe do JSON. Verifique o arquivo com python3 -m json.tool /etc/docker/daemon.json ou restaure a cópia.
  • docker pull trava. O proxy não deixa passar conexões até o registro ou o limite de tráfego do plano foi atingido. Teste o proxy do host com curl, como no passo 1.
  • Erro x509 certificate. O proxy substitui certificados (comum em proxies corporativos; com proxies móveis é raro). Confirme com o provedor.

Passo 5: Configuramos proxy no Docker Compose

Objetivo da etapa: descrever o proxy no arquivo compose.yaml de forma que um grupo de contêineres rode com um comando só, com as configurações necessárias, e que serviços diferentes possam usar proxies móveis diferentes. Esse é exatamente o cenário que afiliados e profissionais de marketing mais precisam: um parser trabalha pelo proxy de São Paulo, o segundo pelo proxy do Rio, e o banco de dados fica sem proxy nenhum.

Preparação do projeto

  1. Crie a pasta do projeto e entre nela: mkdir proxy-demo, depois cd proxy-demo
  2. Crie o arquivo .env (com ponto no início) para guardar os segredos: nano .env
  3. Escreva as variáveis, uma por linha:
PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

O Compose lê o arquivo .env automaticamente, e os valores dele podem ser usados no compose.yaml pelo sintaxe ${NOME}. Adicione .env ao .gitignore se o projeto estiver sob controle de versão: senhas não devem ir para o repositório.

O arquivo compose.yaml

Crie o arquivo compose.yaml (nano compose.yaml) e descreva três serviços. Em YAML a indentação é importante: use dois espaços por nível, não tabulação.

services: parser-msk: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK} http_proxy: ${PROXY_MSK} https_proxy: ${PROXY_MSK} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db parser-kzn: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_KZN} HTTPS_PROXY: ${PROXY_KZN} http_proxy: ${PROXY_KZN} https_proxy: ${PROXY_KZN} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db db: image: postgres:16-alpine environment: POSTGRES_PASSWORD: example

Aqui, no arquivo real, cada linha fica em seu próprio lugar com a indentação correta: services no nível zero, nomes de serviços com recuo de dois espaços, seus parâmetros com quatro, variáveis de ambiente com seis. Note o nome db no NO_PROXY: assim os parsers vão acessar o banco de dados diretamente pela rede interna do Docker, em vez de tentar alcançá-lo pelo proxy móvel, o que obviamente não funcionaria.

Execução e verificação

  1. Veja como o Compose substituiu as variáveis: docker compose config. O comando mostra o arquivo final com os valores expandidos. Confirme que no lugar de ${PROXY_MSK} está o endereço real.
  2. Rode: docker compose up. O Compose baixa as imagens e inicia os três serviços, mostrando seus logs no terminal.
  3. Nos logs você verá linhas do tipo parser-msk-1 | 91.xxx.xxx.xxx e parser-kzn-1 | 176.xxx.xxx.xxx: dois IPs diferentes, de dois proxies diferentes. O Postgres vai iniciar e ficar aguardando conexões.
  4. Pare tudo com Ctrl+C, depois remova os contêineres: docker compose down

Alternativa: env_file para cada serviço

Se as variáveis forem muitas, em vez do bloco environment é mais prático indicar um arquivo:

services: parser-msk: image: curlimages/curl command: -s ifconfig.me env_file: - proxy-msk.env

O arquivo proxy-msk.env contém as mesmas seis linhas do proxy.env do passo 2. Assim cada proxy fica no seu próprio arquivo, e você pode substituí-lo sem abrir o compose.yaml.

Proxy no build do Compose

Se o serviço é construído a partir de um Dockerfile, em vez de usar imagem pronta, passe o proxy para o build via build.args:

services: app: build: context: . args: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK}

Assim o pip, o npm ou o apt dentro do Dockerfile trabalharão pelo proxy, e os valores não vão para a imagem final.

Dica: O Compose suporta vários arquivos. Mantenha um compose.yaml base sem proxy e, em compose.proxy.yaml, descreva apenas os blocos environment. Rode docker compose -f compose.yaml -f compose.proxy.yaml up quando precisar de proxy, e apenas docker compose up quando não. Isso é prático na depuração: você alterna entre os modos em segundos.

✅ Verificação: docker compose config mostra os endereços de proxy substituídos, e nos logs do docker compose up os serviços com proxies diferentes mostram IPs diferentes.

Passo 6: Configuramos proxy no nível de rede através de um contêiner-gateway

Objetivo da etapa: subir um contêiner separado que recebe conexões dos vizinhos na rede Docker e as encaminha para o proxy móvel. Os demais contêineres se dirigem ao gateway pelo nome e não guardam login nem senha. Isso resolve três problemas de uma vez: centraliza o gerenciamento do proxy, elimina senhas de dezenas de configs e permite trocar o proxy sem reiniciar os contêineres de trabalho.

Para que serve um gateway se já existem as variáveis

Imagine que você tem vinte contêineres com parsers e o provedor liberou uma nova porta. Com variáveis de ambiente, você terá de editar vinte configs e reiniciar tudo. Com o gateway, você muda uma linha em um único lugar. Além disso, algumas aplicações não suportam autenticação de proxy com login e senha, mas trabalham perfeitamente com proxy sem autenticação. O gateway dentro da rede Docker fechada não exige autenticação, e ele mesmo se conecta ao proxy móvel já com seus dados.

Criando a rede

  1. Crie uma rede personalizada: docker network create proxynet
  2. Confirme que ela apareceu: docker network ls. Na lista vai aparecer proxynet com driver bridge.

A rede personalizada é necessária porque só nela funciona a resolução de nomes: o contêiner vai poder acessar o gateway pelo nome gateway, e não pelo IP, que muda a cada reinício.

Subindo o gateway

Como gateway, usamos o gost — um servidor de proxy compacto, capaz de receber conexões em um protocolo e encaminhá-las a outro com autenticação. A imagem está disponível no registro público com o nome gogost/gost.

  1. Rode o contêiner-gateway:
docker run -d --name gateway --network proxynet --restart unless-stopped gogost/gost -L=http://:8118 -F=http://user123:secret@185.10.10.10:1050

Vamos aos parâmetros. A flag -d executa o contêiner em segundo plano. A flag --name gateway define o nome pelo qual os vizinhos vão acessá-lo. A flag --network proxynet conecta-o à nossa rede. A flag --restart unless-stopped reergue o gateway após reiniciar o servidor. O parâmetro -L=http://:8118 diz ao gost para aceitar conexões de proxy HTTP na porta 8118 sem autenticação. O parâmetro -F indica para onde encaminhar: para o seu proxy móvel com login e senha.

  1. Verifique se o gateway está rodando: docker logs gateway. No log deve haver uma linha dizendo que o servidor escuta na porta 8118, sem erros.

⚠ Atenção: Não publique a porta do gateway para fora com a flag -p, a menos que haja necessidade real. O gateway trabalha sem autenticação, e uma porta 8118 aberta em servidor público significa que qualquer pessoa na internet poderá usar seu proxy móvel e consumir seu tráfego. Dentro da rede proxynet ele fica acessível apenas aos seus contêineres, e isso basta.

Conectando os contêineres de trabalho

  1. Rode um contêiner de teste na mesma rede, indicando o gateway como proxy:
docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
  1. Você deve ver o IP do proxy móvel. Repare: nas variáveis não há login, senha nem o endereço real do proxy. Só o gateway sabe tudo isso.

O mesmo no Compose

Para uso contínuo, descreva o gateway e os serviços de trabalho em um compose.yaml:

services: gateway: image: gogost/gost command: -L=http://:8118 -F=${PROXY_MSK} restart: unless-stopped networks: - proxynet worker: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: http://gateway:8118 HTTPS_PROXY: http://gateway:8118 NO_PROXY: localhost,127.0.0.1 depends_on: - gateway networks: - proxynet networks: proxynet: driver: bridge

A diretiva depends_on garante que o gateway suba antes do worker. O valor PROXY_MSK vem do arquivo .env, como no passo 5.

Vários gateways para várias geos

Quer proxies diferentes para grupos de contêineres diferentes? Suba vários gateways: gateway-msk, gateway-kzn, gateway-spb, cada um com seu -F. Os contêineres de trabalho apenas indicam o nome desejado em HTTP_PROXY. Dá para ir além e criar uma rede separada para cada geo; assim os contêineres do grupo de São Paulo não conseguem, por acidente, cair no gateway do Rio.

Isolamento: contêiner sem saída direta para a internet

A variante mais rigorosa é proibir que o contêiner de trabalho tenha qualquer saída para a internet, exceto pelo gateway. Para isso, crie uma rede interna com a flag --internal: docker network create --internal isolated. Contêineres nessa rede não têm rota para fora. Conecte o gateway a duas redes ao mesmo tempo (isolated e a comum proxynet) e conecte os workers apenas à isolated. Agora, mesmo que a aplicação ignore as variáveis de proxy, ela simplesmente não conseguirá sair para a internet diretamente, e não haverá vazamento do IP real.

  1. docker network create --internal isolated
  2. docker network connect isolated gateway
  3. docker run --rm --network isolated -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
  4. Para controle, rode o mesmo contêiner sem as variáveis de proxy: docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. A requisição deve terminar em timeout: não há saída direta.

Dica: A combinação de rede interna e gateway é a melhor proteção contra vazamentos em trabalho com múltiplas contas. Mesmo que o desenvolvedor esqueça de configurar o proxy em um serviço novo, ele não conseguirá expor o IP do servidor: ou passa pelo gateway, ou não passa por lugar nenhum.

✅ Verificação: O contêiner na rede proxynet com a variável HTTP_PROXY=http://gateway:8118 mostra o IP do proxy móvel. O contêiner na rede interna sem proxy não consegue sair para a internet de jeito nenhum.

Possíveis problemas

  • Could not resolve host: gateway. O contêiner de trabalho não está na rede certa ou foi iniciado na rede padrão, onde os nomes não são resolvidos. Verifique a flag --network.
  • O gateway reinicia. Erro na linha -F: erro de digitação na senha ou porta errada. Veja docker logs gateway.
  • Lentidão. Proxies móveis são naturalmente mais lentos que os de data center, mas se a lentidão for de dezenas de segundos, verifique se o DNS não está indo por fora: use socks5h em vez de socks5 na linha -F, se o provedor oferecer SOCKS5.

Verificação do resultado: checklist de um proxy funcional no Docker

Passe pelo checklist. Se cada item estiver marcado, você dominou na prática a configuração de proxy no Docker.

Checklist

  • O curl do host via proxy retorna um IP móvel.
  • O contêiner com a flag --env-file proxy.env retorna um IP móvel.
  • O contêiner sem flags, depois de configurar o config.json, retorna um IP móvel (se você fez o passo 3).
  • docker info mostra o endereço do proxy, e o docker pull funciona (se você fez o passo 4).
  • docker compose up sobe os serviços, e nos logs aparecem IPs diferentes para proxies diferentes.
  • O contêiner-gateway funciona, e os vizinhos saem por ele sem login nem senha.
  • Um contêiner na rede interna sem proxy não consegue sair para a internet.

Como testar tudo de ponta a ponta

  1. Rode um contêiner de longa duração: docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
  2. Entre nele: docker exec -it test sh
  3. Instale o curl: apk add --no-cache curl. A instalação deve ocorrer pelo proxy.
  4. Faça cinco requisições seguidas: for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Todas as cinco devem retornar o IP móvel. Se o seu proxy tiver rotação automática ativada, os IPs podem variar entre as requisições, isso é normal.
  5. Saia (exit) e remova o contêiner: docker rm -f test

Indicadores de sucesso

Uma configuração bem-sucedida significa que você consegue, em um segundo, responder a três perguntas: por qual IP sai um contêiner específico, onde está guardada a senha do proxy e o que precisa mudar para transferir um contêiner para outro proxy. Se a resposta a cada pergunta é óbvia, o objetivo foi alcançado.

Erros comuns ao configurar proxy no Docker e como resolvê-los

Erro 1: o IP não muda, mesmo com as variáveis definidas

Causa: a aplicação dentro do contêiner não lê variáveis de ambiente de proxy. Isso é típico de navegadores headless, algumas aplicações Go e utilitários que usam stacks de rede próprias.

Solução: verifique a documentação da aplicação para saber se há uma flag própria de proxy (em navegadores, normalmente é --proxy-server). Se não houver, use o gateway e a rede interna do passo 6, ou o proxy transparente da seção para avançados.

Erro 2: 407 Proxy Authentication Required

Causa: login ou senha incorretos, ou caracteres especiais não codificados, ou o proxy tem autenticação por IP e o IP do servidor não está na lista de permissões.

Solução: confira os dados do host com curl. Codifique os caracteres especiais. Adicione o IP do servidor à lista de permissões no painel ou mude o proxy para autenticação por login e senha.

Erro 3: o Docker não inicia depois de editar o daemon.json

Causa: erro de sintaxe no JSON: vírgula sobrando, aspas faltando, chaves no estilo do config.json em vez do estilo do daemon.json.

Solução: veja o log: sudo journalctl -u docker -n 50. Ali estará indicada a linha com erro. Corrija ou restaure o backup e reinicie o serviço.

Erro 4: os contêineres pararam de se ver

Causa: após a configuração global de proxy no config.json, as requisições para contêineres vizinhos também passaram pelo proxy móvel, que não sabe o que é db ou redis.

Solução: adicione os nomes dos serviços e as sub-redes internas ao NO_PROXY: localhost,127.0.0.1,db,redis,172.16.0.0/12. Lembre que máscaras de sub-rede não são entendidas por todos os programas, então é mais confiável listar os nomes explicitamente.

Erro 5: docker build falha no apt-get ou pip

Causa: o build ocorre sem proxy, porque as variáveis foram definidas para os contêineres, não para o build, ou o proxy do daemon está configurado mas não influencia os passos RUN.

Solução: passe --build-arg HTTP_PROXY e HTTPS_PROXY ou configure a seção proxies no config.json do cliente: ela também se aplica ao build.

Erro 6: a senha do proxy aparece no docker inspect e nos logs

Causa: variáveis de ambiente ficam armazenadas nos metadados do contêiner em texto aberto, e qualquer pessoa com acesso ao Docker as verá via docker inspect.

Solução: use o gateway: os contêineres de trabalho conhecem apenas o endereço gateway:8118. A senha fica em um único contêiner e no arquivo .env com permissões restritas (chmod 600 .env).

Erro 7: depois de reiniciar o servidor, o proxy parou de funcionar

Causa: o contêiner-gateway não foi iniciado com política de restart, ou o endereço IP do host do proxy móvel mudou.

Solução: adicione --restart unless-stopped ao gateway. Use o nome de domínio do proxy em vez do IP, se o provedor oferecer. Verifique docker ps -a: se o gateway estiver com status Exited, veja seus logs.

Erro 8: sites HTTPS não abrem, mas HTTP funciona

Causa: só HTTP_PROXY foi definida e HTTPS_PROXY está vazia, ou em HTTPS_PROXY foi usado o esquema https:// no lugar de http://.

Solução: sempre defina as duas variáveis com o mesmo valor e o mesmo esquema http://.

Recursos adicionais para avançados: proxy transparente, rotação de IP e segurança

Esta seção é para quem passou pelos passos básicos e quer extrair o máximo da combinação Docker e proxies móveis. Aqui há menos listas passo a passo e mais ideias com comandos-chave.

Proxy transparente: quando a aplicação não sabe nada sobre proxy

Se você tem uma aplicação que não consegue trabalhar com proxy de jeito nenhum, é possível envolver todo o seu tráfego TCP no nível da pilha de rede. A ideia é esta: o contêiner de trabalho é iniciado com o parâmetro network_mode: service:gateway (no Compose) ou --network container:gateway (no docker run). Assim ele usa a pilha de rede inteira do contêiner-gateway: o mesmo IP, as mesmas interfaces, as mesmas regras de roteamento.

No gateway, ao mesmo tempo, roda um programa como o redsocks, que escuta uma porta local e encaminha conexões para um proxy SOCKS5, e regras do iptables redirecionam para essa porta todo o tráfego TCP de saída. Para isso o gateway precisa de permissões: cap_add: NET_ADMIN. A aplicação no contêiner de trabalho faz uma requisição normal ao site, o kernel a intercepta e a encaminha ao redsocks, que por sua vez a manda ao proxy móvel. Nenhuma variável de ambiente. A configuração exige cuidado: uma regra de iptables errada pode entrar em loop de tráfego, então teste em uma máquina separada. Considere também que, com network_mode: service, o contêiner de trabalho perde portas próprias e conexões a outras redes, e tudo isso precisa ser descrito no gateway.

Rotação de IP a partir do contêiner

Proxies móveis têm uma particularidade pela qual são escolhidos: o IP pode ser trocado sob demanda. Os provedores disponibilizam um link especial de troca de IP, que basta abrir para o modem reconectar. De dentro do contêiner, isso se faz com o mesmo curl. Um padrão útil: um pequeno serviço separado no Compose que, em intervalos regulares, chama o link de rotação. Ele não deve passar pelo proxy (senão, depois da troca de IP, ele mesmo perde a conexão); então rode-o sem variáveis de proxy ou explicitamente com HTTP_PROXY vazio. Considere que, depois da troca de IP, as conexões ativas dos contêineres de trabalho serão interrompidas: preveja retentativas nos parsers.

Saúde do gateway: healthcheck

Adicione ao Compose uma verificação de que o gateway realmente faz proxy, e não está apenas rodando:

healthcheck: test: ["CMD", "gost", "-V"] interval: 30s timeout: 10s retries: 3

Isso é uma verificação mínima de processo vivo. Para checar a saída real à internet, é melhor um contêiner-monitor à parte, que a cada minuto faz uma requisição pelo gateway e registra o resultado em log ou envia notificação. Se o IP de repente virar o IP do servidor, é alarme: o gateway caiu e os contêineres saíram direto. A rede interna do passo 6 justamente protege desse cenário.

Armazenamento seguro de senhas

O arquivo .env é bom para trabalho local, mas em um servidor com vários usuários vale protegê-lo: chmod 600 .env, dono é o usuário a partir do qual o Compose roda. O Compose também suporta segredos pela diretiva secrets, que são montados no contêiner como arquivo em /run/secrets/, e não como variável de ambiente. O gost não lê senha de arquivo diretamente, mas você pode escrever um pequeno script de wrapper que monta a linha -F a partir do arquivo de segredo na inicialização. Assim a senha não vai aparecer nem no docker inspect nem na saída do docker compose config.

Vários projetos e uma infraestrutura de proxy única

Se você tem vários projetos Compose e os proxies são compartilhados, mova os gateways para um projeto separado com rede externa: nele, declare networks com o parâmetro name: proxynet, e nos outros projetos conecte-se a ela como external: true. Assim os gateways vivem de forma independente, e os projetos de trabalho podem ser reiniciados à vontade, sem mexer nos proxies.

Limitação de tráfego

Tráfego móvel geralmente é tarifado, e um parser descontrolado pode consumir dezenas de gigabytes durante a noite. No nível do Docker não há cotas rígidas de tráfego, mas há medidas indiretas: limitar a frequência de requisições na própria aplicação, limitar o tempo de vida do contêiner via timeout no comando de inicialização e monitorar com docker stats, que mostra NET I/O por contêiner em tempo real. Compare esses números regularmente com as estatísticas do painel do provedor.

Logs sem segredos

Muitas aplicações, ao iniciar, imprimem as variáveis de ambiente no log, incluindo HTTP_PROXY com senha. Se os logs vão para um sistema centralizado, a senha vaza para lá. O gateway resolve também esse problema: nos logs dos contêineres de trabalho aparecerá apenas gateway:8118.

Dica: A cada trimestre, reemita as senhas dos proxies e atualize o .env. Com o gateway isso leva um minuto: você edita uma linha, roda docker compose up -d gateway, e todos os workers continuam funcionando sem reinício.

FAQ: perguntas frequentes sobre configurar proxy no Docker

É preciso reiniciar o contêiner para aplicar novas variáveis de proxy?

Sim. Variáveis de ambiente são definidas no momento da criação do contêiner e não podem ser alteradas em um contêiner em execução. Pare, remova e crie o contêiner de novo (no Compose, isso é docker compose up -d --force-recreate nome_do_serviço). Se os reinícios atrapalharem, use o gateway: as configurações dele podem ser trocadas de forma independente.

Qual é a diferença entre configurar proxy para docker pull e para a aplicação no contêiner?

São dois níveis diferentes. O docker pull é executado pelo daemon, e para ele o proxy se define no daemon.json ou via systemd. A aplicação no contêiner é um processo à parte, com seu próprio ambiente; para ela o proxy se define por variáveis, pelo config.json do cliente ou pela rede. Uma coisa não substitui a outra.

Dá para usar SOCKS5 em vez de proxy HTTP nas variáveis de ambiente?

Dá, se a aplicação suportar SOCKS. curl, Python requests (com o pacote PySocks instalado) e git suportam. apt e muitos outros não. A saída universal é o gateway gost, que recebe HTTP na entrada e envia para SOCKS5 na saída: -L=http://:8118 -F=socks5://user:pass@host:port.

Como verificar qual proxy está sendo usado por um contêiner já em execução?

Execute docker inspect -f '{{.Config.Env}}' nome_do_contêiner. Você verá todas as variáveis de ambiente. Para checar o IP real, use docker exec nome_do_contêiner curl -s ifconfig.me, se houver curl no contêiner, ou wget -qO- ifconfig.me.

Por que no Docker Desktop o proxy funciona, mas no servidor Linux as mesmas configurações não funcionam?

O Docker Desktop aplica as configurações da janela Proxies tanto ao daemon quanto aos contêineres ao mesmo tempo. No Linux são dois lugares separados: daemon.json para o daemon e ~/.docker/config.json para os contêineres. Verifique se você configurou os dois, se precisar dos dois.

Como definir proxy só para um domínio e deixar o resto passar direto?

Variáveis de ambiente não fazem isso: elas funcionam pelo princípio "tudo pelo proxy, exceto o NO_PROXY". Se precisar da lógica inversa, use um arquivo PAC na aplicação (navegadores suportam) ou regras de roteamento no gost, que consegue direcionar tráfego para canais de saída diferentes por domínio.

É seguro guardar a senha do proxy no compose.yaml?

Melhor não. Guarde-a em .env com permissões 600 e use via ${NOME}. Não faça commit do .env no repositório. Em servidores, use o gateway, para que a senha fique em um único lugar.

O que fazer se o proxy móvel trocar de IP e as conexões nos contêineres caírem?

Esse é o comportamento normal durante a rotação. A aplicação precisa saber repetir requisições. Se a rotação acontecer por agendamento do provedor, descubra o intervalo e sincronize com ele as operações pesadas. Se a rotação for pelo seu link, chame-o entre lotes de tarefas, e não no meio delas.

Essas configurações funcionam no Windows sem WSL2?

O Docker Desktop no Windows usa WSL2 ou Hyper-V por baixo dos panos, e todos os comandos docker run e docker compose funcionam igualmente a partir do PowerShell. Só mudam os caminhos: o arquivo config.json fica em C:\Users\NomeDoUsuario\.docker\config.json, e as configurações do daemon são feitas pela janela do Docker Desktop, e não editando o daemon.json na mão.

Quantos contêineres dá para colocar atrás de um único proxy móvel?

Tecnicamente, quantos você quiser; a limitação está só na largura de banda do canal móvel e nos limites do plano. Na prática, para tarefas com contas, é razoável manter um proxy por entidade lógica (conta, projeto, região), para que o comportamento pareça natural e um erro em um contêiner não afete os demais.

Conclusão: o que você fez e para onde seguir

Vamos resumir. Você verificou o funcionamento do proxy a partir do host e entendeu o formato da string de conexão. Configurou proxy para um contêiner individual via variáveis de ambiente e arquivo env-file. Automatizou o envio das variáveis pelo config.json do cliente. Entendeu como e por que configurar proxy para o próprio daemon do Docker de três formas. Descreveu vários serviços com proxies móveis diferentes no Docker Compose, guardando os segredos no .env. E, por fim, construiu um contêiner-gateway com rede isolada — a solução mais confiável para produção, que protege contra vazamento do IP real mesmo que a aplicação ignore as variáveis.

Agora, proxy no Docker para você não é mais uma caixa-preta, e sim três níveis claros com fronteiras bem definidas: daemon, contêiner, rede. Você sabe onde procurar o problema se o IP acabar sendo outro, e consegue verificar isso com um único comando.

O que fazer a seguir

  1. Migre seus projetos de trabalho para o esquema com gateway e rede interna. Comece por um serviço não crítico, confirme que tudo funciona e depois escale.
  2. Adicione um contêiner-monitor que, a cada minuto, verifica o IP externo pelo gateway e sinaliza se ele coincidir com o IP do servidor.
  3. Configure a rotação de IP por agendamento de acordo com suas tarefas e ensine as aplicações a lidar com queda de conexão.
  4. Organize os segredos: .env com permissões 600, nenhuma senha no compose.yaml nem no Dockerfile.

Para onde evoluir

O próximo passo lógico é conectar o Docker a navegadores antidetect e ferramentas de multi-conta, em que cada perfil corresponde a seu próprio contêiner e seu próprio proxy móvel. Outra direção é a automação via API do provedor: obter a lista de proxies, verificar o status deles e fazer rotação direto dos seus serviços. Os dois temas vão além deste guia, mas a base que você acabou de construir torna tudo isso bem mais simples. Boas execuções e IPs estáveis para você!

Sobre o autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Experiência profissional: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Formação: Bauman Moscow State Technical University. Information Systems and Technologies
Especialização:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Compartilhe este artigo: