Spis treści

Wprowadzenie: co zyskasz z tego przewodnika

Jeśli pracujesz z proxy mobilnymi, prędzej czy później zobaczysz w logach parsera, w konsoli przeglądarki antydetekcyjnej albo bezpośrednio w oknie panelu reklamowego wiersz typu „407 Proxy Authentication Required”, „502 Bad Gateway”, „504 Gateway Timeout” albo krótkie i przerażające „tunnel failed”. Błąd serwera proxy w takim momencie przypomina czarną skrzynkę: nie wiadomo, czy winne jest samo proxy, twoje oprogramowanie, docelowa strona, czy po prostu nieaktualne hasło. Ten przewodnik zamienia czarną skrzynkę w przejrzysty schemat działań.

Świadomie zawężamy temat: zajmujemy się tylko kodami i komunikatami, które zwraca warstwa proxy. Timeouty sieciowe na poziomie połączenia (gdy odpowiedzi nie ma w ogóle i klient sam przerywa oczekiwanie) są omówione osobno na blogu i tutaj ich nie powtarzamy. Jeśli w logu masz właśnie kod lub frazę o tunelu, jesteś we właściwym miejscu.

Co zyskasz w efekcie

  • Zrozumiesz, co oznacza każdy z czterech błędów i w którym dokładnie miejscu łańcucha „twoje oprogramowanie — proxy — docelowa strona” się rodzi.
  • Nauczysz się w dwie-trzy minuty określać źródło problemu za pomocą wbudowanego w każdy system narzędzia curl.
  • Otrzymasz gotowe sekwencje działań dla 407, 502, 504 i tunnel failed, które możesz wykonywać jak listę kontrolną.
  • Skonfigurujesz swoje oprogramowanie tak, aby prawidłowo reagowało na każdy kod: jedne błędy trzeba powtarzać, inne powtarzać nie ma sensu.
  • Zbierzesz osobisty dziennik incydentów, który zaoszczędzi godziny przy następnej awarii.

Dla kogo jest ten przewodnik

Przewodnik napisany jest dla marketerów, specjalistów od arbitrażu, właścicieli małych zespołów i programistów, którzy korzystają z proxy mobilnych, ale nie muszą być inżynierami sieciowymi. Główna część jest skierowana do początkujących: każde polecenie jest wyjaśnione, każde działanie rozpisane. Dla tych, którzy piszą własne skrypty i chcą głębiej, na końcu znajduje się osobny blok zaawansowany.

Co trzeba wiedzieć wcześniej

Wystarczy umieć otworzyć terminal lub wiersz poleceń, skopiować do niego tekst i odczytać wynik. Zrozumienie, czym jest adres IP i port, pomoże, ale krótko i to przypomnimy. Doświadczenie w programowaniu nie jest wymagane.

Ile czasu będzie potrzebne

Pełne przeczytanie i pierwsza diagnostyka zajmą od 60 do 120 minut. Jeśli masz teraz naglący konkretny błąd, przejdź do odpowiedniego kroku: na każdy pojedynczy błąd przewidziano 15-25 minut wraz z kontrolami.

Przygotowanie wstępne: narzędzia i dostępy

Diagnostyka błędów warstwy proxy nie wymaga instalowania ciężkich programów. Prawie wszystko masz już w swoim systemie operacyjnym. Mimo to warto przygotować się wcześniej, aby w momencie awarii nie szukać haseł i nie przypominać sobie, gdzie leży konfiguracja.

Potrzebne narzędzia

  1. Terminal lub wiersz poleceń. W Windows 10 i 11 otwórz menu „Start”, wpisz „cmd” lub „PowerShell” i naciśnij Enter. W macOS otwórz „Programy”, następnie „Narzędzia”, a potem „Terminal”. W Linuksie terminal wywołuje się zwykle kombinacją Ctrl+Alt+T.
  2. Narzędzie curl. Jest wbudowane w Windows od wersji 10 (kompilacja 1803), w macOS i w większości dystrybucji Linuksa. Sprawdź: wpisz w terminalu curl --version i naciśnij Enter. Powinien pojawić się wiersz z numerem wersji, na przykład „curl 8.x.x”. Jeśli zamiast tego pojawi się komunikat, że polecenie nie zostało znalezione, zainstaluj curl przez menedżer pakietów swojego systemu.
  3. Zwykła przeglądarka z narzędziami dla deweloperów. Wystarczy dowolna nowoczesna przeglądarka, w której po naciśnięciu F12 otwiera się panel z zakładką „Network” (Sieć).
  4. Edytor tekstu do prowadzenia dziennika incydentów. Wystarczy Notatnik, ale wygodniejszy będzie edytor z podświetlaniem składni, aby widzieć strukturę logów.
  5. Twoje robocze oprogramowanie: przeglądarka antydetekcyjna, parser, menedżer paneli reklamowych lub własny skrypt. Będziemy potrzebować dostępu do jego ustawień proxy i do jego logów.

Potrzebne dostępy

  • Logowanie do panelu klienta dostawcy proxy. Dla użytkowników mobileproxy.space to strona zarządzania kanałami, gdzie widoczne są host, port, login, hasło, typ autoryzacji i link do zmiany IP.
  • Aktualne dane dostępowe przynajmniej jednego proxy: adres (host), port, login i hasło lub zatwierdzony IP do autoryzacji po adresie.
  • Zrozumienie, jakiego protokołu używasz: proxy HTTP(S) czy SOCKS5. Te informacje również pokaże panel klienta.

Wymagania systemowe

Dowolny system operacyjny wydany w ciągu ostatnich ośmiu lat. Połączenie internetowe, przez które dostępny jest host proxy. Nic więcej nie jest potrzebne.

Kopie zapasowe

Zanim zmienisz ustawienia proxy w roboczym oprogramowaniu, zapisz obecny stan. Zajmie to pięć minut i uchroni cię przed sytuacją, w której „naprawiłeś” błąd i jednocześnie straciłeś działającą konfigurację dziesięciu kont.

  1. W przeglądarce antydetekcyjnej wyeksportuj listę profili wraz z ustawieniami proxy. Zwykle funkcja eksportu znajduje się w menu profili i tworzy plik CSV lub JSON.
  2. W parserze lub skrypcie skopiuj plik konfiguracyjny do osobnego folderu z datą w nazwie, na przykład „config_backup_2026-03-14”.
  3. Z panelu klienta skopiuj do pliku tekstowego dane dostępowe wszystkich kanałów. Trzymaj ten plik tam, gdzie nie mają dostępu osoby postronne.
  4. Zapisz, jaki IP ma teraz twój komputer lub serwer. Będzie potrzebny, jeśli używasz autoryzacji po adresie IP.

Wskazówka: załóż jeden plik tekstowy „Dziennik proxy” i zapisuj w nim każdy błąd w formacie „data, godzina, kod, host proxy, docelowa strona, co zrobiłem, co pomogło”. Po miesiącu będziesz mieć osobistą bazę wiedzy, która jest przydatniejsza niż jakikolwiek artykuł.

Sprawdzenie: terminal się otwiera, polecenie curl pokazuje wersję, zalogowałeś się do panelu klienta i widzisz dane dostępowe przynajmniej jednego proxy, kopie zapasowe konfiguracji leżą w osobnym folderze. Można iść dalej.

