Какво ново
Ротацията на изходните IP адреси е частта, която всички автоматизират. Браузърният отпечатък под тях обаче обикновено никога не се променя.
Single и Proxy Finder вече приемат четири опционални полета, които определят какъв браузър представя вашата request: browser, os, version и profile. Каталогът зад тях е публичен на GET /api/profiles и не изисква API key. В момента той съдържа 79 профила за Chrome, Edge, Safari, Firefox и Tor под Windows, macOS, Android и iOS.
Ако не посочите такъв, Proxy Finder ще го смени вместо вас. Но само след като даден сайт два пъти докаже, че отхвърля изпратения.
Как работи
Три от полетата са за хора, а едно е за машини.
browser, os и version стесняват каталога, като можете да изпратите произволна комбинация от тях. os филтрира по семейство, така че задаването на macOS приема всяка macOS версия в списъка, докато посочването на точния етикет на рилийза го ограничава само до него. Когато няколко профила все още съвпадат, най-новата версия печели, тъй като актуалността е основната цел. Остарелите основни версии са това, по което списъците за блокиране филтрират.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
Това се резолва до най-новия Safari на iOS в каталога и изпраща съответния User-Agent, client hints и подредбата на headers, точно в този ред. Подредбата на headers сама по себе си е сигнал, така че нищо не се пренарежда на излизане.
profile е четвъртото поле: точен id от каталога, за код, който трябва да продължи да изпраща същия клиент дори след излизането на по-нова версия. Proxy Finder приема и четирите в рамките на своя request обект. Пълният списък с параметри е в API справочника, а Playground чете същия каталог, така че падащите му менюта предлагат само това, което вашият код може да заяви. Същите четири полета се намират и вътре в foura_single и foura_proxy в MCP сървъра, за да може агентът да опита отново като друг браузър, вместо да връща просто грешка 403.
Две неща, които това умишлено отказва да прави.
Комбинация, която каталогът не може да предостави, е грешка, описваща какво е налично за съответния браузър. Връщането към стойност по подразбиране би изпратило клиент, който не сте избрали и не виждате в response. Избор на профил с unblocker: false също се отхвърля, защото този флаг пренася headers (какво всъщност прави този флаг). Половин профил е по-лошо от никакъв.
Самият каталог се измерва, а не се пише на ръка. Скрипт прекарва всеки профил през реалния request път и записва какво всъщност е изпратено по мрежата. Това има по-голямо значение, отколкото звучи: между две скорошни основни версии на един браузър низът на placeholder бранда се промени и редът на брандовете се обърна, а това е точно детайлът, който системите за засичане следят.
Въздействие
Ето частта, която не очаквахме.
Стойността по подразбиране е споделена стойност по подразбиране. Клиентът, който вашият request подава, когато не заявите нищо, е същият, който всеки друг request без настройки подава. Защитите, търсещи лесен признак за блокиране, се хващат точно за това. Пропадането също изглежда по уникален начин: сайт, който отказва един браузър, го отказва през всяка точка за изход, която притежавате. Изразходвате целия си лимит за повторни опити, само за да докажете, че същият клиент е нежелан.
Измерихме го три пъти при трима различни доставчици и резултатът беше еднакъв всеки път.
Портал за недвижими имоти зад PerimeterX отхвърли девет опита със стойността по подразбиране. Промяната само на платформата, която заявката посочва (всичко останало същото, същият пул), върна страницата шест от шест пъти. Търговец на хранителни добавки зад Akamai отказа стойността по подразбиране и обслужи две други фамилии браузъри без проблем. Сайт за финансови новини зад DataDome върна 401 и междинна страница от 774 байта за стойността по подразбиране, докато три други профила изтеглиха реалната страница от около 760 KB дванадесет пъти всеки. Изпълнихме теста в прав и обратен ред, за да сме сигурни, че последователността не влияе на резултата.
И така, Proxy Finder вече ротира семейството на браузъра, а не само изходната точка (exit node). Два независими изхода трябва да откажат достъп, преди да се направи превключване, защото единичният отказ е просто мнението на една изходна точка. След това системата следва йерархия, която започва с възможно най-малката промяна, платформата, и чак след това пробва други семейства.
Това не струва нищо допълнително. Ротацията променя съдържанието на повторния опит (retry), но не и дали да се извърши такъв, така че броят заявки и кредити за дадена задача остават абсолютно същите.
За напреднали
Ротацията не пречи на персонализираните настройки, като правилата за това са важни.
Тя никога не се задейства, когато сте посочили име на профила сами. Също така никога не се активира, ако сте изпратили свой собствен хедър user-agent или cookie, като това е от ключово значение: дадена clearance бисквитка е обвързана с клиента, който я е получил, така че ротирането на сигнатурата по време на работеща сесия би счупило иначе успешна заявка. Фиксирайте каквото искате и то ще остане фиксирано.
Не всяка грешка се брои за основание за смяна на профила. Разпознат доставчик на защита се зачита. Чист статус за отказ (401, 403, 429, 503) без конкретен вендор също се зачита, което се оказа важно. Една задача върна осем отхвърляния по статус код и нито едно от тях не беше разпознато като система за защита: реални откази, които ротацията игнорираше, защото вярваше единствено на детектора. Липсваща страница или блокиране по държава не се зачитат. Това са отговори, свързани с вашия URL и географско местоположение, а не с клиента ви.
Имате пълна видимост върху всичко. Успешен отговор от Proxy Finder съдържа profile само когато ние сме го избрали, никога когато сте го направили вие. Неуспешна задача съдържа attemptReport.profilesTried: изпратените семейства по реда на тяхното използване, с default за заявка, която е изпратена без промени. Без това поле вариантите "опитахме четири браузъра и всеки от тях беше отхвърлен" и "изобщо не сме сменяли браузъра" изглеждат напълно идентични отвън.
Една добра практика, която си струва да заимствате: когато тествате дали даден профил помага, запазете всички останали параметри непроменени. В своя преглед на инструменти за тестване на fingerprinting от 2026 г. от Scrapfly правилно отбелязват, че промяната на три променливи едновременно показва само, че нещо е проработило, но не и коя точно промяна е помогнала. Една и съща цел, един и същ изход, една единствена разлика в полетата. Точно така бяха изведени и всички числа по-горе.
Какво следва
Списъкът с кандидати се разширява единствено чрез измервания, цел по цел. Дадено семейство се добавя едва след като сме видели реално, че отваря цел, с която стандартното не е успяло, а не защото е изглеждало като добра идея. Каталогът се тества наново при всяко обновяване на ядрото, вместо просто да се пренася напред.
Това е неудобната реалност на този проблем. Най-добрата клиентска сигнатура е движеща се мишена, проследяването ѝ изисква непрекъсната работа, а не еднократно решение, и всичко, което е работело успешно през миналото тримесечие, вече е в списъците за блокиране. Ето защо това е параметър, който вие контролирате, и каталог, който можете да четете, вместо твърдо зададена стойност, която ние сме избрали вместо вас.