Serwer proxy nie odpowiada: diagnoza timeoutów, portów i firewalla krok po kroku

Wprowadzenie: co zyskasz dzięki temu poradnikowi

Sytuacja znana każdemu, kto pracuje z proxy: wczoraj wszystko śmigało, a dziś przeglądarka kręci kółkiem ładowania, skrypt do scrapowania zawiesza się na pierwszym żądaniu, a przeglądarka antydetekcyjna pisze, że serwer proxy nie odpowiada. Brak zrozumiałych komunikatów, tylko oczekiwanie i cisza. Chcesz od razu pisać do supportu albo zmieniać dostawcę, ale w większości przypadków przyczyna leży po Twojej stronie i można ją usunąć w dziesięć minut.

Ten praktyczny poradnik pomoże Ci przejść od „nic nie działa” do „połączenie stabilne” bez zgadywania. Omówimy trzech najczęstszych winowajców sieciowych: limity czasu, zamknięte lub nieprawidłowe porty oraz firewall. Nauczysz się określać, gdzie dokładnie zrywa się łańcuch między Twoim komputerem a proxy, i otrzymasz zestaw komend, które w minutę pokażą źródło problemu.

Ważne zastrzeżenie: mówimy tu wyłącznie o przyczynach sieciowych, gdy połączenie w ogóle się nie nawiązuje lub zawiesza. Sytuacje, gdy proxy odpowiada, ale zwraca kod błędu typu 407 czy 502, to osobny temat i nie zajmujemy się nim. Jeśli widzisz konkretny kod HTTP w odpowiedzi, to znaczy, że proxy żyje, a Twój przypadek nie dotyczy tego artykułu.

Dla kogo jest ten poradnik

• Marketerzy i specjaliści SMM, którzy prowadzą kilka kont przez mobilne proxy i spotkali się z tym, że przeglądarka nie łączy się.
• Arbitrażyści, którym nagle przestały działać zestawy, a panele reklamowe nie otwierają się przez proxy.
• Programiści, których skrypty w Pythonie, Node.js lub Go otrzymują timeout zamiast odpowiedzi.
• Właściciele firm, którzy skonfigurowali proxy dla pracowników i chcą zrozumieć, dlaczego u jednego wszystko działa, a u drugiego nie.

Co trzeba wiedzieć wcześniej

Praktycznie nic specjalnego. Wystarczy umieć otworzyć wiersz poleceń lub terminal, kopiować komendy i czytać to, co wyświetlają. Wszystkie terminy wyjaśnimy po drodze. Jeśli nigdy nie otwierałeś terminala, nie martw się: każde działanie jest opisane do poziomu „naciśnij ten klawisz, wpisz ten tekst”.

Ile czasu to zajmie

Pełna diagnoza według wszystkich kroków zajmuje od 30 do 60 minut. Najczęściej problem wykrywa się już na pierwszym lub drugim kroku i wtedy zmieścisz się w 10-15 minutach. Zaawansowany blok na końcu możesz przeanalizować osobno, gdy podstawowe połączenie zostanie już przywrócone.

Przygotowanie wstępne: narzędzia i dane

Zanim zaczniesz, zbierz wszystko, co potrzebne, w jednym miejscu. Oszczędzi to czas i uchroni od biegania między kartami w najmniej odpowiednim momencie.

Dane Twojego proxy

Otwórz panel klienta u dostawcy i zapisz w pliku tekstowym następujące parametry. Będą potrzebne niemal na każdym kroku.

1. Adres serwera (host). To albo nazwa domenowa typu proxy.example.net, albo adres IP typu 185.10.20.30.
2. Port do połączenia HTTP. W mobilnych proxy to często liczba pięciocyfrowa, na przykład 30001 lub 51234.
3. Port dla SOCKS5, jeśli dostawca udostępnia go osobno. Czasem różni się od portu HTTP o jeden lub o kilka tysięcy.
4. Login i hasło do autoryzacji, jeśli używasz logowania danymi uwierzytelniającymi.
5. Lista dozwolonych IP, jeśli masz włączoną autoryzację po adresie IP. Sprawdź, jaki adres jest tam wpisany.
6. Link do zmiany IP oraz informacje o trybie rotacji: według harmonogramu, przez link czy przy każdym żądaniu.

Wskazówka: zapisz te dane nie tylko w menedżerze haseł, ale też w zwykłym pliku tekstowym na czas diagnozy. Będziesz wklejać je do komend dziesiątki razy, a ciągłe przełączanie okien męczy.

Narzędzia, które już masz w systemie

Dobra wiadomość: prawie wszystko potrzebne jest wbudowane w system operacyjny. Nic nie trzeba kupować.

• Windows 10 i 11: PowerShell (znajdź go przez wyszukiwanie w menu Start) oraz wiersz poleceń cmd. W PowerShellu jest komenda Test-NetConnection, która zastąpi Ci osobne narzędzia.
• macOS: aplikacja Terminal (Programy, folder Narzędzia). Narzędzia nc i curl są już zainstalowane.
• Linux (Ubuntu, Debian, Fedora): dowolny terminal. Być może trzeba będzie zainstalować pakiety curl, netcat i mtr przez menedżer pakietów Twojego systemu.

Co warto zainstalować dodatkowo

1. curl dla Windows. W Windows 10 w wersji 1803 i nowszych oraz w Windows 11 curl już jest. Sprawdź: otwórz cmd i wpisz curl --version. Jeśli zobaczysz numer wersji, wszystko w porządku.
2. Drugie urządzenie do porównania: smartfon, drugi laptop lub maszyna wirtualna. To nie program, ale bardzo przydatne narzędzie, o którym powiemy w pierwszym kroku.
3. Dostęp do ustawień routera: adres panelu (najczęściej 192.168.0.1 lub 192.168.1.1) i hasło administratora. Przyda się w piątym kroku.

Kopie zapasowe przed rozpoczęciem

Będziemy zmieniać ustawienia firewalla i być może routera. Przed tym zrób dwie rzeczy, aby zawsze można było wrócić do stanu początkowego.

1. W Windows utwórz punkt przywracania: otwórz wyszukiwanie, wpisz „Tworzenie punktu przywracania”, naciśnij przycisk Utwórz i nadaj mu zrozumiałą nazwę, na przykład „Przed konfiguracją proxy”.
2. Wyeksportuj bieżące reguły firewalla Windows. Otwórz PowerShell jako administrator i wykonaj komendę netsh advfirewall export "C:/firewall-backup.wfw". Plik pojawi się w katalogu głównym dysku C.
3. W panelu routera znajdź sekcję typu „System”, „Konserwacja” lub „Kopia zapasowa” i zapisz plik konfiguracji na komputerze.

Uwaga: nie wyłączaj firewalla całkowicie „na wszelki wypadek” i nie zostawiaj go wyłączonego. Podczas diagnozy będziemy wyłączać ochronę maksymalnie na dwie minuty, aby sprawdzić hipotezę, a potem wszystko przywrócimy i utworzymy precyzyjną regułę.

Podstawowe pojęcia: co się dzieje, gdy proxy nie odpowiada

Aby diagnoza była sensowna, a nie chaotycznym przeszukiwaniem, ważne jest zrozumienie, jak zbudowany jest łańcuch połączenia. Wtedy każdy krok poradnika będzie sprawdzał jeden konkretny odcinek tego łańcucha.

