Ustawiłeś antydetekt do ostatniego parametru. Unikalny canvas, uczciwy WebGL, schludne czcionki, rozdzielone strefy czasowe, czyste cookies. A i tak konto łapie captchę na każdym kroku, a po dniu przychodzi ban. Znana sytuacja? W pierwszej kolejności obwiniamy odcisk palca: sprawdzamy zestaw entropii, kręcimy wersje przeglądarki, zmieniamy user-agent. Czasem to pomaga. Ale często problem leży zupełnie gdzie indziej i warto zająć się nim wcześniej niż subtelnościami odcisku.

Jest nieprzyjemny fakt, o którym wielu dowiaduje się na własnej skórze. Strona może wyrobić sobie o Tobie opinię zanim w ogóle zobaczy Twoją przeglądarkę. Nie po cookie, nie po odcisku, nie po zachowaniu. Tylko po adresie IP, z którego przyszło zapytanie. Sprawdzenie trwa milisekundy i odbywa się na najwcześniejszym etapie przetwarzania połączenia. Jeśli adres jest znany jako problematyczny, dalej nie ma znaczenia, jak czysto ustawiony jest Twój profil.

W tym artykule przyjrzymy się, jak działają publiczne listy blokujące, dlaczego tanie proxy trafiają na nie latami, czym zasadniczo różni się mobilny IP i jak sprawdzić swoje adresy, zanim zaczną palić konta. Piszemy spokojnie, z prawdziwymi liczbami i żywym przykładem odpowiedzi API. Bez obietnic omijania konkretnych platform i bez przesadnych zachwytów.

Dlaczego ban przychodzi wcześniej, niż myślisz

Typowy scenariusz wygląda tak. Podnosisz sesję, otwierasz docelową platformę i zamiast treści dostajesz 403 lub nieskończoną captchę. Logika podpowiada szukać przyczyny w świeżych ustawieniach przeglądarki. Ale rozłóżmy sekwencję zdarzeń krok po kroku.

Kiedy przeglądarka nawiązuje połączenie, serwer otrzymuje adres IP źródła, zanim odda choć jeden bajt treści. Na tym etapie system antyfraudowy może sprawdzić wewnętrzne i zewnętrzne listy reputacji. Wiele z tych list jest publicznych i aktualizowanych codziennie. Jeśli Twój adres jest na nich, strona już od początku jest do Ciebie nieufna. Dalej wydarzenia rozwijają się jedną z dwóch dróg.

  • Zwiększona nieufność. Pokazują Ci captchę, ograniczają częstotliwość działań, żądają potwierdzenia telefonicznego. Konto żyje, ale każdy krok to walka.
  • Bezpośrednia odmowa. 403 na wejściu, natychmiastowa blokada rejestracji, shadow ban świeżo utworzonego profilu. Przeglądarka nie jest nawet dopuszczana do prawdziwej interakcji.

Kluczowa myśl: odcisk palca jest sprawdzany później. Najpierw – sieć. A jeśli latami wykańczasz odcisk, ale bierzesz adresy ze wspólnego kotła, optymalizujesz drugi etap, oblewając pierwszy. Stąd praktyczny wniosek, do którego będziemy wracać: reputację IP trzeba sprawdzać przed użyciem, a nie po pierwszym banicji.

Jak działają publiczne listy blokujące

Istnieje cały ekosystem otwartych feedów – regularnie aktualizowanych list adresów IP, pogrupowanych według typu zagrożenia. Początkowo tworzono je dla bezpieczeństwa sieci: administratorzy podłączają je do firewalli, aby odcinać skanery, boty spamowe i znane źródła ataków. Ale skoro listy są publiczne, korzysta z nich każdy, w tym antyfraud docelowych stron.

Wewnątrz tego ekosystemu jest osobna grupa feedów, która kataloguje właśnie otwarte proxy, węzły anonimizujące i tym podobne usługi. Wymieńmy konkretne pliki, żeby rozmowa była konkretna:

  • firehol_proxies.netset – zbiorczy zestaw adresów zauważonych jako otwarte proxy.
  • socks_proxy.ipset – lista serwerów SOCKS, dostępna w wycinkach czasowych 1, 7 i 30 dni.
  • sslproxies.ipset – katalog serwerów SSL.
  • tor_exits.ipset – węzły wyjściowe sieci anonimizującej.

