← Назад к блогу
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Как настроить прокси в serverless приложениях: AWS Lambda, Vercel, Cloudflare Workers

Полное руководство по интеграции прокси в serverless функции: от настройки HTTP-клиентов до обхода rate limits и геоблокировок в AWS Lambda, Vercel Edge Functions и Cloudflare Workers

📅19 февраля 2026 г.

Serverless архитектура стала стандартом для современных веб-приложений, но разработчики регулярно сталкиваются с проблемой: все запросы от Lambda функций или Edge Functions идут с IP-адресов дата-центров облачных провайдеров. Это приводит к блокировкам при обращении к внешним API, парсинге данных или автоматизации задач. В этом руководстве разберём как интегрировать прокси в serverless функции для обхода ограничений, rate limits и геоблокировок.

Почему serverless функциям нужны прокси

Serverless платформы (AWS Lambda, Google Cloud Functions, Vercel, Cloudflare Workers) выполняют код в облачной инфраструктуре, используя IP-адреса дата-центров. Это создаёт несколько критических проблем для разработчиков:

Проблема 1: Блокировки по IP дата-центров. Многие сервисы автоматически блокируют запросы с известных IP-адресов AWS, Google Cloud или Azure. Например, при парсинге e-commerce сайтов (Amazon, eBay, Wildberries) или социальных сетей (Instagram API, TikTok API) ваши Lambda функции получат HTTP 403 или captcha уже на первом запросе. Системы защиты от ботов (Cloudflare, Akamai, DataDome) мгновенно распознают трафик из облачных дата-центров.

Проблема 2: Rate limiting на уровне IP. Если вы разворачиваете serverless приложение с тысячами одновременных вызовов, все запросы могут идти с одного или нескольких IP-адресов AWS. Внешние API быстро достигают лимитов (например, GitHub API — 60 запросов/час с одного IP, Google Maps API — 100 запросов/секунду). Даже если у вас оплачен расширенный план API, ограничение по IP всё равно сработает.

Проблема 3: Геоблокировки. Serverless функции в регионе us-east-1 не смогут получить доступ к контенту, доступному только из России, Европы или Азии. Это критично при парсинге региональных маркетплейсов (Ozon, Яндекс.Маркет), проверке рекламных объявлений из разных стран или тестировании локализации сайтов.

Проблема 4: Shared IP с другими пользователями. В serverless среде ваши функции могут получить IP-адрес, который уже использовался другими клиентами облачного провайдера. Если кто-то ранее злоупотреблял этим IP (спам, DDoS, парсинг), он может быть в чёрных списках. Вы получите блокировку без какой-либо вины.

Решение всех этих проблем — интеграция прокси-серверов. Прокси позволяют вашим serverless функциям отправлять запросы через резидентные или мобильные IP-адреса, которые выглядят как обычные пользователи. Это снимает блокировки, обходит rate limits и даёт доступ к геоблокированному контенту.

Какие типы прокси подходят для serverless

Выбор типа прокси зависит от задачи вашего serverless приложения. Рассмотрим три основных варианта и сценарии их применения:

Тип прокси Скорость Анонимность Сценарии использования
Прокси дата-центров Очень высокая (10-50 мс) Низкая Обращение к API без жёстких ограничений, проверка доступности сервисов, мониторинг uptime
Резидентные прокси Средняя (100-500 мс) Высокая Парсинг e-commerce, работа с социальными сетями, обход Cloudflare, доступ к геоблокированному контенту
Мобильные прокси Средняя (150-600 мс) Очень высокая Работа с мобильными API (Instagram, TikTok), тестирование мобильных приложений, обход самых строгих защит

Для большинства serverless приложений рекомендуется использовать резидентные прокси. Они обеспечивают оптимальный баланс между скоростью и анонимностью. Резидентные IP выглядят как обычные домашние пользователи, что позволяет обходить защиты от ботов и rate limits без значительного увеличения latency.

Прокси дата-центров подходят только для простых задач (проверка HTTP статусов, работа с публичными API без ограничений). Мобильные прокси нужны в специфических случаях — когда вы работаете с мобильными API или вам критически важна максимальная анонимность.

Настройка прокси в AWS Lambda

AWS Lambda — самая популярная serverless платформа, и интеграция прокси здесь требует правильной настройки HTTP-клиента. Lambda функции могут использовать различные языки программирования (Node.js, Python, Go), рассмотрим примеры для самых распространённых.

