Como configurar um proxy em aplicações serverless: AWS Lambda, Vercel, Cloudflare Workers

A arquitetura serverless se tornou um padrão para aplicações web modernas, mas os desenvolvedores enfrentam regularmente um problema: todas as solicitações das funções Lambda ou Edge Functions vêm de endereços IP dos data centers dos provedores de nuvem. Isso leva a bloqueios ao acessar APIs externas, fazer scraping de dados ou automatizar tarefas. Neste guia, vamos explorar como integrar proxies em funções serverless para contornar restrições, limites de taxa e bloqueios geográficos.

Por que funções serverless precisam de proxies

Plataformas serverless (AWS Lambda, Google Cloud Functions, Vercel, Cloudflare Workers) executam código na infraestrutura de nuvem, usando endereços IP dos data centers. Isso cria vários problemas críticos para os desenvolvedores:

Problema 1: Bloqueios por IP dos data centers. Muitos serviços bloqueiam automaticamente solicitações de endereços IP conhecidos da AWS, Google Cloud ou Azure. Por exemplo, ao fazer scraping de sites de e-commerce (Amazon, eBay, Wildberries) ou redes sociais (Instagram API, TikTok API), suas funções Lambda receberão HTTP 403 ou captcha já na primeira solicitação. Sistemas de proteção contra bots (Cloudflare, Akamai, DataDome) reconhecem instantaneamente o tráfego de data centers em nuvem.

Problema 2: Limitação de taxa no nível do IP. Se você está implantando uma aplicação serverless com milhares de chamadas simultâneas, todas as solicitações podem vir de um ou mais endereços IP da AWS. APIs externas rapidamente atingem os limites (por exemplo, GitHub API — 60 solicitações/hora de um IP, Google Maps API — 100 solicitações/segundo). Mesmo que você tenha um plano API pago, a limitação por IP ainda se aplicará.

Problema 3: Bloqueios geográficos. Funções serverless na região us-east-1 não conseguirão acessar conteúdo disponível apenas na Rússia, Europa ou Ásia. Isso é crítico ao fazer scraping de marketplaces regionais (Ozon, Yandex.Market), verificar anúncios de diferentes países ou testar a localização de sites.

Problema 4: IP compartilhado com outros usuários. Em um ambiente serverless, suas funções podem receber um endereço IP que já foi usado por outros clientes do provedor de nuvem. Se alguém abusou desse IP anteriormente (spam, DDoS, scraping), ele pode estar em listas negras. Você receberá um bloqueio sem qualquer culpa.

A solução para todos esses problemas é a integração de servidores proxy. Proxies permitem que suas funções serverless enviem solicitações através de endereços IP residenciais ou móveis, que se parecem com usuários comuns. Isso remove bloqueios, contorna limites de taxa e dá acesso a conteúdo bloqueado geograficamente.

Quais tipos de proxies são adequados para serverless

A escolha do tipo de proxy depende da tarefa da sua aplicação serverless. Vamos considerar três opções principais e cenários de uso:

Para a maioria das aplicações serverless, recomenda-se o uso de proxies residenciais. Eles oferecem um equilíbrio ideal entre velocidade e anonimato. IPs residenciais se parecem com usuários domésticos comuns, o que permite contornar proteções contra bots e limites de taxa sem aumentar significativamente a latência.

Proxies de data center são adequados apenas para tarefas simples (verificação de status HTTP, trabalho com APIs públicas sem restrições). Proxies móveis são necessários em casos específicos — quando você trabalha com APIs móveis ou quando a máxima anonimidade é crítica.

Configuração de proxies no AWS Lambda

AWS Lambda é a plataforma serverless mais popular, e a integração de proxies aqui requer a configuração correta do cliente HTTP. Funções Lambda podem usar várias linguagens de programação (Node.js, Python, Go), vamos considerar exemplos para as mais comuns.

Node.js (axios)

Axios é a biblioteca mais popular para requisições HTTP em Node.js. Para configurar o proxy, use o parâmetro proxy na configuração:

const axios = require('axios');

exports.handler = async (event) => {
  const proxyConfig = {
    host: 'proxy.example.com',
    port: 8080,
    auth: {
      username: 'your_username',
      password: 'your_password'
    },
    protocol: 'http'
  };

  try {
    const response = await axios.get('https://api.example.com/data', {
      proxy: proxyConfig,
      timeout: 10000 // 10 segundos
    });

    return {
      statusCode: 200,
      body: JSON.stringify(response.data)
    };
  } catch (error) {
    console.error('Erro de proxy:', error.message);
    return {
      statusCode: 500,
      body: JSON.stringify({ error: error.message })
    };
  }
};