Zwróć uwagę na wycinki 1/7/30 dni w socks_proxy. To znaczy, że adres jest rejestrowany nie jednorazowo, ale z historią. Nawet jeśli proxy przestało odpowiadać dzisiaj, w tygodniowym i miesięcznym wycinku nadal figuruje. Dla antyfraudu to wygodne: świeża etykieta łapie aktywne adresy, a historyczne wycinki odcinają tych, którzy próbują przeczekać.

W naszym projekcie IPGuardian agregujemy ten ekosystem w całości. Aktualne liczby na 2026 rok: 162 źródła list blokujących, 8 kategorii, codzienna aktualizacja. Kategoria „anonimizatory” składa się z 17 źródeł i zawiera 4,88 mln adresów – to największa kategoria w bazie. Dla porównania: kategoria abuse liczy około 1,6 mln adresów, a ataki – około 497 tys. Anonimizatorów jest więcej niż abuse i ataków razem wziętych.

Łącznie we wszystkich kategoriach to 7,11 mln pojedynczych adresów IP plus 356 tys. podsieci, co w przeliczeniu daje ponad 2,1 mld pokrytych adresów. Niezawodność aktualizacji utrzymuje się na poziomie 94,4% udanych synchronizacji w ciągu miesiąca. To nie abstrakcyjna wystawa liczb, ale taka ilość danych, z którą porównuje się każdy, kto podłączył otwarte feedy do swojego antyfraudu.

Demonstracja: bierzemy adres z darmowej listy

Teoria jest dobra, ale spójrzmy na prawdziwą odpowiedź. Weźmy adres, który leży w publicznie dostępnej liście proxy, i przepuśćmy go przez sprawdzenie. Zapytanie jest niezwykle proste:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"1.20.254.32"'

Odpowiedź (w skrócie):

  • "found": true
  • {"filename": "socks_proxy.ipset", "category": "anonymizers"}
  • {"filename": "socks_proxy_7d.ipset", "category": "anonymizers"}
  • {"filename": "firehol_proxies.netset", "category": "anonymizers"}
  • {"filename": "stopforumspam.ipset", "category": "abuse"}

Przeanalizujmy, co widzimy. Pole found: true od razu mówi: adres jest znany. Dalej idzie lista źródeł. Pierwsze trzy wiersze są oczekiwane – to etykiety anonimizatorów. Adres figuruje jako serwer SOCKS w świeżym i tygodniowym wycinku, a także w zbiorczym zestawie otwartych proxy. Nic dziwnego: to naprawdę proxy z otwartej listy.

A teraz spójrz na ostatni wiersz. stopforumspam.ipset, kategoria abuse. To już nie „proxy”. To etykieta źródła spamu. Adres trafił do bazy platformy, która zbiera dane o spamowych rejestracjach i nadużyciach na forach. To znaczy, że przez ten IP ktoś nie tylko chodził anonimowo, ale wykonywał działania, które otrzymały etykietę abuse.

I tutaj zaczyna się najważniejsza różnica, dla której warto czytać dalej.

Dwie różne etykiety, dwa różne losy konta

Etykiety w listach blokujących nie są równoważne. Z punktu widzenia antyfraudu jest duża różnica między „to proxy” a „to źródło nadużyć”.

Etykieta „oznaczony jako proxy”

Kategoria anonymizers mówi stronie: połączenie idzie przez pośredni węzeł, prawdziwe pochodzenie jest ukryte. Reakcja jest zwykle powściągliwa – zwiększona nieufność. Pokażą Ci captchę, poproszą o potwierdzenie, ograniczą limity. Nieprzyjemne, ale można z tym pracować. Wielu legalnych użytkowników chodzi przez firmowe bramki i całkowite cięcie takiego ruchu jest ryzykowne dla samej strony.

Etykieta „oznaczony jako spam/abuse”

Kategorie abuse i spam to inna rozmowa. Tutaj strona widzi nie tylko ukrywanie, ale historię szkodliwych działań z konkretnego adresu. Reakcja jest ostrzejsza: natychmiastowa blokada, odmowa rejestracji, ban na wejściu. Logika jest prosta – z tego IP już wcześniej przychodziło coś złego, po co ryzykować ponownie.

Problem tanich proxy polega na tym, że zbierają obie etykiety naraz. Przez publiczne lub współdzielone proxy latami chodzą wszyscy: ktoś scrapuje, ktoś spamuje, ktoś rejestruje farmy botów, ktoś rozsyła śmieci po forach. Każde takie działanie zostawia ślad i adres obrasta etykietami z różnych kategorii.