Podstawowe pojęcia: jak zbudowana jest warstwa proxy i skąd biorą się kody

Aby naprawiać błąd serwera proxy świadomie, a nie metodą prób i błędów, trzeba wyobrazić sobie drogę żądania. Składa się ona z trzech odcinków, a każdy z naszych czterech błędów żyje na swoim odcinku.

Trzy odcinki drogi żądania

  • Klient — proxy. Twoja przeglądarka, parser lub skrypt łączy się z hostem i portem proxy. Na tym odcinku sprawdzana jest autoryzacja. Tu rodzi się błąd 407 i część przypadków tunnel failed.
  • Proxy — sieć mobilna — docelowa strona. Serwer proxy, otrzymawszy twoje żądanie, otwiera od swojego imienia połączenie przez modem z kartą SIM operatora do wybranej strony. Tu pojawiają się 502 i 504.
  • Docelowa strona — droga powrotna. Odpowiedź strony idzie z powrotem przez te same węzły. Jeśli strona zwróciła własny kod, na przykład 403 lub 429, to już nie jest błąd warstwy proxy i ważne jest, aby nauczyć się je rozróżniać.

Klasy kodów prostym językiem

Kod odpowiedzi to trzycyfrowa liczba, którą serwer wysyła w pierwszym wierszu odpowiedzi. Pierwsza cyfra mówi o klasie. Kody 4xx oznaczają „problem po twojej stronie, popraw żądanie”. Kody 5xx oznaczają „problem po stronie serwera lub za nim”. Dla warstwy proxy działa to tak:

  • 407 Proxy Authentication Required — proxy mówi: „Nie wiem, kim jesteś, albo twoje dane są nieprawidłowe”. Klasa 4xx: naprawiać trzeba u siebie.
  • 502 Bad Gateway — proxy mówi: „Próbowałem dotrzeć dalej, ale dostałem zerwanie lub śmieci zamiast odpowiedzi”. Klasa 5xx: problem jest za proxy lub w samym proxy.
  • 504 Gateway Timeout — proxy mówi: „Czekałem na odpowiedź od następnego węzła wyznaczony czas i się nie doczekałem”. To również 5xx.

Czym kod 504 różni się od timeoutu sieciowego

To kluczowe rozgraniczenie dla całego artykułu. Gdy widzisz kod 504, oznacza to, że serwer proxy żyje, przyjął twoje żądanie, sam czekał na odpowiedź strony i sam poinformował cię o niepowodzeniu. Połączenie między tobą a proxy działało przy tym idealnie. Gdy natomiast twój klient pisze „connection timed out” lub „operation timed out” bez kodu, oznacza to, że odpowiedzi nie było wcale, a zerwanie zainicjowało twoje oprogramowanie. Pierwsze jest przedmiotem tego przewodnika. Drugie to inny temat, omówiony w pokrewnych materiałach bloga. Prosty znak: jest trzycyfrowa liczba w odpowiedzi — czytaj dalej tutaj.

Czym jest tunel i dlaczego „pada”

Gdy otwierasz stronę przez HTTPS za pośrednictwem proxy HTTP, przeglądarka najpierw wysyła do proxy specjalne polecenie CONNECT z adresem i portem docelowym. Proxy otwiera połączenie ze stroną i odpowiada „200 Connection established”. Potem przez proxy płynie zaszyfrowany strumień, którego samo proxy już nie czyta. Takie połączenie nazywa się tunelem. Jeśli na polecenie CONNECT proxy odpowiedziało czymś innym niż 200, klient pisze „tunnel failed” i obok zwykle podaje, jaki dokładnie kod przyszedł. Czyli tunnel failed to nie samodzielny błąd, a opakowanie na jeden z kodów.

Dwa sposoby autoryzacji

  • Login i hasło. Klient przekazuje je w nagłówku Proxy-Authorization. Najczęstszy sposób i najczęstsze źródło 407.
  • Autoryzacja po IP. Z góry podajesz w panelu adres swojego komputera lub serwera, a proxy przepuszcza wszystkie żądania z tego adresu bez hasła. Wygodne, ale psuje się, gdy twoje IP się zmienia.

Nagłówki pomocnicze, po których widać autora odpowiedzi

Proxy często dodaje do swoich odpowiedzi nagłówki Via, Proxy-Agent lub X-Proxy. Docelowe strony ich nie ustawiają. Jeśli w odpowiedzi z kodem 502 jest nagłówek Proxy-Agent, wiesz na pewno, że odpowiedziało proxy. Jeśli nagłówków nie ma, a jest Server z nazwą serwera WWW strony, to odpowiedź samej strony. Będziemy aktywnie korzystać z tego znaku.

Wskazówka: zapamiętaj zasadę mnemotechniczną: „czwórka — szukaj u siebie, piątka — szukaj za proxy, tunel — patrz, jaka liczba obok”. Rozwiązuje ona połowę przypadków bez dalszego czytania.

Krok 1: Ustalamy, kto dokładnie zwrócił błąd

Cel etapu: w kilka minut dokładnie ustalić, czy odpowiedział serwer proxy, docelowa strona, czy twoje własne oprogramowanie, i zapisać pełny tekst odpowiedzi do dalszej pracy.

Instrukcja

  1. Otwórz panel klienta i skopiuj dane dostępowe problematycznego proxy: host, port, login, hasło. Dla przykładu przyjmiemy, że host to proxy.example.net, port to 8080, login to user1, hasło to pass1. Podstawiaj swoje wartości.
  2. Otwórz terminal.
  3. Wpisz polecenie, zamieniając dane dostępowe i adres docelowy na swoje, i naciśnij Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Klucz -v włącza szczegółowe wyjście, klucz -x ustawia proxy.
  4. Poczekaj na zakończenie polecenia. Zwykle trwa to od jednej do trzech sekund. Jeśli polecenie „wisi” dłużej niż 30 sekund, naciśnij Ctrl+C: najprawdopodobniej masz timeout sieciowy, a nie kod, i to nie nasz temat.
  5. Znajdź w wyjściu wiersze zaczynające się od znaku „większy niż” (to, co wysłał curl) i od znaku „mniejszy niż” (to, co przyszło w odpowiedzi). Pierwszy wiersz odpowiedzi będzie postaci „HTTP/1.1 407 Proxy Authentication Required” lub „HTTP/1.1 200 Connection established”.
  6. Spójrz na wiersz z napisem CONNECT. Jeśli zaraz po nim przyszedł kod inny niż 200, oznacza to, że błąd zwróciło proxy na etapie tunelu. Jeśli CONNECT dostał 200, a kod błędu przyszedł później, po wierszach o uzgadnianiu TLS, oznacza to, że odpowiedziała już docelowa strona.
  7. Znajdź nagłówki odpowiedzi. Obecność Proxy-Agent, Via lub podobnych nagłówków pomocniczych jednoznacznie wskazuje na proxy. Nagłówek Server z nazwą serwera WWW i nagłówek Set-Cookie wskazują na docelową stronę.
  8. Powtórz to samo polecenie bez klucza -x, czyli bezpośrednio: curl -v https://example.com/. Jeśli strona odpowiada 200, a przez proxy przychodzi 5xx, problem jest zlokalizowany na odcinku za proxy.
  9. Powtórz polecenie przez proxy, ale do innej strony, na przykład do dowolnego stabilnego dużego zasobu. Jeśli druga strona się otwiera, problem dotyczy konkretnego kierunku, a nie proxy jako całości.
  10. Skopiuj całe wyjście do dziennika proxy wraz z datą i godziną. Będzie potrzebne w kolejnych krokach.

