Dia 14: Proxy e Cache — Squid, Proxy Inverso e CDN

1. Introdução a Proxies

Um proxy é um intermediário entre o cliente e o servidor que recebe pedidos, processa-as e encaminha-as ao destino. Existem dois modelos fundamentais: o proxy directo (forward proxy), que age em nome do cliente para aceder à Internet, e o proxy inverso (reverse proxy), que age em nome do servidor para receber pedidos de clientes externos.

O proxy directo é típico em redes empresariais: os utilizadores configuram o navegador para enviar tráfego HTTP/HTTPS através do Squid, que pode filtrar conteúdo, aplicar políticas de acesso e cachear respostas. O proxy inverso é típico em infra-estruturas web: um Nginx ou Caddy recebe os pedidos dos visitantes e distribui-os pelos servidores de retaguarda, com terminação SSL, balanceamento de carga e caching.

Além do caching, os proxies permitem filtragem de conteúdo (bloquear domínios ou categorias), autenticação (integrar com LDAP/Active Directory), registo de tráfego (auditoria e conformidade) e inspecção HTTPS (SSL bump para analisar tráfego encriptado). Um proxy transparente intercepta tráfego sem necessidade de configuração no cliente, usando redireccionamento a nível de router ou firewall.

2. Squid — Proxy Directo

O Squid é o proxy directo mais usado em ambientes Linux. Suporta HTTP, HTTPS (com SSL bump), FTP e colocação em cache de DNS. A configuração principal fica em /etc/squid/squid.conf.

# Instalar Squid
apt install squid
# /etc/squid/squid.conf
http_port 3128
cache_dir ufs /var/spool/squid 1000 16 256
acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all
# Cache refresh patterns
refresh_pattern ^ftp:    1440 20% 10080
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern .       0 20% 4320
# Reiniciar Squid
systemctl restart squid

A directiva cache_dir define o directório e tamanho do cache. O formato ufs é o mais simples; aufs ou rock oferecem melhor desempenho em ambientes com carga elevada. Os três números após o caminho são: tamanho máximo em MB, número de directórios de primeiro nível e número de directórios de segundo nível.

As ACLs (Access Control Lists) permitem controlar quem pode usar o proxy. acl localnet src 192.168.1.0/24 define a rede interna; http_access allow localnet autoriza essa rede e http_access deny all bloqueia o resto. A ordem das regras é importante — o Squid avalia de cima para baixo e pára na primeira correspondência.

Para verificar o estado do cache e estatísticas em tempo real, usa-se o utilitário squidclient:

# Verificar cache do Squid
squidclient -h 127.0.0.1 -p 3128 mgr:info

3. Proxy Inverso com Nginx

O Nginx é o proxy inverso mais popular em ambientes de produção. Além de proxy, funciona como servidor web, balanceador de carga e terminação SSL. A configuração de proxy inverso com cache combina proxy_pass com proxy_cache.

# Nginx — proxy inverso com cache
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m;
server {
    listen 80;
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_cache mycache;
        proxy_cache_valid 200 10m;
    }
}

A directiva proxy_cache_path define o directório do cache, a estrutura de subdirectórios (levels=1:2) e a zona de memória partilhada (keys_zone=mycache:10m aloca 10 MB para metadados). O proxy_cache_valid 200 10m caches respostas HTTP 200 durante 10 minutos.

Para terminar SSL no Nginx e encaminhar tráfego em texto simples para o backend, basta adicionar listen 443 ssl e os certificados. O Nginx suporta HTTP/2, HTTP/3 (QUIC) e WebSocket nativamente, o que o torna ideal para aplicações modernas e APIs em tempo real.

4. Proxy Inverso com Caddy

O Caddy é uma alternativa moderna ao Nginx com configuração minimalista e HTTPS automático através da Let’s Encrypt. Não é necessário configurar certificados manualmente nem renovações — o Caddy trata de tudo automaticamente.

# Caddy — proxy inverso automático HTTPS
domain.pt {
    reverse_proxy 127.0.0.1:8080
}

Esta configuração de duas linhas faz o seguinte: escuta nas portas 80 e 443, obtém e renova certificados Let’s Encrypt automaticamente, redirecciona HTTP para HTTPS, e faz proxy de todos os pedidos para 127.0.0.1:8080. O Caddy suporta HTTP/2 e HTTP/3 por defeito.

Para ambientes com múltiplos backends, o Caddy suporta balanceamento de carga com uma sintaxe simples. Basta listar os endereços separados por espaço após reverse_proxy. Políticas como round-robin (predefinida), least_conn e aleatório estão disponíveis com a directiva lb_policy.

5. Caching HTTP

O caching HTTP reduz a latência e o consumo de banda ao armazenar respostas próximas do cliente. Existem três níveis de caching: navegador (Cache-Control, ETag, Last-Modified), proxy/CDN (Squid, Nginx cache, Cloudflare) e aplicação (Redis, Memcached). Cada nível tem objectivos e tempos de vida diferentes.

A directiva max-age define o tempo máximo em segundos que a resposta pode ser servida do cache. public permite caching por qualquer intermediário (CDN, proxy); private restringe ao cache do navegador. no-cache obriga a revalidação antes de usar e no-store proíbe caching completamente.

A revalidação condicional usa If-None-Match (com ETag) ou If-Modified-Since (com Last-Modified). Se o recurso não mudou, o servidor responde 304 Not Modified sem corpo — poupando banda. O stale-while-revalidate permite servir cache expirado enquanto revalida em segundo plano.

6. CDN e Computação Periférica

Uma CDN (Rede de Entrega de Conteúdo) distribui cópias de conteúdo em múltiplos pontos de presença (PoPs) geograficamente próximos dos utilizadores. Isto reduz latência, melhora disponibilidade e absorve picos de tráfego. Para uma PME portuguesa com clientes em Portugal, um CDN com PoP em Lisboa ou Madrid pode reduzir o tempo de carregamento de 200-400ms para 20-50ms.

O Computação Periférica vai além do caching estático: executa código (funções sem servidor) nos PoPs, mais próximos do utilizador. Cloudflare Workers, Bunny Edge Scripts e Vercel Edge Functions permitem processar pedidos, personalizar respostas e fazer testes A/B sem ida e volta ao servidor de origem. Isto reduz latência para operações dinâmicas, não apenas ficheiros estáticos.

Para configurar um CDN típico: (1) apontar o DNS do domínio para o CDN, (2) configurar o CDN para fazer proxy para o servidor de origem, (3) definir regras de cache por tipo de conteúdo (estático vs dinâmico), (4) configurar purga de cache quando o conteúdo muda. A maioria dos CDNs oferece API para purga programática e integração com CI/CD.

7. Erros Comuns e Lista de Verificação

A configuração de proxies e caches introduz complexidade adicional na rede. Os erros mais frequentes resultam de regras de acesso mal ordenadas, certificados mal configurados ou políticas de cache demasiado agressivas. Abaixo uma lista de verificação para auditoria rápida.

Lista de verificação pós-configuração:

• Squid escuta na porta correcta e ACLs permitem a rede interna
• Cache do Squid tem espaço suficiente e directório existe
• Proxy inverso encaminha para o backend correcto e testa conectividade
• Certificados SSL configurados e válidos (ou Caddy a gerir automaticamente)
• Políticas de cache definidas por tipo de conteúdo (estático vs dinâmico)
• CDN configurado com regras de cache e purga funcional
• Registos de proxy/CDN recolhidos e monitorizados
• SSL bump testado com CA instalada nos clientes (se filtragem HTTPS necessária)