Droga żądania od Ciebie do strony

Gdy pracujesz przez mobilne proxy, żądanie przechodzi taką drogę. Najpierw Twoja aplikacja (przeglądarka, skrypt, antydetekt) wysyła dane do systemu operacyjnego. System przepuszcza je przez swój firewall i przekazuje do routera. Router oddaje ruch Twojemu dostawcy internetu. Dostawca dostarcza pakiety na serwer proxy. Serwer proxy przekierowuje żądanie przez modem mobilny z kartą SIM do sieci operatora komórkowego. I dopiero potem żądanie trafia na docelową stronę. Odpowiedź idzie tą samą drogą w odwrotnej kolejności.

Przerwanie może nastąpić na każdym z tych odcinków. Fraza „serwer proxy nie odpowiada” oznacza tak naprawdę tylko jedno: odpowiedź nie dotarła do Twojej aplikacji w wyznaczonym czasie. Gdzie dokładnie się zgubiła, to właśnie trzeba ustalić.

Port: drzwi do serwera

Każdy serwer ma jeden adres IP, ale wiele portów, numerowanych od 1 do 65535. Wyobraź sobie wielopiętrowy budynek z jednym adresem i tysiącami mieszkań. Usługa proxy „mieszka” w konkretnym mieszkaniu, czyli nasłuchuje na konkretnym porcie. Jeśli pukasz do innego portu, nikt nie otworzy, a Ty będziesz czekać do wygaśnięcia limitu czasu. Serwer przy tym jest całkowicie sprawny.

Porty bywają otwarte, zamknięte i filtrowane. Otwarty port odpowiada na próbę połączenia zgodą. Zamknięty port od razu odpowiada odmową i otrzymujesz natychmiastowy błąd typu „connection refused”. Port filtrowany milczy: Twoje pakiety są wyrzucane po drodze, a Ty nie otrzymujesz nic. Właśnie filtrowanie daje klasyczny obraz zawieszenia bez odpowiedzi, a winowajcą jest prawie zawsze jakiś firewall.

Timeout: jak długo czekać, zanim się poddasz

Timeout to granica oczekiwania, po której aplikacja przestaje próbować i zgłasza błąd. Timeoutów bywa kilka i nie należy ich mylić.

• Timeout połączenia (connect timeout). Jak długo czekać, aż serwer zgodzi się nawiązać łączność. Jeśli minął, to znaczy, że do portu proxy w ogóle nie dotarłeś.
• Timeout odczytu (read timeout). Jak długo czekać na dane po nawiązaniu połączenia. Jeśli minął, to znaczy, że proxy Cię przyjęło, ale docelowa strona lub sieć mobilna odpowiadały zbyt wolno.
• Ogólny timeout żądania. Górna granica na wszystko razem.

Mobilne proxy działają przez sieć komórkową, gdzie opóźnienia są naturalnie większe niż w centrach danych. Jeśli Twój program ma ustawiony timeout na 5 sekund, może się rozłączać na całkowicie sprawnym mobilnym proxy tylko dlatego, że odpowiedź przyszła w szóstej sekundzie.

Firewall: filtr, który decyduje, co przepuścić

Firewall (zapora sieciowa, ściana ogniowa) to program lub urządzenie, które przegląda pakiety sieciowe i decyduje, czy je przepuścić, czy odrzucić. W Twoim łańcuchu firewalli może być trzy lub cztery: wbudowany w Windows lub macOS, wchodzący w skład antywirusa, na routerze i u administratora korporacyjnego. Każdy z nich może po cichu wyrzucić pakiety na niestandardowy port, a Ty zobaczysz jedynie zawieszenie.

Autoryzacja po IP: niewidzialny firewall po stronie proxy

Wielu dostawców mobilnych proxy ma tryb, w którym zamiast loginu i hasła używa się białej listy adresów IP. Serwer przyjmuje połączenia tylko od adresów z listy, a pozostałe próby może po prostu ignorować. Jeśli Twój domowy IP zmienił się (zdarza się to przy restarcie routera u większości dostawców), proxy przestanie Cię rozpoznawać. Zewnętrznie wygląda to dokładnie tak samo jak zablokowany port.

Teraz, gdy obraz jest jasny, przechodzimy do praktyki. Każdy kolejny krok sprawdza jeden odcinek łańcucha i albo zdejmuje z niego podejrzenie, albo znajduje winowajcę.

Krok 1: Ustalamy, gdzie zrywa się połączenie

Cel etapu: w pięć minut zrozumieć, czy problem jest po Twojej stronie, po stronie sieci, czy po stronie proxy. To najważniejszy krok, bo od razu odrzuca połowę możliwych przyczyn.

Sprawdzamy internet bez proxy

1. Otwórz przeglądarkę i tymczasowo wyłącz w jej ustawieniach proxy. W Chrome to Ustawienia, sekcja System, punkt „Otwórz ustawienia proxy komputera”. W przeglądarce antydetekcyjnej utwórz profil bez proxy lub wybierz tryb „Bez proxy” w ustawieniach profilu.
2. Otwórz dowolną dużą stronę, na przykład stronę wyszukiwarki. Powinna załadować się w sekundę-dwie.
3. Jeśli strona nie otwiera się nawet bez proxy, problem nie leży w proxy. Zrestartuj router, sprawdź kabel lub Wi-Fi i wróć do tego poradnika później.

Sprawdzamy proxy z innego urządzenia

1. Weź smartfon i wyłącz w nim Wi-Fi, aby działał przez internet mobilny. Tak znajdziesz się w zupełnie innej sieci, omijając swój router i dostawcę.
2. Zainstaluj na telefonie dowolną przeglądarkę z obsługą proxy lub użyj ustawień systemowych: w Androidzie w właściwościach punktu dostępowego robi się to przez APN, ale prościej zainstalować aplikację-przeglądarkę z ręcznym wprowadzaniem proxy.
3. Wpisz adres, port, login i hasło swojego proxy i otwórz dowolną stronę pokazującą Twój adres IP.
4. Jeśli z telefonu proxy działa, значит samo proxy żyje, a problem jest między Twoim komputerem a internetem: firewall, router lub ustawienia programu. Przejdź do kroków 2, 3, 4 i 5.
5. Jeśli z telefonu też nie działa, problem jest albo w samym proxy, albo w jego ustawieniach autoryzacji. Przejdź do kroku 6, a potem do supportu.

Wskazówka: jeśli nie masz drugiego urządzenia, spróbuj podłączyć komputer do mobilnego punktu dostępowego z telefonu. Zmiana sieci da ten sam efekt co sprawdzenie z innego urządzenia.

Sprawdzamy status proxy w panelu klienta

1. Zaloguj się do panelu klienta u dostawcy mobilnych proxy.
2. Znajdź kartę swojego proxy i spójrz na wskaźnik stanu. U większości usług pokazuje, czy modem jest w sieci i kiedy była ostatnia aktywność.
3. Jeśli wskaźnik pokazuje, że proxy jest wyłączone lub modem nie jest w sieci, dalej nie ma sensu diagnozować: przyczyna leży po stronie sprzętu i rozwiązuje ją support.

Sprawdzenie: pod koniec tego kroku powinieneś mieć odpowiedź na jedno pytanie: czy proxy działa przynajmniej skądkolwiek, czy nie działa znikąd. Zapisz ten wniosek. Określa on, które kroki będą dalej najważniejsze.