Alternatywna droga przez przeglądarkę

Jeśli praca w terminalu jest niewygodna, otwórz przeglądarkę ze skonfigurowanym proxy, naciśnij F12, przejdź do zakładki „Network”, zaznacz „Preserve log” (Zachowaj dziennik), odśwież stronę. Na liście żądań znajdź wiersz z czerwonym kodem, kliknij go i na zakładce „Headers” przejrzyj blok „Response Headers”. Logika jest ta sama: szukaj nagłówków pomocniczych proxy. Wadą tego sposobu jest to, że przeglądarka często ukrywa szczegóły etapu CONNECT, dlatego dla tunnel failed terminal jest lepszy.

Uwaga: polecenie z kluczem -v wyświetla login i hasło proxy w otwartej postaci. Nie wklejaj tego wyjścia do ogólnych czatów, zgłoszeń do wsparcia i zrzutów ekranu bez zamiany hasła na gwiazdki.

Wskazówka: dodaj do polecenia klucz -sS razem z -o i wskazaniem pustego urządzenia, aby nie zaśmiecać ekranu treścią odpowiedzi: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. W Windows zamiast /dev/null użyj NUL.

Oczekiwany rezultat

W dzienniku pojawił się wpis z pełną odpowiedzią i możesz pewnie powiedzieć jedno z trzech: „odpowiedziało proxy na etapie autoryzacji”, „odpowiedziało proxy na etapie odwołania do strony” albo „odpowiedziała sama strona”. To kieruje cię do kroku 2, 3-4 albo w ogóle poza ramy tego artykułu.

Możliwe problemy

  • Polecenie pisze „Could not resolve proxy”. Literówka w hoście. Porównaj z panelem klienta znak po znaku.
  • Polecenie pisze „Failed to connect to proxy”. Port jest zamknięty lub nieprawidłowy. To problem transportowy, nie kod, sprawdź port i spróbuj innego kanału.
  • Wyjście urywa się na wierszu TLS bez kodu. Oznacza to, że tunel został ustanowiony, ale strona nie odpowiedziała w czasie wyznaczonym przez twojego klienta. Nie myl tego z 504: nie ma kodu, więc to nie nasz przypadek.

Sprawdzenie: potrafisz wskazać autora odpowiedzi i dokładny kod lub frazę, a wiersz wyjścia curl jest zapisany w dzienniku.

Krok 2: Naprawiamy błąd 407 Proxy Authentication Required

Cel etapu: doprowadzić do tego, aby na polecenie CONNECT proxy odpowiadało „200 Connection established”, a nie 407, i zrozumieć przyczynę, aby błąd nie wrócił.

Dlaczego pojawia się 407

Proxy nie przyjęło twoich danych uwierzytelniających. Przyczyn jest zwykle sześć i będziemy je sprawdzać od najprostszej do najbardziej złożonej: literówka, znaki specjalne w haśle, zmiana twojego IP przy autoryzacji po adresie, wygasły termin kanału, oprogramowanie w ogóle nie przekazuje danych, stara pamięć podręczna w przeglądarce.

Instrukcja

  1. Otwórz panel klienta i znajdź problematyczny kanał. Upewnij się, że jego termin nie wygasł i status jest aktywny. Jeśli termin minął, przedłuż go i powtórz żądanie po minucie; w tym przypadku nie musisz iść dalej.
  2. Sprawdź, jaki typ autoryzacji jest włączony dla kanału: login i hasło czy po adresie IP. Wiele paneli pozwala włączyć oba jednocześnie.
  3. Jeśli włączona jest autoryzacja po IP, ustal aktualny zewnętrzny adres swojego komputera lub serwera. Otwórz w przeglądarce bez proxy dowolny serwis pokazujący twoje IP i porównaj z adresem zapisanym w panelu klienta. Domowi dostawcy i operatorzy mobilni często zmieniają adres po restarcie routera. Jeśli adresy się rozjechały, zaktualizuj go w panelu i poczekaj jedną-dwie minuty: zmiany nie działają natychmiast.
  4. Jeśli używasz loginu i hasła, skopiuj je z panelu klienta od nowa, nie przepisując ręcznie. Wklej do polecenia curl z kroku 1 i uruchom. Połowa przypadków 407 kończy się tutaj.
  5. Spójrz na hasło. Jeśli zawiera znaki @, :, /, #, ?, % lub spację, przy przekazywaniu w wierszu adresu trzeba je zakodować. Znak @ zamienia się na %40, dwukropek na %3A, kratka na %23, znak procentu na %25. Na przykład hasło p@ss:1 w adresie URL zapisuje się jako p%40ss%3A1. Aby nie kodować, przekaż dane osobnym kluczem: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Tutaj curl sam poradzi sobie ze znakami.
  6. Jeśli curl przechodzi, a twoje robocze oprogramowanie nadal dostaje 407, problem jest w samym oprogramowaniu. Otwórz jego ustawienia proxy. Sprawdź, czy login i hasło są wpisane w osobne pola, a nie doklejone do adresu, jeśli program tego nie oczekuje. Sprawdź, czy na końcu hasła nie ma spacji: często pojawia się przy kopiowaniu.
  7. W przeglądarce antydetekcyjnej otwórz ustawienia konkretnego profilu, a nie ustawienia globalne. Wielu użytkowników zmienia hasło na ogólnej liście proxy, ale profil nadal przechowuje starą kopię. Zapisz proxy ponownie w profilu i zrestartuj profil.
  8. Jeśli przeglądarka zapamiętała stare dane i nie pyta o nowe, wyczyść zapisane hasła dla tego hosta w ustawieniach przeglądarki lub utwórz nowy profil do testu.
  9. Zwróć uwagę na nagłówek Proxy-Authenticate w odpowiedzi 407. Jeśli jest tam napisane „Basic”, oznacza to, że proxy oczekuje zwykłej pary login-hasło. Jeśli wskazany jest inny schemat, twoje oprogramowanie musi go obsługiwać; dla proxy mobilnych prawie zawsze używa się Basic, a niezgodność oznacza błąd w ustawieniach typu proxy.
  10. Powtórz żądanie curl i upewnij się, że teraz na CONNECT przychodzi 200.

Uwaga: nie próbuj „rozwiązać” 407 masowym powtarzaniem żądań. Niektóre serwery proxy tymczasowo blokują adres po serii nieudanych autoryzacji i zyskasz dodatkowy problem nałożony na pierwotny. Jedna kontrola, jedna poprawka, jedna kontrola.

Wskazówka: jeśli masz kilkadziesiąt kanałów, trzymaj je w tabeli, gdzie login i hasło leżą w osobnych kolumnach, a obok jest kolumna z hasłem już zakodowanym dla URL. Wtedy nigdy nie pomylisz, który wariant gdzie wstawić.

