Na naszych portach mobile proxy PL widać jeden powtarzalny wzorzec: firmy nie scrapują "internetu w ogóle", tylko konkretne polskie serwisy rejestrowe i urzędowe. Największy wolumen idzie w wyszukiwarkę REGON GUS (wyszukiwarkaregon.stat.gov.pl). Zaraz za nią: Przeglądarka Dokumentów Finansowych / RDF, SUDOP UOKiK, EKW, Portal Rejestrów Sądowych / e-KRS, CEIDG, orzeczenia NSA i Eureka MF.
Dane publiczne - limity, blokady ASN datacenter i wymaganie geo PL są jak najbardziej realne. Ten tekst jest mapą tych ośmiu źródeł i praktyką zbierania ich przez mobile proxy z polskich operatorów, bez obchodzenia prawa: rate limity, cache, normalna identyfikacja sesji.
- Które serwisy realnie generują ruch (kolejność wg wolumenu klientów)
- Dlaczego datacenter IP pada na stat.gov.pl, ms.gov.pl i uokik.gov.pl
- Jak układać limity, sticky sesje i cache pod każdy typ źródła
- Kiedy mobile proxy PL obniża liczbę 429 i banów ASN
Co scrapują klienci na proxy PL (kolejność ważności)
To nie jest lista "teoretycznie ciekawych API". To serwisy, które w praktyce widać w ruchu firmowym: windykacja, KYC/AML, due diligence, monitoring kontrahentów, kancelarie, fintech, analytics. Pipeline zwykle zaczyna się od identyfikatora (NIP, REGON, KRS, numer KW), potem dokłada dokumenty finansowe, pomoc publiczną, księgę wieczystą, wpis sądowy, CEIDG, orzecznictwo i interpretacje MF.
Publiczny charakter danych nie oznacza nieskończonej pojemności po stronie GUS, MS, UOKiK czy MF. Po kilkuset szybkich hitach z IP Hetznera/AWS dostajesz 429, captchę albo cichy drop. Mobile IP z Play/Plus/Orange/T-Mobile w PL wygląda jak abonent komórkowy w kraju - i przy rozsądnym tempie żyje znacznie dłużej.
Wyszukiwarka REGON GUS (wyszukiwarkaregon.stat.gov.pl)
To numer jeden pod względem wolumenu u naszych klientów. Wyszukiwarka REGON na domenie wyszukiwarkaregon.stat.gov.pl to domyślny start: NIP → REGON, status podmiotu, adres, PKD, data powstania/zakończenia. Bulk-check kontrahentów i nocne odświeżanie bazy CRM leci właśnie tutaj.
Technicznie bywa kapryśna przy automatyce: sesje, tokeny formularza, throttling per IP. Typowy błąd to "jak najszybciej 10 rps z jednego VPS w DE". Po krótkiej chwili padają limity. Lepiej: sticky IP na batch (np. 50-200 NIP-ów), 0,3-1,5 rps z jitterem, lokalny cache po NIP/REGON z TTL 24h-7d. REGON podmiotu aktywnego nie zmienia się co minutę - pełny rescan bez TTL tylko pali IP.
Geo PL ma tu znaczenie: ruch z polskiego mobile ASN rzadziej wpada w reguły "hosting spoza PL". Po jobie warto potwierdzić exit przez What Is My IP - typ mobile, kraj PL.
Przeglądarka Dokumentów Finansowych KRS / RDF (rdf-przegladarka.ms.gov.pl)
Drugie źródło pod względem obciążenia: Przeglądarka Dokumentów Finansowych / Repozytorium Dokumentów Finansowych na rdf-przegladarka.ms.gov.pl. Stąd schodzą sprawozdania finansowe, uchwały i załączniki powiązane z KRS. Pliki są ciężkie; scraper, który co noc ściąga te same PDF od zera, wygląda agresywnie i marnuje pasmo.
Praktyka: najpierw metadane / lista dokumentów, potem download tylko brakujących (hash pliku w storage). Sesja sticky na czas pobrania pakietu dla jednej spółki. Nie rotuj IP między "lista" a "pobierz PDF" - gubisz kontekst i generujesz błędy 4xx. Rate limit trzymaj niższy niż przy lekkim REGON: PDF to inna klasa obciążenia serwera MS.
SUDOP UOKiK (api-sudop.uokik.gov.pl)
SUDOP (System Udostępniania Danych o Pomocy Publicznej) UOKiK, w tym endpointy wokół api-sudop.uokik.gov.pl, to źródło o pomocy publicznej: kto dostał wsparcie, na jakich zasadach, w jakiej skali. Compliance, due diligence M&A i risk lubią to dokładać do karty kontrahenta.
Tu często jest warstwa API - zanim postawisz HTML-scraper, sprawdź oficjalny kanał i limity dokumentacji. Przy automatyce trzymaj się budżetu zapytań, loguj 429/5xx i nie maskuj floodu rotacją. Mobile PL nadal pomaga przy UI/WAF wokół domen uokik.gov.pl, ale sensowny klient API + cache po identyfikatorze podmiotu załatwia większość wolumenu bez dramatu.
Elektroniczne Księgi Wieczyste EKW (przegladarka-ekw.ms.gov.pl)
Przeglądarka EKW na przegladarka-ekw.ms.gov.pl to Elektroniczne Księgi Wieczyste: treść KW, działy, wzmianki. Ruch bywa skokowy (due diligence nieruchomości, windykacja, bankowość), a interfejs bywa wrażliwy na sesję i tempo.
Zasada: jeden sticky IP na jedną księgę / krótki batch numerów KW. Nie parallelizuj agresywnie dziesiątek KW z jednego portu. Cache wyników z krótkim TTL (dane KW bywają bardziej "na teraz" niż REGON, ale i tak nie odpytujesz tej samej KW co 10 sekund w pętli produkcyjnej bez powodu). Captcha i limity pojawiają się szybciej przy datacenter spoza PL niż przy polskim mobile.
Portal Rejestrów Sądowych / e-KRS (prs.ms.gov.pl)
Portal Rejestrów Sądowych i wyszukiwarka KRS na prs.ms.gov.pl (e-KRS) to klasyczny wpis sądowy: reprezentacja, kapitał, status, odpisy. Często idzie w tandemie z REGON (najpierw identyfikacja w GUS, potem potwierdzenie w KRS) i z RDF (dokumenty finansowe).
Bulk odpisów pali sesje. Trzymaj cache po numerze KRS, rozdziel lekkie wyszukiwanie od ciężkiego pobierania odpisów, backoff przy 429. Mobile proxy PL + sticky na podmiot ogranicza wpadki "sesja związana z IP, a Ty rotujesz co request".
CEIDG i biznes.gov.pl
CEIDG (i ścieżki przez biznes.gov.pl) - JDG: NIP, REGON, PKD, zawieszenie, adres wykonywania. Nadal istotny wolumen, choć w naszym ruchu poniżej REGON/RDF/SUDOP/EKW/PRS. Formularze i tokeny lubią psuć headless bez zachowania ścieżki kroków.
Krótkie bursty, pauzy, sticky na sesję formularza. Cache dzienny zwykle wystarcza do monitoringu statusu działalności. Oficjalne kanały / API tam gdzie są - HTML tylko na luki.
Orzeczenia NSA (orzeczenia.nsa.gov.pl, CBOSA)
Serwis orzeczenia.nsa.gov.pl (orzecznictwo, w tym kontekst CBOSA) to pełnotekstowe orzeczenia sądów administracyjnych. Kancelarie i działy podatkowe scrapują pod research, nie pod "10 000 NIP/h". Inny profil: dłuższe sesje, wyszukiwanie po frazach, pobieranie treści wyroków.
Tu liczy się stabilna sesja i niski RPS bardziej niż agresywna rotacja. Mobile PL pomaga przy dłuższym researchu z biura/scraperów w chmurze, które inaczej wychodzą z zagranicznego DC. Cache po ID orzeczenia; nie redownloaduj tego, co już masz w korpusie.
Interpretacje podatkowe Eureka MF (eureka.mf.gov.pl)
Eureka MF na eureka.mf.gov.pl - baza interpretacji podatkowych Ministerstwa Finansów. Wolumen mniejszy niż REGON, ale stały u tax/legal. Wyszukiwanie + treść interpretacji; podobnie jak NSA: research, nie hurtowy scoring NIP.
Praktyka jak przy orzeczeniach: spokojne tempo, sticky, cache po sygnaturze/ID, brak rotacji w środku paginacji wyników. Datacenter IP bywa tu wycinany wcześniej przy masowych crawlerach "ściągnij całą bazę w weekend".
Dlaczego datacenter przegrywa, a mobile PL trzyma sesję
Wspólny mianownik REGON, RDF, SUDOP, EKW, PRS, CEIDG, NSA i Eureki:
- ASN hostingowy - AWS, GCP, Azure, OVH, Hetzner lądują na listach "cloud". Masowy ruch taniej uciąć niż analizować każdy request.
- Geo poza PL - zapytanie do stat.gov.pl / ms.gov.pl z Singapuru podnosi score ryzyka.
- Rate limit per IP - 429 po N req/min; jeden VPS kończy job w kwadrans.
- Sesja ↔ IP - rotacja co URL psuje formularze REGON, EKW, CEIDG bardziej niż pomaga.
Mobile proxy 4G/5G ProxyPoland wychodzi z modemów i kart SIM polskich operatorów. ASN komórkowy, CGNAT (wielu abonentów za jednym publicznym IP), geo PL. To nie czary: 50 rps w wyszukiwarkę REGON i tak złapie limit. Przy 0,2-2 rps na sesję, jitterze i cache ten sam port trzyma joby godzinami i dniami.
Dobre praktyki wspólne (bez obchodzenia prawa)
Scrapowanie publicznych rejestrów i baz orzeczeń/interpretacji w celach analitycznych i compliance jest codziennością firm w PL. To nie jest instrukcja ataku ani omijania zakazów. Cel: mniej obciążenia urzędów i mniej banów u Ciebie.
- Kolejność jobów jak w wolumenie - najpierw REGON (identyfikacja), potem RDF/PRS/EKW wg potrzeby, SUDOP/CEIDG/NSA/Eureka jako warstwy dodatkowe - nie wszystko na raz z jednego IP.
- Cache z TTL - NIP/REGON/KRS/KW/ID dokumentu; pole
fetched_at. - Sticky na podmiot lub krótki batch, rotacja między batchami lub po limicie - nie po każdym GECIE CSS.
- Backoff na 429 (30s → 2 min → 10 min), nie natychmiastowa zmiana IP i ten sam młot.
- Oficjalne API tam gdzie jest (m.in. okolice SUDOP) - HTML na luki.
- Nagłówki i cookies jak przeglądarka, realny User-Agent, zachowana ścieżka kroków formularza.
- Metryki - status HTTP, latency, captcha/WAF per host (regon vs rdf vs ekw osobno).
Protokół: HTTP(S) do lekkiego HTML; SOCKS5 gdy pełny Playwright/Puppeteer na ciężkim UI. Skala: jeden port mobile + cache = setki REGON/dzień; tysiące i równoległe PDF z RDF = kilka portów z osobnymi kolejkami (osobny budżet RPS na REGON vs PDF).
Podsumowanie
Jeśli Twój scraper celuje w realny polski stack - wyszukiwarkaregon.stat.gov.pl, rdf-przegladarka.ms.gov.pl, api-sudop.uokik.gov.pl, przegladarka-ekw.ms.gov.pl, prs.ms.gov.pl, CEIDG/biznes.gov.pl, orzeczenia.nsa.gov.pl, eureka.mf.gov.pl - węższym gardłem jest reputacja IP i tempo, nie sam parser. Datacenter spoza PL spala się szybko. Mobile proxy z polskich operatorów daje geo PL, ASN komórkowy i CGNAT, przy których limity i cache działają w skali dni i tygodni.
Ułóż joby w kolejności wolumenu, cache'uj identyfikatory, trzymaj niski RPS na PDF i EKW. ProxyPoland: dedykowane porty 4G/5G na polskich modemach - trial, sprawdzenie exit IP, potem produkcja. Plany i trial · sprawdź IP
Przy jobach na REGON i RDF trzymaj osobne limity RPS i nie mieszaj ich z pobieraniem PDF z EKW w tej samej kolejce. W praktyce około 1 zapytanie na kilka sekund na ścieżkach formularzy plus cache NIP/REGON mocno tnie powtórne hit-y. Zanim dodasz kolejne porty, zmierz, ile unikalnych identyfikatorów realnie potrzebujesz w oknie 24 h - często okazuje się, że wystarczy mniejszy pool i dłuższy sticky zamiast agresywnej rotacji.
Joby na CEIDG/biznes.gov.pl i eureka.mf.gov.pl trzymaj w osobnej kolejce od EKW PDF. Formularze znoś z cache NIP/REGON i tempem około jednego zapytania na kilka sekund; PDF z EKW zostaw na nocny niski RPS. Zanim dokupisz porty, policz unikalne identyfikatory w oknie 24 h. Często wystarcza mniejszy pool i dłuższy sticky na polskim LTE, a logi wtedy pokazują, czy pada limit, czy reputacja IP.
Czy jeden port 4G wystarczy na REGON, RDF i EKW naraz? Na mały wolumen tak, ale trzymaj osobne kolejki i limity RPS. Formularze REGON/RDF: ok. 1 zapytanie na kilka sekund plus cache NIP/REGON. PDF z EKW: nocny niski RPS, bez mieszania z formami na tej samej sesji sticky. Zanim dokupisz porty, policz unikalne identyfikatory w oknie 24 h.
Często wystarcza mniejszy pool i dłuższy sticky na polskim LTE; logi wtedy pokazują, czy pada limit, czy reputacja IP.
Joby CEIDG i eureka.mf.gov.pl trzymaj w dziennej kolejce z cache NIP i tempem około jednego zapytania na kilka sekund, a SUDOP oraz ciężkie PDF z EKW w nocnej z niższym RPS. Nie mieszaj bulk PDF z formularzami na tej samej sesji sticky - logi wtedy sklejają limit z reputacją IP. Zanim dokupisz porty, policz unikalne identyfikatory z 24 h i odsetek hitów, które mógłby złapać lokalny cache.
Na polskim 4G często wystarcza mniejszy pool i dłuższy sticky; najpierw domknij kolejki, potem skaluj porty.
Poranna paczka 80-120 NIP-ów do REGON/CEIDG i popołudniowa paczka PDF z e-KRS/EKW. Rano trzymaj jedną sticky 4G z cache NIP i tempem ok. 1 zapytanie na 3-5 s; po południu osobna sesja sticky tylko pod PDF, RPS niższe. Trzymaj obie kolejki osobno - nie na tym samym porcie w tym samym oknie, bo logi sklejają limit formularza z banem na bulk PDF.
Po 24 h policz unikalne NIP i odsetek hitów z lokalnego cache; jeśli cache łapie powyżej ~40%, najpierw podnieś TTL cache, nie liczbę portów.
Policzmy przepustowość jednego portu 4G. Przy tempie 3-5 s na zapytanie wychodzi jakieś 700-1200 wejść formularzowych na godzinę. Paczka 80-120 NIP-ów z cache zamyka się więc w kilkanaście minut, nie w godziny. Skoro PDF z EKW waży zwykle od kilkuset KB do kilku MB, 100 plików przy niskim RPS schodzi w około pół godziny nocnego okna.
Stąd prosty próg: drugi port dokupujesz dopiero wtedy, gdy unikalne identyfikatory z doby przekraczają możliwości jednego portu, nie przy pierwszych 429.
Nowy scenariusz, którego nie ma w porannym batchu księgowym: nocny monitoring stałej listy kontrahentów. Trzymasz 200-400 NIP-ów, które już znasz, i raz na dobę odpytujesz REGON albo CEIDG tylko po status: aktywny, zawieszony albo wykreślony. Całą listę jedziesz na jednej sticky 4G, bez rotacji w środku, bo formularz GUS potrafi zrzucić sesję po zmianie IP. Zapisujesz wyłącznie delty względem wczorajszego snapshotu.
Dopiero po domknięciu listy możesz zrotować port i ruszyć osobną kolejkę PDF. Inaczej logi znowu skleją spokojne sprawdzenie statusu z banem na EKW.
Nowy scenariusz pod oferty i wnioski o dofinansowanie: weryfikacja SUDOP po jednym NIP, zanim wyślesz papiery. Identyfikator masz już z REGON albo CEIDG, więc nie odpalaj znowu formularza GUS. Osobną sticky 4G odpal tylko pod api-sudop.uokik.gov.pl i trzymaj ją z dala od kolejki PDF z EKW oraz od dziennych form CEIDG. Wynik zapisz lokalnie do końca dnia. Jeśli potrzebujesz kolejnego NIP, dokończ bieżącą sesję i dopiero wtedy zrotuj port.
Inaczej logi skleją spokojne sprawdzenie pomocy publicznej z banem na bulk PDF.
Nowy scenariusz, którego nie ma w paczce księgowej ani w nocnym monitoringu, to onboarding jednego nowego kontrahenta przed umową. Masz jeden NIP, nie listę. Na jednej sticky 4G najpierw REGON. Z odpowiedzi weź numer KRS albo potwierdzenie CEIDG i od razu dociągnij ten sam podmiot w rdf-przegladarka.ms.gov.pl. Te dwa kroki zamykają się zwykle w 2-4 minuty, bez rotacji IP w środku.
EKW odpalasz tylko gdy w RDF albo we wniosku jest numer KW i tylko na osobnej sesji. Taki one-shot nie jedzie na porannej kolejce 80-120 NIP-ów.