Możliwe problemy na tym etapie

Czasem z telefonu proxy działa, a po minucie przestaje. Może to być rotacja IP na proxy lub niestabilna sieć komórkowa modemu. Powtórz sprawdzenie dwa-trzy razy w odstępie minuty, aby nie wyciągnąć fałszywych wniosków z jednej próby.

Krok 2: Sprawdzamy adres i port proxy

Cel etapu: upewnić się, że port proxy jest otwarty i dostępny właśnie z Twojego komputera. To kluczowe sprawdzenie: jeśli port nie odpowiada, wszystko inne jest bez sensu.

Dlaczego ping nie wystarczy

Pierwsza myśl wielu osób: pingować serwer. Ale ping sprawdza tylko dostępność adresu IP po protokole ICMP, a nie otwartość konkretnego portu. Wiele serwerów proxy w ogóle nie odpowiada na ping ze względów bezpieczeństwa. Tak więc udany ping niczego nie gwarantuje, a nieudany nic nie znaczy. Potrzebujemy sprawdzenia właśnie portu TCP.

Sprawdzanie portu w Windows

1. Naciśnij klawisz Windows, wpisz PowerShell i otwórz go.
2. Wpisz komendę, podstawiając swój adres i port:

   Test-NetConnection -ComputerName proxy.example.net -Port 30001

3. Naciśnij Enter i poczekaj. Komenda może myśleć do 20 sekund.
4. Znajdź w wynikach wiersz TcpTestSucceeded. Wartość True oznacza, że port jest otwarty i przyjmuje połączenia. Wartość False oznacza, że nie udało się dotrzeć do portu.
5. Zwróć uwagę na wiersz PingSucceeded. Jeśli jest False, a TcpTestSucceeded True, wszystko w porządku: serwer po prostu nie odpowiada na ping.

Sprawdzanie portu w macOS i Linux

1. Otwórz Terminal.
2. Wpisz komendę:

   nc -zv proxy.example.net 30001

3. Klucz -z mówi narzędziu, aby nie wysyłało danych, a tylko sprawdziło połączenie. Klucz -v włącza szczegółowe wyjście.
4. Odpowiedź typu succeeded lub Connection to ... port 30001 succeeded! oznacza sukces. Odpowiedź Connection refused oznacza, że port jest zamknięty, a serwer od razu odmówił. Jeśli komenda wisi bez odpowiedzi, a potem pisze timed out, port jest filtrowany gdzieś po drodze.

Sprawdzanie przez curl na dowolnym systemie

curl potrafi nie tylko sprawdzić port, ale i od razu wykonać żądanie przez proxy. To kolejny poziom weryfikacji.

1. Wpisz komendę, podstawiając swoje dane:

   curl -x http://login:password@proxy.example.net:30001 --connect-timeout 15 -v https://api.ipify.org

2. Klucz -x ustawia proxy. Klucz -v pokazuje wszystkie etapy połączenia. Klucz --connect-timeout ogranicza oczekiwanie na nawiązanie łączności do 15 sekund.
3. Czytaj wynik od góry do dołu. Wiersz Connected to proxy.example.net oznacza, że port jest otwarty. Wiersz CONNECT api.ipify.org:443 pokazuje, że curl poprosił proxy o ustanowienie tunelu. Jeśli po tym przyszła odpowiedź 200, a na końcu widzisz adres IP, proxy działa w pełni.
4. Jeśli wynik zatrzymał się na wierszu Trying 185.10.20.30:30001... i po 15 sekundach pojawiło się Connection timed out, port jest niedostępny z Twojego komputera.

Wskazówka: jeśli w haśle są znaki specjalne typu @ lub #, curl może nieprawidłowo rozłożyć adres. Użyj osobnego klucza -U dla danych logowania: curl -x http://proxy.example.net:30001 -U login:password ... Tak hasło nie pomiesza się z adresem.

Sprawdzamy protokół i port SOCKS5

Częsty błąd: wskazać port HTTP tam, gdzie program oczekuje SOCKS5, lub odwrotnie. Połączenie się wtedy nawiąże, ale dane nie pójdą, a aplikacja może zwrócić timeout.

1. Sprawdź w panelu dostawcy, jakie porty są przydzielone dla HTTP i dla SOCKS5.
2. Wykonaj sprawdzenie przez curl z protokołem SOCKS5:

   curl -x socks5://login:password@proxy.example.net:30002 --connect-timeout 15 https://api.ipify.org

3. Upewnij się, że w Twojej aplikacji wybrany jest ten sam protokół, co w udanej komendzie curl.

Sprawdzenie: po tym kroku wiesz dokładnie jedno z trzech: port jest otwarty i proxy odpowiada przez curl (wtedy problem jest w ustawieniach Twojej aplikacji, przejdź do kroku 3); port jest otwarty, ale żądanie przez proxy zawiesza się (problem z autoryzacją lub po stronie proxy, krok 6); port nie odpowiada (problem w firewallu lub sieci, kroki 4 i 5).

Możliwe problemy na tym etapie

Jeśli Test-NetConnection zwraca błąd rozwiązywania nazwy, значит komputer nie może zamienić nazwy domenowej na adres IP. Spróbuj podstawić zamiast nazwy adres IP z panelu klienta. Jeśli z IP działa, a z nazwą nie, masz problem z DNS: zmień serwer DNS w ustawieniach karty sieciowej na publiczny i powtórz.

Krok 3: Radzimy sobie z timeoutami w Twoim programie

Cel etapu: upewnić się, że aplikacja daje mobilnemu proxy wystarczająco dużo czasu na odpowiedź, i nauczyć się odróżniać timeout połączenia od timeoutu odczytu.

Mierzymy rzeczywisty czas odpowiedzi

1. Wykonaj komendę curl z wyświetleniem czasu:

   curl -x http://login:password@proxy.example.net:30001 -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s" https://api.ipify.org

   W Windows zamiast /dev/null użyj NUL.
2. Wartość connect pokazuje, w ile sekund nawiązano połączenie TCP z proxy. Norma dla mobilnych proxy: od 0,05 do 0,5 sekundy.
3. Wartość total pokazuje czas całego żądania. Dla mobilnych proxy normalne jest 1-4 sekundy, a w godzinach szczytu sieci komórkowej nawet 6-8 sekund.
4. Powtórz komendę pięć razy i zapisz rozrzut. Jeśli connect jest stale niski, a total czasem skacze do 10 sekund, Twój program musi być przygotowany na takie opóźnienia.

Ustawiamy timeouty w popularnych narzędziach

Python i biblioteka requests

Parametr timeout przyjmuje krotkę dwóch wartości: timeout połączenia i timeout odczytu. Zalecane wartości dla mobilnych proxy: 10 sekund na połączenie i 30 sekund na odczyt.

proxies = {"http": "http://login:password@proxy.example.net:30001", "https": "http://login:password@proxy.example.net:30001"}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

Jeśli podajesz jedną liczbę, na przykład timeout=5, stosuje się ona do obu timeoutów i to częsta przyczyna fałszywych komunikatów, że serwer proxy nie odpowiada.

Node.js i axios

