Использование прокси в R: практическое руководство по httr2, rvest и residential-прокси

Что такое использование прокси в R и зачем это нужно

Если вы когда-нибудь пробовали собрать данные с сайта на R и получали HTTP 403 или пустую страницу вместо таблицы — вы уже столкнулись с тем, ради чего нужно использование прокси в R. Серверы фильтруют трафик по IP-адресам, и дата-центровые диапазоны (datacenter) часто оказываются в чёрных списках. Residential-прокси подменяют ваш IP на адрес реального домашнего провайдера, что делает запрос визуально неотличимым от обычного пользователя.

R прокси востребован у дата-сайентистов, аналитиков и исследователей, которые собирают публичные данные: цены, SERP-выдачу, отзывы, открытые таблицы. В этом руководстве мы разберём современный стек — httr2 для HTTP-запросов и rvest для парсинга — и покажем, как маршрутизировать трафик через ProxyHat residential-прокси с гео-таргетингом и sticky-сессиями.

Почему residential, а не datacenter: технический контекст

Антибот-системы (Cloudflare, PerimeterX, DataDome) классифицируют входящие IP по ASN и репутации. Дата-центровые блоки (AWS, DigitalOcean, OVH) помечаются как高风险 с высокой вероятностью — по данным Cloudflare, более 60% автоматического трафика с datacenter-IP блокируется на уровне WAF. Residential-прокси используют пулы IP, зарегистрированные за ISP уровня Comcast, Vodafone или Ростелеком, и поэтому проходят базовые проверки репутации.

Ключевые отличия:

Для веб-скрапинга в R, где цель — получить данные, а не минимизировать задержку, residential-прокси почти всегда оправдывают свою цену.

Современный R-стек: httr2 + rvest

Пакет httr2 (автор Hadley Wickham) — это современная замена httr, построенная на конвейерном API с request(), req_perform() и промежуточными слоями. rvest работает поверх httr2 (или httr) и предоставляет read_html(), html_elements() и html_table() для извлечения данных из HTML.

Установка:

install.packages(c("httr2", "rvest", "purrr", "tibble", "dplyr"))

Базовый запрос через прокси с req_proxy

Функция req_proxy() принимает хост, порт, имя пользователя и пароль. Для ProxyHat residential-прокси шлюз — gate.proxyhat.com, HTTP-порт — 8080.

library(httr2)
library(rvest)

# Базовый запрос через residential-прокси
req <- request("https://httpbin.org/ip") |> 
  req_proxy(
    url = "http://gate.proxyhat.com",
    port = 8080,
    username = "user-country-US",
    password = "YOUR_PASSWORD"
  ) |> 
  req_user_agent(
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
  )

resp <- req_perform(req)
body <- resp_body_string(resp)
cat(body)
# {"origin": "98.x.x.x"}  -- IP из пула residential США

Обратите внимание: флаги гео-таргетинга и сессий кодируются в имени пользователя, а не в URL. Это стандартный подход для backconnect-шлюзов.

Гео-таргетинг и sticky-сессии в имени пользователя

ProxyHat поддерживает гео-таргетинг по стране и городу, а также sticky-сессии для сохранения одного IP между запросами. Все флаги передаются в поле username.

Гео-таргетинг: страна и город

# Великобритания, Лондон
req_uk <- request("https://httpbin.org/ip") |> 
  req_proxy(
    url = "http://gate.proxyhat.com",
    port = 8080,
    username = "user-country-GB-city-london",
    password = "YOUR_PASSWORD"
  ) |> 
  req_user_agent("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)")

resp_uk <- req_perform(req_uk)
cat(resp_body_string(resp_uk))

Sticky-сессия для многостраничного сбора

Если сайт привязывает сессию к IP (например, для корзины или постраничной навигации), используйте флаг session-*:

# Sticky-сессия: один IP на всю цепочку запросов
session_id <- paste0("sess-", as.integer(Sys.time()))

req_sticky <- request("https://example.com/page/1") |> 
  req_proxy(
    url = "http://gate.proxyhat.com",
    port = 8080,
    username = paste0("user-session-", session_id, "-country-DE"),
    password = "YOUR_PASSWORD"
  ) |> 
  req_user_agent("Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101")

resp <- req_perform(req_sticky)

Сессия удерживает один IP до 30 минут. После истечения шлюз выдаёт новый адрес из того же гео-диапазона.

SOCKS5 на порту 1080

Для сценариев, где нужен SOCKS5 (например, обход DPI или совместимость с некоторыми клиентами), ProxyHat предоставляет порт 1080:

