Прокси в Google Colab и Jupyter для парсинга: настройка

Google Colab и Jupyter Notebook — удобные инструменты для быстрого написания и запуска скриптов парсинга без установки Python на локальную машину. Но у облачных ноутбуков есть особенность, о которой часто забывают: все запросы идут с IP-адресов дата-центров Google, которые давно известны антибот-системам и банятся почти мгновенно. В этой статье разберём, как правильно подключить прокси в Colab и Jupyter, какие ограничения накладывает облачная среда и как выстроить парсинг так, чтобы он не падал после первых 50 запросов.

Почему Google Colab банят чаще, чем обычный ПК

Главная проблема Colab для парсинга — это общий пул IP-адресов. Каждый раз, когда вы запускаете ноутбук, Google выделяет виртуальную машину с IP из своих облачных диапазонов (AS15169 и похожие). Эти диапазоны давно внесены в черные списки большинства антибот-систем: Cloudflare, DataDome, PerimeterX, а также встроенная защита Wildberries, Ozon и маркетплейсов распознают их за доли секунды. Запрос даже не доходит до сайта — его отсекает фильтр по ASN (Autonomous System Number) ещё до проверки User-Agent или поведения.

Вторая причина — массовость использования. Тысячи разработчиков одновременно гоняют парсеры, боты и ML-скрипты через Colab, поэтому репутация этих IP у многих целевых сайтов уже «сожжена» задолго до вашего запроса. Даже если вы делаете один аккуратный GET-запрос раз в 10 секунд, сайт может вернуть 403 просто потому, что с этого же диапазона час назад кто-то долбил сервер в 500 потоков.

Третья причина — Jupyter, запущенный локально, этой проблемы обычно не имеет (если у вас обычный домашний или офисный IP), но стоит начать работу через JupyterHub на сервере хостинга или в контейнере облачного провайдера — ситуация становится такой же, как в Colab. Поэтому вопрос «прокси нужны или нет» для облачных ноутбуков решается однозначно: без них парсинг практически не работает дальше первых нескольких запросов.

Какой тип прокси подходит для облачного парсинга

Выбор типа прокси зависит от того, что именно вы парсите и насколько агрессивна защита целевого сайта. Для Colab и Jupyter важно учитывать ещё один нюанс: сессия ноутбука ограничена по времени, поэтому долгоживущие sticky-сессии прокси не всегда критичны — чаще важна стабильность подключения именно в рамках одного запуска.

Тип прокси	Когда использовать в Colab/Jupyter	Особенности
Прокси дата-центров	Парсинг сайтов без жёсткой защиты, открытые API, статичные страницы	Высокая скорость, низкая цена, но тоже могут банить по ASN на агрессивных сайтах
Резидентные прокси	Парсинг Wildberries, Ozon, Avito, Google, соцсетей с антибот-защитой	IP реальных пользователей, редко попадают в черные списки, выше задержка
Мобильные прокси	Парсинг мобильных версий сайтов, TikTok, Instagram через API	Самый высокий траст, но дороже и медленнее ротация

Для большинства задач парсинга маркетплейсов и поисковых систем из Colab оптимальным балансом будет связка из резидентных прокси с ротацией по каждому запросу — это снижает вероятность бана по поведенческому паттерну, даже если сам запрос выполняется из облачной среды Google.

Настройка прокси в requests и urllib

Базовая настройка прокси в Colab ничем не отличается от локального Python-окружения. Разница только в том, что в Colab библиотеки обычно нужно доустановить через !pip install, так как стандартный образ не всегда содержит всё необходимое.

!pip install requests

import requests