Oczekiwany rezultat

W wyjściu curl wiersz odpowiedzi na CONNECT zmienił się na „HTTP/1.1 200 Connection established”, strona oddała treść. W roboczym oprogramowaniu żądania przechodzą. W dzienniku zapisana jest przyczyna: literówka, kodowanie, zmiana IP, wygaśnięcie terminu lub pamięć podręczna.

Możliwe problemy

  • Kod 407 przychodzi dwa razy: najpierw na CONNECT, potem wewnątrz tunelu. To znak, że oprogramowanie wysyła dane tylko na jednym z etapów. Zaktualizuj program lub włącz w nim opcję przekazywania autoryzacji przy CONNECT.
  • Panel mówi, że IP zostało dodane, a 407 pozostaje. Prawdopodobnie pracujesz przez sieć korporacyjną lub serwer z kilkoma adresami wychodzącymi. Sprawdź adres właśnie z tej maszyny, z której idą żądania.
  • Działa u ciebie, nie działa u kolegi z tymi samymi danymi. Przy autoryzacji po IP to oczekiwane: kolega ma inny adres. Przełącz się na login i hasło lub dodaj drugie IP.

Sprawdzenie: trzy żądania pod rząd przez curl i przez robocze oprogramowanie przeszły bez 407, przyczyna jest zapisana w dzienniku.

Krok 3: Radzimy sobie z błędem 502 Bad Gateway od proxy

Cel etapu: odróżnić krótkotrwałą awarię w momencie zmiany IP od trwałego problemu z kierunkiem lub kanałem i wybrać właściwą reakcję dla każdego przypadku.

Dlaczego proxy zwraca 502

Proxy przyjęło twoje żądanie, spróbowało otworzyć połączenie dalej i dostało zerwanie, odmowę lub nieczytelną odpowiedź. Dla proxy mobilnych typowe przyczyny są następujące: modem w tym momencie przełączał adres IP lub rejestrował się ponownie w sieci operatora; docelowa strona zerwała połączenie; po stronie proxy nie udało się rozwiązać nazwy domenowej strony; kanał jest przeciążony zbyt dużą liczbą równoczesnych strumieni; strona jest niedostępna dla wszystkich.

Instrukcja

  1. Zapisz dokładny czas pojawienia się 502 z sekundami. Jest to ważne dla następnego punktu.
  2. Otwórz w panelu klienta historię zmiany IP dla tego kanału lub przypomnij sobie, czy masz włączoną automatyczną rotację według harmonogramu. Jeśli rotacja zadziałała w tych samych sekundach co błąd, spotkałeś się z normalnym zachowaniem: podczas przełączania adresu żądania na dwie-dziesięć sekund dostają 502. Rozwiązanie — powtórzyć żądanie po pauzie.
  3. Poczekaj dziesięć sekund i powtórz polecenie curl z kroku 1. Jeśli odpowiedź zmieniła się na 200, zapisz w dzienniku „502 w momencie rotacji” i przejdź do konfiguracji powtórzeń w kroku 6.
  4. Jeśli 502 powtarza się trwale, sprawdź inną stronę przez to samo proxy. Otworzyła się — problem jest w kierunku. Nie otworzyła się — problem jest w kanale.
  5. Dla problemu w kierunku: otwórz docelową stronę bezpośrednio bez proxy. Jeśli jest niedostępna również bezpośrednio lub zwraca 5xx, proxy nie ma z tym nic wspólnego: strona leży. Jeśli bezpośrednio wszystko działa, strona prawdopodobnie zrywa połączenia z adresów tego operatora. Zmień IP przez link z panelu klienta i powtórz. Jeśli nie pomogło, spróbuj kanału innego operatora lub regionu.
  6. Dla problemu w kanale: sprawdź w panelu klienta status sprzętu. U wielu dostawców jest wskaźnik stanu modemu. Czerwony lub żółty status oznacza, że kanał się odtwarza, i pozostaje tylko poczekać lub przełączyć się na zapasowy.
  7. Sprawdź obciążenie. Zobacz w swoim oprogramowaniu, ile równoczesnych strumieni idzie przez ten kanał. Kanał mobilny ma ograniczoną przepustowość i przy dziesiątkach równoległych połączeń proxy zaczyna odrzucać część żądań właśnie z 502. Zmniejsz równoległość o połowę i powtórz test.
  8. Sprawdź, czy nie chodzi o DNS. Wykonaj żądanie do strony po adresie IP zamiast po domenie, jeśli strona na to pozwala, albo przełącz się na schemat socks5h, w którym nazwy rozwiązuje proxy, i porównaj wynik. Jeśli po nazwie jest 502, a po IP wszystko działa, chodzi o rozwiązywanie nazw po stronie proxy; zgłoś dostawcy dokładną nazwę domeny.
  9. Jeśli nic nie pomogło w ciągu 15 minut, zbierz wyjście curl -v, czas, host kanału, docelową domenę i wyślij do wsparcia dostawcy. Prawidłowo zebrane informacje skracają rozwiązanie z doby do godziny.

Wskazówka: pracując z rotacją według harmonogramu, z góry zsynchronizuj pauzy w oprogramowaniu z interwałem zmiany IP. Jeśli adres zmienia się co 5 minut, niech parser robi pauzę na 15 sekund na początku każdej pięciominutówki. Liczba 502 spadnie prawie do zera bez ani jednej linijki złożonego kodu.

Oczekiwany rezultat

Wiesz dokładnie, do której kategorii należy twoje 502: moment rotacji, konkretny kierunek, przeciążenie kanału, awaria sprzętu lub niedostępność strony. Dla pierwszych trzech masz poprawkę, dla dwóch ostatnich — zrozumienie, na co czekać i do kogo pisać.

Możliwe problemy

  • 502 przychodzi tylko przy dużych plikach. Strona zamyka połączenie z powodu wolnej prędkości wysyłania. Zmniejsz rozmiar pobieranych danych lub użyj kanału z lepszym zasięgiem.
  • 502 przychodzi od strony, a nie od proxy. Sprawdź nagłówki: jeśli jest tam Server strony i nie ma Proxy-Agent, to wewnętrzna awaria strony, powtórz później.
  • 502 przeplata się z 200 bez widocznej logiki. Klasyczny objaw przeciążenia kanału. Obniżaj równoległość do stabilnego wyniku.

Sprawdzenie: dziesięć kolejnych żądań z pauzą dwóch sekund przez problematyczny kanał do stabilnej strony zwraca 200, albo masz w ręku zgłoszenie do wsparcia ze wszystkimi danymi.

Krok 4: Pracujemy z kodem 504 Gateway Timeout

Cel etapu: zrozumieć, na którym odcinku za proxy traci się czas, i zmniejszyć udział 504 do akceptowalnego poziomu, nie myląc kodu z timeoutem sieciowym klienta.

Co dokładnie oznacza 504 od proxy