# SOCKS5 через ProxyHat
req_socks <- request("https://httpbin.org/ip") |> 
  req_proxy(
    url = "socks5://gate.proxyhat.com",
    port = 1080,
    username = "user-country-FR-city-paris",
    password = "YOUR_PASSWORD"
  )

resp_socks <- req_perform(req_socks)
cat(resp_body_string(resp_socks))

SOCKS5 полезен, когда целевой сайт блокирует HTTP CONNECT-туннели или когда вы работаете через корпоративный firewall с ограниченными протоколами.

Практический пример: пагинированная таблица в tidy data frame

Рассмотрим типичную задачу: собрать таблицу с нескольких страниц сайта, вращая сессии для каждой страницы и используя req_retry() и req_throttle() для устойчивости.

Мы используем purrr::map_dfr для безопасного объединения результатов, req_retry() для повторных попыток при 429/5xx и req_throttle() для ограничения частоты (например, 1 запрос в 2 секунды).

library(httr2)
library(rvest)
library(purrr)
library(dplyr)
library(tibble)

PROXY_USER <- "YOUR_USERNAME"
PROXY_PASS <- "YOUR_PASSWORD"

# Функция для одной страницы с вращением сессии
fetch_page <- function(page_num) {
  session_id <- paste0("pg", page_num, "-", as.integer(runif(1, 1, 1e6)))
  
  req <- request("https://example.com/table") |> 
    req_url_query(page = page_num) |> 
    req_proxy(
      url = "http://gate.proxyhat.com",
      port = 8080,
      username = paste0("user-session-", session_id, "-country-US"),
      password = PROXY_PASS
    ) |> 
    req_user_agent(
      "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
    ) |> 
    req_headers(
      Accept = "text/html,application/xhtml+xml",
      Accept-Language = "en-US,en;q=0.9"
    ) |> 
    req_retry(
      max_tries = 4,
      backoff = ~ 2 ^ (.x - 1),
      is_transient = function(resp) {
        status <- resp_status(resp)
        status == 429 || status >= 500
      }
    ) |> 
    req_throttle(0.5)  # не более 0.5 запросов/сек = 1 в 2 сек
  
  tryCatch({
    resp <- req_perform(req)
    html <- read_html(resp_body_string(resp))
    
    table_node <- html |> 
      html_elements("table.data-table") |> 
      html_table(convert = TRUE)
    
    if (length(table_node) > 0) {
      table_node[[1]] |> 
        as_tibble() |> 
        mutate(page = page_num)
    } else {
      tibble()
    }
  }, error = function(e) {
    message("Ошибка на странице ", page_num, ": ", conditionMessage(e))
    tibble()
  })
}

# Сбор 10 страниц
all_pages <- map_dfr(1:10, fetch_page)

# Результат
glimpse(all_pages)

Ключевые моменты этого паттерна:

• Вращение сессий — каждая страница получает уникальный session_id, поэтому IP меняется между страницами. Это снижает риск триггеров на «слишком много запросов с одного IP».
• req_retry с экспоненциальным backoff — при 429 или 5xx httr2 ждёт 1, 2, 4, 8 секунд перед повтором.
• req_throttle(0.5) — глобальное ограничение: не более одного запроса каждые 2 секунды.
• tryCatch — одна упавшая страница не обрушивает весь сбор.

JS-рендеринг: read_html_live() через тот же прокси

Многие современные сайты рендерят контент через JavaScript. rvest::read_html_live() использует chromote — headless Chrome — для выполнения JS. Прокси настраивается через параметры Chrome.

library(rvest)

# read_html_live() использует chromote (headless Chrome)
# Прокси передаётся через chromote_options

session_id <- paste0("live-", as.integer(Sys.time()))

# Настройка прокси для chromote
live_html <- read_html_live(
  "https://example.com/dynamic-table",
  chromote_options = list(
    # Chrome-флаги для прокси-аутентификации
    # chromote не поддерживает прямую прокси-аутентификацию,
    # поэтому используем расширение или локальный туннель
    # Альтернатива: использовать системную переменную
    args = c(
      "--proxy-server=http://gate.proxyhat.com:8080"
    )
  )
)

# Извлечение динамической таблицы
table_data <- live_html |> 
  html_elements("table.dynamic") |> 
  html_table()

print(table_data[[1]])

Важно: chromote не передаёт имя пользователя и пароль прокси напрямую через CLI-флаги Chrome. Для аутентифицированного прокси с read_html_live() используйте локальный туннель (например, mitmproxy или gost), который добавляет заголовок Proxy-Authorization, или настройте прокси на уровне ОС. Для production-сценариев с JS-рендерингом часто проще использовать ProxyHat SDK в связке с Playwright/Python и импортировать результат в R.