proxy = {
    "http": "http://login:[email protected]:9000",
    "https": "http://login:[email protected]:9000"
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

response = requests.get(
    "https://example.com/catalog",
    proxies=proxy,
    headers=headers,
    timeout=15
)

print(response.status_code)
print(response.text[:500])

Важный момент: в Colab нет постоянного файла конфигурации, поэтому логин и пароль прокси приходится либо хардкодить (что небезопасно при публикации ноутбука), либо хранить в переменных окружения Colab через google.colab.userdata, либо подключать через Colab Secrets. Это удобнее, чем хранить пароль прямо в коде, особенно если вы делитесь ноутбуком с коллегами.

from google.colab import userdata

proxy_login = userdata.get('PROXY_LOGIN')
proxy_pass = userdata.get('PROXY_PASS')

proxy_url = f"http://{proxy_login}:{proxy_pass}@gate.proxycove.com:9000"
proxies = {"http": proxy_url, "https": proxy_url}

Прокси с Selenium и headless Chrome в Colab

Если сайт рендерит контент через JavaScript (типичная ситуация для Wildberries, Ozon, Avito), простого requests недостаточно — нужен headless-браузер. В Colab это обычно Selenium с Chromium, который нужно установить вручную, так как в базовом образе его нет.

!apt-get update
!apt install chromium-chromedriver
!pip install selenium

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument('--disable-dev-shm-usage')
chrome_options.add_argument('--proxy-server=http://gate.proxycove.com:9000')

driver = webdriver.Chrome(options=chrome_options)
driver.get("https://example.com/catalog")
print(driver.page_source[:500])
driver.quit()

Проблема в том, что флаг --proxy-server не поддерживает авторизацию логином и паролем напрямую. Для прокси с аутентификацией в Selenium нужно либо использовать IP-авторизацию (whitelisting по статичному IP ноутбука, что в Colab нестабильно, так как IP машины меняется при каждом новом запуске), либо генерировать расширение Chrome «на лету» с прописанными учётными данными прокси, либо использовать прокси-туннель через библиотеку вроде selenium-wire, которая поддерживает authenticated proxy из коробки.

!pip install selenium-wire

from seleniumwire import webdriver

proxy_options = {
    'proxy': {
        'http': 'http://login:[email protected]:9000',
        'https': 'http://login:[email protected]:9000',
    }
}

driver = webdriver.Chrome(seleniumwire_options=proxy_options, options=chrome_options)
driver.get("https://example.com/catalog")

Jupyter Notebook: локально vs в облаке

Jupyter Notebook, запущенный на локальной машине (через Anaconda или напрямую через pip), использует ваш домашний или офисный IP-адрес — и в этом случае прокси нужны только для маскировки или обхода гео-ограничений, а не для спасения от бана по ASN дата-центра. Настройка в этом случае полностью идентична обычному Python-скрипту: тот же requests, тот же Selenium, без ограничений на установку драйверов и системных пакетов.

Ситуация меняется, если вы используете Jupyter через облачный сервис: JupyterHub на VPS, Kaggle Notebooks, Deepnote, Binder или корпоративный облачный кластер. В этих случаях IP снова принадлежит дата-центру провайдера, и все проблемы Colab актуальны один в один. Главное отличие от Colab — у таких сервисов часто более стабильный IP на протяжении сессии (не меняется при каждом перезапуске ядра), что упрощает настройку whitelisting по IP, если ваш прокси-провайдер это поддерживает.

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

Ограничения облачных ноутбуков, которые ломают парсинг

Помимо проблем с репутацией IP, у Google Colab есть ряд технических ограничений, которые напрямую влияют на стабильность парсинга:

Таймаут неактивности. Бесплатная версия Colab отключает ноутбук после ~90 минут простоя и принудительно завершает сессию через 12 часов непрерывной работы — долгий парсинг тысяч страниц нужно разбивать на части или сохранять промежуточные результаты на Google Drive.
Смена IP при каждом новом раннтайме. Если вы отключили и заново подключили среду выполнения, IP-адрес виртуальной машины меняется — это ломает любую настройку с whitelisting по IP на стороне прокси-сервиса.
Ограничение на исходящие соединения. Google ограничивает количество одновременных сетевых подключений с одной виртуальной машины, поэтому агрессивная многопоточность с десятками параллельных запросов может упираться не в блокировку сайта, а в лимиты самого Colab.
Нет персистентного хранилища без монтирования диска. Куки, сессии браузера и кэш прокси-соединений пропадают при каждом перезапуске — для парсинга с авторизацией нужно явно сохранять cookies в файл на Google Drive.
Непредсказуемые задержки сети. Облачная инфраструктура Google иногда даёт скачки латентности, из-за которых таймауты запросов нужно ставить с запасом (15-30 секунд вместо стандартных 5-10).

Эти ограничения делают Colab отличным инструментом для разработки и отладки логики парсера, но плохо подходящим для длительных продакшн-задач — для них лучше переносить готовый скрипт на VPS или выделенный сервер с собственным IP.

Ротация прокси и обработка ошибок в цикле

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

import requests
import time
import random

proxy_pool = [
    "http://login:[email protected]:9000",
    "http://login:[email protected]:9001",
    "http://login:[email protected]:9002",
]

def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries):
        proxy_url = random.choice(proxy_pool)
        proxies = {"http": proxy_url, "https": proxy_url}
        try:
            response = requests.get(url, proxies=proxies, timeout=20)
            if response.status_code == 200:
                return response
            else:
                print(f"Попытка {attempt+1}: статус {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"Попытка {attempt+1}: ошибка {e}")
        time.sleep(random.uniform(2, 5))
    return None

result = get_with_retry("https://example.com/catalog")
if result:
    print(result.status_code)
else:
    print("Все попытки исчерпаны")

Для парсинга больших каталогов (например, тысяч карточек товаров на Wildberries) эту логику дополнительно оборачивают в очередь задач с паузами между запросами и сохранением промежуточных результатов в CSV или базу данных прямо в Google Drive, чтобы не терять прогресс при обрыве сессии Colab.

Чек-лист перед запуском парсера в Colab

Прокси подключены и протестированы отдельным тестовым запросом перед основным циклом
Логин и пароль прокси хранятся в Colab Secrets, а не в открытом коде
Для JS-сайтов используется Selenium с selenium-wire или прописанным расширением авторизации
В коде есть retry-логика и ротация прокси при ошибках 403/429
Промежуточные результаты сохраняются на Google Drive каждые N записей
Таймауты запросов увеличены с учётом возможных задержек облачной сети
Параллельность запросов ограничена, чтобы не упереться в лимиты исходящих соединений Colab
Для продакшн-задач предусмотрен перенос скрипта на отдельный сервер с постоянным IP

Заключение

Google Colab и облачный Jupyter отлично подходят для быстрой разработки и тестирования логики парсера, но из-за общих IP дата-центров почти всегда требуют прокси уже на первых шагах. Для простых сайтов без агрессивной защиты хватит прокси дата-центров, а для парсинга маркетплейсов, поисковых систем и соцсетей надёжнее работают резидентные и мобильные IP, которые реже попадают под фильтры по ASN.

Если вы планируете регулярный мониторинг цен на Wildberries или Ozon прямо из Colab, рекомендуем начать с резидентных прокси — они дают стабильный доступ без частых блокировок, а для разовых тестовых скриптов можно обойтись более бюджетными прокси дата-центров, подключив их по той же схеме через requests или Selenium.