Serwer proxy sam ma wewnętrzny limit oczekiwania na odpowiedź strony. Gdy strona nie zdąży odpowiedzieć w tym limicie, proxy przerywa oczekiwanie i uczciwie informuje cię kodem 504. Twój klient przy tym nie zrywał połączenia, odpowiedź przyszła. Właśnie dlatego ważne jest, aby limit oczekiwania w twoim oprogramowaniu był większy niż limit proxy: inaczej będziesz widzieć timeout sieciowy bez kodu i nie będziesz mógł zrozumieć, co się dzieje.

Instrukcja

  1. Sprawdź limit oczekiwania w swoim oprogramowaniu. W większości programów nazywa się timeout, „czas oczekiwania na odpowiedź” lub „Read timeout”. Jeśli jest mniejszy niż 30 sekund, tymczasowo ustaw 60. To krok diagnostyczny: musisz doczekać się właśnie kodu od proxy.
  2. Zmierz czas do odpowiedzi przez proxy. Wykonaj: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Klucz -w wyświetla cztery liczby: kod, czas do połączenia, czas do pierwszego bajtu i łączny czas w sekundach.
  3. Wykonaj to samo polecenie bez klucza -x. Porównaj czas do pierwszego bajtu. Jeśli bezpośrednio strona odpowiada w 0,4 sekundy, a przez proxy w 8 sekund, opóźnienie na odcinku „proxy — strona” jest duże i 504 będzie pojawiać się przy każdych wahaniach sieci mobilnej.
  4. Sprawdź, przy którym żądaniu pojawia się 504. Zrób żądanie metodą HEAD, która nie ładuje treści strony: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Jeśli HEAD przechodzi, a GET strony daje 504, problem jest w rozmiarze lub wolnym generowaniu strony, a nie w samym połączeniu.
  5. Zmień IP kanału przez link z panelu klienta. Sieć mobilna nie jest jednorodna: jeden adres może trafić na przeciążoną stację bazową, inny na wolną. Powtórz pomiar. Jeśli czas spadł kilkukrotnie, dodaj w oprogramowaniu regułę: przy 504 najpierw zmieniaj IP, potem powtarzaj żądanie.
  6. Sprawdź ciężkość docelowej strony. Niektóre strony oddają odpowiedź dopiero po wykonaniu długich operacji serwerowych. Jeśli twoim celem są konkretne dane, spróbuj odwołać się do lżejszego adresu na tej samej stronie: do API, do wersji mobilnej, do strony bez parametrów sortowania.
  7. Jeśli 504 przychodzi tylko na określoną domenę i tylko przez kanały jednego operatora, zapisz to w dzienniku i rozdziel pracę z tą domeną na kanały innego operatora.
  8. Przywróć limit oczekiwania w oprogramowaniu do roboczej wartości, ale teraz świadomie: powinien być nieco większy niż typowy czas odpowiedzi przez proxy i mniejszy niż to, na co jesteś gotów czekać w ramach zadania. Dla większości scenariuszy to 30-45 sekund.

Uwaga: nie ustawiaj limitu oczekiwania w oprogramowaniu na kilka minut „na wszelki wypadek” i nie zostawiaj go tak na zawsze. Jeden zawieszony strumień zablokuje miejsce w kolejce, a dziesięć zawieszonych strumieni stworzy iluzję, że proxy nie działa, choć problem jest w jednej wolnej stronie.

Wskazówka: dodaj do logu swojego oprogramowania kolumnę „czas do pierwszego bajtu”. Widać po niej, czy kanał degraduje się stopniowo, czy spada gwałtownie. Stopniowy wzrost oznacza przeciążenie lub słaby zasięg, gwałtowny spadek częściej wskazuje na rotację lub awarię u operatora.

Oczekiwany rezultat

Znasz typowy czas odpowiedzi przez każdy kanał, ustawiłeś limit w oprogramowaniu powyżej limitu proxy i 504 stały się rzadkim zdarzeniem, na które skonfigurowano automatyczną reakcję.

Możliwe problemy

  • Zwiększyłeś limit, a zamiast 504 zacząłeś dostawać timeout sieciowy. Oznacza to, że proxy czeka dłużej, niż myślałeś, albo połączenie z samym proxy jest niestabilne. To już poza kodami, patrz pokrewne materiały o timeoutach.
  • 504 tylko w określonych godzinach. Wieczorny szczyt obciążenia sieci mobilnych. Przenieś ciężkie zadania na noc lub na rano.
  • 504 przy pierwszym żądaniu do nowej strony, potem wszystko szybko. Pierwotne rozwiązanie nazwy i ustanowienie połączenia po stronie proxy. Dodaj jedno żądanie rozgrzewające przed główną serią.

Sprawdzenie: seria dwudziestu żądań do roboczej strony pokazuje czas do pierwszego bajtu w przewidywalnym zakresie i nie więcej niż jedno-dwa 504, a oprogramowanie przy 504 zmienia IP i powtarza żądanie.

Krok 5: Naprawiamy błąd tunnel failed

Cel etapu: nauczyć się czytać liczbę obok frazy tunnel failed, łączyć ją z rzeczywistą przyczyną i naprawiać ustawienia protokołu, portu i typu proxy.

Jak wygląda i co oznacza

W curl komunikat wygląda tak: „CONNECT tunnel failed, response 407”. W przeglądarkach i rozwiązaniach antydetekcyjnych mogą to być frazy „Proxy tunnel failed”, „Unable to establish tunnel” lub „Tunnel connection failed”. Wspólne jest jedno: klient wysłał polecenie CONNECT, a proxy odpowiedziało czymś innym niż 200. Liczba obok to właśnie ten kod, a praca z nim sprowadza się do poprzednich kroków plus kilka szczególnych przypadków, które ujawniają się tylko na etapie tunelu.

Instrukcja

  1. Uruchom curl z kluczem -v do adresu HTTPS i znajdź wiersz z tunnel failed. Zapisz liczbę po słowie response.
  2. Jeśli to 407, wróć do kroku 2. Różnica jest tylko w jednym: upewnij się, że oprogramowanie przekazuje autoryzację właśnie na etapie CONNECT. W starszych wersjach niektórych programów pole „Autoryzacja proxy” działa tylko na żądania HTTP, a tunel wychodzi bez hasła.
  3. Jeśli to 502 lub 504, wróć do kroków 3 i 4. Proxy nie mogło otworzyć połączenia z portem 443 strony lub nie doczekało się go.
  4. Jeśli to 403, proxy odmówiło otwarcia tunelu do wskazanego portu lub hosta. Sprawdź, do jakiego portu się łączysz. Proxy mobilne zwykle pozwalają na tunele na 443 i kilka popularnych portów. Jeśli twój serwis nasłuchuje na niestandardowym porcie, zapytaj w panelu lub u dostawcy, czy jest dozwolony.
  5. Jeśli to 400, proxy nie zrozumiało polecenia. Najczęstsza przyczyna — podałeś proxy SOCKS5 jako HTTP lub odwrotnie. Otwórz panel klienta i sprawdź, jaki protokół i port zostały przydzielone. U wielu dostawców dla HTTP i SOCKS5 są różne porty tego samego kanału.
  6. Popraw schemat w poleceniu. Dla SOCKS5 użyj: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. Litera h w socks5h oznacza, że nazwy domenowe rozwiązuje proxy, a nie twój komputer. Dla proxy mobilnych to preferowany wariant.
  7. Jeśli jesteś w przeglądarce antydetekcyjnej, otwórz ustawienia proxy profilu i znajdź listę rozwijaną typu: HTTP, HTTPS, SOCKS5. Wybierz ten, który jest wskazany w panelu klienta, i sprawdź port. Po zapisaniu zrestartuj profil w pełni, a nie tylko odśwież kartę.
  8. Jeśli obok tunnel failed nie ma liczby, a jest tylko fraza, włącz w oprogramowaniu rozszerzone logowanie lub odtwórz sytuację przez curl, aby uzyskać kod.
  9. Sprawdź, czy twoje oprogramowanie nie próbuje ustanowić połączenia TLS z samym proxy. Niektóre programy przy wyborze typu „HTTPS” szyfrują nie tylko ruch do strony, ale i połączenie z proxy. Jeśli proxy tego nie obsługuje, dostaniesz tunnel failed lub błąd uzgadniania. Przełącz się na typ „HTTP” dla połączenia z proxy: ruch do strony i tak pozostanie zaszyfrowany wewnątrz tunelu.
  10. Powtórz test i upewnij się, że CONNECT dostaje 200, a strona się ładuje.