Реалистичные заголовки и User-Agent

Один из частых промахов — дефолтный User-Agent libcurl/x.x, который мгновенно маркируется как бот. Всегда задавайте реалистичный UA и заголовки:

req <- request("https://example.com") |> 
  req_user_agent(
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
  ) |> 
  req_headers(
    Accept = "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    `Accept-Language` = "en-US,en;q=0.9",
    `Accept-Encoding` = "gzip, deflate, br",
    Connection = "keep-alive",
    Upgrade = "1",
    `Sec-Fetch-Dest` = "document",
    `Sec-Fetch-Mode` = "navigate",
    `Sec-Fetch-Site` = "none"
  )

Production-паттерны: логирование, circuit breaker, параллелизм

Структурированное логирование

library(logger)
log_threshold(INFO)

fetch_with_logging <- function(url) {
  log_info("Запрос: {url}")
  start <- Sys.time()
  
  req <- request(url) |> 
    req_proxy(
      url = "http://gate.proxyhat.com",
      port = 8080,
      username = paste0("user-country-US-session-", 
                        as.integer(Sys.time())),
      password = PROXY_PASS
    ) |> 
    req_retry(max_tries = 3, backoff = ~ 2 ^ .x) |> 
    req_throttle(0.5)
  
  tryCatch({
    resp <- req_perform(req)
    elapsed <- as.numeric(difftime(Sys.time(), start, units = "secs"))
    log_info("Готово: {url} — статус {resp_status(resp)}, {round(elapsed, 2)}с")
    resp
  }, error = function(e) {
    log_error("Провал: {url} — {conditionMessage(e)}")
    NULL
  })
}

Параллельный сбор с future + furrr

library(furrr)
plan(multisession, workers = 4)

urls <- paste0("https://example.com/page/", 1:20)

results <- future_map(urls, fetch_page, .options = furrr_options(
  packages = c("httr2", "rvest"),
  seed = TRUE
))

При 4 воркерах и throttle 0.5 запросов/сек на воркер вы получаете ~2 запроса/сек суммарно — комфортная нагрузка для большинства сайтов.

Этика и соответствие требованиям

Веб-скрапинг — это инструмент, и его использование регулируется как техническими, так и правовыми рамками:

• robots.txt — проверяйте /robots.txt перед сбором. R может прочитать его напрямую: read_html("https://example.com/robots.txt").
• Условия использования (ToS) — некоторые сайты прямо запрещают автоматический сбор в ToS. Это не всегда юридически обязательно, но игнорирование может привести к блокировке аккаунта или судебным претензиям.
• GDPR — при сборе данных, содержащих персональные данные жителей ЕС (имена, email, IP), требуется правовое основание. См. официальный портал GDPR.
• Предпочитайте официальные API — если у сайта есть публичный API, используйте его. Это надёжнее, быстрее и юридически чище.
• Rate limiting — уважайте сервер. Не делайте больше запросов, чем необходимо, и используйте req_throttle().

ProxyHat SDK для смешанных пайплайнов

Если ваш пайплайн объединяет R и Python/Node.js, ProxyHat SDK обеспечивает единый интерфейс. Паттерн идентичен: шлюз gate.proxyhat.com, порт 8080 для HTTP и 1080 для SOCKS5, флаги в username. См. документацию ProxyHat для деталей SDK.

В R вы можете вызывать Python-скрипты через reticulate или системные вызовы, сохраняя единый пул прокси между языками. Это удобно, когда JS-рендеринг проще сделать в Playwright (Python), а обработку — в R.

Key Takeaways

• httr2::req_proxy() — основной способ маршрутизации R-запросов через ProxyHat residential-прокси на gate.proxyhat.com:8080.
• Гео-таргетинг и sticky-сессии кодируются в username: user-country-GB-city-london, user-session-abc123.
• req_retry() + req_throttle() — обязательная связка для production-сбора: backoff при 429/5xx и ограничение частоты.
• rvest::read_html_live() — для JS-рендеринга через headless Chrome; прокси-аутентификация требует локального туннеля.
• Residential > datacenter для скрапинга: 2–8% блокировок против 40–70%, ценой более высокой задержки.
• Этика: проверяйте robots.txt, соблюдайте ToS, GDPR для данных жителей ЕС, предпочитайте официальные API.

Готовы начать? Изучите тарифы ProxyHat, доступные локации и use-case для веб-скрапинга. Для SERP-трекинга см. соответствующий раздел.