Ponto importante: armazene as credenciais do proxy no AWS Systems Manager Parameter Store ou no AWS Secrets Manager, e não no código. Isso garantirá segurança e permitirá trocar proxies facilmente sem recompilar a função.

Python (requests)

Em Python, para trabalhar com proxies, usa-se a biblioteca requests com o parâmetro proxies:

import requests
import json

def lambda_handler(event, context):
    proxies = {
        'http': 'http://username:password@proxy.example.com:8080',
        'https': 'http://username:password@proxy.example.com:8080'
    }
    
    try:
        response = requests.get(
            'https://api.example.com/data',
            proxies=proxies,
            timeout=10
        )
        
        return {
            'statusCode': 200,
            'body': json.dumps(response.json())
        }
    except requests.exceptions.RequestException as e:
        print(f'Erro de proxy: {str(e)}')
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

Para proxies SOCKS5 (protocolo mais seguro) em Python, é necessário instalar a biblioteca adicional requests[socks] e alterar o formato da URL:

proxies = {
    'http': 'socks5://username:password@proxy.example.com:1080',
    'https': 'socks5://username:password@proxy.example.com:1080'
}

Otimização para cold starts

Funções Lambda têm o problema de cold starts — a primeira solicitação após um período de inatividade leva de 1 a 3 segundos. Ao usar proxies, esse tempo aumenta. Para minimizar as latências, crie o cliente HTTP fora da função handler:

const axios = require('axios');

// Criamos o cliente uma vez na inicialização do contêiner
const httpClient = axios.create({
  proxy: {
    host: 'proxy.example.com',
    port: 8080,
    auth: {
      username: process.env.PROXY_USER,
      password: process.env.PROXY_PASS
    }
  },
  timeout: 10000
});

exports.handler = async (event) => {
  // Reutilizamos o cliente em cada chamada
  const response = await httpClient.get('https://api.example.com/data');
  return {
    statusCode: 200,
    body: JSON.stringify(response.data)
  };
};

Essa abordagem reduz o tempo de cold start em 200-500 ms, pois a configuração do proxy é feita apenas uma vez na criação do contêiner Lambda.

Integração de proxies em Vercel Edge Functions

Vercel oferece dois tipos de funções serverless: Node.js Functions (análoga ao Lambda) e Edge Functions (executadas em CDN). Edge Functions operam em um runtime semelhante ao Cloudflare Workers, com restrições no uso da API do Node.js. Vamos considerar ambas as opções.

Vercel Node.js Functions

Para funções Vercel comuns, use a mesma abordagem que para AWS Lambda. Crie um arquivo api/fetch-data.js:

import axios from 'axios';

export default async function handler(req, res) {
  const proxyConfig = {
    host: process.env.PROXY_HOST,
    port: parseInt(process.env.PROXY_PORT),
    auth: {
      username: process.env.PROXY_USER,
      password: process.env.PROXY_PASS
    }
  };

  try {
    const response = await axios.get(req.query.url, {
      proxy: proxyConfig,
      timeout: 8000
    });

    res.status(200).json(response.data);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
}

Adicione variáveis de ambiente no Vercel Dashboard (Configurações → Variáveis de Ambiente): PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS.

Vercel Edge Functions

Edge Functions usam a Web Fetch API em vez de bibliotecas do Node.js. O proxy é configurado através de cabeçalhos personalizados ou middleware:

export const config = {
  runtime: 'edge',
};

export default async function handler(req) {
  const proxyUrl = `http://${process.env.PROXY_USER}:${process.env.PROXY_PASS}@${process.env.PROXY_HOST}:${process.env.PROXY_PORT}`;
  
  // Para Edge Runtime, é necessário fetch com proxy através de agent (requer polyfill)
  // Alternativa: usar a API de proxy diretamente
  const targetUrl = new URL(req.url).searchParams.get('target');
  
  const response = await fetch(targetUrl, {
    headers: {
      'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
    }
  });

  return new Response(await response.text(), {
    status: response.status,
    headers: response.headers
  });
}

Limitação importante: Edge Runtime não suporta agentes proxy padrão do Node.js. Para um funcionamento completo com proxies, recomenda-se usar Node.js Functions ou criar um servidor proxy intermediário em um servidor separado que receberá solicitações das Edge Functions.

Proxies em Cloudflare Workers

Cloudflare Workers operam em V8 isolates e têm restrições ainda mais rigorosas do que Vercel Edge Functions. A maneira padrão de conectar proxies através de bibliotecas do Node.js não funciona aqui. Existem duas abordagens funcionais:

Método 1: Tunneling HTTP CONNECT

Use um proxy que suporte o método HTTP CONNECT. Crie um túnel através do servidor proxy:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const proxyUrl = 'http://proxy.example.com:8080';
  const targetUrl = 'https://api.example.com/data';
  
  const proxyAuth = btoa(`${PROXY_USER}:${PROXY_PASS}`);
  
  const response = await fetch(proxyUrl, {
    method: 'CONNECT',
    headers: {
      'Host': new URL(targetUrl).host,
      'Proxy-Authorization': `Basic ${proxyAuth}`
    }
  });

  if (response.status === 200) {
    // Túnel estabelecido, executamos a solicitação principal
    const finalResponse = await fetch(targetUrl, {
      headers: {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'
      }
    });
    
    return finalResponse;
  }
  
  return new Response('Falha na conexão do proxy', { status: 502 });
}

