Всички публикации

FourA Digest, 1 май до 8 май 2026 г.

Proxy Finder вече избира proxy-та на базата на това какво действително е проработило за вашите целеви сайтове, плюс корекции за стабилност на Browser и продуктов филтър в Dashboard.

Акценти

Proxy Finder вече се обучава за всеки отделен хост. Той вече не просто избира общо взето бързо proxy, а избира такова, което вече е работило за сайта, който достъпвате. Browser получи корекция за стабилност, която улавя клас от грешки при студен старт (cold-start). А изгледите Metrics и Activity в Dashboard вече могат да се филтрират по продукт.

Какво ново

Proxy Finder избира proxy-та, които действително работят за вашата цел

Това е най-голямата промяна за седмицата и отне няколко итерации, за да бъде внедрена.

Преди: Proxy Finder избираше от глобалния пул въз основа на обща пригодност. Две request-а към един и същ целеви сайт избираха от един и същ широк пул, въпреки че повечето proxy-та в този пул не биха работили за този конкретен сайт.

Сега: за всеки целеви хост, който заявявате, Proxy Finder проследява кои proxy-та действително са доставили успешно response. Новите request-и вземат за проба няколко от доказания набор, преминават към малка проверка на непознати, за да продължат да се учене, и избягват тези, които вече са се провалили там. Доказаният набор е за всеки отделен хост и се запазва при рестартиране.

Ако скрапвате защитени сайтове, където работи само малка част от proxy-тата, би трябвало да усетите това. По-малко грешни избори, по-малко повторни опити, по-малко изразходван бюджет.

Внедрихме това зад flag, направихме шест итерации за изглаждане на проблемите (една от тях, ограничаваща логиката на обучение, за да остане стабилна при нисък трафик, отне още две преминавания) и превключихме стойността по подразбиране за production тази седмица.

Browser е надежден след периоди на престой

Две корекции, един резултат.

Първо, Browser имаше бъг със застояло състояние (stale-state) при студен старт. След достатъчно време на престой, базовият слой на дисплея задържаше lock, който пречеше на следващото стартиране да бъде успешно. Първият ви request след период на бездействие можеше да се провали или да увисне. Сега изчистваме lock-а преди стартиране.

Второ, публичният API път, който рутира към Browser, сочеше към грешна дестинация в някои среди. Трафикът беше безшумно пренасочван погрешно. Конфигурацията за рутиране вече е правилна.

Ако сте забелязали нестабилно поведение при първия request в Browser при нисък обем, това беше причината.

Филтриране на Metrics и Activity по продукт

Страниците Metrics и Activity в Dashboard вече имат филтър с продуктови чипове. Кликнете върху Single, Browser или Proxy Finder и графиките ще се ограничат само до трафика на този продукт. Полезно е, когато искате да виждате само latency или грешки от една част от вашето потребление, вместо обобщения изглед.

Малка актуализация на сайта

Страницата /jobs е активна. Търсим да назначим Founding Engineer и Engineer. И двете страници описват подробно обхвата на работата, как изглежда първият месец и как да кандидатствате.

Също така оптимизирахме мобилното изобразяване на прегледа на Dashboard на началната страница, обновихме изображенията за споделяне в социалните мрежи за всяка страница в девет публични маршрута, актуализирахме robots.txt за ерата на AI през 2026 г. (разрешени са инструменти за извличане и преглед при споделяне в социалните мрежи, блокирани са crawlers за обучение) и обновихме Terms of Service с по-ясна клауза за приемлива употреба и бележка за юрисдикция в София с изключение за потребителите в ЕС.

Под капака

Преименуване, което не е видимо за клиентите, извършено по-рано през този период: "anti-bot bypass" стана "anti-bot resilience" в целия сайт. Същият продукт, същото поведение, старата формулировка задействаше филтрите за политики на рекламните платформи.

Все още не публикуваме данни от новата логика за избор. Искаме две чисти седмици на production трафик, преди да правим твърдения за нивата на успеваемост. Реални числа, когато ги имаме.

Прекарахме последния месец в пренаписване на слоя, който решава кое proxy да се използва за коя цел. И трудната част не е алгоритъмът, а измерването дали той действително помага при реални натоварвания. Ето как изглежда май.