Najgorsze adresy w naszej bazie figurują w 32 listach jednocześnie – od razu w kategoriach abuse, anonymizers, attacks i spam. Wyobraź sobie, że bierzesz taki adres dla nowego konta. Strona widzi połączenie, w milisekundy porównuje z listami, odkrywa cały bukiet problematycznych etykiet i zamyka drzwi, zanim Twój idealnie skonfigurowany antydetekt zdążył wyrenderować pierwszą stronę. Taniość proxy w tym momencie zamienia się w spalone konto, stracony czas na rozgrzewkę i, w przypadku arbitrażu, wylany budżet.

Czym zasadniczo różni się mobilny IP

Teraz kluczowy moment – dlaczego adresy mobilne działają inaczej. Nie chodzi o magię, ale o architekturę sieci komórkowych.

Operator wydaje adresy IP abonentom przez technologię CGNAT. Za jednym publicznym adresem operatora siedzi jednocześnie setki żywych abonentów – zwykłych ludzi ze smartfonami, którzy przeglądają feed, płacą za usługi, logują się do komunikatorów i na marketplace'y. To prawdziwy ludzki ruch, różnorodny i legalny.

Stąd wynika najważniejsze. Operator nie udostępnia swojego adresu jako otwartego proxy. Nie ma go w socks_proxy.ipset, nie ma go w firehol_proxies.netset, nie ma go w katalogach anonimizatorów – po prostu dlatego, że z natury nie jest publicznym proxy. Skanery, które szukają otwartych portów proxy, nie znajdują takiego adresu i nie umieszczają go na listach.

Co więcej, strona ma silny bodziec ekonomiczny, aby nie blokować takich adresów w całości. Zablokowanie mobilnego IP operatora oznacza odcięcie od razu setek prawdziwych klientów, którzy w tym momencie dzielą ten sam adres. Dla platformy to bezpośrednia strata żywych użytkowników i pieniędzy. Dlatego antyfraud z definicji ostrożniej podchodzi do adresów mobilnych.

Właśnie dlatego mobilne proxy wykazują inną dynamikę pracy z kontami. Jesteś wśród żywego ruchu, a nie we wspólnym kotle anonimizatorów z historią nadużyć.

Ważne zastrzeżenie: mobilny IP to nie pancerz

Tutaj musimy być uczciwi, a to zastrzeżenie wzmacnia materiał, a nie osłabia go. Mobilny IP też może trafić na listy spam lub abuse. Jeśli któryś z abonentów za tym samym adresem CGNAT narozrabiał – rozsyłał spam, włamywał się na cudze konta, prowadził szkodliwą aktywność – adres otrzyma etykietę abuse. Kategoria anonymizers prawdopodobnie go ominie, ale spam/abuse – całkiem możliwe.

Z tego wynika bezpośredni praktyczny wniosek, a nie błogie stwierdzenie „bierz mobilne i śpij spokojnie”. Potrzebne są dwie rzeczy:

  • Sprawdzenie przed użyciem. Zanim puścisz adres w ruch, porównaj go z listami. Niezależnie od tego, czy jest mobilny, czy nie – jeśli wisi na nim etykieta abuse, lepiej dowiedzieć się o tym wcześniej, niż po banicji.
  • Rotacja. Możliwość zmiany adresu, jeśli obecny został splamiony cudzą aktywnością. Sieci mobilne pozwalają na zmianę IP, co jest wbudowanym zabezpieczeniem przed cudzymi błędami.

Żaden typ proxy nie daje stuprocentowej gwarancji. Różnica polega na prawdopodobieństwach i na tym, czy masz narzędzia kontroli. W przypadku adresów mobilnych prawdopodobieństwo trafienia do kotła anonimizatorów jest bliskie zeru ze względów architektonicznych, a ryzyko abuse można zarządzać poprzez sprawdzanie i rotację.

Praktyka: jak sprawdzić swoje adresy

Przechodzimy do najbardziej przydatnej części – jak wbudować sprawdzanie reputacji w swój proces pracy. Dobra wiadomość: do podstawowego sprawdzenia nie są potrzebne ani rejestracja, ani klucz API.

Pojedyncze sprawdzenie przez curl