Wskazówka: zrób dwa krótkie żądania testowe częścią codziennej rutyny: jedno do adresu po HTTP, drugie do tego samego adresu po HTTPS. Jeśli pierwsze przechodzi, a drugie pada z tunnel failed, w sekundę rozumiesz, że chodzi o tunel, a nie o autoryzację czy kanał.

Oczekiwany rezultat

Fraza tunnel failed zniknęła z logów, dla każdego kanału zapisano prawidłowy typ i port, a w oprogramowaniu nie włączono zbędnego szyfrowania połączenia z proxy.

Możliwe problemy

  • Tunel się ustanawia, ale potem błąd certyfikatu. To już nie warstwa proxy: strona lub twój systemowy zestaw certyfikatów. Sprawdź datę i godzinę na komputerze.
  • Działa w curl, nie działa w oprogramowaniu przy tych samych danych. Oprogramowanie stosuje inny schemat lub dodaje własny prefiks. Przejrzyj jego dokumentację dotyczącą formatu wiersza proxy.
  • tunnel failed tylko dla jednej strony. Strona używa niestandardowego portu, wróć do punktu o 403.

Sprawdzenie: żądanie HTTPS przez curl i przez robocze oprogramowanie daje 200 na CONNECT, typ i port dla wszystkich kanałów są zapisane w tabeli.

Krok 6: Konfigurujemy prawidłową reakcję oprogramowania na każdy kod

Cel etapu: sprawić, aby błędy serwera proxy były obsługiwane automatycznie: jedne powtarzane z pauzą, inne natychmiast podnoszące alarm, a ty dostawałeś zrozumiałe logi, a nie strumień czerwonych wierszy.

Zasada: nie wszystkie błędy są takie same

Powtarzanie żądania przy 407 nie ma sensu: hasło nie stanie się prawidłowe od powtórzenia. Powtarzanie przy 502 w momencie rotacji jest konieczne: po pięciu sekundach wszystko zadziała. Powtarzanie przy 504 lepiej po zmianie IP. Te trzy zasady stanowią podstawę zdrowej obsługi błędów.

Instrukcja dla gotowego oprogramowania

  1. Otwórz ustawienia parsera lub menedżera kont i znajdź sekcję odpowiadającą za powtórzenia. Może nazywać się „Retries”, „Próby ponowne”, „Obsługa błędów”.
  2. Ustaw liczbę powtórzeń dla 5xx na 3, a początkową pauzę między nimi na 5 sekund ze zwiększaniem dwukrotnym: 5, 10, 20 sekund. Taki wzrost pauz nazywa się opóźnieniem wykładniczym i nie pozwala twojemu oprogramowaniu dobić przeciążonego kanału.
  3. Jeśli oprogramowanie pozwala podać listę kodów do powtórzenia, wpisz 502 i 504. Nie dodawaj tam 407.
  4. Znajdź ustawienie działania przy 407. Jeśli go nie ma, ustaw liczbę powtórzeń w sekcji ogólnej na minimum i włącz powiadomienie o nieudanych żądaniach. Twoim celem jest zobaczenie 407 w pierwszych minutach, a nie po dobie przestoju.
  5. Znajdź pole na link zmiany IP, jeśli istnieje. Wklej tam link z panelu klienta dla odpowiedniego kanału i włącz opcję „Zmień IP przy błędzie” lub „Rotacja przy niepowodzeniu”.
  6. Ogranicz liczbę równoczesnych strumieni na jeden kanał mobilny. Zacznij od 3-5 i zwiększaj, aż udział 502 pozostanie poniżej jednego procenta.
  7. Włącz szczegółowy log z zapisywaniem kodu odpowiedzi i nagłówków. Upewnij się, że w logu widać różnicę między kodem od proxy a kodem od strony: wiele programów pokazuje to w osobnej kolumnie „Proxy status”.
  8. Zapisz ustawienia, zrestartuj oprogramowanie i przeprowadź testową serię 50 żądań.

Instrukcja dla własnego skryptu

Jeśli piszesz kod, logika jest ta sama. W pseudokodzie w Pythonie z biblioteką requests wygląda to tak:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Zwróć uwagę na trzy rzeczy. Pierwsza: przy 407 wychodzimy z pętli natychmiast i wysyłamy powiadomienie. Druga: przy 502 i 504 najpierw zmieniamy IP, potem czekamy rosnącą pauzę. Trzecia: wartość timeout została wybrana tak, aby doczekać się kodu od proxy, a nie przerwać połączenie wcześniej.

Uwaga: w niektórych bibliotekach błąd na etapie CONNECT przychodzi nie jako odpowiedź z kodem, a jako wyjątek z tekstem zawierającym tunnel failed i liczbę. Łap takie wyjątki osobno i wyciągaj kod z tekstu, inaczej twoja logika powtórzeń nie zadziała.

Wskazówka: licz udziały kodów dla każdego kanału na dobę i wyświetlaj je w prostej tabeli. Kanał, u którego 5xx jest stale wyższe niż u pozostałych, warto sprawdzić pierwszy, nawet jeśli formalnie działa.

Oczekiwany rezultat

Oprogramowanie automatycznie powtarza żądania przy 502 i 504 z rosnącą pauzą i zmianą IP, natychmiast informuje o 407, ogranicza liczbę strumieni i prowadzi log z rozdzieleniem kodów proxy i strony.

Możliwe problemy

  • Oprogramowanie powtarza też 407, przez co proxy tymczasowo blokuje adres. Wyłącz powtórzenia dla 4xx całkowicie lub zmniejsz ogólną liczbę powtórzeń do jednego.
  • Po włączeniu rotacji przy błędzie IP zmienia się zbyt często. Wprowadź minimalny odstęp między zmianami, na przykład 60 sekund, aby jedna seria 502 nie wywołała pięciu rotacji pod rząd.
  • Log rozrasta się do gigabajtów. Zapisuj nagłówki tylko dla odpowiedzi z kodami błędów, a dla 200 zachowuj jeden wiersz.

