Najważniejsze zmiany
Proxy Finder uczy się teraz per-host. Nie wybiera już tylko ogólnie szybkiego proxy; wybiera takie, które sprawdziło się już na odpytywanej stronie. Browser otrzymał poprawkę stabilności, która eliminuje całą klasę błędów typu cold-start. Z kolei widoki Metrics i Activity w Dashboardzie można teraz filtrować według produktu.
Co nowego
Proxy Finder wybiera proxy, które faktycznie działają z Twoim celem
To największa zmiana tego tygodnia, a jej wdrożenie wymagało kilku iteracji.
Wcześniej: Proxy Finder wybierał z globalnej puli na podstawie ogólnej kondycji. Dwa requesty do tej samej strony docelowej losowały z tej samej szerokiej puli, mimo że większość proxy w tej puli nie działała z tą konkretną witryną.
Teraz: dla każdego odpytywanego hosta docelowego Proxy Finder śledzi, które proxy rzeczywiście obsłużyły ruch. Nowe requesty pobierają próbkę z zestawu sprawdzonych adresów, sięgają po małą próbkę nieznanych, aby stale się uczyć, i unikają tych, które już wcześniej zawiodły. Zestaw sprawdzonych proxy działa per-host i zachowuje stan między restartami.
Jeśli scrapujesz chronione strony, na których działa tylko niewielki ułamek proxy, od razu zauważysz różnicę. Mniej nietrafionych wyborów, mniej ponownych prób, mniejsze straty budżetu.
Wdrożyliśmy to za feature flagiem, przeprowadziliśmy sześć iteracji, aby dopracować szczegóły (jedna z nich, ograniczająca logikę uczenia się, aby zachować stabilność przy niskim natężeniu ruchu, wymagała dwóch dodatkowych podejść), i w tym tygodniu włączyliśmy to domyślnie na produkcji.
Browser działa niezawodnie po okresie bezczynności
Dwie poprawki, jeden rezultat.
Po pierwsze, Browser miał błąd nieświeżego stanu (stale-state) przy zimnym starcie. Po dłuższym czasie bezczynności bazowa warstwa wyświetlania utrzymywała blokadę, która uniemożliwiała kolejne uruchomienie. Pierwszy request po okresie ciszy mógł zakończyć się błędem lub zawiesić. Teraz zwalniamy blokadę przed uruchomieniem.
Po drugie, publiczna ścieżka API kierująca do Browsera w niektórych środowiskach wskazywała niewłaściwy cel. Ruch był po cichu błędnie przekierowywany. Konfiguracja routingu jest już poprawna.
Jeśli przy niskim wolumenie zdarzały się niestabilne pierwsze requesty do Browsera, to była właśnie tego przyczyna.
Filtrowanie Metrics i Activity według produktu
Strony Metrics i Activity w Dashboardzie zyskały filtr w postaci kafelków produktów. Kliknij Single, Browser lub Proxy Finder, a wykresy zawężą się wyłącznie do ruchu wybranego produktu. Przydatne, gdy chcesz sprawdzić opóźnienia lub błędy dla konkretnej części użycia zamiast widoku zagregowanego.
Drobne aktualizacje serwisu
Strona /jobs jest już aktywna. Rekrutujemy na stanowiska Founding Engineer oraz Engineer. Obie podstrony dokładnie opisują zakres obowiązków, plan na pierwszy miesiąc oraz sposób aplikacji.
Poprawiliśmy także renderowanie mobilne podglądu Dashboardu na stronie głównej, odświeżyliśmy grafiki social-share dla dziewięciu publicznych podstron, zaktualizowaliśmy plik robots.txt pod kątem AI w 2026 roku (dozwolone pobieranie i podglądy social-share, zablokowane crawlery trenujące modele) oraz zaktualizowaliśmy Regulamin o czytelniejszą klauzulę dopuszczalnego użytkowania i zapis o jurysdykcji w Sofii z wyłączeniem dla konsumentów z UE.
Pod maską
Niewidoczna dla klientów zmiana nazwy przeprowadzona wcześniej w tym oknie zmieniła nazwę funkcji w całym serwisie. Ten sam produkt, to samo zachowanie; stare sformułowanie uruchamiało filtry zasad platform reklamowych.
Nie publikujemy jeszcze danych liczbowych dotyczących nowej logiki wyboru. Chcemy dwóch pełnych tygodni ruchu produkcyjnego, zanim zaczniemy deklarować wskaźniki sukcesu. Rzeczywiste liczby podamy, gdy będziemy je mieć.
Ostatni miesiąc spędziliśmy na przebudowie warstwy decydującej o tym, którego proxy użyć dla danego celu. Trudnością nie jest sam algorytm, lecz zmierzenie, czy rzeczywiście pomaga on przy realnych obciążeniach. Tak właśnie wygląda maj.