Отправка запросов
Отправляй HTTP-запросы через прокси — импорт/экспорт cURL, заголовки, куки и тело
Скрипт получает 403 или HTML, который не совпадает с тем, что ты видишь в браузере, и надо понять почему. Отправь ровно тот же запрос отсюда — со своими заголовками, куками и прокси — и посмотри сырой ответ, цепочку редиректов и имя анти-бот системы, которая ответила вместо сайта.
через Germany · datacenter · HTTP
:
:
Прокси Parsistent
Твои прокси
Добавь прокси в менеджере ниже
Один прокси на строку:
Как использовать
- 1Начни с запроса, который уже работает — Открой DevTools на странице, правый клик по запросу, Copy as cURL — и вставь на вкладку cURL. URL, метод, заголовки, куки и тело подставятся сами. Работают оба формата Chrome: bash и windows-вариант с кареткой. Заполнить поля руками тоже можно.
- 2Выбери, откуда уйдёт запрос — Используй встроенные прокси или добавь свои — HTTP, SOCKS4, SOCKS5, с авторизацией и без. Если сайт уже заблокировал один адрес, смена прокси часто и есть весь эксперимент.
- 3Отправь и прочитай ответ целиком — Код статуса, заголовки ответа, тело и вся цепочка 301/302. Если вместо сайта ответил Cloudflare, DataDome или PerimeterX — в результате будет его имя.
- 4Поменяй одно, отправь снова — User-Agent, одна кука, другой прокси — по одному изменению за раз. Разница между двумя ответами и есть ответ на вопрос, почему код блокируют, а браузер нет.
- 5Верни рабочий запрос в код — Вкладка cURL в любой момент собирает готовую команду из текущего состояния. Вставь её в Конвертер cURL и получи Python, Node, Go или PHP с теми же заголовками.
Примеры
Сайт отдаёт скрипту 403, а в браузере открывается
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36Отправь запрос без User-Agent, потом с настоящим. Если 403 превратился в 200, никакой защиты на сайте нет: всё портил заголовок по умолчанию у твоей HTTP-библиотеки.
Нужно понять, что стоит перед сайтом
GET https://example.com -> определено: DataDomeДо того как писать код, узнай, что за стена: Cloudflare, DataDome или PerimeterX. Они ведут себя по-разному, и от ответа зависит, хватит ли пары заголовков или понадобится настоящий браузер.
Приходит не тот HTML, который ты смотрел в браузере
GET https://example.com (в теле нет блока с ценой)Браузер выполнил JavaScript и собрал DOM, твой парсер этого не сделает. Здесь виден сырой ответ, ровно то, что получит код. Наткнуться на это лучше сейчас, чем после написания парсера.
Данных нет в HTML вообще
GET https://example.com/api/v1/items?page=2Страница подтягивает содержимое из JSON-эндпоинта. Скопируй этот запрос из вкладки Network, повтори здесь и проверь, работает ли он без кук — часто разбор HTML можно не делать вовсе.
Прокси работает на одном сайте и умирает на другом
socks5://user:pass@host:1080Тот же запрос, та же цель, другой прокси. У прокси есть репутация: адрес, заблокированный на одном сайте, проходит на другом, а текст ошибки говорит, чья сторона отказала. Проверить сразу весь список — Проверка прокси.
Copy as cURL работает, а твой Python нет
curl 'https://example.com' -H 'cookie: session=...' -H 'accept-language: ru-RU'Вставь рабочую команду сюда и отключай заголовки по одному. Тот, без которого запрос перестал проходить, и есть недостающий в коде.
Сессия умирает после первого запроса
Cookie: session_id=abc123; consent=1; ab_group=bРазверни заголовок Cookie в строки и выключай куки по одной. Обычно дело в одной куке согласия или региона, которую сайт молча требует.
Короткая ссылка скрывает, куда ведёт
GET http://bit.ly/xxxx (Follow redirects: включено)Посмотри всю цепочку 301/302 до конечного адреса со всеми промежуточными переходами — пригодится, когда парсер всё время оказывается не там, где ждёшь.
Когда использовать
Самый частый вопрос при написании парсера — «почему мой код получает не то, что я вижу в браузере». Настоящих ответов три: страница собирает содержимое через JavaScript, сайт отдаёт разное в зависимости от User-Agent или кук, либо вместо сайта ответила анти-бот система. Один запрос отсюда показывает, какой из трёх вариантов твой. Имя анти-бот системы — то, чего почти нигде больше не получить. Когда запрос перехватывает Cloudflare, DataDome или PerimeterX, ты обычно видишь безликий 403 без объяснений. Здесь в результате будет имя, и от него зависит следующий шаг: одну проходишь с User-Agent и сессионной кукой, другая смотрит на TLS-отпечаток, и подбор заголовков там бесполезен. Запросы уходят через прокси — встроенный или твой, — а не с твоего адреса. Дело не только в анонимности: половина проблем в парсинге живёт именно в прокси, и проверять запрос имеет смысл через тот же адрес, с которого пойдёт рабочий код. Чего инструмент не делает: он не выполняет JavaScript. Если содержимое появляется только после работы скриптов страницы, в сыром ответе его не будет, и никакая комбинация заголовков этого не изменит — нужен Playwright, Puppeteer или облачный браузер. Это тоже ответ, и получить его за один запрос лучше, чем после дня работы над парсером. Когда ответ на руках, следующий шаг — Тестер CSS-селекторов и Тестер XPath, чтобы вытащить из него данные.
Частые вопросы
Почему сайт отдаёт скрипту 403, а в браузере открывается нормально?›
Почти всегда одно из трёх. Твоя HTTP-библиотека отправляет собственный User-Agent (python-requests/2.31.0, axios, Go-http-client), а многие сайты такие запросы просто отклоняют. Сайту нужна кука, которую код не получал. Либо анти-бот система решила, что запрос автоматический. Отправь один и тот же запрос здесь с настоящим User-Agent и без него — если ответ меняется, причина найдена за один шаг. Если в результате появилось имя Cloudflare, DataDome или PerimeterX, это третий случай, и одних заголовков может не хватить.
Как узнать, какая анти-бот система стоит на сайте?›
Отправь на него любой запрос отсюда. Ответ сверяется с признаками Cloudflare, DataDome и PerimeterX: заголовки ответа, выставленные куки, характерные коды и маркеры в теле. Найденная система называется в результате. Это важно, потому что системы не равнозначны — одну обходят правильными заголовками за пять минут, другая читает TLS-рукопожатие, и обмануть её из браузерного инструмента нельзя вовсе.
Почему я вижу другой HTML, чем в браузере?›
Браузер выполняет JavaScript и достраивает DOM после загрузки. Здесь возвращается сырой HTTP-ответ — те же байты, которые получит твой парсер на Python или Node. Если содержимое вставляют скрипты, в сыром ответе его нет и не будет. Проверь, не приходят ли данные из JSON-эндпоинта: открой вкладку Network, отфильтруй по Fetch/XHR — повторить такой запрос здесь обычно проще и надёжнее, чем разбирать HTML.
Запрос работает в DevTools, а в коде нет — в чём разница?›
Возьми Copy as cURL из DevTools, перенеси сюда и отправь без изменений. Если здесь работает, разница в заголовках, которые код не отправляет: чаще всего это Accept-Language, Referer, сессионная кука или кука согласия, реже Accept-Encoding. Убирай заголовки по одному, пока не сломается — последний убранный и есть недостающий. Потом выгрузи рабочий запрос обратно в cURL и переведи его в код через Конвертер cURL.
Как понять, сломан прокси или меня блокирует сайт?›
Сбой классифицируется по тому, установилось ли соединение с прокси, а не по времени: время обманывает — мёртвый прокси может падать восемь секунд и выглядеть в точности как медленный сайт. Если соединение с прокси не установилось, в сообщении будет сказано, что виноват прокси; если установилось, а цель потом отказала или разорвала связь — будет сказано это. Чтобы проверить сразу весь список, а не по одному, используй Проверку прокси.
Инструмент отправляет запросы с моего IP?›
Нет. Запросы всегда идут через прокси: по умолчанию встроенные, либо твои, добавленные в менеджере прокси. Целевой сайт твоего адреса не видит, поэтому домашний или рабочий IP не попадёт в чёрные списки, даже если проверяешь сайт, который блокирует жёстко.
В каком формате добавлять свои прокси?›
Формат URI: http://host:port, http://user:pass@host:port, socks5://host:port, socks5://user:pass@host:port, socks4:// точно так же. Строка вида host port user pass тоже работает — по одному прокси на строку. Все принимаемые форматы с примерами перечислены в окне «Формат» в менеджере прокси.
Можно ли импортировать cURL-команду и какие флаги распознаются?›
Да — вставь её на вкладку cURL и нажми «Заполнить поля». Распознаются: URL (первый аргумент или --url), -X/--request, -H/--header, -d/--data/--data-raw/--data-binary/--data-ascii, --data-urlencode, -F/--form (multipart упрощается до сырого тела, с предупреждением), -b/--cookie, -u/--user, -A/--user-agent, -e/--referer. Игнорируются --compressed, -k, -L, -s, -i, -v и -x/--proxy, потому что у инструмента свой выбор прокси. Тип тела — JSON, Form или Raw — определяется по Content-Type или по самому телу.
Можно ли получить cURL обратно из своего запроса?›
Да. Вкладка cURL показывает готовую команду, которая пересобирается на лету из текущего URL, метода, заголовков, кук и тела, рядом кнопка копирования. Свой прокси подставляется через -x; встроенные прокси работают на сервере и намеренно в команду не попадают, поэтому скопированная команда работает где угодно и не раскрывает их.
Как подставить прокси в cURL-команду?›
Через -x: curl -x http://user:pass@host:port 'https://target' для HTTP или -x socks5://user:pass@host:port для SOCKS5. Если нужно, чтобы DNS резолвился на стороне прокси, а не на твоей, пиши socks5h:// — одна эта разница объясняет часть случаев, когда прокси работает в одном инструменте и не работает в другом.
Как передать куки в запросе?›
Добавь заголовок Cookie — например Cookie: session_id=abc123; user_pref=dark, скопированный из DevTools во вкладке Network в разделе Request Headers. Дальше этот заголовок можно развернуть в отдельные строки и включать, править или удалять каждую куку по отдельности; отправляются только включённые. Это самый быстрый способ найти, какая именно кука сайту нужна.
Почему запрос завершается по таймауту?›
Таймаут — 15 секунд. Так заканчиваются медленные цели, намеренно задержанные ответы и мёртвые прокси. Сначала повтори через другой прокси: если ответ пришёл сразу, дело было в прокси; если на том же адресе виснут все прокси, цель не медленная, а просто не отвечает.