Accept-Language, валюта и гео-cookie: чиним парсер

Парсер запускается, код не падает, данные приходят — но цены в долларах вместо рублей, текст на английском, а товары отличаются от тех, что видит живой пользователь из России. Это одна из самых частых и обидных проблем парсинга: технически всё работает, но контент «не тот». Разбираем, из-за чего это происходит и как собрать запрос, который получает именно ту версию страницы, которую вам нужно.

Симптомы: как понять, что парсер видит не ту версию

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

Язык контента не совпадает — вы ожидаете русский текст, а приходит английский или украинский вариант страницы.
Валюта и цены отличаются — сайт показывает цену в USD или EUR, хотя в браузере из России вы видите рубли, либо цифры просто другие (региональное ценообразование).
Каталог товаров/контента другой — доступность товаров, акции, витрина целиком зависят от региона, который сайт «увидел» у вас.

Причина почти всегда одна из трёх (или их комбинация): заголовок Accept-Language, отсутствующие или неверные cookie, либо геолокация IP-адреса, с которого идёт запрос. Разберём каждую по порядку.

Accept-Language: как сервер выбирает язык ответа

Браузер при каждом запросе отправляет заголовок Accept-Language, в котором перечислены предпочитаемые языки пользователя с весами (q-значения). Пример того, что реально отправляет Chrome с русской локалью:

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