W axios parametr timeout jest jeden i ogólny. Ustaw go na nie mniej niż 30000 milisekund. Dla proxy użyj agenta, na przykład z pakietu https-proxy-agent, i przekaż go w parametrze httpsAgent.

Przeglądarki antydetekcyjne

1. Otwórz ustawienia profilu, sekcję z proxy.
2. Znajdź przycisk sprawdzania połączenia. Jest praktycznie we wszystkich nowoczesnych antydetektach.
3. Zwróć uwagę, w jakim czasie przychodzi wynik. Jeśli sprawdzenie trwa dłużej niż 10 sekund i kończy się niepowodzeniem, a curl przy tym działa, sprawdź w ogólnych ustawieniach przeglądarki parametr timeoutu proxy i zwiększ go.
4. Upewnij się, że w polu protokołu wybrano właśnie HTTP lub SOCKS5 zgodnie z portem, który przeszedł sprawdzenie w kroku 2.

Narzędzia do scrapowania i automatyzacji

W Scrapy odpowiada parametr DOWNLOAD_TIMEOUT, domyślnie 180 sekund, i rzadko bywa problemem. W Puppeteer i Playwright domyślny timeout nawigacji to 30 sekund, ale przy pracy przez wolną sieć komórkową ciężkie strony mogą nie zdążyć: zwiększ do 60 sekund przez parametr timeout w metodzie goto.

Wskazówka: nie ustawiaj zbyt dużych timeoutów. 30-60 sekund na odczyt to rozsądna granica. Jeśli ustawisz 300 sekund, Twój skrypt będzie godzinami wisiał na martwych połączeniach zamiast szybko powtórzyć żądanie.

Odróżniamy timeout połączenia od timeoutu odczytu

To ważne, bo leczy się je różnie.

• Timeout połączenia w curl wygląda jak „Connection timed out after 15001 milliseconds” zaraz po wierszu Trying. W Python requests to wyjątek ConnectTimeout. Leczenie: kroki 4, 5 i 6, bo nie dotarłeś do portu.
• Timeout odczytu w curl wygląda jak „Operation timed out after 30000 milliseconds with 0 bytes received” już po wierszu Connected. W Pythonie to ReadTimeout. Leczenie: zwiększyć timeout odczytu, sprawdzić, czy nie trwa właśnie rotacja IP na proxy, i upewnić się, że docelowa strona jest w ogóle dostępna.

Sprawdzenie: po tym kroku czas odpowiedzi proxy przez curl mieści się w timeoutach Twojej aplikacji z zapasem co najmniej dwukrotnym. Jeśli curl odpowiada w 3 sekundy, w programie powinno być nie mniej niż 10 sekund na odczyt.

Krok 4: Sprawdzamy firewall i antywirus na Twoim urządzeniu

Cel etapu: upewnić się, że oprogramowanie ochronne na komputerze nie blokuje połączeń wychodzących na port proxy, i w razie potrzeby utworzyć precyzyjną regułę zezwalającą.

Szybki test: tymczasowe wyłączenie

Zanim zaczniesz grzebać w regułach, sprawdźmy hipotezę najprostszym sposobem. Wyłączamy ochronę na minutę, powtarzamy sprawdzenie portu, włączamy z powrotem.

1. W Windows otwórz wyszukiwanie, wpisz „Zapora Windows Defender” i otwórz ją.
2. Po lewej naciśnij „Włączanie i wyłączanie zapory Windows Defender”.
3. Dla aktualnie aktywnego profilu sieci (zwykle Prywatna lub Publiczna) wybierz „Wyłącz” i naciśnij OK.
4. Natychmiast wykonaj Test-NetConnection z kroku 2.
5. Od razu przywróć przełącznik do pozycji „Włącz” i naciśnij OK.

Uwaga: nie pracuj z wyłączonym firewallem dłużej, niż potrzeba na jedno sprawdzenie. Jedna komenda zajmuje sekundy, a otwarty system w sieci to realne ryzyko. Jeśli zapomnisz włączyć z powrotem, Windows przypomni powiadomieniem, ale lepiej na tym nie polegać.

Jeśli z wyłączonym firewallem port stał się dostępny, winowajca znaleziony. Jeśli nie, sprawdzamy antywirusa tym samym sposobem: u większości produktów jest punkt „Wstrzymaj ochronę na 5 minut” w menu kontekstowym ikony w zasobniku. Powtórz sprawdzenie portu i przywróć ochronę.

Tworzymy regułę zezwalającą w firewallu Windows

Nie można wyłączyć firewalla na stałe. Zamiast tego utworzymy regułę, która zezwoli właśnie Twojej aplikacji na połączenia wychodzące.

1. Otwórz „Zapora Windows Defender” i po lewej naciśnij „Ustawienia zaawansowane”. Otworzy się okno z rozszerzonymi ustawieniami.
2. W lewej kolumnie wybierz „Reguły dla połączeń wychodzących”.
3. W prawej kolumnie naciśnij „Nowa reguła”.
4. Wybierz typ „Dla programu” i naciśnij Dalej.
5. Wybierz „Ścieżka programu” i przez przycisk Przeglądaj wskaż plik wykonywalny swojej aplikacji: przeglądarki, antydetektu lub interpretera Python. Naciśnij Dalej.
6. Wybierz „Zezwól na połączenie” i naciśnij Dalej.
7. Zaznacz wszystkie trzy profile: Domena, Prywatny, Publiczny. Naciśnij Dalej.
8. Nadaj regule zrozumiałą nazwę, na przykład „Zezwól na proxy dla przeglądarki antydetekcyjnej”, i naciśnij Zakończ.

Alternatywny wariant, jeśli aplikacji jest wiele: utwórz regułę typu „Dla portu”, wybierz protokół TCP, wskaż konkretny port zdalny proxy i zezwól na niego dla wszystkich programów. Aby to zrobić, w czwartym punkcie wybierz „Niestandardowe”, w sekcji „Protokół i porty” wskaż TCP i w polu „Port zdalny” wpisz numer portu proxy.

Sprawdzamy, czy nie ma reguły blokującej

Czasem problem nie polega na braku zezwolenia, ale na istnieniu zakazu, który utworzył antywirus lub polityka korporacyjna.

1. W tym samym oknie ustawień zaawansowanych otwórz „Reguły dla połączeń wychodzących”.
2. Naciśnij nagłówek kolumny „Akcja”, aby posortować listę. Reguły z akcją „Blokuj” znajdą się obok siebie.
3. Przejrzyj je. Jeśli widzisz regułę blokującą Twoją aplikację lub zakres portów, do którego należy port proxy, kliknij ją prawym przyciskiem i wybierz „Wyłącz regułę”.
4. Powtórz sprawdzenie portu.

Firewall w macOS

1. Otwórz Ustawienia systemowe, sekcję Sieć, a następnie Zapora.
2. Jeśli zapora jest włączona, naciśnij Opcje.
3. Upewnij się, że Twoja aplikacja na liście ma status „Zezwalaj na połączenia przychodzące”. Chociaż interesują nas wychodzące, niektóre aplikacje otwierają lokalny port do pracy z proxy.
4. Odznacz „Blokuj wszystkie połączenia przychodzące”, jeśli jest zaznaczone, i powtórz sprawdzenie.

