Comment configurer un proxy dans des applications serverless : AWS Lambda, Vercel, Cloudflare Workers

L'architecture serverless est devenue la norme pour les applications web modernes, mais les développeurs sont régulièrement confrontés à un problème : toutes les requêtes des fonctions Lambda ou des Edge Functions proviennent des adresses IP des centres de données des fournisseurs de cloud. Cela entraîne des blocages lors de l'accès à des API externes, du scraping de données ou de l'automatisation des tâches. Dans ce guide, nous allons examiner comment intégrer des proxies dans les fonctions serverless pour contourner les restrictions, les limites de taux et les géoblocages.

Pourquoi les fonctions serverless ont besoin de proxies

Les plateformes serverless (AWS Lambda, Google Cloud Functions, Vercel, Cloudflare Workers) exécutent du code dans une infrastructure cloud, utilisant les adresses IP des centres de données. Cela crée plusieurs problèmes critiques pour les développeurs :

Problème 1 : Blocages par IP des centres de données. De nombreux services bloquent automatiquement les requêtes provenant d'adresses IP connues d'AWS, Google Cloud ou Azure. Par exemple, lors du scraping de sites e-commerce (Amazon, eBay, Wildberries) ou de réseaux sociaux (API Instagram, API TikTok), vos fonctions Lambda recevront un HTTP 403 ou un captcha dès la première requête. Les systèmes de protection contre les bots (Cloudflare, Akamai, DataDome) reconnaissent instantanément le trafic en provenance des centres de données cloud.

Problème 2 : Limitation de taux au niveau IP. Si vous déployez une application serverless avec des milliers d'appels simultanés, toutes les requêtes peuvent provenir d'une ou plusieurs adresses IP AWS. Les API externes atteignent rapidement leurs limites (par exemple, l'API GitHub — 60 requêtes/heure par IP, l'API Google Maps — 100 requêtes/seconde). Même si vous avez souscrit à un plan API étendu, la limitation par IP s'appliquera toujours.

Problème 3 : Géoblocages. Les fonctions serverless dans la région us-east-1 ne pourront pas accéder à du contenu disponible uniquement depuis la Russie, l'Europe ou l'Asie. Cela est critique lors du scraping de places de marché régionales (Ozon, Yandex.Market), de la vérification des annonces publicitaires provenant de différents pays ou des tests de localisation des sites.

Problème 4 : IP partagée avec d'autres utilisateurs. Dans un environnement serverless, vos fonctions peuvent obtenir une adresse IP qui a déjà été utilisée par d'autres clients du fournisseur de cloud. Si quelqu'un a abusé de cette IP auparavant (spam, DDoS, scraping), elle peut être sur des listes noires. Vous serez bloqué sans aucune faute de votre part.

La solution à tous ces problèmes est l'intégration de serveurs proxy. Les proxies permettent à vos fonctions serverless d'envoyer des requêtes via des adresses IP résidentielles ou mobiles qui ressemblent à des utilisateurs ordinaires. Cela lève les blocages, contourne les limites de taux et donne accès à du contenu géobloqué.

Quels types de proxies conviennent aux serverless

Le choix du type de proxy dépend de la tâche de votre application serverless. Examinons trois options principales et les scénarios de leur utilisation :

Pour la plupart des applications serverless, il est recommandé d'utiliser des proxies résidentiels. Ils offrent un équilibre optimal entre vitesse et anonymat. Les IP résidentielles ressemblent à des utilisateurs domestiques ordinaires, ce qui permet de contourner les protections contre les bots et les limites de taux sans augmenter significativement la latence.

Les proxies de centre de données ne conviennent qu'aux tâches simples (vérification des statuts HTTP, travail avec des API publiques sans restrictions). Les proxies mobiles sont nécessaires dans des cas spécifiques — lorsque vous travaillez avec des API mobiles ou lorsque la plus grande anonymat est critique.

Configuration des proxies dans AWS Lambda

AWS Lambda est la plateforme serverless la plus populaire, et l'intégration de proxies ici nécessite une configuration correcte du client HTTP. Les fonctions Lambda peuvent utiliser différents langages de programmation (Node.js, Python, Go), examinons des exemples pour les plus courants.

Node.js (axios)

Axios est la bibliothèque la plus populaire pour les requêtes HTTP en Node.js. Pour configurer un proxy, utilisez le paramètre proxy dans la configuration :

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 secondes
    });

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