Najprostszy scenariusz – sprawdzić jeden adres przed uruchomieniem profilu:

  1. Wyślij zapytanie POST na endpoint /api/check.
  2. W treści przekaż adres IP jako string w formacie JSON.
  3. Przeczytaj odpowiedź: pole found, tablica sources z nazwami plików i kategoriami.

Komenda:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"TWOJ_IP"'

Jeśli found ma wartość false – adres nie figuruje w znanych listach, to dobry znak. Jeśli true – spójrz, w jakich dokładnie kategoriach. Etykieta anonymizers jest tolerowana w wielu zadaniach, etykieta abuse lub spam to powód, aby odłożyć adres.

Zbiorcze sprawdzenie do 100 adresów

Kiedy masz pulę kilkudziesięciu adresów, sprawdzanie pojedynczo jest niewygodne. Usługa przyjmuje do 100 adresów w jednym zapytaniu. Szybkość odpowiedzi to 4–5 ms na adres, czyli cała pula stu adresów jest sprawdzana w ułamku sekundy. To pozwala wbudować sprawdzanie bezpośrednio w pipeline, nie czyniąc z niego wąskiego gardła.

Typowy algorytm sprawdzania zbiorczego:

  1. Zbierz listę adresów, które zamierzasz użyć (do 100 na zapytanie).
  2. Wyślij je jednym zapytaniem POST na endpoint sprawdzania.
  3. Przeanalizuj odpowiedź: dla każdego adresu będzie found i lista źródeł.
  4. Odfiltruj adresy z etykietami abuse i spam – nie wpuszczamy ich do pracy.
  5. Adresy z czystą odpowiedzią lub tylko z lekkimi etykietami wysyłaj do rotacji.

Jak czytać odpowiedź

Trzy pola, których naprawdę potrzebujesz:

  • found – wartość logiczna. true oznacza, że adres został znaleziony na co najmniej jednej liście.
  • category – typ zagrożenia. anonymizers, abuse, spam, attacks i inne. Po kategorii rozumiesz wagę problemu.
  • filename – nazwa konkretnego źródła. Przydatne, aby zrozumieć, jak świeża jest etykieta. Na przykład socks_proxy.ipset w porównaniu z socks_proxy_7d.ipset mówi o różnej aktualności.

Sposoby zastosowania: pięć praktycznych scenariuszy

Przeanalizujmy, jak sprawdzanie reputacji wpisuje się w konkretne zadania. Dla każdego scenariusza – dla kogo, po co i jak.

Scenariusz 1. Sprawdzenie przed startem w multiakountingu

Dla kogo: ci, którzy prowadzą dziesiątki i setki profili w przeglądarkach antydetekt.

Po co: odsiać splamione adresy przed utworzeniem konta, aby nie palić rozgrzanych profili na złej sieci.

Jak: przed przypięciem proxy do profilu przepuść adres przez sprawdzenie. Jeśli widzisz abuse lub spam – nie używaj tego adresu do ważnego konta. Prosta zasada oszczędza godziny na odzyskiwaniu banów. Lifehack: trzymaj krótki skrypt, który sprawdza adres w momencie przypisywania do profilu i podświetla problematyczne etykiety.

Scenariusz 2. Higiena puli do scrapowania

Dla kogo: specjaliści od zbierania danych.

Po co: adresy z etykietą anonymizers częściej łapią captchę, co psuje stabilność scrapowania i zawyża koszty jej obsługi.

Jak: przed dużą sesją sprawdź zbiorczo całą pulę. Podziel adresy na trzy grupy: czyste (priorytet), z lekkimi etykietami (rezerwa), z abuse/spam (odrzut). Pracuj głównie na czystej grupie, utrzymując rozsądną szybkość zapytań.

Scenariusz 3. Debugowanie nagłego wzrostu banów w arbitrażu

Dla kogo: arbitrzy ruchu.

Po co: gdy zestaw nagle przestaje działać, ważne jest szybkie zrozumienie, czy problem leży w kreacji, koncie, czy sieci.

Jak: przy wzroście banów najpierw sprawdź adresy. Jeśli obrosły etykietami abuse – przyczyna znaleziona, problem nie leży w kreacjach. To oszczędza budżet, który w innym wypadku poszedłby na nieskończone testy reklam. Insiderska rada: rejestruj historię sprawdzeń, aby widzieć, kiedy dokładnie adres się popsuł.