Osobno sprawdź narzędzia firm trzecich typu Little Snitch lub LuLu: kontrolują właśnie ruch wychodzący i mogły kiedyś zapamiętać Twoją odmowę na prośbę o zezwolenie. Znajdź w ich liście reguł swoją aplikację i zezwól na połączenia z adresem proxy.

Firewall w Linux

1. Sprawdź status ufw komendą sudo ufw status verbose. Zwróć uwagę na wiersz Default: jeśli dla outgoing jest deny, połączenia wychodzące są domyślnie blokowane.
2. Zezwól na połączenie wychodzące na port proxy:

   sudo ufw allow out to 185.10.20.30 port 30001 proto tcp

3. Jeśli używasz iptables bezpośrednio, obejrzyj reguły komendą sudo iptables -L OUTPUT -n -v i znajdź wiersze z DROP lub REJECT, pod które trafia Twój ruch.
4. Na serwerach z Dockerem pamiętaj, że kontenery używają osobnej podsystemu sieciowego. Sprawdzaj dostępność portu z wnętrza kontenera, a nie tylko z hosta.

Wskazówka: zapisz dokładny czas, kiedy zmieniałeś reguły firewalla. Jeśli za tydzień coś się zepsuje, szybko przypomnisz sobie, która zmiana mogła być przyczyną, i cofniesz ją przez plik wyeksportowany na etapie przygotowania.

Sprawdzenie: po tym kroku Test-NetConnection lub nc pokazują udane połączenie przy włączonym firewallu i aktywnym antywirusie. Jeśli port jest nadal niedostępny, a przy wyłączonej ochronie też się nie otwierał, problem jest wyżej, na poziomie routera lub sieci. Przejdź do kroku 5.

Krok 5: Sprawdzamy router, sieć korporacyjną i dostawcę

Cel etapu: ustalić, czy sprzęt między komputerem a serwerem proxy nie odrzuca Twojego ruchu, i w razie potrzeby poprawić ustawienia routera lub zmienić sieć.

Patrzymy, gdzie dokładnie giną pakiety

Narzędzie trasowania pokazuje listę węzłów, przez które przechodzą pakiety do serwera. Jeśli pakiety docierają do jakiegoś węzła i dalej znikają, widzisz, czyj to węzeł: Twój router, dostawca czy coś dalej.

1. W Windows otwórz cmd i wykonaj tracert 185.10.20.30, podstawiając IP proxy.
2. W macOS wykonaj traceroute 185.10.20.30. W Linux lepiej użyć mtr -n 185.10.20.30: pokazuje statystyki w czasie rzeczywistym i straty na każdym węźle.
3. Pierwszy wiersz to Twój router. Drugi i trzeci to zwykle sprzęt dostawcy. Dalej węzły szkieletowe, a na końcu serwer proxy.
4. Jeśli odpowiedź przychodzi od wszystkich węzłów oprócz ostatniego, to normalne: serwery proxy często nie odpowiadają na takie żądania. Patrz na straty w środku trasy.
5. Jeśli gwiazdki zaczynają się zaraz po pierwszym węźle, Twój router lub dostawca nie przepuszczają ruchu do tego adresu.

Pamiętaj: trasowanie używa ICMP lub UDP, a nie TCP na potrzebny port, więc pokazuje ogólną dostępność trasy, a nie otwartość portu. To dodatkowe narzędzie, a nie zamiennik sprawdzenia z kroku 2.

Sprawdzamy router

1. Otwórz przeglądarkę i wpisz w pasku adresu adres routera, zwykle 192.168.0.1 lub 192.168.1.1. Login i hasło są wydrukowane na naklejce pod urządzeniem, jeśli ich nie zmieniałeś.
2. Znajdź sekcję o nazwie typu „Bezpieczeństwo”, „Zapora sieciowa”, „Filtrowanie” lub „Kontrola rodzicielska”.
3. Sprawdź, czy nie jest włączone filtrowanie po portach lub URL. Niektóre routery mają predefiniowane profile typu „Wysoki poziom ochrony”, które blokują wszystko oprócz portów 80 i 443. Przełącz na standardowy poziom.
4. Sprawdź sekcję „Kontrola dostępu” lub „Harmonogram”: może być tam reguła ograniczająca internet dla Twojego urządzenia w określonych godzinach.
5. Znajdź ustawienie SPI Firewall lub „Ochrona przed DoS”. Czasem zbyt agresywna ochrona postrzega wiele równoległych połączeń do jednego adresu jako atak i zaczyna je ciąć. Jeśli masz dziesiątki wątków scrapowania, spróbuj tymczasowo wyłączyć tę ochronę i powtórzyć sprawdzenie.
6. Zapisz zmiany i w razie potrzeby zrestartuj router.

Uwaga: nie zmieniaj ustawień routera, których przeznaczenia nie rozumiesz, zwłaszcza w sekcjach WAN i DHCP. Błąd tam pozbawi internetu cały dom lub biuro. Jeśli masz wątpliwości, zrób kopię zapasową konfiguracji, jak opisano w przygotowaniu, i zmieniaj tylko jeden parametr naraz.

Sprawdzamy MTU

MTU to maksymalny rozmiar jednego pakietu danych. Jeśli jest ustawione nieprawidłowo, małe żądania przechodzą, a duże odpowiedzi giną. Objaw charakterystyczny: połączenie z proxy się nawiązuje, małe strony otwierają się, a duże zawieszają.

1. W Windows wykonaj w cmd: ping -f -l 1472 8.8.8.8. Jeśli pakiety przechodzą, MTU 1500 jest w porządku. Jeśli pisze „wymagana fragmentacja”, zmniejszaj liczbę o 10, aż przejdzie.
2. Znajdź w routerze ustawienie MTU (zwykle w sekcji WAN lub Internet) i ustaw znalezioną wartość plus 28.
3. Typowe wartości: 1500 dla zwykłego połączenia kablowego, 1492 dla PPPoE, 1400-1450 dla niektórych kanałów mobilnych i satelitarnych.

Sieć korporacyjna i publiczne Wi-Fi

Jeśli pracujesz w biurze, coworkingu lub hotelu, między Tobą a internetem prawie na pewno stoi korporacyjna brama z własnym firewallem. Takie bramy bardzo często zezwalają tylko na porty 80 i 443 i tną wszystko inne. Pięciocyfrowy port mobilnego proxy przy tym po prostu nie przechodzi.

1. Połącz się z mobilnym punktem dostępowym z telefonu i powtórz sprawdzenie portu. Jeśli zadziałało, winna jest korporacyjna brama.
2. Zwróć się do administratora systemu z konkretnym żądaniem: zezwolić na wychodzące połączenia TCP na taki a taki IP i taki a taki port. Im precyzyjniejsze żądanie, tym szybciej je wykonają.
3. Dowiedz się u dostawcy proxy, czy istnieje możliwość otrzymania portu ze standardowego zakresu, na przykład 443 lub 8080. U wielu usług jest to konfigurowalne.

Dostawca domowy

Dostawcy domowi rzadko blokują porty wychodzące, ale niektórzy tną znane zakresy związane z torrentami lub serwerami pocztowymi. Jeśli po wszystkich sprawdzeniach port nie odpowiada z sieci domowej, ale odpowiada przez internet mobilny, zadzwoń do supportu dostawcy i zapytaj wprost, czy nie filtrują połączeń wychodzących na wskazany port.

