Squid proxy no Ubuntu 24.04: instalação, senha e squid.conf

Uma equipe de dados de cinco pessoas quer que os servidores de teste baixem pacotes de um só lugar e acessem a API de um fornecedor sempre pelo mesmo endereço IP. Alguém instala o Squid em uma VPS pequena em dez minutos. Uma semana depois, o access.log está cheio de endereços que ninguém reconhece: a configuração veio de um post de fórum que terminava em http_access allow all, e agora desconhecidos mandam o próprio tráfego para a internet pelo IP da equipe.

Este guia instala o Squid no Ubuntu 24.04 sem esse erro. Ele explica o que é o Squid, em que ordem ele verifica uma requisição e o que um único servidor pode e não pode oferecer. Depois vêm um arquivo de configuração completo, com lista de IPs permitidos, login, cache em disco e ajustes de cabeçalhos, um proxy pai (parent) com cache_peer e os comandos que testam tudo isso.

O que é um proxy Squid?#

O Squid é um servidor proxy de cache de código aberto. Um servidor proxy envia requisições em seu nome e devolve as respostas a você (O que é um servidor proxy?). O Squid costuma rodar como forward proxy, que trabalha para os clientes atrás dele, e não como reverse proxy na frente de um site (Forward proxy e reverse proxy). Ele transporta HTTP, HTTPS por túneis CONNECT e FTP, com regras de acesso, programas auxiliares de login (helpers), cache e um log de requisições.

A versão estável atual do projeto Squid é a 7.7, publicada em 24 de agosto de 2026, e os desenvolvedores dão suporte apenas à versão estável mais recente. O Ubuntu 24.04 traz o Squid 6.14, pacote 6.14-0ubuntu0.24.04.4 no noble-updates, e as correções de segurança dele chegam pelas atualizações normais do Ubuntu. Este guia usa esse pacote.

Como o Squid trata uma requisição?#

A ordem destes passos explica a maioria dos erros de configuração.

1. O cliente se conecta à porta definida em http_port, a 3128 na configuração do Ubuntu.
2. O Squid lê as linhas http_access de cima para baixo. Decide a primeira linha em que todas as condições batem. A documentação do http_access acrescenta que, quando nenhuma linha bate, o Squid faz o contrário da última linha; por isso toda lista deve terminar com http_access deny all.
3. Uma regra que exige login pede o login. Quando o Squid chega a uma condição proxy_auth sem credenciais válidas, responde 407 Proxy Authentication Required (Autenticação de proxy).
4. O HTTP simples é procurado no cache. Uma cópia guardada que ainda está válida é um hit, e a requisição não sai do servidor; qualquer outro caso é um miss, e a resposta é buscada no site.
5. O HTTPS vira um túnel. Depois que um CONNECT example.com:443 dá certo, o Squid apenas repassa bytes criptografados. A RFC 9110 chama isso de "blind forwarding of data" (repasse cego de dados), então o Squid não consegue guardar a página em cache nem adicionar cabeçalhos dentro do túnel.
6. Um proxy pai assume, se você definir um com cache_peer e never_direct.
7. O Squid grava uma linha no access.log com o cliente, o código de resultado, o tamanho, a URL e o nome de usuário.

O que o seu próprio servidor Squid oferece e o que não oferece?#

O Squid dá a você controle sobre quem se conecta, o que vai para o cache e o que fica registrado. Ele não consegue dar um segundo endereço: um site que vê centenas de requisições por minuto vindas daquele único IP de datacenter vai limitar a velocidade dele ou bloqueá-lo (Diferença entre proxy residencial e datacenter).

Como instalar o Squid no Ubuntu 24.04?#

O apache2-utils traz o htpasswd, usado para criar o arquivo de senhas. Guardar uma cópia somente leitura da configuração original segue o guia oficial do Ubuntu Server.

sudo apt update
sudo apt install squid apache2-utils
squid -v | head -n 1                       # a versão instalada
systemctl status squid --no-pager          # deve mostrar "active (running)"

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original
sudo chmod a-w /etc/squid/squid.conf.original

# onde as suas próprias regras serão lidas?
grep -n "include /etc/squid/conf.d" /etc/squid/squid.conf
grep -n "^http_access deny all" /etc/squid/squid.conf