Scenariusz 4. Odbiór nowych proxy od dostawcy

Dla kogo: wszyscy, którzy kupują proxy.

Po co: sprawdzić jakość puli przed zapłatą lub zaraz po otrzymaniu dostępu.

Jak: otrzymawszy testowy dostęp, przepuść wydane adresy przez sprawdzenie zbiorcze. Wysoki udział etykiet anonymizers i abuse w puli to sygnał, że płacisz za wspólny kocioł. To obiektywne kryterium zamiast obietnic sprzedawcy.

Scenariusz 5. Automatyczna rotacja według reputacji

Dla kogo: specjaliści od automatyzacji.

Po co: nie tylko zmieniać adres co jakiś czas, ale zmieniać go, gdy reputacja się pogorszyła.

Jak: wbuduj okresowe sprawdzanie bieżącego adresu w swój pipeline. Gdy tylko pojawi się na nim etykieta abuse (na przykład inny abonent za tym samym CGNAT narozrabiał) – zainicjuj rotację. Szybkość 4–5 ms na adres pozwala robić to bez opóźnień w głównym procesie.

Typowe błędy i jak ich unikać

Zebraliśmy częste potknięcia, które widzimy w praktyce.

  • Sprawdzanie adresu dopiero po banicji. W tym momencie konto już jest stracone. Sprawdzanie powinno być przed startem, a nie pośmiertne.
  • Uważanie mobilnego IP za niezniszczalny. Już to omówiliśmy: etykieta abuse jest możliwa również na adresie mobilnym. Sprawdzaj też pule mobilne.
  • Ignorowanie nazwy źródła. Etykieta w wycinku tygodniowym i świeża to inny poziom aktualności. Patrz na filename, a nie tylko na kategorię.
  • Gonienie za taniością puli. Oszczędność na proxy zamienia się w koszty odzyskiwania banów i wylany budżet testowy. Licz pełny koszt.
  • Nierozróżnianie kategorii etykiet. anonymizers i abuse wymagają różnej reakcji. Pierwszą czasem można tolerować, drugą – prawie nigdy.

Kombinacje z innymi narzędziami

Sprawdzanie reputacji nie zastępuje reszty higieny, ale ją uzupełnia. Jak to się łączy:

  • Przeglądarka antydetekt + sprawdzanie IP. Odcisk zamyka poziom behawioralny i techniczny, sprawdzanie IP – sieciowy. Razem zamykają oba etapy, na których ocenia Cię antyfraud.
  • System zarządzania profilami + sprawdzanie zbiorcze. Przypisuj adresy do profili dopiero po filtracji pod kątem reputacji. Sprawdzanie 100 adresów na zapytanie łatwo wpiąć w ten krok.
  • Skraper + rotacja według reputacji. Niech skraper otrzymuje z puli tylko czyste adresy, a zepsute automatycznie idą do odrzutu.

Porównanie podejść: tani proxy kontra mobilny ze sprawdzaniem

Sprowadźmy różnicę do zrozumiałego obrazu, bez wymieniania konkretnych konkurentów.

Współdzielone lub publiczne proxy

  • Często obecne w katalogach anonimizatorów (socks_proxy, firehol_proxies).
  • Nierzadko nosi etykiety abuse i spam z powodu historii używania przez wszystkich.
  • Najgorsze egzemplarze – na 32 listach jednocześnie.
  • Tańsze na wejściu, droższe w efekcie z powodu banów i captchy.

Mobilny IP ze sprawdzaniem reputacji

  • Architektonicznie nieobecny w katalogach otwartych proxy.
  • Znajduje się wśród żywego ruchu abonenckiego przez CGNAT.
  • Stronie nie opłaca się blokować go w całości – za nim są prawdziwi klienci.
  • Ryzyko etykiety abuse pozostaje, ale jest zarządzane przez sprawdzanie i rotację.

Wniosek nie jest taki, że jedna opcja jest „lepsza”, ale że w podejściu mobilnym prawdopodobieństwa są inne i są narzędzia kontroli. To różnica między nadzieją a zarządzanym procesem.

FAQ

Czy potrzebna jest rejestracja, aby sprawdzić adres?

Do podstawowego sprawdzenia przez API rejestracja i klucz nie są wymagane. Wysyłasz zapytanie POST i czytasz odpowiedź.

Ile adresów można sprawdzić w jednym zapytaniu?