Node.js (axios)

Axios — наиболее популярная библиотека для HTTP-запросов в Node.js. Для настройки прокси используйте параметр proxy в конфигурации: 

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 секунд
    });

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

Важный момент: храните учётные данные прокси в AWS Systems Manager Parameter Store или AWS Secrets Manager, а не в коде. Это обеспечит безопасность и позволит легко менять прокси без пересборки функции.

Python (requests)

В Python для работы с прокси используется библиотека requests с параметром 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'Proxy error: {str(e)}')
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

Для SOCKS5 прокси (более защищённый протокол) в Python нужно установить дополнительную библиотеку requests[socks] и изменить формат URL: 

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

Оптимизация для холодных стартов

Lambda функции имеют проблему холодных стартов — первый запрос после простоя занимает 1-3 секунды. При использовании прокси это время увеличивается. Чтобы минимизировать задержки, создавайте HTTP-клиент вне handler функции: 

const axios = require('axios');

// Создаём клиент один раз при инициализации контейнера
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) => {
  // Переиспользуем клиент при каждом вызове
  const response = await httpClient.get('https://api.example.com/data');
  return {
    statusCode: 200,
    body: JSON.stringify(response.data)
  };
};

Такой подход сокращает время холодного старта на 200-500 мс, так как конфигурация прокси выполняется только один раз при создании контейнера Lambda.

Интеграция прокси в Vercel Edge Functions

Vercel предлагает два типа serverless функций: Node.js Functions (аналог Lambda) и Edge Functions (выполняются на CDN). Edge Functions работают в runtime, близком к Cloudflare Workers, с ограничениями на использование Node.js API. Рассмотрим оба варианта.

Vercel Node.js Functions

Для обычных Vercel Functions используйте тот же подход, что и для AWS Lambda. Создайте файл 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 });
  }
}

Добавьте переменные окружения в Vercel Dashboard (Settings → Environment Variables): PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS.

Vercel Edge Functions