Wskazówka: zapisz wynik trasowania i sprawdzenia portu z Twojej sieci oraz z sieci mobilnej w jednym pliku. Gdy będziesz pisać do dostawcy lub administratora, załącz oba wyniki. Skróci to dialog z tygodnia do jednego dnia.

Sprawdzenie: port proxy jest dostępny z Twojej sieci komendą z kroku 2, trasowanie nie pokazuje strat na węzłach dostawcy, a ping z flagą -f przechodzi na rozmiarze 1472. Jeśli wszystkie trzy warunki są spełnione, a proxy nadal nie odpowiada, sprawa leży w jego własnych ustawieniach. Idziemy do kroku 6.

Krok 6: Sprawdzamy ustawienia po stronie proxy

Cel etapu: upewnić się, że serwer proxy przyjmuje właśnie Ciebie: Twój IP jest na białej liście, modem jest w sieci, rotacja nie pokrywa się z Twoimi żądaniami, a limit połączeń nie został przekroczony.

Sprawdzamy autoryzację po IP

To najczęstsza przyczyna, gdy proxy działa z telefonu, ale nie działa z komputera, albo działało wczoraj, a dziś nie.

1. Ustal swój aktualny zewnętrzny IP. Otwórz bez proxy dowolną stronę pokazującą IP lub wykonaj curl https://api.ipify.org w terminalu.
2. Otwórz panel klienta u dostawcy proxy, sekcję z ustawieniami autoryzacji.
3. Porównaj adres z białej listy z Twoim aktualnym adresem. Jeśli się różnią, oto przyczyna: Twój dostawca przydzielił nowy adres po restarcie routera lub według harmonogramu.
4. Zaktualizuj adres na białej liście lub przełącz się na autoryzację loginem i hasłem. Drugi wariant jest pewniejszy, jeśli Twój zewnętrzny IP się zmienia.
5. Poczekaj jedną-dwie minuty: ustawienia na serwerze proxy stosują się nie od razu.
6. Powtórz sprawdzenie przez curl z kroku 2.

Wskazówka: jeśli pracujesz z domu z dynamicznym IP, autoryzacja loginem i hasłem uwolni Cię od tego problemu na zawsze. Biała lista jest wygodna dla serwerów ze statycznym adresem, a nie dla domowych komputerów.

Sprawdzamy stan modemu i rotację

1. W panelu klienta znajdź informacje o bieżącym IP proxy i czasie ostatniej zmiany.
2. Jeśli masz ustawioną automatyczną rotację co kilka minut, zwróć uwagę: w momencie zmiany IP modem przełącza się ponownie do sieci komórkowej i przez 5-20 sekund proxy rzeczywiście nie odpowiada. To normalne zachowanie, a nie awaria.
3. Jeśli Twoje żądania regularnie łapią timeout właśnie w momencie rotacji, zwiększ interwał rotacji lub przełącz się na zmianę IP przez link, aby samodzielnie kontrolować moment przełączenia.
4. Spróbuj wymusić zmianę IP przez link z panelu. Jeśli po zmianie proxy zadziałało, problem był w konkretnym IP lub w zawieszonym połączeniu modemu.

Sprawdzamy limit równoczesnych połączeń

Mobilne proxy mają ograniczenie liczby równoległych połączeń z jednego portu. Jeśli Twój scraper otworzył sto wątków, a limit wynosi pięćdziesiąt, nadmiarowe połączenia będą wisieć w kolejce i odpadać po timeoucie.

1. Ustal limit w opisie taryfy lub w panelu.
2. Zamknij wszystkie aplikacje korzystające z proxy i wykonaj pojedyncze żądanie przez curl. Jeśli pojedyncze żądanie przechodzi, a pod obciążeniem zaczynają się timeouty, trafiasz w limit.
3. Zmniejsz liczbę wątków w ustawieniach scrapera lub antydetektu do wartości poniżej limitu. Dla mobilnych proxy rozsądny start: 5-10 równoległych połączeń na jeden port.

Sprawdzamy strefy czasowe i sieć komórkową

Modem proxy fizycznie znajduje się w konkretnym mieście i jest podłączony do konkretnego operatora. W godzinach wieczornych, gdy sieci komórkowe są przeciążone, opóźnienia rosną wielokrotnie. Jeśli timeouty pojawiają się tylko od 19 do 23 czasu regionu proxy, to sieć komórkowa, a nie Twoja konfiguracja. Rozwiązanie: zwiększyć timeouty w tym czasie lub rozłożyć obciążenie na inne godziny.

Sprawdzenie: Twój aktualny IP pokrywa się z białą listą lub używana jest autoryzacja hasłem, modem w panelu pokazuje status „w sieci”, pojedyncze żądanie przez curl przechodzi, a liczba wątków w programie nie przekracza limitu. Jeśli wszystko to jest spełnione, a serwer proxy nie odpowiada, czas napisać do supportu dostawcy z załączonymi wynikami wszystkich sześciu kroków.

Sprawdzenie wyniku: lista kontrolna stabilnego połączenia

Przeszedłeś wszystkie kroki. Teraz upewnijmy się, że wynik został osiągnięty nie przypadkiem i nie na minutę. Przejdź przez listę kontrolną i odhacz każdy punkt.

Lista kontrolna

• Test-NetConnection lub nc pokazują udane połączenie TCP z portem proxy przy włączonym firewallu i antywirusie.
• curl przez proxy zwraca adres IP operatora mobilnego w czasie nie dłuższym niż 5 sekund w pięciu kolejnych próbach.
• Timeout połączenia w Twoim programie wynosi nie mniej niż 10 sekund, a timeout odczytu nie mniej niż 30 sekund.
• Protokół w aplikacji (HTTP lub SOCKS5) zgadza się z portem, który przeszedł sprawdzenie przez curl.
• W firewallu utworzono precyzyjną regułę zezwalającą, a nie wyłączono ochronę całkowicie.
• Twój zewnętrzny IP pokrywa się z białą listą lub używana jest autoryzacja hasłem.
• Liczba równoległych połączeń w aplikacji jest mniejsza niż limit taryfy.
• Kopie zapasowe ustawień firewalla i routera są zapisane na wypadek wycofania zmian.

Test obciążeniowy

Pojedyncze żądanie to jedno, a realna praca to dziesiątki żądań pod rząd. Przeprowadźmy krótki test.

1. Wykonaj w terminalu pętlę 20 żądań. W macOS i Linux:

   for i in $(seq 1 20); do curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.ipify.org; done

   W PowerShell użyj pętli 1..20 | ForEach-Object z tą samą komendą curl w środku.
2. W wynikach zobaczysz 20 wierszy z kodem odpowiedzi i czasem. Wszystkie kody powinny być 200, a czas nie powinien przekraczać 5-6 sekund.
3. Jeśli jedno-dwa żądania z dwudziestu zajęły więcej, to dopuszczalne dla sieci mobilnej. Jeśli co trzecie żądanie idzie w timeout, wróć do kroku 6 i sprawdź limit połączeń oraz rotację.

Test w realnej aplikacji