Point important : stockez les identifiants du proxy dans AWS Systems Manager Parameter Store ou AWS Secrets Manager, et non dans le code. Cela garantira la sécurité et permettra de changer facilement de proxy sans reconstruire la fonction.

Python (requests)

En Python, pour travailler avec des proxies, utilisez la bibliothèque requests avec le paramètre 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'Erreur de proxy : {str(e)}')
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

Pour les proxies SOCKS5 (protocole plus sécurisé) en Python, vous devez installer une bibliothèque supplémentaire requests[socks] et modifier le format de l'URL :

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

Optimisation pour les démarrages à froid

Les fonctions Lambda ont un problème de démarrage à froid — la première requête après une période d'inactivité prend 1 à 3 secondes. Lors de l'utilisation de proxies, ce temps augmente. Pour minimiser les délais, créez le client HTTP en dehors de la fonction handler :

const axios = require('axios');

// Créez le client une fois lors de l'initialisation du conteneur
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) => {
  // Réutilisez le client à chaque appel
  const response = await httpClient.get('https://api.example.com/data');
  return {
    statusCode: 200,
    body: JSON.stringify(response.data)
  };
};

Cette approche réduit le temps de démarrage à froid de 200 à 500 ms, car la configuration du proxy n'est effectuée qu'une seule fois lors de la création du conteneur Lambda.

Intégration des proxies dans Vercel Edge Functions

Vercel propose deux types de fonctions serverless : Node.js Functions (similaires à Lambda) et Edge Functions (exécutées sur le CDN). Les Edge Functions fonctionnent dans un runtime proche de Cloudflare Workers, avec des limitations sur l'utilisation de l'API Node.js. Examinons les deux options.

Vercel Node.js Functions

Pour les Vercel Functions classiques, utilisez la même approche que pour AWS Lambda. Créez un fichier 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 });
  }
}

Ajoutez des variables d'environnement dans le tableau de bord Vercel (Settings → Environment Variables) : PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS.

Vercel Edge Functions

Les Edge Functions utilisent l'API Web Fetch au lieu des bibliothèques Node.js. Les proxies sont configurés via des en-têtes personnalisés ou des 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}`;
  
  // Pour Edge Runtime, il faut fetch avec proxy via agent (nécessite un polyfill)
  // Alternative : utiliser l'API proxy directement
  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
  });
}

Limitation importante : Edge Runtime ne prend pas en charge les agents proxy Node.js standards. Pour un fonctionnement complet avec des proxies, il est recommandé d'utiliser des Node.js Functions ou de créer un serveur proxy intermédiaire sur un serveur distinct qui acceptera les requêtes des Edge Functions.

Proxies dans Cloudflare Workers

Les Cloudflare Workers fonctionnent dans des isolats V8 et ont des restrictions encore plus strictes que les Vercel Edge Functions. La méthode standard de connexion de proxies via des bibliothèques Node.js ne fonctionne pas ici. Il existe deux approches fonctionnelles :

Méthode 1 : Tunneling HTTP CONNECT

Utilisez un proxy prenant en charge la méthode HTTP CONNECT. Créez un tunnel via le serveur 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) {
    // Tunnel établi, exécutez la requête principale
    const finalResponse = await fetch(targetUrl, {
      headers: {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'
      }
    });
    
    return finalResponse;
  }
  
  return new Response('Échec de la connexion au proxy', { status: 502 });
}

Cette méthode ne fonctionne qu'avec des proxies HTTP prenant en charge CONNECT. La plupart des fournisseurs de proxies résidentiels offrent cette possibilité.

Méthode 2 : Passerelle proxy (recommandée)

Une méthode plus fiable consiste à déployer une passerelle proxy intermédiaire sur un serveur distinct (par exemple, sur un VPS ou AWS EC2). Le Cloudflare Worker envoie des requêtes à votre passerelle, qui les transmet ensuite via le 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 // Protection de votre passerelle
    },
    body: JSON.stringify({
      url: targetUrl,
      method: 'GET'
    })
  });

  return response;
}

Du côté de la passerelle proxy (serveur 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: 'Non autorisé' });
  }

  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);

Cette approche ajoute un saut supplémentaire (augmentation de la latence de 50 à 100 ms), mais assure une compatibilité complète et un contrôle sur la connexion proxy.

Rotation des adresses IP dans un environnement serverless

L'une des principales raisons d'utiliser des proxies est de répartir les requêtes entre de nombreuses adresses IP pour contourner les limites de taux. Dans une architecture serverless, il existe deux approches pour la rotation :