Sprawdzenie: testowa seria 50 żądań zakończyła się bez ręcznej interwencji, w logu widać powtórzenia z pauzami 5, 10, 20 sekund dla 5xx, a przy podstawieniu nieprawidłowego hasła oprogramowanie zatrzymało się i wyświetliło powiadomienie o 407.

Sprawdzenie rezultatu: lista kontrolna i testy

Przejdź przez listę i odhacz każdy punkt. Jeśli choć jeden nie jest wykonany, wróć do odpowiedniego kroku.

Lista kontrolna

  • Polecenie curl z kluczem -v wykonuje się i umiesz znaleźć w wyjściu wiersz odpowiedzi na CONNECT oraz nagłówki pomocnicze proxy.
  • Dla każdego kanału w tabeli zapisane są host, port, typ protokołu, sposób autoryzacji i zakodowane hasło.
  • Przy autoryzacji po IP aktualny adres twojej maszyny zgadza się z adresem w panelu klienta.
  • Żądanie HTTPS przez każdy kanał dostaje 200 na CONNECT.
  • Zmierzono typowy czas do pierwszego bajtu przez każdy kanał, a limit oczekiwania w oprogramowaniu przewyższa go z zapasem.
  • W oprogramowaniu skonfigurowano powtórzenia tylko dla 502 i 504, z pauzami 5, 10, 20 sekund i zmianą IP przed powtórzeniem.
  • Przy 407 oprogramowanie zatrzymuje się i powiadamia.
  • Liczba strumieni na kanał jest ograniczona, a udział 5xx w serii testowej jest poniżej jednego procenta.
  • Dziennik incydentów jest prowadzony i zawiera choć jeden w pełni przeanalizowany wpis.

Jak przetestować

  1. Celowo wpisz nieprawidłowe hasło i uruchom jedno żądanie. Oczekiwane: 407 w curl i powiadomienie w oprogramowaniu bez serii powtórzeń.
  2. Przywróć prawidłowe hasło i uruchom 30 żądań do stabilnej strony z pauzą jednej sekundy. Oczekiwane: wszystkie 200 albo nie więcej niż jedno 5xx z udanym powtórzeniem.
  3. Podczas serii naciśnij link zmiany IP w panelu klienta. Oczekiwane: jedno-dwa 502 w logu, potem automatyczne powtórzenie i kontynuacja serii.
  4. Wskaż w ustawieniach typ SOCKS5 dla kanału przydzielonego jako HTTP i zrób żądanie. Oczekiwane: tunnel failed lub błąd protokołu, który rozpoznasz w sekundę. Przywróć prawidłowy typ.

Wskaźniki udanego wykonania

Udział błędów warstwy proxy w roboczych seriach nie przekracza jednego-dwóch procent, każdy błąd jest sklasyfikowany po kodzie i żaden nie wymaga ręcznej interwencji poza 407. Czas reakcji na 407 to minuty, a nie godziny.

Typowe błędy i rozwiązania

Problem: 407 po każdym restarcie routera

Przyczyna: autoryzacja po IP, a dostawca przydziela dynamiczny adres.

Rozwiązanie: przełącz się na autoryzację po loginie i haśle lub włącz oba sposoby jednocześnie. Jeśli potrzebujesz właśnie IP, zamów u dostawcy statyczny adres.

Problem: hasło prawidłowe, ale 407 w przeglądarce, choć curl przechodzi

Przyczyna: przeglądarka lub profil przeglądarki antydetekcyjnej zbuforował stare dane.

Rozwiązanie: zapisz proxy ponownie w ustawieniach konkretnego profilu i zrestartuj profil, w razie potrzeby wyczyść zapisane hasła dla hosta proxy.

Problem: 502 dokładnie co N minut

Przyczyna: pokrywa się z interwałem automatycznej rotacji IP.

Rozwiązanie: zsynchronizuj pauzy oprogramowania z harmonogramem rotacji albo przejdź na zmianę IP przez link w wygodnych momentach między zadaniami.

Problem: 502 przy dużej liczbie strumieni, przy małej wszystko dobrze

Przyczyna: przeciążenie kanału mobilnego.

Rozwiązanie: zmniejsz równoległość do 3-5 strumieni na kanał i rozłóż obciążenie na kilka kanałów.

Problem: 504 tylko na jednej stronie, pozostałe szybkie

Przyczyna: strona wolno generuje treść lub ogranicza adresy operatorów mobilnych.

Rozwiązanie: używaj lżejszych adresów strony, zmieniaj IP przed powtórzeniem, przy trwałym problemie przenieś pracę z tą stroną na kanał innego operatora.

Problem: zamiast 504 zaczął przychodzić brak odpowiedzi bez kodu

Przyczyna: limit oczekiwania w oprogramowaniu jest mniejszy niż wewnętrzny limit proxy.

Rozwiązanie: zwiększ limit w oprogramowaniu do wartości, przy której zdążysz otrzymać kod, zwykle 30-60 sekund.

Problem: tunnel failed, response 400

Przyczyna: port SOCKS5 podany jako proxy HTTP lub odwrotnie.

Rozwiązanie: porównaj typ i port z panelem klienta, dla SOCKS5 używaj schematu socks5h, dla HTTP — http.

Problem: tunnel failed, response 403 na niestandardowy port

Przyczyna: proxy nie pozwala na tunele do tego portu.

Rozwiązanie: ustal listę dozwolonych portów u dostawcy i w miarę możliwości przekonfiguruj docelowy serwis na port 443.

Problem: kod 502 lub 504 przychodzi z nagłówkiem Server od strony

Przyczyna: to odpowiedź samej strony, a nie warstwy proxy: strona ma problemy z własnymi wewnętrznymi serwisami.

Rozwiązanie: poczekaj i powtórz później; zmiana proxy nie pomoże.

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

Jeśli podstawowa diagnostyka jest opanowana, poniższe techniki uczynią pracę z błędami warstwy proxy niemal automatyczną.

Ręczne przekazywanie nagłówka autoryzacji

Czasem warto sprawdzić, jak proxy reaguje na konkretny nagłówek. Zakoduj parę login:hasło w Base64 dowolnym lokalnym narzędziem i przekaż nagłówek samodzielnie: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Ten sposób działa dla zwykłych żądań HTTP i pomaga zrozumieć, czy proxy w ogóle przyjmuje dane, niezależnie od tego, jak formuje je twoje oprogramowanie. Dla CONNECT użyj klucza --proxy-header zamiast -H.

Rozwiązywanie nazw po stronie proxy

Schemat socks5h i tunel HTTP przekazują nazwę domenową serwerowi proxy, a nie rozwiązują jej lokalnie. Daje to dwie korzyści: strona widzi żądanie w pełni wychodzące z sieci mobilnej, a ty pozbywasz się rozbieżności, gdy twój lokalny DNS zwraca jeden adres, a sieć operatora — inny. Jeśli widzisz 502 tylko przy lokalnym rozwiązywaniu, przejście na socks5h często rozwiązuje problem bez zwracania się do dostawcy.

Automatyzacja przez API dostawcy