1. Otwórz profil przeglądarki antydetekcyjnej ze skonfigurowanym proxy i naciśnij sprawdzenie połączenia. Wynik powinien przyjść w 2-4 sekundy i pokazać IP operatora mobilnego.
2. Otwórz ciężką stronę, na przykład kanał w serwisie społecznościowym. Powinna w pełni załadować się w 10-15 sekund.
3. Zostaw kartę otwartą na 10 minut i odśwież stronę. Jeśli się załadowała, połączenie przetrwa pauzy i nie zrywa się od bezczynności.
4. Dla skryptów: uruchom zadanie robocze na 50-100 żądań i spójrz na procent udanych. Wskaźnik sukcesu: nie mniej niż 95 procent bez powtórzeń.

Wskaźniki udanego wykonania: port jest dostępny, czas odpowiedzi przewidywalny, aplikacja nie narzeka na timeouty przez 30 minut pracy, a Ty dokładnie wiesz, który z sześciu kroków był przyczyną problemu. To ostatnie jest szczególnie cenne: następnym razem zaczniesz diagnozę właśnie od niego.

Typowe błędy i ich rozwiązania

Zebrano tu sytuacje, z którymi użytkownicy mobilnych proxy spotykają się najczęściej. Format: co widzisz, dlaczego tak się dzieje, co zrobić.

Proxy działa z telefonu, ale nie z komputera

Przyczyna: firewall lub antywirus na komputerze blokuje połączenie wychodzące na niestandardowy port, albo Twój domowy IP nie pokrywa się z białą listą, a telefon autoryzuje się w inny sposób.

Rozwiązanie: wykonaj szybki test z wyłączeniem firewalla z kroku 4. Jeśli nie pomogło, porównaj zewnętrzny IP komputera z białą listą według instrukcji z kroku 6.

Połączenie się nawiązuje, ale strona się nie ładuje

Przyczyna: wskazałeś port HTTP tam, gdzie aplikacja oczekuje SOCKS5, lub odwrotnie. Połączenie się otwiera, ale aplikacja i proxy mówią różnymi językami i dane nie idą.

Rozwiązanie: sprawdź oba protokoły przez curl z kluczami http:// i socks5:// i ustaw w aplikacji ten, który zadziałał.

Działało tydzień, potem przestało bez zmian z Twojej strony

Przyczyna: zmienił się zewnętrzny IP Twojego dostawcy internetu, a w panelu proxy ustawiona jest autoryzacja po IP. Drugi wariant: aktualizacja antywirusa dodała nową regułę blokującą.

Rozwiązanie: zaktualizuj białą listę lub przejdź na autoryzację hasłem. Sprawdź listę reguł blokujących w firewallu według instrukcji z kroku 4.

Timeouty tylko w godzinach wieczornych

Przyczyna: przeciążenie sieci komórkowej w regionie, gdzie stoi modem proxy. To cecha internetu mobilnego, a nie usterka.

Rozwiązanie: zwiększ timeout odczytu do 45-60 sekund na godziny wieczorne, dodaj powtórzenia żądań i w miarę możliwości przenieś ciężkie zadania na rano.

Co dziesiąte żądanie pada po timeoucie

Przyczyna: zbieg żądań z momentem automatycznej rotacji IP albo przekroczenie limitu równoległych połączeń.

Rozwiązanie: przełącz rotację na zmianę przez link i wywołuj ją między partiami żądań. Zmniejsz liczbę wątków do 5-10.

W biurze nie działa, w domu działa

Przyczyna: korporacyjna brama przepuszcza tylko porty 80 i 443.

Rozwiązanie: poproś administratora o zezwolenie na konkretny IP i port lub uzyskaj u dostawcy proxy port ze standardowego zakresu.

Test-NetConnection pokazuje True, a przeglądarka nadal wisi

Przyczyna: port jest otwarty, ale w przeglądarce ustawiony jest inny port, inny adres lub włączone jest wykluczenie systemowe, przez które ruch idzie obok proxy. Możliwe też, że rozszerzenie do proxy koliduje z ustawieniami systemowymi.

Rozwiązanie: porównaj znak po znaku adres i port w przeglądarce z tym, co sprawdzałeś komendą. Wyłącz wszystkie rozszerzenia związane z proxy i skonfiguruj proxy tylko jednym sposobem.

Małe strony otwierają się, duże zawieszają

Przyczyna: nieprawidłowe MTU na routerze lub u dostawcy. Duże pakiety nie przechodzą.

Rozwiązanie: dobierz MTU komendą ping z flagą -f z kroku 5 i ustaw je w routerze.

Dodatkowe możliwości dla zaawansowanych użytkowników

Jeśli podstawowe połączenie zostało przywrócone i chcesz mieć większą kontrolę, ten rozdział jest dla Ciebie. Znajdziesz tu narzędzia i podejścia, które zamieniają jednorazową diagnozę w stały monitoring.

Patrzymy na pakiety: Wireshark i tcpdump

Gdy komendy z głównych kroków nie dają jednoznacznej odpowiedzi, można spojrzeć na ruch sieciowy bezpośrednio.

1. W Linux lub macOS wykonaj:

   sudo tcpdump -i any host 185.10.20.30 and port 30001 -nn

   W Windows zainstaluj Wireshark i w filtrze wyświetlania wpisz ip.addr == 185.10.20.30 and tcp.port == 30001.
2. Uruchom sprawdzenie portu z kroku 2 i patrz na przechwycone pakiety.
3. Jeśli widzisz pakiety wychodzące z flagą SYN, ale nie ma odpowiedzi SYN-ACK, Twoje pakiety wychodzą, a odpowiedź nie wraca. Blokada jest gdzieś poza komputerem.
4. Jeśli pakietów SYN nie ma wcale, odrzuca je lokalny firewall jeszcze przed wyjściem do sieci.
5. Jeśli w odpowiedzi przychodzi RST, port na serwerze jest zamknięty lub serwer odmawia właśnie Tobie.

Automatyczne powtórzenia z rosnącą pauzą

Sieć mobilna z natury jest niestabilna. Zamiast padać na pierwszym timeoucie, ustaw powtórzenia z wykładniczym opóźnieniem: pierwsza próba po 1 sekundzie, druga po 2, trzecia po 4. W Pythonie robi się to przez adapter z klasą Retry z urllib3, w Node.js przez pakiet axios-retry. Trzy powtórzenia z takim schematem zdejmują 90 procent przypadkowych timeoutów bez utraty danych.

Połączenia stałe i pule

Każde nowe połączenie TCP przez mobilne proxy kosztuje 100-500 milisekund na nawiązanie. Jeśli Twój skrypt otwiera nowe połączenie na każde żądanie, tracisz czas i szybciej trafiasz w limit. Używaj sesji: w Pythonie requests.Session, w Node.js agenta z keepAlive: true. Jedno połączenie będzie ponownie wykorzystywane dla dziesiątek żądań.

Monitoring dostępności

Ustaw proste sprawdzenie raz na minutę: skrypt wykonuje żądanie przez proxy i zapisuje czas odpowiedzi oraz kod. Po tygodniu otrzymasz obraz, o których godzinach proxy jest szybsze, a kiedy łapie timeouty. Pozwoli to planować obciążenie i z wyprzedzeniem widzieć degradację, a nie dowiadywać się o niej ze zepsutych zadań.

*/1 * * * * curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -m 20 -w "$(date +%H:%M) %{http_code} %{time_total}\n" https://api.ipify.org >> /var/log/proxy-check.log

DNS przez proxy