Библиотеки для парсинга (requests, httpx, scrapy) по умолчанию либо вообще не отправляют этот заголовок, либо отправляют что-то вроде */*. Сервер в этом случае либо отдаёт язык по умолчанию (чаще английский), либо определяет язык по IP — и вот тут уже вступает в игру гео-часть, о которой ниже.

Важный нюанс: многие сайты используют именно комбинацию «Accept-Language + геолокация IP», а не что-то одно. То есть даже если вы отправите корректный заголовок языка, но запрос идёт с IP другой страны, сайт может всё равно переключить вас на английскую или локальную версию для того региона, откуда реально пришёл запрос.

Валюта и локаль: откуда сайт берёт цены

Валюта почти никогда не определяется заголовком Accept-Language напрямую. Чаще используется один из трёх механизмов (или их сочетание):

GeoIP-база — сервер смотрит, из какой страны пришёл IP, и подставляет соответствующую валюту и локаль автоматически при первом визите.
Cookie с ранее выбранным регионом — если пользователь когда-то вручную выбрал страну и валюту, сайт сохраняет это в cookie и больше не проверяет IP.
Параметр в URL или поддомен — некоторые площадки используют явные маркеры вроде ?country=ru или ru.example.com.

На практике, если вы парсите интернет-магазин и видите цены в долларах вместо рублей, в 80% случаев дело не в заголовках, а именно в IP-адресе запроса. Сайт просто «увидел» не российский IP и подставил дефолтную международную витрину.

После того как сайт один раз определил ваш регион (по IP или по ручному выбору на баннере «Выберите ваш город»), он сохраняет это решение в cookie — обычно с именами вроде region, geo_city, currency или locale. Дальше все запросы с этим cookie обрабатываются по сохранённому региону — даже если IP вдруг сменился.

Это создаёт ловушку для парсера: если вы один раз получили «не ту» версию и сохранили cookie сессии, все последующие запросы будут воспроизводить ту же ошибку, даже если вы исправите заголовки или прокси. Поэтому при диагностике всегда проверяйте парсинг с чистой сессией — без сохранённых cookie от прошлых запусков.

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

Роль IP-адреса и прокси в определении региона

GeoIP-определение — самый надёжный для сайта способ понять, откуда реально пришёл запрос, потому что заголовки и cookie можно подделать, а IP-адрес подделать нельзя (можно только заменить на другой реальный). Именно поэтому для стабильного получения «правильной» региональной версии страницы недостаточно одних HTTP-заголовков — нужен IP, который действительно принадлежит нужной стране.

Здесь есть существенная разница между типами IP-адресов:

IP дата-центров — GeoIP-базы часто определяют их верно по стране, но многие крупные сайты (особенно маркетплейсы и сервисы с защитой от ботов) помечают диапазоны дата-центров как подозрительные и могут показывать урезанную или дефолтную версию контента независимо от геолокации.
Резидентные IP — принадлежат реальным провайдерам и физическим адресам, поэтому GeoIP определяет регион точнее, а сайт воспринимает запрос как обычного пользователя из этой страны/города.
Мобильные IP — привязаны к мобильным операторам конкретной страны, что особенно важно для сайтов и приложений, которые по-разному работают с мобильным и десктопным трафиком.

Для задач вроде мониторинга цен на Wildberries, Ozon или Авито из конкретных городов лучше всего подходят резидентные прокси — они дают IP с привязкой к реальному региону, и GeoIP-базы сайтов определяют страну и город корректно, без подмены на дефолтную международную витрину.

Практика: собираем правильный запрос на Python

Соберём запрос, который одновременно решает все три проблемы: отправляет корректный Accept-Language, использует чистую сессию с нужными cookie и идёт через IP нужного региона.

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

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

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

Несколько важных моментов в этом коде:

Используется requests.Session(), а не одиночный requests.get(), чтобы при необходимости сервер мог установить дополнительные cookie, и они сохранялись между запросами одной сессии парсинга.
Значения cookie region и currency — условные, их реальные имена и значения нужно подсмотреть в DevTools браузера (вкладка Application → Cookies) на целевом сайте с нужной локацией.
Прокси должен реально находиться в нужной стране — иначе даже правильные заголовки и cookie могут быть перезаписаны сервером при повторном определении геолокации.

JS-сайты: Playwright и управление заголовками/cookie

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

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

Обратите внимание на параметр timezone_id — многие сайты дополнительно сверяют часовой пояс браузера с ожидаемым для региона, и расхождение (например, IP из России, а часовой пояс браузера — американский) само по себе может быть сигналом для антибот-системы, что запрос подозрительный, даже если язык и валюта формально верные.

Типичные ошибки и чек-лист перед запуском

Перед тем как запускать парсер в продакшен, пройдитесь по короткому чек-листу — это экономит часы отладки:

✅ Заголовок Accept-Language выставлен и соответствует ожидаемому региону.
✅ Сессия чистая — cookie не унаследованы от предыдущего неудачного запроса.
✅ IP прокси физически находится в нужной стране (проверьте через любой geo-IP чекер перед парсингом).
✅ User-Agent соответствует реальному браузеру и не содержит признаков headless-режима.
✅ Часовой пояс и локаль браузера (для Playwright/Selenium) совпадают со страной IP.
✅ Если сайт использует ручной выбор региона на баннере — cookie этого выбора передаются вручную.

Отдельно стоит сказать про ротацию прокси: если вы меняете IP на каждый запрос, а cookie сессии остаются теми же, сайт может увидеть несостыковку «cookie региона А, но IP региона Б» и сбросить сессию. Для задач мониторинга цен лучше закреплять один IP на всю сессию парсинга конкретного региона, а не ротировать его посреди сбора данных.

Какой тип прокси выбрать под задачу

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

Тип прокси	Точность геолокации	Когда использовать
Прокси дата-центров	Средняя, страна верна, но IP может помечаться как «не жилой»	Парсинг сайтов без строгой антибот-защиты, высокая скорость и объём запросов
Резидентные прокси	Высокая, вплоть до города	Мониторинг цен на маркетплейсах, региональный контент, обход GeoIP-проверок
Мобильные прокси	Высокая, плюс метка мобильного оператора	Сайты и приложения, по-разному работающие с мобильным трафиком конкретной страны

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

Заключение

Проблема «парсер видит не ту версию страницы» почти всегда складывается из трёх факторов: заголовка Accept-Language, который определяет предпочитаемый язык ответа; cookie, которые запоминают ранее выбранный регион и валюту; и геолокации IP-адреса, по которому сервер определяет страну запроса при первом визите. Чтобы получить именно ту версию сайта, которую видит живой пользователь, нужно синхронизировать все три параметра одновременно, а не чинить их по отдельности.

Если вы регулярно парсите региональные версии сайтов, мониторите цены конкурентов на маркетплейсах или собираете данные из разных стран, стоит начать именно с выбора подходящего IP — остальные настройки (заголовки, cookie, часовой пояс) достраиваются вокруг него. Для точного попадания в нужный регион рекомендуем попробовать резидентные прокси, которые дают предсказуемую геолокацию и минимизируют риск получить дефолтную международную версию сайта вместо локальной.