Прокси для нейросетей и ChatGPT: API, интеграции и гео-тесты

У крупных AI-сервисов есть списки поддерживаемых стран, разные тарифы для регионов и защита от автоматических злоупотреблений. Например, у OpenAI в справочном центре опубликован список стран и территорий, из которых доступны ChatGPT и API, а запрос из неподдерживаемого места получает ошибку unsupported_country_region_territory с HTTP-статусом 403. Сервис смотрит, откуда пришёл запрос, и это напрямую касается серверной инфраструктуры компании.

Отсюда несколько вполне рабочих задач, в которых прокси экономят время инженеров:

• Постоянный исходящий адрес для API. Бэкенд в облаке может менять внешний IP после перезапуска или переезда, а адрес облачного провайдера иногда определяется геобазами не в той стране. Прокси с фиксированным IP делает картину предсказуемой.
• Белые списки IP. Корпоративные шлюзы, внутренние API и некоторые платформы разрешают доступ только с перечисленных адресов. Один статический прокси проще внести в список, чем десяток плавающих адресов разработчиков.
• Проверка продукта из стран клиентов. Как отвечает ваш чат-бот пользователю из Германии, на каком языке приходит интерфейс, какие функции видит клиент в Казахстане, корректно ли работают региональные ограничения в самом продукте.
• Разделение окружений. Трафик тестового стенда, нагрузочных тестов и продакшена удобно выпускать через разные адреса, чтобы проще читать логи и не путать лимиты.
• Сбор открытых данных для обучения и RAG. Парсинг документации, каталогов и новостей для собственной базы знаний: здесь прокси нужны по тем же правилам, что и для любого парсинга.

Распространённое заблуждение: «поменял IP, и сервис думает, что я в другой стране». На практике регион складывается из нескольких сигналов, и IP среди них только один.

Вывод практический: прокси нужен, чтобы исходящий адрес совпадал с тем, что и так соответствует действительности, а не противоречил ему. Если аккаунт компании зарегистрирован на европейское юрлицо и оплачивается европейской картой, разумно, чтобы и серверы ходили в API с европейского адреса, а не с адреса облака, который геобаза относит к другой стране.

Запросы к языковым моделям лёгкие по трафику, но чувствительны к стабильности: обрыв соединения посреди потокового ответа ломает пользовательский сценарий. Поэтому для постоянной работы выбирают статические адреса, а ротацию оставляют для проверок и сбора данных.

• Задача

  Если сервер ходит в API постоянно

  Выбор

  Берите ISP-прокси нужной страны: статический адрес из подсети провайдера и скорость дата-центра. Подходит для продакшена и белых списков.

  Смотреть: Если сервер ходит в API постоянно
• Задача

  Если нужен недорогой фиксированный IP для скриптов

  Выбор

  Индивидуальный IPv4: адрес только ваш на весь срок, HTTP(S) и SOCKS5, удобен для тестовых стендов и внутренних инструментов.

  Смотреть: Если нужен недорогой фиксированный IP для скриптов
• Задача

  Если нужно посмотреть продукт из десятка стран

  Выбор

  Резидентские прокси с оплатой за гигабайты и выбором страны: разовые проверки без аренды отдельного IP в каждой стране.

  Смотреть: Если нужно посмотреть продукт из десятка стран
• Задача

  Если собираете данные для базы знаний

  Выбор

  Пакет общих или индивидуальных IPv4 под парсер, а для защищённых сайтов резидентская ротация.

  Смотреть: Если собираете данные для базы знаний

Мобильные прокси для этих задач обычно избыточны: они дороже, а адрес меняется по ссылке или по решению оператора, что для серверной интеграции скорее минус. Подробнее о том, чем отличаются типы адресов, читайте в статье серверные, ISP, резидентские и мобильные прокси.

Страна выбирается не по принципу «где дешевле», а по тому, где реально находится бизнес-контекст запроса.

• Интеграция продакшена. Страна, где зарегистрирован аккаунт компании у AI-провайдера и где работают ваши серверы. Часто это США, Германия или Нидерланды.
• Тестирование для клиентов. Страны вашей аудитории. Если продукт продаётся в Казахстане, проверяйте его с адреса Казахстана, если в Европе, то из нескольких европейских стран.
• Задержка. Чем ближе прокси к серверу, который делает запрос, и к дата-центру провайдера модели, тем меньше добавочная задержка. Для потоковых ответов разница в десятки миллисекунд на каждый запрос заметна.

Большинство SDK и HTTP-клиентов умеют работать через прокси без доработки кода: достаточно переменных окружения или параметра клиента.

1. 01

   Купите статический адрес

   ISP или индивидуальный IPv4 нужной страны на минимальный срок, чтобы проверить связку. В течение 24 часов неподходящий адрес можно бесплатно заменить.

2. 02

   Проверьте адрес

   Убедитесь, что страна в геобазах совпадает с заказом, а соединение стабильно. Удобно сделать это в проверке прокси.

3. 03

   Пропишите прокси в окружении

   Для большинства клиентов на Python и Node.js достаточно переменной HTTPS_PROXY со строкой вида http://user:pass@ip:port. Секреты храните в менеджере секретов, а не в репозитории.

4. 04

   Включите таймауты и повторы

   Задайте таймаут соединения и чтения, а для ошибок сети предусмотрите повтор с паузой. Прокси добавляет ещё одно звено, и клиент должен переживать кратковременный сбой.

5. 05

   Внесите адрес в белые списки

   Если ваши внутренние сервисы или корпоративный шлюз ограничивают доступ по IP, добавьте туда адрес прокси.

6. 06

   Включите автопродление

   Адрес, внесённый в конфигурацию и белые списки, не должен закончиться в выходные. Автопродление с баланса снимает этот риск.

export HTTPS_PROXY="http://user:[email protected]:8080"

import httpx
client = httpx.Client(proxy="http://user:[email protected]:8080", timeout=60)
print(client.get("https://api.ipify.org").text)  # должен вывести IP прокси

Больше примеров с requests, aiohttp и SOCKS5 в статье прокси в Python. Если сервер с постоянным IP, можно отказаться от пароля и включить привязку по IP: разница описана в материале логин или привязка по IP.

Если ваш продукт сам построен на нейросети, проверять его из стран клиентов нужно так же, как обычный сайт, плюс несколько специфичных пунктов.

• Язык ответа. Определяет ли бот язык пользователя по локали браузера, по IP или по тексту вопроса, и не переключается ли он неожиданно.
• Региональные ограничения вашего продукта. Если какие-то функции по закону или по договору доступны только в определённых странах, проверьте, что ограничения срабатывают правильно.
• Скорость первого токена. Пользователь на другом континенте ждёт ответ дольше, и это стоит измерить, а не угадывать.
• Цены и валюта. Тарифы вашего сервиса, налоги и способы оплаты для страны клиента.
• Юридические тексты. Баннер cookie, согласие на обработку данных, ссылки на политику для нужной юрисдикции.

Для таких проверок не нужно держать статический адрес в каждой стране: удобнее пакет резидентских прокси с выбором страны и липкой сессией, чтобы адрес не менялся посреди диалога с ботом. Как работает липкая сессия, рассказано в статье ротация и sticky-сессии.

Отдельно про безопасность: через прокси проходит API-ключ и содержимое запросов, а это часто персональные данные клиентов. Пользуйтесь только адресами с понятным владельцем и HTTPS до конечного сервиса. Почему бесплатные списки здесь недопустимы, разобрано в статье опасность бесплатных прокси. Больше о сценарии на странице прокси для нейросетей и AI-сервисов.