Este método funciona apenas com proxies HTTP que suportam CONNECT. A maioria dos provedores de proxies residenciais oferece essa possibilidade.

Método 2: Proxy Gateway (recomendado)

Uma maneira mais confiável é implantar um proxy gateway intermediário em um servidor separado (por exemplo, em VPS ou AWS EC2). O Cloudflare Worker envia solicitações para seu gateway, que as encaminha através do proxy:

// Cloudflare Worker
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const targetUrl = new URL(request.url).searchParams.get('url');
  const gatewayUrl = 'https://your-proxy-gateway.com/fetch';
  
  const response = await fetch(gatewayUrl, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-API-Key': API_KEY // Proteção do seu gateway
    },
    body: JSON.stringify({
      url: targetUrl,
      method: 'GET'
    })
  });

  return response;
}

No lado do proxy gateway (servidor Node.js):

const express = require('express');
const axios = require('axios');

const app = express();
app.use(express.json());

const proxyConfig = {
  host: 'proxy.example.com',
  port: 8080,
  auth: {
    username: process.env.PROXY_USER,
    password: process.env.PROXY_PASS
  }
};

app.post('/fetch', async (req, res) => {
  if (req.headers['x-api-key'] !== process.env.API_KEY) {
    return res.status(401).json({ error: 'Não autorizado' });
  }

  try {
    const response = await axios({
      url: req.body.url,
      method: req.body.method || 'GET',
      proxy: proxyConfig,
      timeout: 10000
    });

    res.json(response.data);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000);

Essa abordagem adiciona um hop adicional (aumentando a latência em 50-100 ms), mas garante total compatibilidade e controle sobre a conexão proxy.

Rotação de endereços IP em ambiente serverless

Uma das principais razões para usar proxies é distribuir solicitações entre vários endereços IP para contornar limites de taxa. Na arquitetura serverless, existem duas abordagens para rotação:

Rotação automática pelo provedor de proxy

A maioria dos provedores de proxies residenciais oferece proxies rotativos — você se conecta a um único endpoint, e o IP muda automaticamente a cada solicitação ou em um intervalo definido (por exemplo, a cada 5 minutos). Esta é a opção mais simples para serverless:

// Um endpoint, IP muda automaticamente
const proxyConfig = {
  host: 'rotating.proxy.example.com',
  port: 8080,
  auth: {
    username: 'user-session-' + Date.now(), // Sessão única
    password: 'password'
  }
};

Alguns provedores permitem gerenciar a rotação através de parâmetros no nome de usuário: user-session-random (novo IP a cada solicitação), user-session-sticky-300 (um IP por 300 segundos).

Rotação manual através de um pool de proxies

Se você tem uma lista de proxies estáticos (por exemplo, comprou proxies dedicados), pode implementar a rotação no nível da aplicação. Em um ambiente serverless, use DynamoDB (AWS) ou KV Storage (Cloudflare) para armazenar o estado:

const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

const PROXY_POOL = [
  { host: 'proxy1.example.com', port: 8080 },
  { host: 'proxy2.example.com', port: 8080 },
  { host: 'proxy3.example.com', port: 8080 }
];

async function getNextProxy() {
  // Obtém o índice atual do DynamoDB
  const result = await dynamodb.get({
    TableName: 'ProxyRotation',
    Key: { id: 'current_index' }
  }).promise();

  const currentIndex = result.Item?.index || 0;
  const nextIndex = (currentIndex + 1) % PROXY_POOL.length;

  // Atualiza o índice
  await dynamodb.put({
    TableName: 'ProxyRotation',
    Item: { id: 'current_index', index: nextIndex }
  }).promise();

  return PROXY_POOL[currentIndex];
}

exports.handler = async (event) => {
  const proxy = await getNextProxy();
  
  const response = await axios.get('https://api.example.com/data', {
    proxy: {
      ...proxy,
      auth: {
        username: process.env.PROXY_USER,
        password: process.env.PROXY_PASS
      }
    }
  });

  return { statusCode: 200, body: JSON.stringify(response.data) };
};

Este método oferece controle total sobre a rotação, mas requer solicitações adicionais ao DynamoDB (adicionando 10-30 ms de latência). Para aplicações de alta carga, recomenda-se armazenar em cache o índice na memória do contêiner Lambda e atualizá-lo a cada 100-1000 solicitações.

Tratamento de erros e timeouts

Proxies adicionam um ponto adicional de falha à sua aplicação serverless. É crítico tratar erros corretamente para não perder solicitações dos usuários.

Erros típicos ao trabalhar com proxies

Implementação de lógica de retry com fallback

Adicione tentativas automáticas com mudança para um proxy de reserva em caso de erros:

const axios = require('axios');

const PRIMARY_PROXY = {
  host: 'primary.proxy.com',
  port: 8080,
  auth: { username: 'user', password: 'pass' }
};

const FALLBACK_PROXY = {
  host: 'fallback.proxy.com',
  port: 8080,
  auth: { username: 'user', password: 'pass' }
};

async function fetchWithRetry(url, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const proxy = attempt === 0 ? PRIMARY_PROXY : FALLBACK_PROXY;
    
    try {
      const response = await axios.get(url, {
        proxy,
        timeout: 8000
      });
      
      return response.data;
    } catch (error) {
      console.log(`Tentativa ${attempt + 1} falhou:`, error.message);
      
      // Não retry em erros do cliente (4xx)
      if (error.response && error.response.status < 500) {
        throw error;
      }
      
      // Última tentativa — lança o erro
      if (attempt === maxRetries - 1) {
        throw error;
      }
      
      // Atraso exponencial antes do retry
      await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, attempt)));
    }
  }
}