Rotation automatique du côté du fournisseur de proxy

La plupart des fournisseurs de proxies résidentiels proposent des proxies rotatifs — vous vous connectez à un seul point de terminaison, et l'IP change automatiquement à chaque requête ou à intervalles réguliers (par exemple, toutes les 5 minutes). C'est l'option la plus simple pour serverless :

// Un seul point de terminaison, l'IP change automatiquement
const proxyConfig = {
  host: 'rotating.proxy.example.com',
  port: 8080,
  auth: {
    username: 'user-session-' + Date.now(), // Session unique
    password: 'password'
  }
};

Certains fournisseurs permettent de gérer la rotation via des paramètres dans le nom d'utilisateur : user-session-random (nouvelle IP à chaque requête), user-session-sticky-300 (une IP pendant 300 secondes).

Rotation manuelle via un pool de proxies

Si vous avez une liste de proxies statiques (par exemple, si vous avez acheté des proxies dédiés), vous pouvez implémenter la rotation au niveau de l'application. Dans un environnement serverless, utilisez DynamoDB (AWS) ou KV Storage (Cloudflare) pour stocker l'état :

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() {
  // Obtenez l'index actuel depuis 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;

  // Mettez à jour l'index
  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) };
};

Cette méthode donne un contrôle total sur la rotation, mais nécessite des requêtes supplémentaires à DynamoDB (ajoute 10 à 30 ms de latence). Pour les applications à fort trafic, il est recommandé de mettre en cache l'index en mémoire dans le conteneur Lambda et de le mettre à jour tous les 100 à 1000 requêtes.

Gestion des erreurs et des délais d'attente

Les proxies ajoutent un point de défaillance supplémentaire à votre application serverless. Il est crucial de gérer correctement les erreurs pour ne pas perdre les requêtes des utilisateurs.

Erreurs typiques lors de l'utilisation de proxies

Implémentation de la logique de retry avec fallback

Ajoutez des tentatives automatiques avec un basculement vers un proxy de secours en cas d'erreurs :

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(`Tentative ${attempt + 1} échouée :`, error.message);
      
      // Ne pas réessayer sur les erreurs client (4xx)
      if (error.response && error.response.status < 500) {
        throw error;
      }
      
      // Dernière tentative — relancer l'erreur
      if (attempt === maxRetries - 1) {
        throw error;
      }
      
      // Délai exponentiel avant de réessayer
      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 }) };
  }
};

Cette implémentation donne trois tentatives de requête : la première via le proxy principal, les autres via le proxy de secours. Entre les tentatives, un délai exponentiel a été ajouté (1 seconde, 2 secondes, 4 secondes) pour ne pas créer une charge excessive.

Surveillance et alertes

Configurez la surveillance des erreurs de proxy via CloudWatch (AWS), Vercel Analytics ou Sentry. Suivez les métriques :

• Pourcentage de requêtes réussies via le proxy (doit être >95%)
• Latence moyenne des requêtes (une augmentation peut indiquer des problèmes avec le proxy)
• Nombre d'erreurs de délai d'attente (si >5% — le proxy est surchargé ou lent)
• Répartition des erreurs par code (407, 502, ETIMEDOUT, etc.)

Configurez des alertes lorsque les seuils sont dépassés — cela vous permettra de passer rapidement à un fournisseur de proxy de secours ou de modifier la configuration.

Conclusion

L'intégration de proxies dans des applications serverless résout des problèmes critiques : blocages par IP des centres de données, limitations de taux et géoblocages. Nous avons examiné la configuration des proxies dans AWS Lambda (Node.js et Python), les Vercel Functions et les Cloudflare Workers, ainsi que la mise en œuvre de la rotation des adresses IP et la gestion des erreurs.

Recommandations clés : utilisez des proxies résidentiels pour les tâches nécessitant une grande anonymat (scraping, travail avec les API des réseaux sociaux), stockez les identifiants dans des stockages sécurisés (AWS Secrets Manager, Vercel Environment Variables), implémentez une logique de retry avec un fallback vers des proxies de secours et configurez la surveillance des erreurs.

Pour les applications serverless avec des exigences élevées en matière de stabilité, nous recommandons d'utiliser des proxies résidentiels avec rotation automatique — ils offrent un équilibre optimal entre vitesse, anonymat et fiabilité, minimisant le risque de blocages lors de l'utilisation d'API et de services externes.