Эта статья не о том, что Puppeteer - плохой инструмент. Это отличный инструмент. Как и curl. И грамотный TLS-фингерпринтинг через uTLS вынесет большинство защит. Но есть класс задач, где даже идеальный сетевой стек не спасает - потому что детект давно вышел за пределы HTTP-заголовков и приземлился на уровень поведения рендеринг-движка. Разберём, где именно проходит эта граница.
Лет пять назад антифрод жил на сетевом уровне: смотрел на IP-репутацию, сверял User-Agent и проверял Referer. Сегодня Cloudflare, Akamai и DataDome работают в несколько эшелонов:
L1 — Сеть: IP-репутация, ASN, JA3/JA4-отпечаток TLS-рукопожатия, MTU/TTL пакетов.
L2 — Браузер/Runtime:
navigator.webdriver, WebGLRENDERER/VENDOR, Canvas-хеш, перечисление шрифтов черезdocument.fonts, AudioContext fingerprint, navigator.hardwareConcurrency & deviceMemory: Браузер честно сообщает количество CPU-ядер и объём RAM. Серверный Chromium на VPS с одним vCPU и 512 МБ памяти моментально отличается от ноутбука пользователя (8 ядер, 16 ГБ). В облачном профиле эти значения синхронизированы с легендой железа.L3 — Поведение: Движение мыши, динамика зажатия клавиш, скролл-паттерны, тайминги XHR-запросов. Наиболее агрессивная реализация L3 это Akamai sensor data: обфусцированный JS-бандл (~150 КБ), который собирает 50+ поведенческих сигналов (акселерометр, давление на тач, отклонение движения мыши от прямой) и отправляет зашифрованный blob на /akam/11/... до любого целевого запроса. Декодировать его вручную — отдельная дисциплина.
L4 — Пассивный сетевой анализ: HTTP/2 fingerprint (порядок заголовков HEADERS-фрейма, значения SETTINGS, размер окна), TCP-стек (размер буфера, опции SYN-пакета). Akamai Bot Manager строит отпечаток именно на этом уровне — до того, как браузер отправил первый байт JavaScript.
Пробить L1 на чистом curl с правильным uTLS это реально. Пробить L2-L3 без полноценного браузера — уже нет. Именно здесь заканчивается сфера применения «чистых» инструментов и начинается область облачных браузеров (BaaS).
Архитектура подключения: От скрипта до цели
В классической схеме ваш сервер сам делает запросы, борется с TLS-отпечатками и пытается не «протечь» по WebRTC. В схеме с облачным браузером ваш код это просто пульт управления. Сами «боевые действия» происходят в облаке, где развернута полностью управляемая инфраструктура браузеров.
Искать BaaS-решения меня заставила конкретная стена. Локальный Playwright с резидентными прокси перестал проходить L2-детекты: Canvas-хеш «светился» несоответствием железа, WebGL RENDERER выдавал серверную виртуалку, а поведенческий трек был слишком «ровным». Stealth-плагины латали симптомы, а не причину. Нужен был инструмент, где браузерный контекст формируется с нуля на правильном железе, а не патчится поверх. В этот момент и попался NodeMaven Scraping Browser не как рекомендация, а как один из немногих сервисов с нормальной CDP-документацией.
Где локальный стек упирается в потолок?
Главная боль локальной автоматизации это Leakage (утечки). Даже при использовании резидентских прокси реальный отпечаток «железа» часто протекает сквозь патчи Puppeteer.
Hardware Fingerprinting: Сайты просят браузер отрисовать сложную 3D-фигуру через WebGL. То, как видеокарта обрабатывает тени и сглаживание, уникально. Облачные браузеры маскируют эти метаданные, отдавая валидные, но подмененные данные реального железа.
Синхронизация стека: Антифрод видит несоответствие между вашим IP (домашний провайдер) и параметрами MTU/TTL вашего сервера в дата-центре. В BaaS-решениях прокси-слой и браузер синхронизированы на уровне инфраструктуры.
Ресурсоемкость: Запуск 50 окон Chrome локально «положит» средний VPS. Облако позволяет открывать сессии параллельно (масштабирование ограничено лишь тарифом), так как рендеринг JS и обработка DOM происходят на стороне провайдера.
Анатомия сессии: Что под капотом?
При формировании строки подключения вы собираете «личность» своего бота. В параметрах URL указывается всё: от ГЕО до времени жизни сессии (sid) и уникального профиля отпечатка (pid).
// Пример подключения через Playwright const { chromium } = require("playwright"); (async () => { const endpoint = "wss://user_country-us_sid-888:pass@browser.nodemaven.com"; const browser = await chromium.connectOverCDP(endpoint); const page = await browser.newPage(); await page.goto("https://target-website.com"); // Вся нагрузка на CPU — в облаке, у вас только результат await browser.close(); })();
Практическая проверка: «Детектор лжи»
Для проверки реального качества пула взял экзотическое ГЕО — Фиджи (Vodafone). Логика простая: если провайдер подмешивает дешёвые дата-центровые IP, экзотика это покажет быстрее, чем условный US/DE.
Прогнал через три независимых публичных чекера: Scamalytics, IPQualityScore и Pixelscan. Смотрел конкретно: Fraud Score (репутация IP), тип соединения (ISP/datacenter/mobile), наличие утечек DNS и WebRTC.
Результаты оказались ожидаемо чистыми для мобильного канала: Fraud Score на уровне 0–2 по Scamalytics, тип соединения определился как ISP/Mobile (Vodafone Fiji Limited), DNS и WebRTC без утечек. Это не значит «идеальный IP» — это значит, что адрес не засвечен в известных базах спама и ведёт себя как реальный абонент.
Тип соединения: ISP/Mobile. Независимые базы подтверждают статус реального домашнего абонента.
DNS & WebRTC: Утечек нет. DNS-серверы соответствуют региону IP, WebRTC не «палит» реальный адрес сервера.
Параметр | Результат | Инструмент |
Fraud Score | 2/100 (Scamalytics) | Scamalytics |
Fingerprint | Consistent | Pixelscan |
Latency | ~150-250ms (для WSS) | Custom ping |
Когда стоит переплачивать за BaaS?
Облачный браузер — это не волшебная палочка, это инструмент оптимизации ресурсов и обхода L2-L3 защиты. В моих сценариях BaaS оказался дороже обычных прокси по прямым расходам, но дешевле по времени поддержки: не нужно постоянно чинить stealth-патчи и админить отдельный серверный парк под десятки Chromium-экземпляров. Это не универсальное решение, а вариант, который имеет смысл, когда упираешься именно в L2–L3-детекты.
Анатомия Scraping Browser: WSS, автоскейлинг и реальные задержки
Когда вы работаете с обычным Puppeteer локально, библиотека запускает экземпляр Chromium прямо у вас в системе. Это съедает сотни мегабайт RAM на каждую вкладку. В случае со Scraping Browser взаимодействие переходит на уровень протокола WSS (WebSocket Secure).
Разбор подключения по WebSocket
Вместо запуска процесса chrome.exe, ваш скрипт инициирует защищенное соединение с удаленным эндпоинтом. Это не просто HTTP-запрос «отправил-получил». WSS создает постоянный двусторонний канал связи. Это критически важно для CDP (Chrome DevTools Protocol) — через него ваш Playwright или Puppeteer посылает команды (кликни, введи текст, подожди селектор) и получает события обратно в реальном времени.
Нюанс, который не пишут в документации: сам факт CDP-подключения потенциально детектируем. Некоторые сайты проверяют, открыт ли порт --remote-debugging-port, через window.chrome.runtime и нестандартные свойства объекта performance. Scraping Browser решает это изоляцией — CDP-туннель существует только между вашим скриптом и облаком, целевой сайт видит чистый Chromium без отладочных артефактов.
Строка подключения как конфиг
Самое интересное зарыто в самом URL. Это не просто адрес, а полноценный конфигурационный файл в одну строку:
wss://{user}_country-us_sid-888_pid-123:{pass}@browser.nodemaven.com
Меняя параметры, вы на лету переключаете ГЕО или привязываете сессию к конкретному IP без перезапуска кода:
country-us: Принудительный подъем браузера с американским «железом» и IP.sid(Session ID): Любая случайная строка превращает сессию в «липкую» (Sticky). Пока вы используете один и тот жеsid, вы сидите с одного IP, что критично для логина или работы с корзиной.pid(Profile ID): Уникальный отпечаток (фингерпринт). Сайт будет «узнавать» вас как старого знакомого, даже если вы зашли через неделю.
Преимущество: Unlimited concurrent sessions
Главная фишка облака — автоскейлинг. Поскольку весь рендеринг DOM, выполнение тяжёлого JavaScript и обработка графики происходят на стороне провайдера, нагрузка на ваш локальный CPU и RAM стремится к нулю.
Вы можете запустить хоть 100, хоть 500 параллельных сессий с обычного ноутбука. Инфраструктура сама распределяет ресурсы, поднимая новые инстансы браузеров под ваш запрос. Для антифрод-систем это выглядит как сотни разных пользователей, зашедших с разных устройств, хотя управляются они из одного скрипта.
Важный нюанс про сетевой стек
Здесь часто возникает заблуждение: «нулевая нагрузка» означает нулевую нагрузку на CPU/RAM вашего сервера — рендеринг действительно происходит в облаке. Но если вы тянете 500 потоков с сайтов, которые грузят картинки, видео и рекламные скрипты, ваш сетевой канал всё равно должен переваривать входящий поток данных через WSS.
Решение простое: используйте page.route() в Playwright (или его аналог в Puppeteer) для блокировки ненужных ресурсов прямо на стороне облачного браузера, ещё до передачи данных вам:
await page.route('**/*.{png,jpg,jpeg,gif,svg,mp4,webp,woff2}', r => r.abort()); await page.route('**/{ads,analytics,tracking}/**', r => r.abort());
Это экономит и ваш трафик, и пропускную способность канала особенно критично при работе с медиатяжёлыми сайтами вроде TikTok.
Прощай, перегрев: Время админа, а не такты процессора
Часто можно услышать: «Один экземпляр Chromium отъедает ОЗУ, облако экономит ваш CPU». Инженер ответит: «И что? У меня сервак на 64 ядра, мне не жалко CPU, мне важен профит».
Правда в другом. Перенос рендеринга на сторону BaaS экономит время системного администратора и разработчика, а не просто аппаратные ресурсы. Вам не нужно админить ферму из 20 серверов с иксами и виртуалками, чтобы просто стабильно крутить 500 браузеров, регулярно обновлять им профили и следить за утечками памяти.
Но давайте с цифрами. Что по задержкам?
Замеры на практике (измерения через Date.now() вокруг CDP-кома��ды):
Операция | Локальный Chromium | Облачный браузер (US→US) | Облачный браузер (RU→US) |
| ~180 мс | ~320 мс | ~580 мс |
| ~15 мс | ~45 мс | ~90 мс |
| ~200 мс | ~350 мс | ~620 мс |
(замер: медиана по 20 прогонам в промежутке 14:00–16:00 UTC, цель — публичный портал с включённым UAM, конфигурация: country-us, sid фиксированный)
Вывод честный: накладные расходы на WSS-туннель — это реальные ~30–100 мс на команду в зависимости от географии. Для задач, где важна скорость прокрутки (массовый сбор данных без авторизации), это имеет значение. Для задач, где важна «чистота» прохождения антифрода (логин, регистрация, работа с корзиной), эти миллисекунды не критичны — там всё равно нужны человекоподобные задержки между действиями.
Отдельный сценарий — Cloudflare Turnstile (замена классической CAPTCHA). В отличие от hCaptcha, Turnstile не показывает пользователю ничего визуального: он молча запускает JS-челлендж в фоне и выдаёт токен. Для облачного браузера это означает дополнительные 2–4 секунды на первый page.goto() — Chromium должен пройти челлендж до отдачи контента. Учитывайте это в таймаутах.
Примеры кода: От «Hello World» к реальным задачам
Интеграция выглядит максимально нативно. Вместо запуска локального браузера командой chromium.launch(), мы используем connectOverCDP().
// Базовое подключение за 30 секунд const { chromium } = require("playwright"); (async () => { const auth = "your_user_country-us_sid-random123:your_password"; const endpoint = `wss://${auth}@browser.nodemaven.com`; console.log("Подключаемся к облачному браузеру..."); const browser = await chromium.connectOverCDP(endpoint); const page = await browser.newPage(); await page.goto("https://target-website.com"); console.log("Заголовок страницы:", await page.title()); await browser.close(); })();
Кейс 1: Перехватить скрытый API за цепочкой редиректов
Многие сайты не отдают данные напрямую — они делают XHR-запросы к внутреннему API после нескольких редиректов и JS-инициализации. Решение: перехватываем ответы сетевым хуком прямо в облачном браузере.
// ...подключение к браузеру... // Блокируем лишнее ещё до загрузки — экономим трафик await page.route('**/*.{png,jpg,gif,svg,mp4,woff2}', r => r.abort()); // Перехватываем нужный API-ответ, прячущийся за JS-инициализацией const apiDataPromise = page.waitForResponse( resp => resp.url().includes('/api/v2/products') && resp.status() === 200 ); // Задаём кастомные заголовки — имитируем реальный запрос из приложения await page.setExtraHTTPHeaders({ 'X-Requested-With': 'XMLHttpRequest', 'Accept-Language': 'en-US,en;q=0.9', }); await page.goto('https://target-site.com/catalog', { waitUntil: 'networkidle' }); const apiResponse = await apiDataPromise; const json = await apiResponse.json(); console.log('Товаров получено:', json.items.length); // ...закрытие браузера...
Важно: не убивайте траст своим же кодом. Идеальный облачный профиль не спасёт, если ваш скрипт ведёт себя как робот. Стандартный await page.click('.button') в Playwright буквально «телепортирует» курсор в точный геометрический центр элемента за 0 миллисекунд по прямой линии. Для L3-эшелона это мгновенный детект. Всегда рандомизируйте координаты клика (offset) и используйте библиотеки генерации человекоподобных траекторий (кривые Безье) для движения мыши перед кликом.
Кейс 2: CDP-сессия для live-решения капчи
Если сайт показал капчу, не паникуйте. Через CDP вы можете передать URL сессии оператору-человеку или solver-сервису, который решит её в реальном времени прямо в том же контексте браузера.
// ...внутри async функции после page.goto()... // Создаём CDP-сессию для текущей страницы const cdpSession = await page.context().newCDPSession(page); // Получаем inspect-ссылку — её можно открыть в локальном Chrome DevTools const { frameTree } = await cdpSession.send('Page.getFrameTree'); console.log('Frame URL:', frameTree.frame.url); // Ждём сигнала об успешном прохождении капчи // (человек или solver открывает URL и кликает в облачном браузере) await page.waitForFunction(() => !document.querySelector('.captcha-container')); console.log('Капча пройдена, продолжаем...');
Принципиальное отличие от локального решения: браузерный контекст уже имеет «правильный» отпечаток с первого байта — решение капчи не создаёт аномалии в поведенческом треке.
Боевой кейс: Cloudflare UAM
Задача: автоматизировать сбор данных с портала, который включает UAM в пиковые часы.
Результат: Чистый
curlблокирован мгновенно (несоответствие JA3). Puppeteer на серверных IP проходит JS Challenge, но не получаетcf_clearanceиз-за ASN дата-центра.Решение: Scraping Browser + резидентский ISP. Проходит $JS$ Challenge за 5-7 секунд, cookie выдаётся, сессия устанавливается.
// Cloudflare UAM запускает JS Challenge — ждём прохождения await page.waitForFunction(() => { return !document.title.includes('Just a moment'); }, { timeout: 30000 }); const cookies = await page.context().cookies(); const cfClearance = cookies.find(c => c.name === 'cf_clearance'); console.log('cf_clearance получен:', cfClearance?.value);
Fingerprinting: Как сайты вычисляют ваше «железо» — и при чём здесь TLS
Если вы думали, что IP и User-Agent — это всё, что о вас знает сайт, у меня плохие новости. Современный антифрод работает в несколько эшелонов, и самый недооценённый из них — сетевой уровень.
JA3/JA4 — отпечаток TLS-рукопожатия
Когда ваш клиент открывает HTTPS-соединение, он отправляет ClientHello с набором поддерживаемых шифров, расширений и их порядком. Этот набор хешируется в JA3-отпечаток (или более новый JA4). У Chrome 120 он один, у curl — кардинально другой, у Python requests — третий. Cloudflare видит этот хеш ещё до того, как вы отправили первый HTTP-байт.
Как это решает Scraping Browser:
Поскольку соединение с целевым сайтом устанавливает сам облачный Chromium, а не ваш скрипт, JA3-отпечаток идентичен реальному браузеру нужной версии. Ваш connectOverCDP — это просто туннель внутри уже установленного TLS-соединения.
Важно помнить, что TLS — только половина картины. Cloudflare и Akamai дополнительно строят HTTP/2 fingerprint: порядок pseudo-заголовков (:method, :path, :authority), значения фрейма SETTINGS и начальный размер окна. У Chrome этот паттерн специфичен и отличается от curl или Requests даже при идентичном JA3. Инструмент tls-fingerprint от lwthiker позволяет проверить свой отпечаток публично.
Шрифты и плагины — тихая утечка
Через document.fonts.check() сайт перебирает сотни системных шрифтов. Набор шрифтов уникален для ОС и локали. Аналогично navigator.plugins: на серверном Chromium их обычно ноль, что является мгновенным красным флагом. Облачный браузер эмулирует профили с реалистичным набором шрифтов и плагинов под конкретную платформу через pid (Profile ID).
Четыре всадника детекта на уровне L2
Headless-аномалии: Раньше ботов ловили по флагу navigator.webdriver = true. Сейчас смотрят на косвенные признаки: отсутствие плагина Chrome PDF Viewer, нулевые размеры window.outerWidth/outerHeight или заблокированные уведомления (Notification.permission). BaaS-инфраструктура запускает инстансы в полноценном headful-режиме (с виртуальным дисплеем) или использует глубоко пропатченный новый --headless=new, где весь графический стек идентичен десктопному.
Canvas Fingerprinting: Сайт просит браузер отрисовать скрытый текст или фигуру. Результат зависит от видеокарты, драйверов и шрифтов. Разница в один пиксель — и вы «подозрительны».
WebGL Metadata: Глубокое сканирование графической подсистемы. Антифрод видит модель видеокарты, объем видеопамяти и нюансы рендеринга 3D-сцен.
WebRTC Leakage: Технология, которая часто «сливает» ваш реальный локальный IP в обход любых прокси.
Маскировка vs Шум: Как не выстрелить себе в ногу
Многие новички пытаются просто отключить JavaScript или заблокировать передачу данных о железе. Для системы защиты «пустой» профиль такой же маркер бота, как и серверный IP.
Scraping Browser идет по пути маскировки (Masking):
Real Hardware Parameters: Вместо блокировки браузер отдает валидные, но подмененные данные реального железа.
Canvas Noise: В отрисовку добавляется минимальный «шум», меняющий хеш отпечатка, но оставляющий его похожим на результат работы обычного устройства.
Resolution & Language: Вы задаете разрешение экрана и язык системы, которые на 100% совпадают с ГЕО вашего прокси.
Важный нюанс: современные антифрод-системы редко дают hard block с HTTP 403. Чаще срабатывает shadow ban запросы проходят, но возвращают пустые результаты, подделанные цены или заниженную выдачу. Это сложнее детектировать на стороне скрапера. Признак: расхождение данных между авторизованной сессией и ботом при одинаковых запросах.
Аналогично добавлю, что дешёвые open-source stealth-плагины часто делают фатальную ошибку — подмешиваютMath.random()при каждом вызовеtoDataURL(). Антифрод (тот же DataDome) просто просит браузер отрисовать канвас дважды подряд за миллисекунду. Если хеши разные без изменения DOM — вы бот. Облачные браузеры применяют детерминированный шум (привязанный кpid): он искажает картинку, но всегда одинаково для конкретной сессии, имитируя реальную железную особенность конкретного GPU.
Наст��ойка «личности» в один клик
В интерфейсе создания профиля это выглядит как чек-лист выживания: эмуляция Windows/macOS/Linux, подмена часового пояса и имитация конкретных моделей видеокарт. Когда вы подключаетесь через pid, все эти настройки уже «приклеены» к вашей сессии.
Прокси-менеджмент: От Residential до Static ISP
Прокси — это фундамент доверия. Если ваше «железо» идеально, но запрос идет с заспамленного дата-центра, антифрод срежет вас на взлете.
Ротация vs Липкость (Sticky)
Rotating (Ротируемые): Каждый новый запрос — новый IP. Идеально для массового скрапинга тысяч страниц без авторизации.
Sticky (Липкие): Удержание одного IP до 24 часов. Критично для мультиаккаунтинга: залогинились, погуляли по сайту, положили товар в корзину.
Quality Filter: Как не кормить антифрод «грязными» IP
В интерфейсе реализована механика фильтрации:
Quality (Default): Отсеивает адреса с низким Trust Score или те, что попали в блэклисты.
Quality + Speed: Приоритет чистоте и минимальному пингу.
Max Pool Size: Максимально широкая база, если объем важнее чистоты.
Глубокий таргетинг через WSS-строку
Вы можете менять локацию «на лету», просто модифицируя строку подключения:
wss://{username}_country-{country}-region-{region}-city-{city}-isp-{isp}-sid-{sid}:{password}@browser.nodemaven.com
Разбор параметров:
country-us: Весь мир у ваших ног.region-new_york: Доступ к локальному контенту штата.city-brooklyn: Таргетинг до города.isp-t_mobile: Имитация пользователя конкретного провайдера.sid-{any_string}: Любая строка делает сессию «липкой».
Статистика и контроль: Куда уходят мегабайты?
В дашборде доступна прозрачная аналитика по доменам. Можно отследить, сколько трафика «съел» oracle.com или tiktokcdn-eu.com и сколько запросов было успешно обработано. Это база для оптимизации: блокируйте загрузку видео или тяжелых картинок, если вам нужен только текст.
Продвинутая автоматизация: API и Live Debugging
Если вам нужно управлять сотнями аккаунтов или строить свой сервис поверх инфраструктуры, ручного создания профилей недостаточно. Тут в дело вступает NodeMaven API v2.
Edge-кейс: Автостоп «бешеного» саб-юзера
Пересказывать эндпоинты скучно, поэтому вот реальная ситуация. В продакшне у нас было несколько скриптов, каждый под своим саб-юзером. Один из них начал получать массовые ошибки 403 (сайт сменил структуру). Скрипт не упал, а продолжил молотить запросы, сливая резидентский трафик со скоростью ~2 ГБ/час.
Решение watchdog через API:
import requests, time SUB_USER = "project_parser_v2" API_KEY = "your_api_key" ERROR_THRESHOLD = 50 # лимит ошибок 403 CHECK_INTERVAL = 60 # интервал проверки (сек) while True: # Запрашиваем статистику по конкретному саб-юзеру stats = requests.get( f"https://api.nodemaven.com/v2/statistics/data/?sub_user={SUB_USER}", headers={"Authorization": f"Bearer {API_KEY}"} ).json() error_rate = stats.get("errors_403", 0) if error_rate > ERROR_THRESHOLD: # Блокируем саб-юзера через API до выяснения причин requests.post( f"https://api.nodemaven.com/v2/sub-users/{SUB_USER}/disable/", headers={"Authorization": f"Bearer {API_KEY}"} ) print(f"[ALERT] Sub-user {SUB_USER} отключён: {error_rate} ошибок") break time.sleep(CHECK_INTERVAL)
Это и есть главная причина, зачем нужен API: программный контроль бюджета и безопасности.
Live Debugging: Как заглянуть в «мозги» облачного бота
Обычно работа с удалённым браузером — это «чёрный ящик». Но поддержка CDP (Chrome DevTools Protocol) превращает его в прозрачное стекло. Вы создаёте CDP-сессию через page.context().newCDPSession(page), запрашиваете Page.inspect и получаете ссылку. Теперь вы видите в реальном времени, как бот проходит капчу или на каком шаге «поплыл» верстка.
Парадокс Pixelscan: Почему просто прокси мало?
Если прогнать этот прокси через Pixelscan в обычном антидетекте, мы часто видим: Location: Green, но Hardware: Red (Unreliable).
Это классика: антифрод палит несоответствие железа сетевому отпечатку. Scraping Browser решает это на этапе формирования browserContext. Параметры WebGL, AudioContext и шрифты патчатся на уровне runtime Chromium ещё до загрузки страницы. Для антифрода «красных зон» просто не существует — он видит консистентный профиль с первого байта.
Заключение: Честный взгляд на BaaS
Browser as a Service (BaaS) — это специализированный инструмент. BaaS с резидентными прокси обойдётся примерно в 5 раз дороже обычных дата-центровых адресов. Если вам нужно просто качать картинки с незащищённых сайтов — это «пушка по воробьям».
Когда это нужно:
Вы упёрлись в L2-L3 детекты (Cloudflare/Akamai), и
stealth-плагины не спасают.Важна репутация IP и нативный TLS-отпечаток.
Вы не хотите админить Docker-фермы для сотен экземпляров Chromium и бороться с утечками памяти.
Промокоды для читателей:
Статья писалась под конкретные задачи — ваши сценарии могут дать другие цифры. Если хотите воспроизвести тесты, ребята из NodeMaven дали промокоды: PROXY35 (−35% на мобильные и резидентские) и PROXY40 (−40% на ISP). Скрипты из статьи можно запустить без изменений.