Coloque as suas configurações em um arquivo dentro de /etc/squid/conf.d/, para que as atualizações do pacote não mexam nelas. O empacotamento do Debian, em que o Ubuntu se baseia, coloca include /etc/squid/conf.d/*.conf sob o comentário INSERT YOUR OWN RULE(S) HERE: depois das regras que bloqueiam portas inseguras e antes de http_access allow localhost e http_access deny all. O número de linha do include mostrado pelo grep precisa ser menor que o do deny all; se não for, coloque as suas linhas no próprio squid.conf, nesse comentário. O debian.conf da pasta define logfile_rotate 0, porque quem cuida dos logs é o logrotate.

Um team.conf completo para um proxy fechado#

Salve isto como /etc/squid/conf.d/team.conf. Troque a rede de documentação 203.0.113.0/24 pela rede do seu escritório ou pelos IPs fixos da sua equipe.

# /etc/squid/conf.d/team.conf
# Lido dentro da lista http_access do squid.conf, acima de "http_access deny all".
# Nunca adicione "http_access allow all": isso transforma este servidor em um proxy aberto.

# 1. Quais redes podem se conectar
acl team_net src 203.0.113.0/24

# 2. Nome de usuário e senha de /etc/squid/passwords.
#    Mantenha as linhas auth_param acima da ACL proxy_auth.
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5 startup=5 idle=1
auth_param basic realm Team proxy
auth_param basic credentialsttl 2 hours
acl team_users proxy_auth REQUIRED

# 3. Permitir só quando as DUAS batem: a rede certa E um login válido.
#    Todo o resto cai em "http_access deny all".
http_access allow team_net team_users

# 4. Não repassar o endereço dos clientes em requisições HTTP simples
forwarded_for delete
via off

# 5. Cache: memória, maior objeto a guardar e, por fim, o cache em disco
cache_mem 512 MB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 10000 16 256

Depois, adicione os usuários, confira a sintaxe, reinicie uma vez e abra a porta só para endereços conhecidos:

sudo htpasswd -c /etc/squid/passwords team1   # -c cria o arquivo: só no primeiro usuário
sudo htpasswd /etc/squid/passwords team2      # usuários seguintes: sem -c
sudo chown root:proxy /etc/squid/passwords
sudo chmod 640 /etc/squid/passwords

sudo squid -k parse                           # mostra erros e avisos, se houver
sudo systemctl restart squid                  # uma vez, por causa do novo cache_dir
sudo tail -n 20 /var/log/squid/cache.log      # mensagens de inicialização

sudo ufw allow OpenSSH                        # mantém a sua sessão SSH acessível
sudo ufw allow from 203.0.113.0/24 to any port 3128 proto tcp
sudo ufw enable

Como escrever as regras acl e http_access?#

Uma linha acl dá nome a uma condição; uma linha http_access combina esses nomes em uma decisão. As condições de uma mesma linha precisam bater todas, então allow team_net team_users significa "da nossa rede e com login". Linhas separadas são alternativas: para um segundo escritório, adicione acl office2 src 198.51.100.0/24 e http_access allow office2 team_users.

A posição importa tanto quanto o conteúdo. Um allow abaixo de http_access deny all nunca é alcançado, e todo cliente recebe 403. Não mexa nas regras acima do include: deny CONNECT !SSL_ports só deixa os túneis chegarem à porta 443. A RFC 9110 recomenda limitar o CONNECT a portas conhecidas, porque um proxy que abre túneis para qualquer porta pode ser usado para repassar spam à porta 25.

Para mudar a porta, edite a linha http_port 3128 que já existe no squid.conf em vez de adicionar uma segunda, e atualize o firewall. Uma porta nova não protege nada; quem protege são a ACL e o firewall. O que a 3128 e a 8080 significam está em Porta 8080 e outras portas de proxy.

Como adicionar nome de usuário e senha?#

O htpasswd guarda uma linha por usuário, com a senha em forma de hash. O hash padrão dele é MD5, que o helper basic_ncsa_auth do Squid consegue ler; no Ubuntu, o helper fica em /usr/lib/squid/basic_ncsa_auth. Ele roda como o usuário proxy, e por isso o arquivo pertence ao grupo proxy. As linhas auth_param iniciam até cinco helpers, definem o texto da janela de login e deixam o Squid confiar em um login correto por duas horas antes de consultar o arquivo de novo.

A documentação do auth_param do Squid diz que o cliente só recebe o pedido de credenciais quando uma regra http_access avalia uma ACL proxy_auth. Se você configurar o auth_param sem usar team_users no http_access, o Squid nunca pede senha.

A autenticação básica envia a senha codificada em Base64, e não criptografada, em cada cabeçalho Proxy-Authorization entre o cliente e o Squid. Qualquer pessoa que observe esse caminho consegue lê-la, e é por isso que a lista de IPs permitidos continua ao lado da senha. Como interpretar um 407 está explicado em Autenticação de proxy.

Como configurar o cache e ler os logs?#

O cache_mem define a memória para os objetos mais acessados (o padrão é 256 MB). cache_dir ufs /var/spool/squid 10000 16 256 acrescenta até 10.000 MB de cache em disco, em 16 pastas de primeiro nível e 256 de segundo nível; a documentação do Squid desaconselha informar ali o tamanho total do disco. O maximum_object_size tem padrão de 4 MB, o que deixa os pacotes maiores fora do cache, então aumente esse valor. Ele define o limite de tamanho padrão de todo cache_dir, e é por isso que o arquivo acima o coloca antes.

O squid -z cria as pastas do cache, e o arquivo de serviço do Ubuntu roda squid --foreground -z antes de cada início, então o restart já cria essas pastas. Para mudanças posteriores de regras ou de usuários, sudo systemctl reload squid envia o mesmo sinal que squid -k reconfigure.

O cache só ajuda no HTTP simples. Os espelhos (mirrors) do Ubuntu costumam usar endereços http:// e o apt confere as assinaturas dos pacotes, então máquinas de CI que apontam o apt para o Squid baixam cada pacote uma única vez (Configurar proxy no Linux). O HTTPS nunca gera um hit. Abrir esse tráfego para o cache (SSL bump) exige o certificado do Squid em todos os clientes e o pacote separado squid-openssl, e fica fora deste guia.

O /var/log/squid/access.log tem uma linha por requisição, e o cache.log guarda as mensagens de inicialização e os erros; o logrotate rotaciona os dois diariamente e mantém duas cópias antigas. O código de resultado conta o que aconteceu:

Como remover os cabeçalhos Via e X-Forwarded-For?#

Por padrão, o Squid acrescenta o IP do cliente ao X-Forwarded-For (forwarded_for on) e adiciona um cabeçalho Via (via on). forwarded_for delete remove o cabeçalho, off escreve unknown no lugar do endereço, e via off tira o Via. As duas diretivas só agem no HTTP simples; dentro de um túnel, o Squid não adiciona nada de qualquer forma. Para conferir o resultado com uma requisição de eco, veja Níveis de anonimato do proxy.

Uma saída para a equipe: cache_peer com um proxy pai#

Uma equipe que usa um proxy comercial pode não querer a senha dele em cada notebook e em cada job de CI. O Squid pode ficar no meio: as pessoas entram no Squid com as próprias contas, e só o servidor conhece as credenciais comerciais. Adicione ao team.conf:

# Envia todas as requisições pelo proxy pai. Os clientes nunca veem a senha dele.
cache_peer pr.proxynet.io parent 8000 0 no-query default login=user:pass
never_direct allow all

Seguindo a documentação do cache_peer: host, tipo parent, porta do proxy 8000 e porta ICP 0, porque o peer não responde a consultas ICP. no-query desliga essas consultas, default faz dele o pai de último recurso, e login= envia as credenciais do pai; um % na senha deve ser escrito como %%.

Sem never_direct allow all, o Squid pode buscar algumas requisições diretamente pelo IP da própria VPS. No HTTPS, o Squid repassa o CONNECT ao pai. No access.log, o campo de hierarquia passa então a mostrar o pai com um código como DEFAULT_PARENT em vez de HIER_DIRECT.

Trocar a senha passa a ser uma linha e um reload, cada requisição fica registrada com o nome de usuário de quem a fez, e o HTTP simples continua indo para o cache. Com um Proxies rotativos como pai, o provedor troca o IP de saída, enquanto os clientes continuam apontando para um único endereço, o do Squid (O que é rotação de IP). A cadeia organiza as credenciais; ela não esconde quem você é, e os termos do provedor e as regras de cada site continuam valendo.

Como conectar um cliente e testar?#

Rode isto a partir de uma máquina da rede permitida; 198.51.100.20 representa o seu servidor.

# 1. Sem login: o Squid pede um
curl -x http://198.51.100.20:3128 https://httpbin.org/ip
# curl: (7) CONNECT tunnel failed, response 407

# 2. Com login: a resposta mostra o IP do servidor, não o seu
curl -x http://team1:pass@198.51.100.20:3128 --retry 3 https://httpbin.org/ip

# 3. No servidor: as três últimas requisições
sudo tail -n 3 /var/log/squid/access.log

Rodamos o lado do curl com o curl 8.21 contra um proxy de teste local que exige login: o primeiro comando mostrou a linha acima, e o segundo devolveu o endereço de saída do proxy. --retry 3 repete a requisição após um timeout ou um código HTTP transitório como 429 ou 503, nunca após um 407. Mais detalhes em Como usar cURL com proxy e Como testar um proxy.

Para que usar o seu próprio servidor proxy?#

• Um IP de saída fixo para uma API: só o tráfego da API passa pelo Squid (IP estático para API).
• Controle de acesso à web no escritório: ACLs dstdomain e o access.log, com os funcionários avisados antes (Proxy ou firewall).
• Configurações de navegador no escritório: um arquivo PAC diz a cada navegador quando usar o Squid (Arquivo PAC).
• Um cache de pacotes para máquinas de CI: o apt baixa cada pacote HTTP simples uma única vez (Configurar proxy no Linux).
• Não para trabalho com dados em vários países: checagem de preços e scraping por localização precisam de muitos endereços (extração de dados).

Erros comuns#

• http_access allow all. Um proxy aberto, cujo IP logo vai parar em listas de bloqueio (Lista negra de IP).
• auth_param sem proxy_auth no http_access. A senha nunca é pedida.
• Um allow abaixo de deny all. Nunca é alcançado; todos recebem 403.
• A porta 3128 aberta para a internet. Uma senha sozinha convida a tentativas de adivinhação, e a autenticação básica a envia sem criptografia.
• Esperar hits de cache no HTTPS. Túneis nunca vão para o cache.
• Pular o squid -k parse. Um erro de digitação derruba o serviço; journalctl -u squid mostra o motivo.
• maximum_object_size deixado em 4 MB em um cache de pacotes, ou um cache_dir maior que o espaço livre em disco.
• Scraping pesado a partir do IP da VPS. Os sites respondem 429 e depois bloqueiam (Códigos de status HTTP no web scraping).

Guia de decisão#

Perguntas frequentes#

Qual porta o Squid usa?#

A configuração do Ubuntu define http_port 3128, então o Squid escuta na 3128 depois da instalação. Você pode mudar essa linha junto com a regra do firewall, mas outra porta não acrescenta proteção; quem protege são a ACL de rede, o login e o firewall. O significado dos números de porta de proxy mais comuns está no nosso guia da porta 8080.

O Squid consegue guardar sites HTTPS em cache?#

Não na configuração padrão. Uma requisição HTTPS chega como um túnel CONNECT, e o Squid repassa bytes criptografados sem ver a página, então não há nada para guardar. O SSL bump, que abre o tráfego, exige um certificado do Squid em cada dispositivo cliente e o pacote squid-openssl, e fica fora deste guia.

Como aplicar mudanças no squid.conf sem parar o serviço?#

Rode primeiro sudo squid -k parse, para que um erro de digitação não derrube o proxy. Depois rode sudo systemctl reload squid, que envia o mesmo sinal que squid -k reconfigure e mantém o serviço no ar. Depois de adicionar ou mover um cache_dir, reinicie uma vez em vez de recarregar, para que o serviço crie as pastas do cache.

Onde ficam os logs do Squid e como lê-los?#

No Ubuntu, eles ficam em /var/log/squid/: o access.log tem uma linha por requisição, e o cache.log tem as mensagens de inicialização e os erros. No access.log, leia o código de resultado: TCP_HIT veio do cache, TCP_MISS veio do site, TCP_TUNNEL é HTTPS, e TCP_DENIED com 407 ou 403 significa recusado.

Qual é a diferença entre Squid e Tinyproxy?#

O Tinyproxy se descreve como um daemon de proxy HTTP e HTTPS leve, feito para sistemas pequenos demais para um proxy completo, e o manual de configuração dele não lista nenhuma opção de cache. O Squid acrescenta cache em memória e em disco, ACLs detalhadas, vários helpers de login e cadeias de proxies pais. Para um encaminhamento simples em um dispositivo pequeno, o Tinyproxy pode bastar.

O meu próprio servidor Squid esconde a minha identidade?#

Só em parte. Os sites veem o IP da VPS em vez do endereço da sua casa, e forwarded_for delete com via off remove os cabeçalhos de proxy do HTTP simples. Mas esse IP pertence a um datacenter, é alugado no seu nome e sempre vem do mesmo lugar. O Squid é uma ferramenta de controle de acesso e de saída compartilhada, não de anonimato.

Em resumo#

O Squid dá a você um forward proxy próprio, com controle de acesso, cache para HTTP simples e um log de cada requisição. Uma instalação segura mantém três coisas em ordem: uma ACL de rede, um login proxy_auth usado no http_access e http_access deny all no fim, com o firewall aberto só para endereços conhecidos. O limite é o endereço: um servidor é um IP de datacenter em um único lugar. Quando um trabalho precisa de mais endereços ou de outros países, um Proxies de datacenter ou um Proxies residenciais cobre essa lacuna, e a nossa página de serviços de proxy compara as opções.