Повечето scrapers се провалят, преди да бъде прочетен дори един header.
Сървърът разглежда TLS handshake (подредба на cipher suites, подредба на разширенията, предпочитания за кривите) и решава дали сте браузър или клиентска библиотека, която се преструва на такъв. Python requests, net/http на Go, чист curl: всички те предават характерен fingerprint в момента, в който кажат „здравей“. Сайтовете, които се интересуват от това (Datadome, Akamai, Imperva, управляваната защита на Cloudflare), прекъсват връзката или ви показват challenge страница, преди вашият User-Agent изобщо да има значение.
Точно това решава unblocker: true в FourA. През последния месец фиксирахме елементите, които го карат да работи надеждно.
Какво ново
unblocker: true е единичен флаг при всяко извикване на /api/single. Включете го и ние правим три неща: инжектираме набора от browser headers, изпращаме request през curl-impersonate с TLS fingerprint на реален браузър и декомпресираме всичко, което сървърът връща (gzip, brotli, deflate). Първите две възможности са налични още от beta версията. Третата (автоматична декомпресия на brotli) беше пусната на 25 март, а работата по фиксирането на версията на браузъра приключи на следващия ден, за да се поддържат headers и TLS в пълен синхрон.
Как работи
Ето как изглежда один request:
curl -X POST "https://api.foura.ai/api/single" \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_API_KEY" \
-d '{
"url": "https://example.com/products",
"method": "GET",
"unblocker": true
}'
Под капака работят три слоя.
Header injection. Настройваме пълния пакет от browser headers: User-Agent, Sec-Ch-Ua, Sec-Ch-Ua-Platform, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Accept, Accept-Language и Accept-Encoding. Подредбата има значение. Реалните браузъри ги изпращат в специфична последователност и библиотеките за засичане проверяват именно това.
TLS fingerprint. curl-impersonate 0.8.2 компилира libcurl срещу BoringSSL и пренарежда TLS разширенията, за да съвпадат с това, което целевата версия на браузъра действително изпраща по мрежата. Вашите JA3 и JA4 hashes се получават идентични с тези от реална браузърна сесия. Стандартният curl, Python requests и net/http на Go генерират fingerprints, които биват автоматично маркирани за милисекунди от защитената инфраструктура.
Автоматична декомпресия. Когато unblocker е включен, задаваме Accept-Encoding на gzip, deflate, br и оставяме libcurl да разопакова тялото. Получавате обратно декодиран string (или Buffer, ако подадете returnBuffer: true). Без ръчно управление на brotli, без несъответствия между headers и тялото, когато даден сайт избере deflate пред gzip.
Защо фиксирането на версията е важно
TLS fingerprints са обвързани с конкретна версия. Подредбата на ciphers в браузъра този месец не е същата като миналия и сайт, който внимателно анализира fingerprints, ще забележи разликата. curl-impersonate предоставя профили за конкретни версии на браузъри, а ние фиксираме нашия реален browser binary към версията, която curl-impersonate таргетира в момента. Headers, navigator обектите и TLS докладват една и съща версия.
Ако това ви звучи сложно и пипкаво, то наистина е такова. Бяхме засегнати от несъответствие по време на миграцията към monorepo през март, когато браузърът се актуализира автоматично и неговите headers се разминаха с curl-impersonate. Решението изискваше два commits: фиксиране на browser binary и правилото никога да не се доверяваме на package manager да ги поддържа синхронизирани вместо нас.
Ефектът
При вътрешни тестове срещу цели със засилен анализ на fingerprints (финанси, туризъм, защитени сайтове за електронна търговия), разликата между unblocker: false and unblocker: true е разликата между challenge страница и статус 200. Обикновен curl, насочен към управляван Cloudflare, получава 403 още при първия опит. Същият URL с unblocker: true преминава успешно, защото TLS hello изглежда като реално ръкостискане от браузър.
Но за сайтове, които не анализират fingerprints (повечето публични APIs, по-стари CMS шаблони, всичко, което е ограничено само по IP rate limits), оставянето на unblocker изключен е напълно нормално и спестява няколко милисекунди от TLS negotiation. Използвайте го там, където е необходимо.
За напреднали потребители
Няколко модела, които си струва да знаете.
Комбинирайте unblocker с residential proxy, когато целта проверява и репутацията на IP адреса. Datacenter IPs, съчетани с перфектен TLS handshake, все пак ще бъдат засечени поради ASNs, които сайтът е включил в черния си списък. Нашият proxy endpoint (/api/proxy) се ротира според целевия домейн, така че добавянето на "proxy": "residential" към request обикновено е достатъчно.
Пропуснете unblocker, когато извиквате JSON APIs, които не се интересуват от браузъри. Допълнителните headers всъщност могат да изглеждат подозрително за API, което очаква програмен клиент (например backend, който извиква собствения си микросервиз).
Ако сайтът използва JavaScript anti-bot защита (интерактивни предизвикателства Turnstile, Perimeter X при най-строги настройки, Akamai Bot Manager с повишена евристика), само unblocker няма да бъде достатъчен. Нуждаете се от browser endpoint, който стартира реален Chromium и може да изпълни съответното предизвикателство. Това е различен продукт с различно ценообразуване на кредитите, за който писахме в Browser Tasks: Как да скрейпваме сайтове с интензивно използване на JavaScript.
Освен това можете да комбинирате unblocker с блока validate, за да отхвърляте responses, които технически връщат 200, но съдържат challenge страница:
{
"url": "https://example.com/products",
"method": "GET",
"unblocker": true,
"validate": {
"data": { "fail": ["captcha", "Access Denied"] }
}
}
Това превръща тихите грешки в класифицирани грешки, което е важно за проследяването на вашия success-rate в dashboard.
Какво предстои
Браузърите пускат нова стабилна версия на всеки четири седмици. Поддържащият curl-impersonate обикновено наваксва месец по-късно, а ние обновяваме нашия stack, когато това се случи. Не е необходимо да променяте нищо от ваша страна: unblocker: true продължава да сочи към версията на браузъра, която сме тествали и потвърдили end-to-end.
По-трудната работа тепърва предстои. Анализът на HTTP/3 fingerprinting вече се появява при управляваните anti-bot защити, QUIC транспортът е по-сложен за симулиране от TLS 1.3, а миграцията от статични пакети от headers към наистина динамична емулация вече започва. Защитените сайтове преминаха към проверка на подредбата на HTTP/2 frames и JA4+ варианти, а разликата между „curl, който изглежда като браузър“ и „реален браузър“ ще продължи да се свива и от двете страни. Ще пишем за това, когато го пуснем официално.