Edge Functions используют Web Fetch API вместо Node.js библиотек. Прокси настраивается через custom headers или 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}`;
  
  // Для Edge Runtime нужен fetch с proxy через agent (требует полифилла)
  // Альтернатива: использовать proxy API напрямую
  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
  });
}

Важное ограничение: Edge Runtime не поддерживает стандартные Node.js прокси-агенты. Для полноценной работы с прокси рекомендуется использовать Node.js Functions или создать промежуточный прокси-сервер на отдельном сервере, который будет принимать запросы от Edge Functions.

Прокси в Cloudflare Workers

Cloudflare Workers работают в V8 isolates и имеют ещё более строгие ограничения, чем Vercel Edge Functions. Стандартный способ подключения прокси через библиотеки Node.js здесь не работает. Есть два рабочих подхода:

Метод 1: HTTP CONNECT туннелирование

Используйте прокси, поддерживающий HTTP CONNECT метод. Создайте туннель через прокси-сервер: 

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) {
    // Туннель установлен, выполняем основной запрос
    const finalResponse = await fetch(targetUrl, {
      headers: {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'
      }
    });
    
    return finalResponse;
  }
  
  return new Response('Proxy connection failed', { status: 502 });
}

Этот метод работает только с HTTP прокси, поддерживающими CONNECT. Большинство резидентных прокси-провайдеров предоставляют такую возможность.

Метод 2: Прокси-шлюз (рекомендуется)

Более надёжный способ — развернуть промежуточный прокси-шлюз на отдельном сервере (например, на VPS или AWS EC2). Cloudflare Worker отправляет запросы на ваш шлюз, а тот уже пересылает их через прокси: 

// 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 // Защита вашего шлюза
    },
    body: JSON.stringify({
      url: targetUrl,
      method: 'GET'
    })
  });

  return response;
}

На стороне прокси-шлюза (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: 'Unauthorized' });
  }

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

Этот подход добавляет дополнительный hop (увеличение latency на 50-100 мс), но обеспечивает полную совместимость и контроль над прокси-соединением.

Ротация IP-адресов в serverless среде

Одна из главных причин использования прокси — распределение запросов между множеством IP-адресов для обхода rate limits. В serverless архитектуре есть два подхода к ротации:

Автоматическая ротация на стороне прокси-провайдера

Большинство провайдеров резидентных прокси предлагают rotating proxies — вы подключаетесь к одному endpoint, а IP меняется автоматически при каждом запросе или через заданный интервал (например, каждые 5 минут). Это самый простой вариант для serverless: 

// Один endpoint, IP меняется автоматически
const proxyConfig = {
  host: 'rotating.proxy.example.com',
  port: 8080,
  auth: {
    username: 'user-session-' + Date.now(), // Уникальная сессия
    password: 'password'
  }
};

Некоторые провайдеры позволяют управлять ротацией через параметры в username: user-session-random (новый IP при каждом запросе), user-session-sticky-300 (один IP в течение 300 секунд).

Ручная ротация через пул прокси

Если у вас есть список статических прокси (например, вы купили dedicated прокси), можно реализовать ротацию на уровне приложения. В serverless среде используйте DynamoDB (AWS) или KV Storage (Cloudflare) для хранения состояния: 

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() {
  // Получаем текущий индекс из 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;

  // Обновляем индекс
  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) };
};

Этот метод даёт полный контроль над ротацией, но требует дополнительных запросов к DynamoDB (добавляет 10-30 мс latency). Для высоконагруженных приложений рекомендуется кэшировать индекс в памяти Lambda контейнера и обновлять его раз в 100-1000 запросов.

Обработка ошибок и таймаутов

Прокси добавляют дополнительную точку отказа в ваше serverless приложение. Критически важно правильно обрабатывать ошибки, чтобы не терять запросы пользователей.

Типичные ошибки при работе с прокси

Ошибка Причина Решение
ETIMEDOUT Прокси не отвечает или медленно работает Уменьшите timeout до 5-8 секунд, добавьте retry с другим прокси
ECONNREFUSED Прокси-сервер недоступен Проверьте доступность прокси, используйте fallback на другой прокси
407 Proxy Authentication Required Неверные учётные данные Проверьте username/password, убедитесь что IP Lambda разрешён в whitelist прокси
502 Bad Gateway Прокси не может подключиться к целевому сайту Сайт может блокировать прокси, попробуйте другой IP или тип прокси

Реализация retry логики с fallback

Добавьте автоматические повторные попытки с переключением на резервный прокси при ошибках: 

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(`Attempt ${attempt + 1} failed:`, error.message);
      
      // Не retry на клиентских ошибках (4xx)
      if (error.response && error.response.status < 500) {
        throw error;
      }
      
      // Последняя попытка — пробрасываем ошибку
      if (attempt === maxRetries - 1) {
        throw error;
      }
      
      // Экспоненциальная задержка перед 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 }) };
  }
};

Эта реализация даёт три попытки запроса: первая через основной прокси, остальные через резервный. Между попытками добавлена экспоненциальная задержка (1 сек, 2 сек, 4 сек), чтобы не создавать излишнюю нагрузку.

Мониторинг и алерты

Настройте мониторинг ошибок прокси через CloudWatch (AWS), Vercel Analytics или Sentry. Отслеживайте метрики:

  • Процент успешных запросов через прокси (должен быть >95%)
  • Средняя latency запросов (рост может указывать на проблемы с прокси)
  • Количество timeout ошибок (если >5% — прокси перегружен или медленный)
  • Распределение ошибок по кодам (407, 502, ETIMEDOUT и т.д.)

Настройте алерты при превышении порогов — это позволит оперативно переключиться на резервного прокси-провайдера или изменить конфигурацию.

Заключение

Интеграция прокси в serverless приложения решает критические проблемы: блокировки по IP дата-центров, rate limiting и геоблокировки. Мы рассмотрели настройку прокси в AWS Lambda (Node.js и Python), Vercel Functions и Cloudflare Workers, а также реализацию ротации IP-адресов и обработку ошибок.

Ключевые рекомендации: используйте резидентные прокси для задач, требующих высокой анонимности (парсинг, работа с API социальных сетей), храните учётные данные в защищённых хранилищах (AWS Secrets Manager, Vercel Environment Variables), реализуйте retry логику с fallback на резервные прокси и настройте мониторинг ошибок.

Для serverless приложений с высокими требованиями к стабильности рекомендуем использовать резидентные прокси с автоматической ротацией — они обеспечивают оптимальный баланс между скоростью, анонимностью и надёжностью, минимизируя риск блокировок при работе с внешними API и сервисами.