Do 100 adresów w jednym zapytaniu. Szybkość przetwarzania to 4–5 ms na adres, cała pula jest sprawdzana w ułamku sekundy.

Jak często aktualizowane są listy?

Codziennie. Niezawodność synchronizacji w ciągu miesiąca to 94,4% udanych aktualizacji. W bazie jest łącznie 162 źródła i 8 kategorii.

Co oznacza found: true?

Adres został znaleziony na co najmniej jednej liście. Dalej spójrz na tablicę sources – są tam wskazane kategorie i nazwy plików, aby zrozumieć wagę problemu.

Czy etykieta anonymizers to wyrok?

Nie. To sygnał zwiększonej nieufności: możliwa captcha i ograniczenia. Znacznie poważniejsze są etykiety abuse i spam – częściej prowadzą do bezpośredniego bana.

Czy mobilne IP mogą trafić na listy blokujące?

Do katalogów otwartych proxy – praktycznie nie, co wynika z architektury sieci komórkowych. Ale na listy spam/abuse mobilny adres może trafić, jeśli ktoś z abonentów za tym samym CGNAT nadużywał. Dlatego sprawdzanie i rotacja są potrzebne również tutaj.

Dlaczego tani proxy w efekcie kosztuje więcej?

Przez współdzielone adresy latami chodzą wszyscy, obrastają etykietami z różnych kategorii. Ban konta, stracona rozgrzewka i wylany budżet testowy kosztują więcej niż różnica w cenie proxy.

Jak wbudować sprawdzanie w automatyzację?

Wysyłaj zbiorcze zapytanie na etapie przypisywania adresów do profili i okresowo sprawdzaj aktywne adresy. Gdy pojawi się etykieta abuse, inicjuj rotację.

Co jest ważniejsze – odcisk palca czy reputacja IP?

Oba są ważne, ale są sprawdzane na różnych etapach. Reputacja IP jest oceniana wcześniej, przed renderowaniem przeglądarki. Idealny odcisk nie uratuje, jeśli adres już jest na czarnych listach.

Ile adresów obejmuje baza?

7,11 mln pojedynczych IP plus 356 tys. podsieci, co w przeliczeniu daje ponad 2,1 mld pokrytych adresów. Największa kategoria to anonimizatory – 4,88 mln adresów.

Wnioski: od czego zacząć

Zbierzmy obraz w całość. Ban konta to nie zawsze historia o odcisku palca. Często przyczyną jest reputacja samego IP, znana stronie jeszcze przed pierwszym zapytaniem. Publiczne feedy katalogują otwarte proxy i anonimizatory, a historia nadużyć dodaje do adresów etykiety abuse i spam. Tanie proxy zbierają oba typy etykiet, a najgorsze z nich figurują na 32 listach jednocześnie.

Mobilne IP działają inaczej: za adresem CGNAT operatora siedzą setki żywych abonentów, taki adres nie trafia do katalogów otwartych proxy, a blokowanie go w całości nie opłaca się stronie. Ale i mobilny adres to nie pancerz – etykieta abuse jest możliwa również tutaj. Dlatego praktyka pracy jest jedna i ta sama niezależnie od typu proxy: sprawdzaj reputację przed użyciem i rotuj przy pogorszeniu.

Komu jest to szczególnie potrzebne: specjalistom od multiakountingu, scrapowania, automatyzacji i arbitrażu – wszystkim, którzy pracują z pulami adresów i płacą za każde spalone konto czasem i pieniędzmi.

Jak zacząć od razu:

  1. Weź adresy, których używasz, i przepuść je przez sprawdzenie API – bez rejestracji i klucza. Jeden adres przez curl lub pakiet do 100 adresów na zapytanie.
  2. Odfiltruj adresy z etykietami abuse i spam. Oceń, ile z Twojej puli tak naprawdę jest problematycznych.
  3. Zbuduj proces tak, aby do pracy szły tylko sprawdzone adresy, a zepsute trafiały do rotacji.

Jeśli nie chcesz składać zestawu z osobnych narzędzi, sprawdzanie reputacji jest już wbudowane w mobileproxy.space. Otrzymujesz mobilne adresy i możliwość porównania ich z listami w ramach jednego procesu pracy – jako gotowe rozwiązanie tego samego zadania, od którego zaczęliśmy: dowiedzieć się o problemie przed banem, a nie po nim.