Headless вече не е скрит
Преди седем дни cside публикува технически анализ на засичането на headless браузъри през 2026 г. Основният извод: детекторите вече улавят headless сесии на ниво пиксел. Същият номинален браузър, същата операционна система, различен WebGL изход. Различен тайминг на AudioContext. Различно изброяване на шрифтове. Малки сигнали, но достатъчно постоянни за оценка.
Тази публикация излезе седмица след обзора на WebDecoy Browser Fingerprinting 2026, който стигна до същия извод по различен път. Докладът на Browserless State of Web Scraping 2026 (публикуван по-рано тази година) го каза ясно: headless браузърите биват маркирани по-често от тези, управлявани от потребители, а разликата продължава да се увеличава.
Ако използвате Puppeteer или Playwright в продукция, това променя кривата на разходите ви.
Какво всъщност се промени
Старата история за засичането на headless беше navigator.webdriver === true, празни масиви с плъгини и HeadlessChrome в user-agent. Всеки stealth плъгин от 2020 г. пачва това. Затова детекторите слязоха по-надолу в стека.
Софтуерното рендиране е основният фактор. Потребителският браузър използва GPU. Headless средите, работещи в контейнери, обикновено преминават към софтуерен растеризатор. Низът за WebGL рендиране се чете различно. Пикселният изход се различава при същия номинален вход. Canvas отпечатъците се разминават при идентични входове. Нито едно от тези не задейства булева проверка, а захранва вероятностна оценка.
AudioContext е вторият фактор. Когато страница инстанцира аудио контекст и поиска честотата на дискретизация или броя канали, headless средите отговарят с леко различни стойности от нормалните десктоп сесии. Таймингът при същата операция се отклонява предвидимо.
Изброяването на шрифтове е третият фактор. Потребителските машини имат шрифтове, инсталирани с времето. Изображенията на контейнери имат подбран (и малък) набор. Когато скрипт за снемане на отпечатъци измери ширината на сто често срещани низа през петдесет шрифта, моделът на липсващите шрифтове е диагностичен.
Всеки един от тях е слаб сигнал. Заедно и в комбинация с по-старите сигнали, които детекторите все още проверяват, те формират резултат, който отделя автоматизираните сесии от потребителските с достатъчно висока увереност за предприемане на действия.
Защо детекторите инвестират сега
Защото числата най-накрая оправдаха бюджета за R&D.
Докладът на F5 2026 Advanced Persistent Bot Report определи трафика от скрейпъри на 10.2% от глобалния уеб трафик след прилагане на съществуващите мерки за смекчаване на ботове. Това е остатъкът: делът, който защитниците не могат да сведат до нула с инструментите, които вече имат. Всяка допълнителна точка от този дял си струва да бъде затворена.
Cloudflare пусна Precursor на 13 юли. Precursor събира непрекъснати клиентски поведенчески сигнали (движение на показалеца, времеви интервали на клавиатурата, фокус, видимост) и ги подава към текущ bot score, който се запазва при опресняване на страницата. Ние писахме за това преди две седмици: поведението на сесията вече се оценява по същия начин, по който се оценяваха отпечатъците преди година.
Precursor и вълната от специфични за headless сигнали не са независими ходове. Те са част от същата стратегия. Спрете да оценявате един request изолирано. Оценявайте цялата сесия по всяка ос, която можете да измерите.
Двата данъка, които всъщност плащате
Изпълнението на headless вътрешно винаги е било евтино на хартия. Рамката е безплатна, браузърът е безплатен, а контейнерите са евтини. Но 2026 г. добави две позиции, които не се показват във фактурата.
Данъкът за поддръжка е този, който хората забелязват. Puppeteer-extra-stealth осигуряваше месеци спокойствие между кръпките. За всеки сайт с реална защита през 2026 г., той осигурява седмици. Между актуализациите на headless, актуализациите на браузъра, актуализациите на защитата и актуализациите на stealth-plugin, един инженер може да изгори цяла седмица на месец, за да поддържа стека синхронизиран. Никой не слага това в пътната карта. То просто изяжда пътната карта.
Данъкът за засичане е този, който хората не забелязват, защото се крие в графиката за успеваемост. Процентите на блокиране при защитени цели пълзят нагоре. Повторните опити се увеличават. Разходите за успешен fetch се покачват заедно с тях. Отдавате го на "сайтът стана по-труден" и продължавате. Част от това е реално. Друга част е разширяващата се пропаст между това как изглежда вашият стек и как изглежда нормален браузър. И двете тенденции се движат в една и съща посока.
Нито един от двата данъка не убива проект. Заедно те променят математиката относно изграждането срещу купуването.
Какво означава това за екипите за данни
Не всеки scrape се нуждае от браузър. Тази част не се е променила. Но си струва да се повтори, защото много headless внедрявания започнаха със страница, която можеше да бъде просто обикновено HTTP извикване.
Ако данните на целта идват чрез XHR или JSON endpoint, пропуснете браузъра. HTTP request-ите са по-евтини, по-бързи и изобщо не носят нито един от тези сигнали за отпечатъци. Статията на okhlopkov от юли поставя стълбата в правилния ред: API и XHR първо, вграден JSON след това, браузър само когато страницата наистина го изисква, LLM извличане само след като всичко останало е проверено.
За сайтовете, които наистина се нуждаят от браузър, въпросът е нивото на защита. Лека защита (rate limit-и, филтри на User-Agent, проверки на referer): добре конфигуриран headless стек все още работи, а данъкът е нисък. Тежка защита (Cloudflare, PerimeterX, DataDome с пълно оценяване на сесията): данъкът е реален и се натрупва. Тогава сметката се обръща.
Има и средно положение, за което никой не говори. Сайтове, които не блокират директно, но тихо влошават качеството. Различна цена, по-бедни списъци, липсващи изображения, липсващи отзиви. Вашият scraper отчита успех. Данните са тихомълком грешни. Този режим на грешка става все по-чест, тъй като резултатите от fingerprinting стават входни данни за решения за съдържание, а не за решения за блокиране.
Ако не можете да разберете дали сте в това положение, вероятно сте в него.
Накъде отива това
Headless беше хак, който работеше едно десетилетие, защото никой не гледаше внимателно. Последните две години промениха това. Доставчиците на системи за детекция най-накрая решиха, че остатъчният дял от scraper си струва да бъде блокиран, и избраха слоя, където автоматизацията е най-лесна за изолиране.
Следващият рунд няма да бъде за по-умни stealth плъгини. Той ще бъде за това кои сайтове ще решат, че прецизността на детекция си струва процента фалшиво положителни резултати при легитимни потребители с необичайни конфигурации: инструменти за достъпност, по-стари GPU, корпоративни proxies, частен DNS. Всяка точка точност на детекция на headless, която купуват, струва някаква част от процента от реалните потребители. Този компромис е мястото, където всъщност се разиграва надпреварата, а не във вашата Puppeteer конфигурация.
Ако вече плащате данъка за headless, поне го измерете. В противен случай това е просто ред, за който не сте знаели, че сте се съгласили.