Domyślnie niektóre aplikacje rozwiązują nazwy domen lokalnie, a nie przez proxy. Może to prowadzić do wycieku informacji i do sytuacji, gdy lokalny DNS zwraca adres niedostępny z sieci mobilnej. W ustawieniach przeglądarek i antydetektów szukaj opcji „DNS przez proxy” lub używaj protokołu socks5h zamiast socks5 w curl i Pythonie: litera h oznacza, że nazwy będzie rozwiązywał sam proxy.

Zmiana portu na standardowy

Jeśli często pracujesz z różnych sieci, zapytaj dostawcę o możliwość przypisania proxy portu 443 lub 8080. Takie porty są otwarte praktycznie wszędzie i nie będziesz musiał za każdym razem walczyć z korporacyjnymi firewallami.

Dostrajanie rotacji

Scenariusz zaawansowany: powiązać zmianę IP z logiką aplikacji. Przed rozpoczęciem nowej partii żądań skrypt pociąga link zmiany IP, czeka 10-15 sekund, sprawdza przez api.ipify.org, że adres naprawdę się zmienił, i dopiero potem zaczyna pracę. Tak całkowicie eliminujesz timeouty z powodu przypadkowego zbiegu żądania z rotacją.

Wskazówka: dodaj do logu każdego żądania nie tylko czas, ale i bieżący IP proxy. Gdy za miesiąc będziesz analizować, dlaczego spadły wskaźniki, korelacja między konkretnymi IP a timeoutami od razu podpowie, które adresy operatora były problematyczne.

FAQ: częste pytania o diagnozę

Serwer proxy nie odpowiada, ale ping przechodzi. Co to znaczy?

Ping sprawdza tylko dostępność IP po protokole ICMP, a nie otwartość portu. Serwer może być żywy i odpowiadać na ping, ale port proxy przy tym jest filtrowany przez firewall lub usługa na nim nie działa. Zawsze sprawdzaj właśnie port TCP komendami z kroku 2.

Jak długo czekać, zanim uznać, że proxy nie odpowiada?

Dla nawiązania połączenia z mobilnym proxy normalne jest do 1 sekundy, granica 10 sekund. Dla otrzymania danych normalne jest do 5 sekund, granica 30-45 sekund. Jeśli połączenie nie nawiązało się w 10 sekund, dalsze czekanie jest bez sensu: odpowiedź nie przyjdzie.

Czy można po prostu wyłączyć firewall i tak pracować?

Nie. Wyłączenie ochrony jest dopuszczalne tylko na minutę dla sprawdzenia hipotezy. Potem utwórz precyzyjną regułę dla konkretnej aplikacji lub portu, jak opisano w kroku 4, i włącz firewall z powrotem. Komputer bez ochrony w sieci to ryzyko dla Twoich kont i danych.

Dlaczego proxy działa w jednej przeglądarce, a nie działa w innej?

Zwykle dlatego, że jedna przeglądarka używa systemowych ustawień proxy, a druga własnych, i są w nich różne dane. Drugi wariant: firewall zezwolił na jeden plik wykonywalny, a nie zezwolił na drugi. Sprawdź ustawienia obu przeglądarek i listę reguł firewalla.

Jak poznać, że chodzi o rotację IP, a nie o moje ustawienia?

Zapisz czas każdego timeoutu w ciągu godziny i porównaj z interwałem rotacji z panelu. Jeśli timeouty przychodzą z tą samą częstotliwością co zmiana IP, to rotacja. Przełącz się na zmianę przez link i problem zniknie.

Czy trzeba używać terminala? Nie ma narzędzi graficznych?

Terminal jest szybszy i dokładniejszy, ale są alternatywy. W przeglądarkach antydetekcyjnych wbudowane jest sprawdzenie proxy z wyświetleniem czasu odpowiedzi. Są programy desktopowe do sprawdzania list proxy ze wskazaniem otwartych portów. Jednak do znalezienia przyczyny właśnie u Ciebie terminal jest niezastąpiony: pokazuje, na jakim etapie zatrzymało się połączenie.

Co zrobić, jeśli wszystkie sześć kroków przeszło, a problem został?

Napisz do supportu dostawcy proxy i załącz: wynik Test-NetConnection lub nc, wynik curl z kluczem -v, rezultat trasowania, swój zewnętrzny IP, czas prób oraz informację, czy proxy działa z innej sieci. Z takimi danymi specjalista znajdzie przyczynę w jednej odpowiedzi, a nie po pięciu pytaniach doprecyzowujących.

Czy trzeba restartować komputer po zmianie reguł firewalla?

Nie, reguły firewalla Windows, macOS i Linux stosują się natychmiast. Restart potrzebny jest tylko routerowi po zmianie MTU lub profili bezpieczeństwa, i to nie we wszystkich modelach.

Czy można stosować to samo podejście do proxy datacenter?

Tak, kroki od 1 do 5 są uniwersalne dla każdego typu proxy. Różni się krok 3: proxy datacenter odpowiadają szybciej i timeouty można ustawić mniejsze. I krok 6: proxy datacenter nie mają rotacji przez przełączanie modemu, więc pauz w momencie zmiany IP nie będzie.

Zakończenie

Podsumujmy. Nauczyłeś się nie panikować przy komunikacie, że serwer proxy nie odpowiada, ale rozkładać sytuację na łańcuch. Najpierw ustaliłeś, czy proxy działa przynajmniej skądkolwiek. Potem sprawdziłeś, czy port jest otwarty właśnie z Twojego urządzenia. Zająłeś się timeoutami i zrozumiałeś różnicę między timeoutem połączenia a timeoutem odczytu. Sprawdziłeś firewall i antywirus i utworzyłeś precyzyjną regułę zamiast wyłączania ochrony. Zbadałeś router, MTU i korporacyjną bramę. I wreszcie upewniłeś się, że samo proxy przyjmuje właśnie Ciebie: biała lista, modem, rotacja, limity.

Najważniejszy wynik to nawet nie to, że połączenie zostało przywrócone. Chodzi o to, że masz teraz metodę. Następnym razem, gdy coś się zawiesi, nie będziesz zgadywać i przeszukiwać ustawień na oślep. Otworzysz terminal, wykonasz dwie komendy i w minutę dowiesz się, na którym odcinku łańcucha jest przerwa.

Co robić dalej

1. Zapisz plik z działającymi komendami i danymi swojego proxy w wygodnym miejscu. To Twój zestaw pierwszej pomocy.
2. Przejdź na autoryzację loginem i hasłem, jeśli jeszcze używasz białej listy z domowego komputera.
3. Sprawdź timeouty we wszystkich aplikacjach, które pracują przez mobilne proxy, i doprowadź je do zalecanych wartości.
4. Ustaw minutowy monitoring z zaawansowanego rozdziału przynajmniej na jednym proxy, aby po tygodniu zobaczyć realny obraz stabilności.

Kierunki rozwoju

Następny poziom to automatyzacja obsługi awarii: powtórzenia z rosnącą pauzą, sterowana rotacja, pule połączeń i logowanie każdego żądania z przypisaniem do IP. Opanowawszy to, przestaniesz w ogóle zauważać pojedyncze timeouty: Twój system będzie je przeżywał sam, a Ty będziesz widzieć tylko końcowe metryki. Powodzenia w pracy i niech Twoje proxy odpowiadają zawsze za pierwszym razem.