exports.handler = async (event) => {
  try {
    const data = await fetchWithRetry('https://api.example.com/data');
    return { statusCode: 200, body: JSON.stringify(data) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: error.message }) };
  }
};

Esta implementação dá três tentativas de solicitação: a primeira através do proxy principal, as outras através do proxy de reserva. Entre as tentativas, foi adicionado um atraso exponencial (1 seg, 2 seg, 4 seg) para não criar carga excessiva.

Monitoramento e alertas

Configure o monitoramento de erros do proxy através do CloudWatch (AWS), Vercel Analytics ou Sentry. Monitore as métricas:

• Porcentagem de solicitações bem-sucedidas através do proxy (deve ser >95%)
• Latência média das solicitações (um aumento pode indicar problemas com o proxy)
• Número de erros de timeout (se >5% — o proxy está sobrecarregado ou lento)
• Distribuição de erros por códigos (407, 502, ETIMEDOUT, etc.)

Configure alertas ao ultrapassar limites — isso permitirá uma troca rápida para um provedor de proxy de reserva ou a alteração da configuração.

Conclusão

A integração de proxies em aplicações serverless resolve problemas críticos: bloqueios por IP dos data centers, limitação de taxa e bloqueios geográficos. Nós exploramos a configuração de proxies no AWS Lambda (Node.js e Python), Vercel Functions e Cloudflare Workers, além da implementação de rotação de endereços IP e tratamento de erros.

Recomendações principais: use proxies residenciais para tarefas que exigem alta anonimidade (scraping, trabalho com APIs de redes sociais), armazene credenciais em repositórios seguros (AWS Secrets Manager, Vercel Environment Variables), implemente lógica de retry com fallback para proxies de reserva e configure monitoramento de erros.

Para aplicações serverless com altas exigências de estabilidade, recomendamos o uso de proxies residenciais com rotação automática — eles oferecem um equilíbrio ideal entre velocidade, anonimato e confiabilidade, minimizando o risco de bloqueios ao trabalhar com APIs e serviços externos.