mobileproxy.space ma interfejs programistyczny do zmiany IP i pobierania statusu kanałów. Wbuduj wywołanie zmiany IP w obsługę 504, a sprawdzanie statusu kanału w obsługę trwałych 502. Wtedy skrypt sam zdecyduje, czy powtórzyć żądanie przez ten sam kanał, czy przełączyć się na zapasowy. Prosty algorytm: trzy 502 pod rząd w ciągu minuty — zapytaj o status, jeśli kanał jest w porządku, zmień IP, jeśli nie — oznacz kanał jako niedostępny na pięć minut i przejdź do następnego.

Rozdzielenie metryk proxy i strony

Załóż w systemie monitoringu dwie osobne metryki: kody, które przyszły z nagłówkami proxy, i kody, które przyszły bez nich. Pierwsza metryka mówi o zdrowiu twojej infrastruktury proxy, druga — o zachowaniu docelowych stron. Dopóki są zmieszane, będziesz szukać błędu serwera proxy tam, gdzie go nie ma, i odwrotnie.

Pula kanałów z wagami

Przypisz każdemu kanałowi wagę, która spada przy każdym 5xx i powoli odbudowuje się w czasie. Rozdzielaj żądania proporcjonalnie do wag. Takie podejście automatycznie odsuwa obciążenie od problematycznego operatora lub regionu i przywraca je, gdy kanał się odbuduje, bez ani jednego ręcznego przełączenia.

Eksport HAR z przeglądarki

Dla złożonych przypadków w przeglądarce antydetekcyjnej otwórz zakładkę Network, odtwórz błąd i wybierz „Save all as HAR”. Plik zawiera wszystkie nagłówki żądań i odpowiedzi, w tym etapy, których nie widać w zwykłym logu programu. Przed wysłaniem do wsparcia usuń z pliku wartości Proxy-Authorization i ciasteczka.

Optymalizacja limitów oczekiwania

Zbierz statystyki czasu do pierwszego bajtu dla każdego kanału i kierunku za tydzień. Ustaw limit oczekiwania w oprogramowaniu na poziomie 95. percentyla plus 10 sekund. Taki limit rzadko przerywa żywe żądania i jednocześnie szybko uwalnia strumienie przy rzeczywistych zawieszeniach.

FAQ: częste pytania o diagnostykę

Jak poznać, że 502 zwróciło proxy, a nie strona?

Spójrz na nagłówki odpowiedzi. Jeśli jest Proxy-Agent, Via lub inne nagłówki pomocnicze proxy i nie ma Set-Cookie oraz Server strony, odpowiedź jest od proxy. Dodatkowo: jeśli kod przyszedł od razu w odpowiedzi na CONNECT, to na pewno proxy.

Czy warto powtarzać żądanie przy 407?

Nie. Dane uwierzytelniające nie staną się prawidłowe od powtórzenia, a seria nieudanych prób może doprowadzić do tymczasowej blokady twojego adresu po stronie proxy. Popraw dane i powtórz raz.

Dlaczego w curl wszystko działa, a w moim oprogramowaniu nie?

Najczęściej oprogramowanie inaczej formuje wiersz proxy, nie koduje znaków specjalnych hasła, stosuje inny typ protokołu lub nie przekazuje autoryzacji przy CONNECT. Porównaj dokładny wiersz z ustawień oprogramowania z działającym poleceniem curl znak po znaku.

Jak prawidłowo zapisać hasło ze znakami specjalnymi?

W wierszu adresu koduj: @ jako %40, : jako %3A, # jako %23, % jako %25, spację jako %20. W osobnych polach loginu i hasła wpisuj hasło tak, jak jest, bez kodowania.

Czym 504 różni się od timeoutu, o którym pisze się w innych artykułach?

504 to kod, który proxy zwróciło samo, doczekawszy się własnego limitu oczekiwania na stronę. Timeout bez kodu oznacza, że połączenie zerwał twój klient, nie otrzymawszy niczego. Leczone są inaczej, dlatego zostały rozdzielone na różne materiały.

Ile strumieni można puszczać przez jeden kanał mobilny?

Nie ma uniwersalnej liczby. Zacznij od 3-5 i zwiększaj, aż udział 502 pozostanie poniżej jednego procenta. Dla ciężkich stron liczba będzie mniejsza, dla lekkich żądań API większa.

Czy trzeba zmieniać IP przy każdym błędzie?

Przy 504 i trwałych 502 — tak, to pierwsze działanie. Przy 407 — nie, zmiana IP nie wpływa na autoryzację. Wprowadź minimalny odstęp między zmianami, aby seria błędów nie wywołała lawiny rotacji.

Co wysłać do wsparcia, aby szybciej rozwiązać sprawę?

Pełne wyjście curl -v z hasłem zamienionym na gwiazdki, dokładny czas z sekundami i strefą czasową, host i port kanału, docelową domenę, typ autoryzacji i wynik żądania bezpośredniego bez proxy. Z takim zestawem wsparcie zwykle odpowiada już w pierwszej wiadomości.

Czy można używać HTTPS do połączenia z samym proxy?

Tylko jeśli dostawca wyraźnie to obsługuje. W większości przypadków dla proxy mobilnych połączenie z proxy idzie po zwykłym HTTP lub SOCKS5, a szyfrowanie ruchu do strony zapewnia tunel. Włączenie zbędnego szyfrowania do proxy daje tunnel failed lub błąd uzgadniania.

Podsumowanie

Przeszedłeś drogę od niezrozumiałego czerwonego wiersza w logu do pełnego systemu diagnostyki. Teraz umiesz ustalać, kto dokładnie zwrócił odpowiedź, czytasz 407 jako sygnał do sprawdzenia danych uwierzytelniających i sposobu autoryzacji, 502 jako oznakę awarii za proxy lub w momencie rotacji, 504 jako uczciwy raport proxy o wolnej stronie, a tunnel failed jako opakowanie na jeden z tych kodów z podpowiedzią w postaci liczby. Twoje oprogramowanie nie powtarza już bezsensownego i nie poddaje się przy chwilowym.

Co robić dalej

  1. Prowadź dziennik incydentów co najmniej przez miesiąc. Już po dwóch tygodniach zauważysz powtarzające się wzorce i usuniesz ich przyczyny.
  2. Raz w tygodniu przeglądaj udziały kodów dla kanałów i rozdzielaj obciążenie.
  3. Automatyzuj zmianę IP i sprawdzanie statusu przez API dostawcy, aby rutynowe 5xx rozwiązywały się bez ciebie.
  4. Przestudiuj pokrewne materiały bloga o timeoutach sieciowych i o zachowaniu docelowych stron, aby zamknąć pozostałe dwa odcinki drogi żądania.

W jakim kierunku się rozwijać

Następny poziom to budowa własnej puli kanałów z wagami i monitoringiem, gdzie błąd serwera proxy staje się nie powodem do paniki, a punktem na wykresie, który system obsługuje sam. Wszystkie narzędzia do tego już masz: zrozumienie kodów, curl, panel dostawcy i nawyk zapisywania. Dobrej pracy i stabilnych 200.

O autorze

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Doświadczenie zawodowe: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Wykształcenie: Bauman Moscow State Technical University. Information Systems and Technologies
Ekspertyza:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Podziel się artykułem: