Spis treści

Błędy proxy przerażają swoją nagłością. Przed chwilą zapytanie działało, a teraz widzisz tajemnicze 407, 502 albo komunikat tunnel connection failed. Dobra wiadomość: za każdym takim błędem stoi zrozumiała i logiczna przyczyna. Ten przewodnik nauczy cię czytać te komunikaty jak otwartą książkę.

Wprowadzenie: po co ci ten przewodnik i co z niego wyniesiesz

Praca z proxy przypomina rozmowę telefoniczną przez tłumacza. Twój klient rozmawia z proxy, proxy rozmawia z docelową stroną, a odpowiedź wraca tą samą drogą. Kiedy coś się psuje, ważne jest, aby zrozumieć, na którym dokładnie odcinku pojawił się problem. Właśnie temu poświęcony jest ten przewodnik.

Co z niego wyniesiesz:

  • Umiejętność natychmiastowego odróżnienia błędu proxy od błędu docelowej strony.
  • Zrozumienie, co oznaczają kody 407, 502, 504, 403 i komunikat tunnel connection failed.
  • Umiejętność czytania wyniku polecenia curl -v linia po linii z wyraźnym podziałem na odcinki klient-proxy-serwer.
  • Gotowe przykłady diagnostyki w curl, Python requests i Node.js z rzeczywistymi tekstami błędów.
  • Tabelę szybkiej diagnostyki objaw-przyczyna-sprawdzenie, którą możesz wydrukować i trzymać pod ręką.

Dla kogo jest ten przewodnik. Został napisany dla tych, którzy dopiero zaczynają pracę z proxy, ale zawiera też zaawansowane szczegóły dla doświadczonych programistów i specjalistów od automatyzacji. Jeśli konfigurujesz scrapery, pracujesz z multiaccountingiem lub po prostu chcesz zrozumieć, dlaczego twój skrypt nagle przestał pobierać dane, ten materiał jest dla ciebie.

Co warto wiedzieć wcześniej. Wystarczy podstawowe zrozumienie tego, czym jest URL, port i zapytanie HTTP. Głęboka wiedza o sieciach nie jest wymagana. Wszystkie terminy wyjaśnimy prostymi słowami po drodze.

Ile czasu to zajmie. Pierwsze przeczytanie zajmie około 30-40 minut. Przećwiczenie przykładów na własnym projekcie zajmie kolejne 20-30 minut. Potem diagnostyka typowego błędu zajmie ci minutę lub dwie.

Ważne doprecyzowanie tematu. W tym przewodniku omawiamy wyłącznie błędy samej warstwy proxy. Kod 429 (zbyt wiele żądań) i strategie ponawiania prób nie są tu poruszane, ponieważ to duży, osobny temat z własną logiką i podejściami. Dla 429 potrzebny jest osobny materiał o retry i limitach. Tutaj koncentrujemy się ściśle na diagnostyce awarii połączenia proxy.

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

Zanim zaczniemy diagnostykę, zbierzmy zestaw narzędzi. Wszystkie są darmowe i działają na każdym systemie operacyjnym.

Niezbędne narzędzia

  1. Zainstaluj curl. W większości systemów Linux i macOS już jest. Sprawdź poleceniem curl --version. Jeśli zobaczysz numer wersji, wszystko gotowe.
  2. W Windows curl jest częścią systemu od nowszych wersji. Otwórz PowerShell i wpisz to samo polecenie sprawdzające.
  3. Zainstaluj Python w wersji 3.10 lub nowszej, jeśli planujesz przykłady z requests. Sprawdź poleceniem python --version.
  4. Zainstaluj bibliotekę requests poleceniem pip install requests w terminalu.
  5. Zainstaluj Node.js w wersji 20 lub nowszej dla przykładów w JavaScript. Sprawdź poleceniem node --version.

Co trzeba przygotować

  • Dane twojego proxy: adres hosta, port, login i hasło, jeśli są potrzebne.
  • Testowy adres docelowy, do którego będziesz się odwoływać. Do testów wygodnie jest użyć prostej strony zwracającej informacje o zapytaniu.
  • Edytor tekstu, aby zapisywać logi i notatki z diagnostyki.

Wskazówka: Załóż osobny plik tekstowy o nazwie diagnostic-notes. Zapisuj w nim każde polecenie i jego wynik. To uratuje cię, gdy po pół godzinie zapomnisz, co już sprawdzałeś.

⚠️ Uwaga: Nigdy nie zapisuj loginu i hasła do proxy w publicznych czatach, publicznych repozytoriach ani na zrzutach ekranu. Wyciek tych danych daje obcym dostęp do twojego ruchu. Przechowuj je w bezpiecznym menedżerze haseł.

✅ Sprawdzenie: Na tym etapie powinny ci się poprawnie wykonywać trzy polecenia sprawdzające wersje: curl, python i node. Jeśli choć jedno nie działa, wróć do instalacji potrzebnego narzędzia.

Podstawowe pojęcia prostym językiem

Aby diagnostyka była świadoma, omówmy kilka kluczowych terminów. Nie pomijaj tego rozdziału, nawet jeśli terminy wydają się znajome.

Czym naprawdę jest proxy

Proxy to pośrednik między twoim programem a docelową stroną. Twoje zapytanie najpierw trafia do proxy, a proxy przekazuje je dalej. Odpowiedź wraca tą samą drogą. Z powodu tego pośrednictwa każdy błąd może pojawić się w trzech miejscach: u twojego klienta, u samego proxy lub u docelowej strony.

Główny podział: klient, proxy, serwer

Zapamiętaj trzy ogniwa łańcucha. Pierwsze ogniwo to twój klient, czyli program, który wysyła zapytanie. Drugie ogniwo to proxy, pośrednik. Trzecie ogniwo to serwer docelowy, ta strona, do której chcesz trafić. Cała diagnostyka sprowadza się do pytania: na którym z trzech ogniw nastąpiła awaria?

Kody HTTP w dwóch słowach

Strony i proxy odpowiadają kodami liczbowymi. Kody z 4 (na przykład 407, 403) zwykle oznaczają problem po stronie zapytania lub dostępu. Kody z 5 (502, 504) oznaczają problem po stronie serwera lub pośrednika. Ale jest tu podstępny niuans: kod 502 może przysłać zarówno docelowa strona, jak i samo proxy. Nauczenie się ich rozróżniania to jeden z głównych celów przewodnika.

Różnica między HTTP i HTTPS przez proxy

Gdy idziesz na zwykłą stronę po HTTP, proxy widzi całe zapytanie. Gdy idziesz na zabezpieczoną stronę po HTTPS, proxy nie może odczytać zawartości. Zamiast tego klient prosi proxy o utworzenie bezpiecznego tunelu specjalnym poleceniem CONNECT. Właśnie dlatego błąd tunnel connection failed pojawia się tylko przy HTTPS. Omówimy to szczegółowo osobno.

Wskazówka: Miej w głowie prosty obrazek. Klient puka do proxy. Proxy decyduje, czy go wpuścić. Potem proxy puka do strony. Strona decyduje, czy odpowiedzieć. Błąd powstaje na tym puknięciu, które się nie udało.

Krok 1: Jak odróżnić błąd proxy od błędu docelowej strony

Cel etapu: nauczyć się w kilka sekund rozumieć, kto zawinił — proxy czy strona. To fundamentalna umiejętność, od której zaczyna się każda diagnostyka.

Główna zasada podziału

Kluczowe pytanie brzmi tak: czy twoje zapytanie dotarło do docelowej strony, czy utknęło na proxy? Jeśli zapytanie utknęło na proxy, zawiniła warstwa proxy. Jeśli zapytanie dotarło do strony i strona odpowiedziała, problem jest po stronie strony.

  1. Spójrz na kod błędu i tekst komunikatu.
  2. Ustal, kto przysłał tę odpowiedź: proxy czy serwer. Opowie o tym nagłówek odpowiedzi i zawartość.
  3. Jeśli w tekście błędu wprost pojawia się słowo proxy, tunnel lub nazwa programu proxy, prawie na pewno zawiniła warstwa proxy.
  4. Jeśli odpowiedź zawiera znajomą stronę HTML docelowej witryny z jej logo i wyglądem, to znaczy, że zapytanie dotarło do strony.

Trzy szybkie oznaki błędu właśnie proxy

  • Kod 407. Ten kod istnieje tylko u proxy. Docelowa strona nigdy go nie przysyła. Zobaczyłeś 407 — jesteś na pewno na warstwie proxy.
  • Tekst tunnel connection failed lub Received HTTP code od proxy. Takie sformułowania generuje właśnie pośrednik.
  • Natychmiastowe odrzucenie połączenia. Jeśli zapytanie pada praktycznie od razu, jeszcze zanim mogłoby dotrzeć do strony, najprawdopodobniej problem jest między klientem a proxy.

Wskazówka: Przeprowadź eksperyment kontrolny. Wykonaj to samo zapytanie bezpośrednio, bez proxy. Jeśli bezpośrednio wszystko działa, a przez proxy nie, to problem jest w warstwie proxy lub w jej interakcji ze stroną. To odcina połowę hipotez w ciągu minuty.

Przykład w curl do szybkiego sprawdzenia

Wykonaj zapytanie przez proxy z flagą szczegółowego wyjścia. Polecenie wygląda tak: curl -v -x http://login:hasło@host:port https://przykładowa-strona. Flaga -v pokazuje cały dialog. Flaga -x ustawia proxy. Patrz na linie zaczynające się od strzałek i gwiazdek. O nich szczegółowo w osobnym kroku o czytaniu logów.

⚠️ Uwaga: Nigdy nie wyciągaj wniosków na podstawie jednego zapytania do niestabilnej strony. Powtórz zapytanie dwa-trzy razy. Jednorazowa awaria sieci może wyglądać jak błąd proxy, choć proxy nie ma z tym nic wspólnego.

✅ Sprawdzenie: Powinieneś umieć dla każdego komunikatu o błędzie odpowiedzieć na pytanie: przysłało to proxy czy strona? Jeśli potrafisz — przechodź dalej. Jeśli wciąż się wahasz, wróć do trzech szybkich oznak powyżej.

Krok 2: Błąd 407 Proxy Authentication Required

Cel etapu: nauczyć się naprawiać najczęstszy błąd autoryzacji w proxy i zrozumieć, czym różni się od podobnego kodu 401.

Co oznacza 407 i czym różni się od 401

Kod 407 mówi dosłownie tyle: proxy wymaga, żebyś się przedstawił loginem i hasłem, ale tego nie zrobiłeś lub zrobiłeś to niepoprawnie. Kluczowa różnica względem 401: kod 401 przysyła docelowa strona, gdy to ona wymaga autoryzacji. A kod 407 przysyła właśnie proxy. Jeśli widzisz 407, to znaczy, że nawet nie dotarłeś do strony — zatrzymał cię pośrednik na wejściu.

Gdzie dokładnie ginie login i hasło

Najczęściej dane giną w trzech miejscach.

  1. Login i hasło w ogóle nie zostały przekazane w poleceniu. Klient zapukał do proxy anonimowo, a proxy go odrzuciło.
  2. Dane zostały przekazane, ale z literówką. Jedna zbędna spacja lub zła klawiatura — i autoryzacja nie przechodzi.
  3. Dane zostały przekazane poprawnie, ale hasło zawiera znaki specjalne, które psują strukturę ciągu połączenia. To najbardziej podstępna przyczyna.

Znaki specjalne w haśle i kodowanie URL

Ciąg połączenia do proxy wygląda tak: login dwukropek hasło małpa host dwukropek port. Problem w tym, że dwukropek, małpa, ukośnik i inne znaki mają specjalne znaczenie wewnątrz tego ciągu. Jeśli twoje hasło zawiera na przykład małpę lub dwukropek, program zrozumie je niepoprawnie i rozerwie ciąg w złym miejscu.

Rozwiązanie nazywa się kodowaniem URL. Znaki specjalne zastępuje się kodem ze znaku procentu i dwóch cyfr lub liter. Na przykład małpa zamienia się w procent cztery zero, dwukropek zamienia się w procent trzy A, ukośnik zamienia się w procent dwa F, spacja zamienia się w procent dwa zero.

  1. Znajdź w swoim haśle wszystkie znaki specjalne.
  2. Zastąp każdy z nich jego kodem URL.
  3. Złóż ciąg połączenia od nowa z zakodowanym hasłem.
  4. Powtórz zapytanie.

Wskazówka: Nie koduj hasła ręcznie, jeśli jest złożone. W Pythonie jest funkcja do kodowania z modułu urllib.parse o nazwie quote. Przekaż jej hasło, a zwróci bezpieczną wersję. To wyklucza błędy ręcznego wpisywania.

Przykład w curl

Rzeczywisty tekst błędu przy niepoprawnej autoryzacji wygląda tak: curl (56) Received HTTP code 407 from proxy after CONNECT. Albo na stronie HTTP: HTTP 407 Proxy Authentication Required. Poprawne polecenie z autoryzacją: curl -v --proxy-user login:hasło -x http://host:port https://przykładowa-strona. Użycie flagi --proxy-user jest często pewniejsze niż wpisywanie danych bezpośrednio w adres, ponieważ curl sam poprawnie obsłuży znaki.

Przykład w Python requests

W requests proxy ustawia się przez słownik. Klucze http i https, wartości — ciągi połączenia. Jeśli hasło zawiera znaki specjalne, opakuj je w funkcję quote. Typowy błąd w odpowiedzi obiektu: response.status_code zwróci 407, a w tekście będzie wzmianka o Proxy Authentication Required. Sprawdzaj właśnie kod statusu, a nie tylko tekst.

Przykład w Node.js

W Node przy użyciu popularnych klientów proxy ustawia się przez specjalnego agenta. Rzeczywisty błąd wygląda jak obiekt z polem statusCode równym 407 lub jak odrzucona obietnica z komunikatem o błędzie autoryzacji tunelu. Upewnij się, że przekazujesz nagłówek autoryzacji proxy, a nie nagłówek autoryzacji strony — to dwie różne rzeczy.

⚠️ Uwaga: Nagłówek autoryzacji dla proxy i nagłówek autoryzacji dla strony to dwa różne nagłówki. Jeden nazywa się Proxy-Authorization, drugi Authorization. Jeśli je pomylisz, dostaniesz albo 407 od proxy, albo 401 od strony. Sprawdzaj, który dokładnie nagłówek wysyła twoja biblioteka.

✅ Sprawdzenie: Po naprawieniu autoryzacji kod odpowiedzi powinien zmienić się z 407 na dowolny inny. Nawet jeśli strona odpowie swoim błędem, to już postęp: przeszedłeś przez proxy i dotarłeś do strony.

Krok 3: Błąd 502 od proxy

Cel etapu: nauczyć się rozumieć, kiedy 502 oznacza problem docelowej strony, a kiedy awarię samego kanału proxy.

Co oznacza 502

Kod 502 nazywa się Bad Gateway, czyli zła brama. Mówi, że pośrednik próbował odwołać się do następnego ogniwa, ale otrzymał niewyraźną lub zerwaną odpowiedź. Problem w tym, że 502 może przyjść w dwóch zupełnie różnych sytuacjach, a zewnętrznie są podobne.

Kiedy zawinił host docelowy

Pierwsza sytuacja: proxy poprawnie połączyło się z docelową stroną, ale strona zwróciła śmieci, zerwała połączenie lub sama nie mogła uzyskać odpowiedzi od swojego backendu. W tym przypadku proxy rzetelnie przekazało ci 502 jako stwierdzenie: dotarłem do strony, ale strona odpowiedziała źle.

  1. Wykonaj to samo zapytanie bezpośrednio, bez proxy.
  2. Jeśli bezpośrednio strona też odpowiada 502 lub się zawiesza, to znaczy, że zawiniła strona, a nie proxy.
  3. W tym przypadku zmiana proxy nic nie da. Problem jest po stronie celu.

Kiedy zawinił sam kanał

Druga sytuacja: samo proxy jest niestabilne, jego nadrzędny kanał się zerwał lub proxy nie mogło nawet normalnie ustanowić połączenia ze stroną. Wtedy 502 to oznaka chorego pośrednika.

  1. Wykonaj zapytanie przez to samo proxy do strony z założenia stabilnej.
  2. Jeśli nawet stabilna strona zwraca 502, to znaczy, że problem jest w kanale proxy.
  3. Spróbuj innego proxy lub innego węzła, jeśli go masz.

Wskazówka: Metoda weryfikacji krzyżowej działa niezawodnie. Zmieniaj po jednej zmiennej na raz. Najpierw ustal proxy i zmieniaj stronę. Potem ustal stronę i zmieniaj proxy. Przecięcie wyników pokaże winowajcę.

Rzeczywiste teksty błędów

W curl zobaczysz odpowiedź HTTP z kodem 502 i często stronę HTML z napisem Bad Gateway. Czasem w nagłówkach odpowiedzi widać oznakę, który serwer przysłał odpowiedź. W Python requests to response.status_code równy 502. W Node to pole statusCode równe 502. Zwróć uwagę na treść odpowiedzi: sformatowana strona docelowej witryny wskazuje, że zapytanie dotarło do strony, a zwięzła strona techniczna często pochodzi od proxy.

⚠️ Uwaga: Nie spiesz się z obwinianiem proxy przy pierwszym 502. Docelowe strony zwracają 502 bardzo często, zwłaszcza pod obciążeniem. Zawsze wykonaj zapytanie kontrolne bezpośrednio, zanim zmienisz ustawienia proxy.

✅ Sprawdzenie: Powinieneś umieć na podstawie wyników dwóch krzyżowych zapytań pewnie powiedzieć: to 502 jest od strony czy od proxy. Jeśli jeszcze ci się nie udaje, powtórz oba zapytania kontrolne i porównaj wyniki.

Krok 4: Błąd 504 i timeouty

Cel etapu: nauczyć się rozróżniać dwa zasadniczo różne rodzaje timeoutu i poprawnie je ustawiać w kliencie.

Co oznacza 504

Kod 504 nazywa się Gateway Timeout, czyli brama nie doczekała się odpowiedzi. Mówi, że pośrednik zbyt długo czekał na odpowiedź od następnego ogniwa i poddał się. Ale żeby zrozumieć, gdzie dokładnie zatrzymał się czas, trzeba rozdzielić dwa rodzaje timeoutu.

Connect timeout kontra read timeout

Istnieją dwa zupełnie różne momenty oczekiwania.

  • Connect timeout — to czas na ustanowienie samego połączenia. Klient próbuje dodzwonić się do proxy lub proxy do strony. Jeśli połączenie nie zostanie ustanowione w wyznaczonym czasie, uruchamia się connect timeout. Zwykle to oznaka, że adres jest niedostępny lub port zamknięty.
  • Read timeout — to czas oczekiwania na odpowiedź po tym, jak połączenie zostało już ustanowione. Połączenie jest, zapytanie poszło, ale dane nie przychodzą. Zwykle to oznaka, że strona długo myśli lub zawiesiła się na przetwarzaniu.

Jak je rozdzielić w kliencie

Poprawna diagnostyka zaczyna się od rozdzielnego ustawienia tych dwóch timeoutów. Wtedy od razu zrozumiesz, na jakim etapie zatrzymał się czas.

  1. W curl użyj flagi --connect-timeout do ograniczenia czasu ustanowienia połączenia. Osobno flaga --max-time ogranicza łączny czas całej operacji.
  2. W Python requests parametr timeout można przekazać jako krotkę dwóch liczb. Pierwsza liczba — connect timeout, druga — read timeout. Na przykład timeout z pięciu i trzydziestu sekund.
  3. W Node w większości klientów są osobne ustawienia dla czasu połączenia i dla czasu oczekiwania na odpowiedź. Ustaw je na różne wartości, aby widzieć, który dokładnie się uruchomił.

Jak czytać wynik

Jeśli uruchomił się connect timeout, to znaczy, że nawet nie ustanowiłeś połączenia. Sprawdzaj dostępność proxy i poprawność portu. Jeśli uruchomił się read timeout, to znaczy, że połączenie było, ale odpowiedź nie przyszła na czas. Sprawdzaj, czy strona nie jest przeciążona i czy nie wykonujesz zbyt ciężkiego zapytania.

Wskazówka: Ustaw connect timeout niewielki, około pięciu sekund. Ustanowienie połączenia albo następuje szybko, albo nie następuje wcale. A read timeout ustaw z zapasem, ponieważ niektóre strony uczciwie przygotowują odpowiedź dłużej.

⚠️ Uwaga: Zbyt mały read timeout prowadzi do fałszywych błędów. Będziesz przerywać normalne, ale wolne odpowiedzi i myśleć, że proxy jest zepsute. Zawsze sprawdzaj, czy sam nie ustawiłeś zbyt surowego limitu.

Rzeczywiste teksty błędów

W curl connect timeout wygląda jak komunikat Connection timed out po stderr. W Python requests to wyjątek ConnectTimeout dla połączenia i ReadTimeout dla odpowiedzi. Właśnie nazwa wyjątku od razu mówi ci, który etap zawiódł. W Node zobaczysz błąd z kodem ETIMEDOUT lub osobny komunikat o przekroczeniu czasu odpowiedzi.

✅ Sprawdzenie: Po ustawieniu rozdzielnych timeoutów powinieneś otrzymywać w błędzie wyraźne wskazanie: to timeout połączenia czy timeout czytania. Jeśli widzisz tylko ogólne słowo timeout bez uściślenia, to znaczy, że timeouty nie są jeszcze rozdzielone.

Krok 5: Błąd tunnel connection failed i metoda CONNECT

Cel etapu: zrozumieć, dlaczego ten błąd pojawia się tylko na zabezpieczonych stronach i jak go diagnozować.

Dlaczego błąd przychodzi tylko przy HTTPS

Gdy idziesz na zwykłą stronę HTTP, proxy po prostu przekazuje twoje zapytanie. Ale gdy idziesz na stronę HTTPS, zawartość jest zaszyfrowana i proxy nie może jej odczytać. Dlatego klient najpierw wysyła do proxy specjalne polecenie CONNECT z adresem strony. To polecenie oznacza prośbę: proszę, zbuduj mi bezpieczny tunel do tego adresu, będę rozmawiać ze stroną bezpośrednio przez ciebie.

Jeśli proxy z jakiegoś powodu nie mogło zbudować tunelu, zwraca błąd tunnel connection failed. Przy zwykłym HTTP takiego polecenia nie ma, dlatego tego błędu przy HTTP nie bywa. To twój główny znak rozpoznawczy.

Główne przyczyny niepowodzenia tunelu

  • Proxy nie mogło połączyć się z adresem docelowym. Możliwe, że strona jest niedostępna lub port zamknięty.
  • Proxy zabrania metody CONNECT do tego adresu lub portu. Niektóre proxy zezwalają tylko na określone porty.
  • Autoryzacja nie przeszła. W tym przypadku często zobaczysz kombinację: najpierw próba CONNECT, potem kod 407.
  • Proxy jest przeciążone lub jego nadrzędny kanał zerwał się w momencie budowania tunelu.

Jak diagnozować

  1. Wykonaj curl -v do adresu HTTPS i znajdź w wyniku linię z CONNECT. Pokazuje moment żądania tunelu.
  2. Spójrz, jaka odpowiedź przyszła na CONNECT. Odpowiedź z kodem 200 oznacza, że tunel zbudowany. Każdy inny kod oznacza porażkę.
  3. Jeśli obok widzisz 407, to znaczy, że problem jest w autoryzacji, a nie w samym tunelu. Wróć do kroku o 407.
  4. Jeśli widzisz odrzucenie połączenia, to znaczy, że proxy nie mogło dosięgnąć strony.

Wskazówka: Sprawdź, czy odwołujesz się właśnie do dozwolonego portu. Klasyczne porty dla zabezpieczonych połączeń są zwykle dozwolone, a niestandardowe porty wiele proxy blokuje. Zmiana portu na standardowy często rozwiązuje problem natychmiast.

Rzeczywiste teksty błędów

W curl to komunikat postaci curl (56) Received HTTP code od proxy after CONNECT lub bezpośrednie tunnel connection failed. W Python requests to wyjątek ProxyError z zagnieżdżonym komunikatem o nieudanym tunelu. W Node to błąd z tekstem o tym, że połączenie tunelowe nie udało się ustanowić, często ze wskazaniem kodu statusu od proxy.

⚠️ Uwaga: Nie myl porażki tunelu z błędem certyfikatu. Jeśli tunel jest zbudowany, ale potem pojawia się skarga na certyfikat strony — to już inny problem, niezwiązany z warstwą proxy. Patrz, na jakim etapie dokładnie powstał błąd: przed odpowiedzią na CONNECT czy po niej.

✅ Sprawdzenie: Powinieneś znajdować w wyniku curl linię z odpowiedzią na CONNECT i rozumieć po jej kodzie, czy tunel się zbudował. Odpowiedź 200 — tunel jest. Inny kod — szukaj przyczyny porażki.

Krok 6: Błąd 403 od proxy

Cel etapu: nauczyć się rozpoznawać, kiedy 403 przysyła proxy z powodu limitów, geografii lub zabronionego portu.

Co oznacza 403 w kontekście proxy

Kod 403 nazywa się Forbidden, czyli zabronione. Zwykle ten kod przysyła docelowa strona, gdy zamyka dostęp. Ale proxy też może przysłać 403, gdy samo decyduje nie przepuścić twojego zapytania. Zadanie polega na zrozumieniu, kto dokładnie postawił zakaz.

Trzy przyczyny 403 od proxy

  • Limity. Proxy może ograniczać liczbę żądań, objętość ruchu lub liczbę jednoczesnych połączeń. Po przekroczeniu zwraca 403 jako odmowę obsługi.
  • Ograniczenie geograficzne. Niektóre proxy zezwalają na odwołania tylko do określonych regionów lub wręcz przeciwnie, zabraniają określonych kierunków. Zapytanie w zamkniętym kierunku otrzymuje 403.
  • Zabroniony port. Proxy może zezwalać tylko na standardowe porty. Odwołanie do niestandardowego portu kończy się odmową.

Jak odróżnić 403 proxy od 403 strony

  1. Spójrz na treść odpowiedzi. Sformatowana strona docelowej witryny z jej wyglądem oznacza, że zakaz postawiła strona.
  2. Zwięzła strona techniczna lub wzmianka o proxy w tekście oznacza, że zakaz postawił pośrednik.
  3. Wykonaj to samo zapytanie bezpośrednio. Jeśli bezpośrednio strona zwraca 403, a przez proxy też, to znaczy, że zawiniła strona.
  4. Jeśli bezpośrednio strona się otwiera, a przez proxy zwraca 403, szukaj przyczyny w limitach lub ograniczeniach proxy.

Wskazówka: Sprawdź dokumentację lub panel zarządzania swojego proxy pod kątem limitów. Często w panelu widać, czy ruch został wyczerpany lub czy osiągnięto limit żądań. To najszybszy sposób potwierdzenia przyczyny.

⚠️ Uwaga: Nie próbuj obchodzić limitów proxy sprytnymi sztuczkami. Jeśli trafiłeś na ograniczenie taryfy, właściwym rozwiązaniem jest rozszerzenie taryfy lub optymalizacja liczby żądań. Obchodzenie ograniczeń technicznych serwisu narusza warunki użytkowania.

Rzeczywiste teksty błędów

W curl to odpowiedź HTTP 403 Forbidden z treścią, która podpowie źródło. W Python requests to response.status_code równy 403. W Node to statusCode równy 403. Zawsze analizuj treść odpowiedzi razem z kodem, ponieważ właśnie treść ujawnia prawdziwego autora zakazu.

✅ Sprawdzenie: Powinieneś po treści odpowiedzi i wyniku bezpośredniego zapytania ustalić, kto przysłał 403. Jeśli to proxy — sprawdzaj limity, geo i port. Jeśli strona — przyczyna nie leży w warstwie proxy.

Krok 7: Zerwanie połączenia bez odpowiedzi — connection reset i EOF

Cel etapu: nauczyć się diagnozować najbardziej zagadkowe przypadki, gdy odpowiedzi nie ma w ogóle, a połączenie po prostu się urywa.

Czym są te błędy

Czasem nie otrzymujesz żadnego kodu HTTP. Zamiast tego połączenie nagle się urywa. Są dwa typowe objawy.

  • Connection reset. Dosłownie — połączenie zresetowane. Jedna ze stron gwałtownie zamknęła kanał, nie kończąc wymiany. Jakby rozmówca rzucił słuchawką w połowie słowa.
  • EOF, unexpected end of file. Dosłownie — nieoczekiwany koniec danych. Klient czekał na kontynuację odpowiedzi, ale strumień danych nagle się skończył.

Na co patrzeć w pierwszej kolejności

  1. Ustal moment zerwania. Nastąpiło przed odpowiedzią na CONNECT, podczas przekazywania zapytania czy podczas otrzymywania odpowiedzi? Wynik curl -v pokaże ostatnią udaną linię przed zerwaniem.
  2. Jeśli zerwanie nastąpiło na samym początku, przy podłączaniu do proxy, najprawdopodobniej problem jest w samym proxy lub w drodze sieciowej do niego.
  3. Jeśli zerwanie nastąpiło po ustanowieniu tunelu, podczas komunikacji ze stroną, prawdopodobnie problem jest po stronie strony lub niestabilnego kanału.
  4. Powtórz zapytanie kilka razy. Stabilnie powtarzające się zerwanie mówi o przyczynie systemowej. Przypadkowe — o chwilowej niestabilności sieci.

Częste przyczyny

  • Proxy jest przeciążone i przymusowo zamyka nadmiarowe połączenia.
  • Nadrzędny kanał proxy jest niestabilny i się rwie.
  • Docelowa strona zamyka połączenie z powodu własnych ograniczeń.
  • Problemy sieciowe między ogniwami łańcucha.

Wskazówka: Przy przypadkowych zerwaniach prowadź statystyki. Wykonaj na przykład dwadzieścia zapytań pod rząd i policz, ile się zerwało. Jeśli rwie się jedno na dwadzieścia, to znośna niestabilność. Jeśli połowa, to znaczy, że jest problem systemowy, który trzeba rozwiązać.

Rzeczywiste teksty błędów

W curl to Connection reset by peer lub Empty reply from server. W Python requests to wyjątek ConnectionError z zagnieżdżonym komunikatem o zerwaniu połączenia. W Node to błąd z kodem ECONNRESET. Te komunikaty nie zawierają kodu HTTP właśnie dlatego, że wymiana HTTP nie zakończyła się normalnie.

⚠️ Uwaga: Zerwanie bez odpowiedzi łatwo pomylić z timeoutem. Różnica polega na tym, że przy timeoucie klient sam przerywa oczekiwanie, a przy resecie druga strona aktywnie zamyka kanał. Patrz na tekst błędu: słowo reset wskazuje na aktywny reset, słowo timeout — na upływ oczekiwania.

✅ Sprawdzenie: Powinieneś po ostatniej linii wyniku curl ustalać, na jakim etapie zerwało się połączenie. To od razu zawęża krąg podejrzanych do jednego-dwóch ogniw.

Krok 8: Praktyka — czytamy curl -v linia po linii

Cel etapu: nauczyć się widzieć w wyniku curl granicę między klientem, proxy i serwerem. To zwieńczenie całego przewodnika.

Co oznaczają symbole na początku linii

Wynik curl -v używa specjalnych symboli na początku każdej linii i to jest twój główny klucz do zrozumienia.

  • Gwiazdka na początku linii oznacza komunikat informacyjny samego curl. To komentarze klienta o tym, co robi: ustanawia połączenie, buduje tunel, sprawdza certyfikat.
  • Strzałka w prawo oznacza dane, które klient wysyła do proxy lub serwera. To zapytanie wychodzące.
  • Strzałka w lewo oznacza dane, które klient otrzymuje w odpowiedzi. To odpowiedź przychodząca.

Gdzie przebiega granica klient-proxy-serwer

Omówmy typową drogę na zabezpieczoną stronę przez proxy. Najpierw curl komunikuje gwiazdką, że łączy się z proxy pod podanym adresem i portem. To odcinek klient-proxy. Potem idzie strzałka wychodząca z poleceniem CONNECT — klient prosi proxy o zbudowanie tunelu. Dalej strzałka przychodząca z odpowiedzią na CONNECT — to odpowiedź proxy. Jeśli kod 200, tunel zbudowany, a granica się przesuwa: dalej cała wymiana idzie już klient-serwer przez tunel.

Analiza rzeczywistego logu

Wyobraźmy sobie, że widzisz taką sekwencję. Linia z gwiazdką: łączę się z adresem proxy i portem. To znaczy, klient znalazł proxy. Następna linia z gwiazdką: połączenie z proxy ustanowione. Świetnie, pierwszy odcinek przebyty. Dalej strzałka wychodząca: CONNECT do adresu docelowej strony. Klient poprosił o tunel. Potem strzałka przychodząca: odpowiedź na CONNECT z kodem. Tu kluczowe rozwidlenie.

  1. Jeśli kod odpowiedzi na CONNECT to 200, tunel zbudowany. Czytaj dalej.
  2. Jeśli kod to 407, proxy wymaga autoryzacji. Problem w warstwie proxy, odcinek klient-proxy. Idź do kroku o 407.
  3. Jeśli linia głosi tunnel connection failed, proxy nie mogło zbudować tunelu. Przyczyna między proxy a stroną.

Załóżmy, że tunel zbudowany. Dalej idą gwiazdki o sprawdzaniu zabezpieczonego połączenia ze stroną. To już odcinek klient-serwer. Potem strzałka wychodząca z prawdziwym zapytaniem: linia zapytania i nagłówki. Zwróć uwagę: do tego momentu strona w ogóle nie widziała twojego zapytania, była zajęta budowaniem tunelu. I wreszcie strzałka przychodząca z kodem odpowiedzi strony. Tu zaczyna się strefa odpowiedzialności docelowej strony.

Jak to stosować do diagnostyki

  1. Znajdź linię ustanowienia połączenia z proxy. Jeśli jej nie ma lub jest z błędem, problem między klientem a proxy.
  2. Znajdź odpowiedź na CONNECT. Po jej kodzie ustal, czy warstwa proxy przeszła.
  3. Znajdź strzałkę przychodzącą z odpowiedzią strony. Jeśli jest, to znaczy, że dotarłeś do strony, a każdy błąd tutaj to już strefa strony.
  4. Ostatnia linia przed zerwaniem zawsze podpowiada, na jakim odcinku wszystko się zepsuło.

Wskazówka: Czytaj wynik od góry do dołu jak kronikę podróży zapytania. Każda linia to krok drogi. Gdy tylko dotrzesz do linii z błędem lub zerwaniem, spójrz na poprzednią udaną linię. Wskaże ostatnie żywe ogniwo.

⚠️ Uwaga: Flaga -v pokazuje nagłówki, w tym linię autoryzacji proxy. Jeśli dzielisz się logiem z kimś dla pomocy, koniecznie zamazaj linię z danymi autoryzacyjnymi. Inaczej ujawnisz swój login i hasło.

✅ Sprawdzenie: Weź dowolny swój log curl -v i oznacz go: gdzie odcinek klient-proxy, gdzie odpowiedź na CONNECT, gdzie zaczyna się strefa strony. Jeśli pewnie wyznaczasz te granice, opanowałeś główną umiejętność diagnostyki.

Krok 9: Tabela szybkiej diagnostyki objaw-przyczyna-sprawdzenie

Cel etapu: otrzymać gotowy informator, do którego można sięgać w momencie każdego błędu.

Jak korzystać z tabeli

Znajdź swój objaw w pierwszej kolumnie. Przeczytaj prawdopodobną przyczynę. Wykonaj działanie z trzeciej kolumny w pierwszej kolejności — ono z największym prawdopodobieństwem potwierdzi lub zaprzeczy przyczynie.

Objaw: kod 407

Prawdopodobna przyczyna: nieprzekazane lub niepoprawne dane autoryzacji proxy, albo znaki specjalne w haśle zepsuły ciąg połączenia. Co sprawdzić najpierw: poprawność loginu i hasła, a także kodowanie URL znaków specjalnych w haśle.

Objaw: tunnel connection failed przy HTTPS

Prawdopodobna przyczyna: proxy nie mogło zbudować tunelu do strony, możliwe z powodu zabronionego portu lub niedostępności strony. Co sprawdzić najpierw: odpowiedź na CONNECT w wyniku curl -v i dozwoloność docelowego portu.

Objaw: kod 502

Prawdopodobna przyczyna: zła odpowiedź od następnego ogniwa, zawiniła albo strona, albo niestabilny kanał proxy. Co sprawdzić najpierw: zapytanie krzyżowe — ta sama strona bezpośrednio i to samo proxy do stabilnej strony.

Objaw: kod 504

Prawdopodobna przyczyna: upłynął czas oczekiwania, trzeba zrozumieć — połączenia czy odpowiedzi. Co sprawdzić najpierw: rozdzielne connect timeout i read timeout, aby zobaczyć, który etap się przeciągnął.

Objaw: kod 403 przez proxy

Prawdopodobna przyczyna: limity proxy, ograniczenie geograficzne lub zabroniony port. Co sprawdzić najpierw: treść odpowiedzi na źródło zakazu i panel zarządzania proxy pod kątem wyczerpanych limitów.

Objaw: connection reset lub ECONNRESET

Prawdopodobna przyczyna: jedna ze stron przymusowo zamknęła połączenie, często przeciążone proxy lub niestabilny kanał. Co sprawdzić najpierw: etap zerwania po ostatniej linii curl -v i powtarzalność problemu w serii zapytań.

Objaw: EOF, empty reply

Prawdopodobna przyczyna: strumień danych urwał się, nie dochodząc do końca odpowiedzi. Co sprawdzić najpierw: na jakim odcinku nastąpiło zerwanie — przed czy po odpowiedzi na CONNECT.

Objaw: connect timeout

Prawdopodobna przyczyna: niemożliwe ustanowienie połączenia, adres niedostępny lub port zamknięty. Co sprawdzić najpierw: dostępność adresu proxy i poprawność portu.

Objaw: read timeout

Prawdopodobna przyczyna: połączenie jest, ale odpowiedź nie przychodzi, strona długo przetwarza lub się zawiesiła. Co sprawdzić najpierw: czy twój read timeout nie jest zbyt mały i czy strona nie jest przeciążona.

Wskazówka: Wydrukuj tę tabelę lub zapisz w notatkach. W momencie rzeczywistego błędu pod presją łatwo zapomnieć logikę. Gotowy informator oszczędza nerwy i czas.

✅ Sprawdzenie: Przejdź po tabeli przez każdy ze swoich niedawnych błędów. Dla każdego z nich powinieneś znać pierwsze działanie sprawdzające.

Sprawdzenie wyniku: lista kontrolna diagnosty

Upewnij się, że opanowałeś wszystkie kluczowe umiejętności. Przejdź przez listę kontrolną.

  • Umiesz w kilka sekund odpowiedzieć, kto przysłał błąd — proxy czy strona.
  • Rozumiesz różnicę między 407 i 401 i umiesz naprawić autoryzację, w tym znaki specjalne w haśle.
  • Rozróżniasz 502 od strony i 502 od proxy przez weryfikację krzyżową.
  • Rozdzielasz connect timeout i read timeout i wiesz, co oznacza każdy.
  • Rozumiesz, dlaczego tunnel connection failed bywa tylko przy HTTPS, i umiesz czytać odpowiedź na CONNECT.
  • Rozpoznajesz trzy przyczyny 403 od proxy: limity, geo i port.
  • Diagnozujesz zerwania połączenia po etapie, na którym nastąpiły.
  • Czytasz wynik curl -v linia po linii i wyznaczasz granice klient-proxy-serwer.

Jak sprawdzić się

  1. Weź trzy rzeczywiste logi z różnymi błędami.
  2. Dla każdego ustal winne ogniwo w ciągu minuty.
  3. Nazwij pierwsze działanie sprawdzające z tabeli.
  4. Jeśli poradziłeś sobie ze wszystkimi trzema, diagnostyka opanowana.

✅ Sprawdzenie: Wskaźnikiem sukcesu jest to, że nie panikujesz już na widok błędu proxy, ale spokojnie rozkładasz go na ogniwa łańcucha.

Typowe błędy i rozwiązania

Problem: od razu zmieniam proxy przy każdym błędzie

Przyczyna: brak nawyku weryfikacji krzyżowej. Rozwiązanie: zawsze wykonaj zapytanie kontrolne bezpośrednio i do stabilnej strony, zanim zmienisz ustawienia. Połowa błędów okazuje się po stronie strony.

Problem: hasło z małpą psuje połączenie

Przyczyna: znak specjalny nie jest zakodowany i rozrywa ciąg. Rozwiązanie: zastosuj kodowanie URL do hasła lub użyj osobnego parametru autoryzacji zamiast wpisywania w adresie.

Problem: mylę 407 i 401

Przyczyna: nie rozróżniam autoryzacji proxy i autoryzacji strony. Rozwiązanie: zapamiętaj — 407 zawsze od proxy, 401 zawsze od strony. Sprawdzaj, który nagłówek wysyłasz: Proxy-Authorization czy Authorization.

Problem: zbyt surowy timeout rwie normalne zapytania

Przyczyna: read timeout ustawiony zbyt mały. Rozwiązanie: rozdziel connect i read timeouty, daj read z zapasem na wolne strony.

Problem: tunnel connection failed na niestandardowym porcie

Przyczyna: proxy zabrania CONNECT do tego portu. Rozwiązanie: użyj standardowego portu dla zabezpieczonych połączeń lub doprecyzuj listę dozwolonych portów u proxy.

Problem: widzę 502 i myślę, że proxy jest martwe

Przyczyna: nie sprawdziłem, kto przysłał 502. Rozwiązanie: weryfikacja krzyżowa. Często 502 przychodzi od przeciążonej docelowej strony, a proxy jest sprawne.

Problem: ujawniłem login i hasło w logu

Przyczyna: podzieliłem się wynikiem curl -v bez oczyszczenia. Rozwiązanie: zawsze zamazuj linię autoryzacji przed wysłaniem logu komukolwiek, a jeśli to możliwe, zmień skompromitowane dane.

Problem: traktuję zerwanie połączenia jako timeout

Przyczyna: nie rozróżniam reset i timeout. Rozwiązanie: patrz na tekst błędu. Reset — aktywne zamknięcie przez drugą stronę, timeout — upływ twojego oczekiwania. To różne przyczyny.

Dodatkowe możliwości dla zaawansowanych

Logowanie na stałe

Ustaw zapisywanie szczegółowych logów wszystkich zapytań proxy w twojej aplikacji. Wtedy przy wystąpieniu błędu będziesz już mieć historię i nie będziesz musiał odtwarzać problemu od nowa. Zapisuj kod odpowiedzi, etap zerwania i czas wykonania.

Automatyczna klasyfikacja błędów

W kodzie można mieć funkcję, która po typie wyjątku i kodzie odpowiedzi od razu przypisuje błąd do odpowiedniego ogniwa. Na przykład ConnectTimeout — odcinek połączenia, ReadTimeout — odcinek odpowiedzi, ProxyError z tunelem — warstwa proxy. To przyspiesza reakcję w zautomatyzowanych systemach.

Zbieranie statystyk stabilności

Prowadź metryki: odsetek udanych zapytań, odsetek zerwań, średni czas odpowiedzi. Gwałtowne pogorszenie metryk podpowie o problemie wcześniej, niż zetkniesz się z nim ręcznie.

Wskazówka: Rozdzielaj metryki po ogniwach. Osobno licz błędy ustanowienia połączenia i błędy na etapie odpowiedzi. Tak od razu zobaczysz, co dokładnie się degraduje — dostęp do proxy czy komunikacja ze stronami.

⚠️ Uwaga: Budując automatyczną obsługę, nie zamieniaj jej w nieskończone powtórzenia tego samego zapytania. Logika ponawiania prób to osobny, duży temat z własnymi zasadami, związany między innymi z kodem 429. Poświęcony jest mu osobny materiał i warto go poznać osobno.

FAQ: częste pytania o diagnostykę

Jak szybko zrozumieć, że zawiniło właśnie proxy, a nie mój kod?

Wykonaj to samo zapytanie bezpośrednio, bez proxy. Jeśli bezpośrednio wszystko działa, a przez proxy nie, problem jest w warstwie proxy lub w jej interakcji ze stroną. To odcina połowę hipotez w minutę.

Dlaczego dostaję 407, choć wpisałem poprawne hasło?

Najprawdopodobniej w haśle są znaki specjalne, które psują ciąg połączenia. Zastosuj kodowanie URL do hasła lub przekaż dane przez osobny parametr autoryzacji, a nie w adresie.

Czy kod 502 zawsze oznacza, że proxy jest zepsute?

Nie. 502 może przysłać też docelowa strona, jeśli sama odpowiedziała źle. Wykonaj weryfikację krzyżową: ta sama strona bezpośrednio i to samo proxy do stabilnej strony. Przecięcie wyników pokaże winowajcę.

Czym różni się connect timeout od read timeout?

Connect timeout — to oczekiwanie na ustanowienie połączenia. Read timeout — oczekiwanie na odpowiedź po tym, jak połączenie zostało już ustanowione. Rozdziel je w kliencie, a od razu zobaczysz, który etap się przeciągnął.

Dlaczego tunnel connection failed bywa tylko przy HTTPS?

Ponieważ dla zabezpieczonych stron klient prosi proxy o zbudowanie tunelu poleceniem CONNECT. Przy zwykłym HTTP takiego polecenia nie ma. Jeśli tunel się nie zbudował, przychodzi ten błąd i jest możliwy tylko przy HTTPS.

Jak odróżnić 403 od proxy od 403 od strony?

Spójrz na treść odpowiedzi. Sformatowana strona witryny oznacza zakaz strony. Strona techniczna lub wzmianka o proxy oznaczają zakaz pośrednika. Potwierdź bezpośrednim zapytaniem do strony.

Co robić przy przypadkowych zerwaniach połączenia?

Najpierw ustal powtarzalność: wykonaj serię zapytań i policz odsetek zerwań. Pojedyncze zerwania — znośna niestabilność sieci. Masowe zerwania — problem systemowy proxy lub kanału.

Jak bezpiecznie podzielić się logiem curl -v dla pomocy?

Koniecznie zamazaj linię z autoryzacją proxy i wszelkie wrażliwe nagłówki przed wysłaniem. Inaczej ujawnisz login i hasło. W razie wątpliwości zmień skompromitowane dane.

Dlaczego moje normalne zapytania czasem urywają się przez timeout?

Prawdopodobnie read timeout jest ustawiony zbyt surowo i przerywasz wolne, ale sprawne odpowiedzi. Zwiększ read timeout z zapasem, a connect timeout zostaw niewielki.

Gdzie poczytać o kodzie 429 i ponawianiu prób?

Kod 429 i strategie retry to osobny, duży temat, niezwiązany bezpośrednio z awariami warstwy proxy. Poświęcony jest mu osobny materiał, poznaj go osobno od diagnostyki błędów proxy.

Zakończenie: co opanowałeś i dokąd zmierzać dalej

Gratulacje. Przeszedłeś drogę od zagubienia przed zagadkowymi kodami do pewnej diagnostyki krok po kroku. Przypomnijmy, co masz teraz w swoim arsenale.

Podsumowanie wykonanych działań. Nauczyłeś się dzielić łańcuch na trzy ogniwa — klient, proxy i serwer — i ustalać, gdzie dokładnie powstał błąd. Rozgryzłeś kod 407 i autoryzację proxy, w tym podstępne znaki specjalne w haśle. Zrozumiałeś dwoistą naturę 502 i metodę weryfikacji krzyżowej. Opanowałeś rozdzielenie connect i read timeoutów przy 504. Rozgryzłeś metodę CONNECT i błąd tunnel connection failed przy HTTPS. Nauczyłeś się rozpoznawać trzy przyczyny 403 od proxy i diagnozować zerwania połączenia po etapie. I wreszcie opanowałeś główną umiejętność — czytanie wyniku curl -v linia po linii z precyzyjnym wyznaczaniem granic między ogniwami.

Co robić dalej. Utrwal umiejętność w praktyce. Za każdym razem, napotykając błąd proxy, nie zgaduj, ale spokojnie rozkładaj go na ogniwa za pomocą tabeli diagnostyki. Po tygodniu takiej praktyki diagnostyka stanie się automatyczna.

Dokąd się rozwijać. Następny logiczny krok to poznanie tematu kodu 429 i rozsądnych strategii ponawiania prób, któremu poświęcony jest osobny materiał. Potem zagłęb się w automatyczną klasyfikację błędów w kodzie i zbieranie metryk stabilności. To zamieni cię z człowieka, który gasi pożary, w inżyniera, który przewiduje problemy z wyprzedzeniem.

Wskazówka: Zapisz ten przewodnik i tabelę diagnostyki w zakładkach. Wracaj do nich przy każdym nowym błędzie, aż logika stanie się twoją drugą naturą. Pewność w diagnostyce przychodzi właśnie przez powtarzanie. Wszystko ci się uda.