Spis treści

Zdanie "proxy nie działa" brzmi dla inżyniera pomocy technicznej mniej więcej jak "boli gdzieś w środku" dla lekarza. Kierunek jest jasny, ale bez badań i objawów nie da się postawić diagnozy. W tym przewodniku nauczysz się zbierać dokładnie taki zestaw danych, który zamienia mgliste zgłoszenie w konkretne zadanie z jedną jasną odpowiedzią.

Wprowadzenie: dlaczego "nie działa" jest niemożliwe do zdiagnozowania

Wyobraź sobie dwa zgłoszenia do pomocy technicznej Proxeon. Pierwsze: "Kupiłem proxy, nic nie działa, pomóżcie". Drugie: "Proxy o identyfikatorze PX-48213 o 14:32 czasu polskiego (UTC+1) zwraca błąd połączenia przy żądaniu do api.example.com przez HTTP, przy czym do innej strony to samo proxy działa, połączenie bezpośrednie bez proxy też działa, załączam wynik curl". Pierwsze zgłoszenie uruchamia łańcuch pięciu-sześciu maili z dopytkami, z których każdy to godziny oczekiwania. Drugie zamyka się jedną odpowiedzią.

Różnica nie tkwi w uprzejmości ani w szczęściu. Różnica tkwi w danych. Inżynier nie widzi twojego ekranu, nie zna twojego systemu operacyjnego, nie może odtworzyć twojego żądania bez parametrów źródłowych. Wszystko, co ma, to tekst twojego maila. Jeśli w tym tekście nie ma faktów, pierwszą rzeczą, jaką zrobi, będzie poproszenie o fakty. I to jest właśnie ten łańcuch maili, który rozciąga rozwiązanie prostego problemu na kilka dni.

Co czytelnik z tego wyniesie

Po tym przewodniku będziesz w stanie w 15-20 minut zebrać pakiet diagnostyczny, który zawiera wszystko, co niezbędne do rozwiązania problemu już w pierwszej odpowiedzi. Będziesz mieć gotowy skrypt, który zbierze dane techniczne do jednego pliku tekstowego, szablon zgłoszenia do skopiowania i jasne zrozumienie, jakie testy wykonać, zanim napiszesz do pomocy technicznej.

Dla kogo jest ten przewodnik

Przewodnik jest skierowany do średnio zaawansowanych użytkowników proxy: tych, którzy potrafią otworzyć terminal lub wiersz poleceń, wiedzą, czym jest URL, i przynajmniej raz konfigurowali proxy w aplikacji. Zaawansowani użytkownicy znajdą tu gotowy skrypt diagnostyczny i tabelę izolacji problemu. Początkującym szczegółowo wyjaśnimy każdy termin.

Co trzeba wiedzieć wcześniej

Wystarczy rozumieć trzy rzeczy. Proxy to pośrednik, przez który przechodzi twoje żądanie sieciowe. Adres docelowy to strona lub usługa, do której się zwracasz. Klient to program, który wykonuje żądanie przez proxy (przeglądarka, scraper, skrypt). Resztę omówimy po drodze.

Ile czasu to zajmie

Pierwsze przejście przez przewodnik z konfiguracją skryptu zajmie około 30 minut. Potem zbieranie diagnostyki według gotowego szablonu będzie zajmować 10-15 minut. To nieporównywalnie mniej niż kilka dni wymiany maili z dopytkami.

Wskazówka: zapisz ten przewodnik i skrypt w zakładkach. Problemy z proxy zdarzają się rzadko, a gdy się pojawiają, trudno przypomnieć sobie całą procedurę od nowa. Gotowa lista kontrolna pod ręką oszczędza nerwy.

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

Zanim zaczniesz zbierać dane, upewnij się, że masz podstawowe narzędzia. Wszystkie są darmowe i w większości systemów już zainstalowane.

Niezbędne narzędzia

  • curl — narzędzie wiersza poleceń do wysyłania żądań sieciowych. To nasze główne narzędzie do odtwarzania problemu. W macOS i większości dystrybucji Linux jest preinstalowane. W Windows 10 i 11 również wchodzi w skład systemu.
  • Terminal lub wiersz poleceń — okno, w którym wpisujesz polecenia. W Windows to PowerShell lub Wiersz poleceń (cmd), w macOS i Linux — Terminal.
  • Edytor tekstu — Notatnik, TextEdit lub inny do przeglądania zebranego pliku i usuwania sekretów.
  • Dane twojego proxy od Proxeon — identyfikator, adres, port, login i hasło. Zostały ci wydane w panelu klienta.

Sprawdzenie obecności curl

Otwórz terminal i wykonaj proste sprawdzenie.

  1. W Windows naciśnij klawisz Win, wpisz PowerShell i otwórz aplikację.
  2. W macOS otwórz Spotlight skrótem Cmd+Spacja, wpisz Terminal i naciśnij Enter.
  3. W Linux otwórz terminal przez menu aplikacji lub skrótem Ctrl+Alt+T.
  4. Wpisz polecenie 
    curl --version
    i naciśnij Enter.

Jeśli zobaczysz wiersz w rodzaju "curl 8.x.x" z listą obsługiwanych protokołów, narzędzie jest gotowe. Jeśli system pisze, że polecenie nie zostało znalezione, zainstaluj curl: w Windows zaktualizuj system do aktualnej wersji, w Linux zainstaluj przez menedżer pakietów swojej dystrybucji.

✅ Sprawdzenie: polecenie 

curl --version
wyświetliło numer wersji i listę protokołów, w tym http i https. To znaczy, że wszystko jest gotowe do pracy.

Co przygotować z danych Proxeon

Zaloguj się do panelu klienta Proxeon na proxeon.net i otwórz kartę swojego proxy. Zapisz lub skopiuj do osobnego pliku następujące pola: identyfikator proxy, host (adres), port, typ (HTTP, HTTPS lub SOCKS5), login i hasło. Te dane będą potrzebne do sformułowania polecenia odtwarzającego.

⚠️ Uwaga: login i hasło do proxy to dane tajne. Będziemy z nimi pracować lokalnie, ale w zgłoszeniu do pomocy technicznej NIE wolno ich wstawiać. Poniżej znajduje się osobna sekcja o tym, jak bezpiecznie oczyścić logi przed wysłaniem.

Podstawowe pojęcia: granica klient — proxy — serwer

Aby zrozumieć, które dane są ważne, trzeba sobie wyobrazić drogę żądania. Przechodzi ono przez trzy odcinki i problem może pojawić się na każdym z nich.

Trzy ogniwa jednego łańcucha

Gdy zwracasz się do strony przez proxy, żądanie idzie tak: twój klient wysyła żądanie do serwera proxy, ten przekierowuje je do serwera docelowego, otrzymuje odpowiedź i zwraca ją tobie. Trzy ogniwa, dwie granice. Zrozumienie, na której granicy utknęło, to połowa diagnostyki.

  • Granica klient — proxy. Jeśli żądanie nie dotarło nawet do proxy, problem jest po twojej stronie: błędny adres proxy, zamknięty port, filtr korporacyjny, błąd w ustawieniach klienta.
  • Granica proxy — serwer. Jeśli proxy przyjął żądanie, ale nie mógł dotrzeć do docelowej strony, problem jest między proxy a celem: strona niedostępna, odrzuca połączenie lub odpowiada błędem.

Zadaniem diagnostyki jest ustalenie, na której granicy wszystko się zepsuło. Inżynier pomocy technicznej Proxeon po twoim wyniku od razu zobaczy, gdzie zatrzymało się żądanie, i to drastycznie zawęzi krąg przyczyn.

Dlaczego dokładny czas jest tak ważny

Infrastruktura proxy prowadzi logi. Aby znaleźć w nich twoje konkretne żądanie, inżynier potrzebuje dokładnego czasu zdarzenia ze wskazaniem strefy czasowej. "Dziś rano" nie da się wyszukać w logach. "14:32 czasu polskiego, UTC+1" znajduje się w sekundę. Różnica czasu między twoim sformułowaniem a zapisem w logu to częsta przyczyna tego, że zdarzenia w ogóle nie udaje się znaleźć.

Wskazówka: zawsze podawaj strefę czasową wprost. Format "UTC+1" lub "CET" jest zrozumiały bez domysłów. Jeśli jesteś w innej strefie, podaj swoją — serwer sam przeliczy.

Krok 1: Zebrać minimalny zestaw danych

Cel etapu: zapisać pięć faktów, bez których każde zgłoszenie będzie niepełne. To fundament, wszystko inne buduje się na nim.

Pięć obowiązkowych faktów

  1. Identyfikator proxy. Dokładna nazwa lub numer z panelu klienta Proxeon, na przykład PX-48213. Nie "to proxy, które kupiłem wczoraj", a konkretny identyfikator. Jeśli masz pakiet kilku proxy, wskaż, o które dokładnie chodzi.
  2. Dokładny czas ze strefą czasową. Kiedy dokładnie pojawił się problem. Format: data, godzina, strefa. Na przykład: 12 marca 2026, 14:32, UTC+1. Jeśli problem się powtarza, podaj kilka znaczników czasu.
  3. Adres docelowy. Pełny URL lub host, do którego się zwracałeś. Na przykład: https://api.example.com/v2/data. Nie "jakaś strona", a dokładny adres.
  4. Co dokładnie robiłeś. Jedno-dwa zdania o działaniu. "Wysyłałem żądanie GET ze swojego skryptu" lub "otwierałem stronę w przeglądarce ze skonfigurowanym proxy". Kontekst pomaga zrozumieć naturę żądania.
  5. Czego oczekiwałeś, a co otrzymałeś. Oczekiwałeś kodu 200 i danych, otrzymałeś błąd połączenia. Oczekiwałeś załadowania strony, otrzymałeś nieskończone ładowanie. Różnica między oczekiwaniem a rzeczywistością to istota problemu.

⚠️ Uwaga: nie zastępuj konkretów emocjami. "Wszystko się wlecze i w ogóle tragedia" nie niesie informacji technicznej. "Odpowiedź przychodzi w 40 sekund zamiast zwykłych 2" — niesie.

Jak poprawnie zapisać czas

Jeśli problem występuje teraz, spójrz na zegar i natychmiast zapisz czas. Jeśli był w przeszłości, odtwórz czas z logów swojej aplikacji lub z historii przeglądarki. Im dokładniejszy znacznik, tym szybciej znajdzie się zapis po stronie serwera.

✅ Sprawdzenie: masz pięć zapisanych faktów. Przeczytaj je na głos. Jeśli osoba niewidząca twojego ekranu rozumie, co się stało, gdzie i kiedy, minimalny zestaw jest zebrany.

Krok 2: Odtworzyć problem jednym poleceniem curl

Cel etapu: sprowadzić problem do pojedynczego polecenia, które inżynier będzie mógł w myśli lub dosłownie powtórzyć, i uzyskać szczegółowy wynik techniczny.

Przeglądarka i złożony skrypt wykonują dziesiątki ukrytych działań. Trudno w nich wyizolować problem. Narzędzie curl wykonuje dokładnie jedno żądanie i pokazuje każdy jego etap. To idealne narzędzie do odtwarzania.

Podstawowe polecenie przez proxy Proxeon

Zbuduj polecenie ze swoich danych. Ogólna postać jest taka:

curl -v -x http://LOGIN:HASŁO@HOST:PORT https://ADRES-DOCELOWY

Omówmy flagi. -v włącza tryb szczegółowy (verbose): curl pokaże cały przebieg połączenia wiersz po wierszu. -x ustawia proxy, przez które idzie żądanie. Po nim — adres proxy z autoryzacją. Na końcu — adres docelowy.

Przykład z podstawionymi wartościami (dane fikcyjne):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Dodajemy pomiar czasu i zapis do pliku

Aby wynik był jak najbardziej informacyjny, rozszerzymy polecenie. Flaga -w doda na końcu podsumowanie czasów.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Kod końcowy: %{http_code}, całkowity czas: %{time_total}s" https://api.example.com/v2/data

Teraz na samym końcu wyniku zobaczysz końcowy kod HTTP i całkowity czas żądania. To kluczowe liczby dla diagnostyki szybkości.

Wskazówka: jeśli problem dotyczy wolnego działania, a nie błędu, dodaj szczegółowe czasy przez 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
To pokaże, na którym etapie ginie czas.

Dla proxy SOCKS5

Jeśli twoje proxy jest typu SOCKS5, zmień schemat w adresie:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Uwaga: polecenie zawiera twój prawdziwy login i hasło. Wykonuj je w swoim terminalu, ale NIE kopiuj go z sekretami do maila. W zgłoszeniu login i hasło zastępuje się zaślepkami — o tym w kroku 5.

Kolejność wykonania

  1. Otwórz terminal.
  2. Wklej zbudowane polecenie, podstawiając swoje prawdziwe dane.
  3. Naciśnij Enter i poczekaj na zakończenie.
  4. Zaznacz cały wynik od pierwszego do ostatniego wiersza i skopiuj go do pliku tekstowego.

✅ Sprawdzenie: otrzymałeś wielowierszowy wynik, w którym widać wiersze zaczynające się od znaków "*", ">" i "<". Jeśli wynik jest, odtworzenie się udało, nawet jeśli żądanie zakończyło się błędem — błąd też jest cenną informacją.

Krok 3: Przeczytać wynik wiersz po wierszu i znaleźć granicę problemu

Cel etapu: nauczyć się rozumieć, co pokazuje wynik curl, i określać, na którym ogniwie zatrzymało się żądanie. Rozszyfrowania konkretnych kodów błędów tu nie powtarzamy — do tego jest osobny artykuł w bazie wiedzy Proxeon, do którego możesz dać link w zgłoszeniu, jeśli zajdzie potrzeba.

Trzy typy wierszy w wyniku

Szczegółowy wynik curl używa prefiksów, po których łatwo się orientować.

  • Wiersze z gwiazdką (*) — komunikaty samego curl o przebiegu połączenia: rozwiązywanie nazwy, nawiązywanie połączenia z proxy, uzgadnianie szyfrowania. To wewnętrzna kuchnia.
  • Wiersze ze strzałką w prawo (>) — to, co twój klient WYSYŁA. Nagłówki żądania, metoda, ścieżka.
  • Wiersze ze strzałką w lewo (<) — to, co ci ODPOWIADA. Kod odpowiedzi, nagłówki serwera.

Gdzie przebiega granica klient — proxy

Na początku wyniku curl informuje, że nawiązuje połączenie z proxy. Zobaczysz wiersz w rodzaju "Connected to proxy.proxeon.net port 8080". Jeśli tego wiersza nie ma, a zamiast niego jest błąd połączenia, znaczy to, że żądanie nie dotarło do proxy. Problem na granicy klient — proxy: być może zamknięty port, błędny adres lub lokalny filtr.

Jeśli wiersz o połączeniu z proxy jest, ale dalej pojawia się błąd autoryzacji, znaczy to, że proxy jest dostępny, ale nie przyjął twojego loginu i hasła. To też granica klient — proxy, ale już na poziomie uwierzytelnienia.

Gdzie przebiega granica proxy — serwer

Po udanym połączeniu z proxy curl pokazuje nawiązanie połączenia z serwerem docelowym przez proxy. Jeśli tutaj pojawia się błąd, znaczy to, że proxy przyjął żądanie, ale nie mógł dotrzeć do celu. Problem na granicy proxy — serwer: docelowa strona niedostępna, odrzuca połączenie lub odpowiada powoli.

Jeśli natomiast widzisz wiersz odpowiedzi ze strzałką w lewo, na przykład "< HTTP/1.1 200" lub inny kod, znaczy to, że cały łańcuch zadziałał i otrzymałeś odpowiedź. Dalej to już kwestia treści odpowiedzi, a nie działania proxy.

Kluczowe wiersze, które są ważne dla inżyniera

  1. Wiersz połączenia z proxy — potwierdza, że pierwsze ogniwo działa.
  2. Wiersz o autoryzacji na proxy — pokazuje, czy dane uwierzytelniające zostały przyjęte.
  3. Wiersz o uzgadnianiu szyfrowania (TLS) — ważny dla celów HTTPS.
  4. Pierwszy wiersz odpowiedzi ze strzałką w lewo — końcowy werdykt łańcucha.
  5. Końcowe podsumowanie z kodem i czasem z flagi -w.

Wskazówka: nie próbuj samodzielnie stawiać diagnozy na podstawie kodu błędu, jeśli nie jesteś pewien. Twoim zadaniem jest załączyć pełny wynik. Inżynier Proxeon przeczyta go dokładniej. Pełne rozszyfrowanie kodów jest w osobnym artykule bazy wiedzy — odnieś się do niego, jeśli chcesz zgłębić temat.

✅ Sprawdzenie: potrafisz wskazać palcem wiersz, po którym żądanie się zepsuło, i powiedzieć, na której to granicy — klient-proxy czy proxy-serwer. Jeśli potrafisz, zaliczyłeś ten etap.

Krok 4: Wykonać testy przed zgłoszeniem

Cel etapu: metodą wykluczania zawęzić krąg przyczyn jeszcze zanim napiszesz do pomocy technicznej. Każdy test odcina całą klasę problemów.

Zasada jest prosta: zmieniamy jeden parametr naraz i patrzymy, czy zachowanie się zmieniło. To klasyczne inżynierskie podejście do izolowania usterki.

Cztery kluczowe testy

  1. Inna strona docelowa. Powtórz to samo żądanie przez to samo proxy, ale do innego adresu. Weź jakąś stabilną publiczną stronę. Jeśli przez to proxy działa ona, a twoja docelowa nie, problem wiąże się z docelową stroną lub jej relacją z proxy, a nie z samym proxy.
  2. Inny protokół. Jeśli używałeś HTTP, spróbuj celu HTTPS, i odwrotnie. Czasem problem pojawia się tylko na jednym protokole i to jest ważny sygnał.
  3. Inne proxy. Jeśli masz drugie proxy od Proxeon, powtórz żądanie przez nie. Jeśli drugie działa, a pierwsze nie — problem w konkretnym proxy. Jeśli oba zachowują się identycznie — problem jest bardziej systemowy.
  4. Połączenie bezpośrednie. Wykonaj żądanie do celu BEZ proxy, bezpośrednio. Usuń flagę -x. Jeśli bezpośrednio strona też jest niedostępna, problem wcale nie jest w proxy, a w samej stronie docelowej lub twojej sieci.

Polecenie do bezpośredniego sprawdzenia

curl -v https://api.example.com/v2/data

To samo polecenie, ale bez części z proxy. Porównaj wynik z żądaniem przez proxy.

Tabela: co wyklucza każdy test

Poniżej — jak interpretować wyniki testów.

  • Inna strona działa, twoja nie. Wyklucza awarię proxy jako całości. Wskazuje na specyfikę interakcji konkretnego celu z proxy.
  • Inny protokół działa, twój nie. Wyklucza całkowitą niedostępność. Lokalizuje problem na poziomie konkretnego protokołu lub portu.
  • Inne proxy działa, twoje nie. Wyklucza problem po twojej stronie i w sieci. Wskazuje na konkretne proxy.
  • Połączenie bezpośrednie też nie działa. Wyklucza winę proxy. Problem w docelowej stronie lub twojej sieci.
  • Bezpośrednie działa, przez proxy nie. Potwierdza, że chodzi właśnie o związek z proxy, i to jest dokładnie to, w czym pomoże pomoc techniczna.

Wskazówka: wyniki tych czterech testów to najcenniejsza część zgłoszenia. Oszczędzają inżynierowi połowę pracy, bo już odciąłeś to, co zbędne. Koniecznie wymień je w mailu.

⚠️ Uwaga: używaj tych proxy wyłącznie do zgodnych z prawem celów: testowanie własnych usług, zbieranie publicznych danych w ramach regulaminów, praca z API. Testy nie są przeznaczone do działań naruszających regulaminy stron lub przepisy prawa.

✅ Sprawdzenie: masz wyniki wszystkich czterech testów i potrafisz jednym zdaniem powiedzieć, co one razem wykluczają. Na przykład: "połączenie bezpośrednie i inne proxy działają, więc chodzi o konkretne proxy PX-48213 przy żądaniu do tego celu".

Krok 5: Zebrać dane o swojej stronie

Cel etapu: opisać środowisko, w którym pojawia się problem. Połowa niezrozumiałych przypadków tłumaczy się osobliwościami klienta lub lokalnej sieci.

Co podać o środowisku

  1. System operacyjny i jego wersja. Windows 11, macOS 15, Ubuntu 24.04. Dokładna wersja pomaga odtworzyć warunki.
  2. Klient i jego wersja. Przez co pracujesz z proxy: przeglądarka i jej wersja, nazwa i wersja scrapera lub biblioteki, wersja curl. Różne klienty różnie obsługują proxy.
  3. Sposób konfiguracji proxy. Skonfigurowane w systemie, w przeglądarce, przekazywane w kodzie, ustawione w zmiennych środowiskowych. To wpływa na to, jak dokładnie stosowane jest proxy.
  4. Obecność filtra korporacyjnego lub lokalnego. Czy pracujesz z sieci korporacyjnej, czy jest antywirus z zaporą sieciową, czy stoi lokalny firewall. Takie filtry mogą przechwytywać lub blokować połączenia jeszcze przed proxy.
  5. Typ połączenia z internetem. Domowy dostawca, internet mobilny, sieć firmowa. Czasem dostawca wpływa na dostępność.

Jak poznać wersję klienta

Dla curl użyj znanego już polecenia 

curl --version
Dla przeglądarki otwórz sekcję "O programie" w menu. Dla biblioteki w kodzie sprawdź jej wersję w pliku zależności twojego projektu.

Test filtra korporacyjnego

Jeśli jesteś w sieci korporacyjnej i podejrzewasz filtr, łatwo to sprawdzić. Wykonaj żądanie bezpośrednio do proxy bez celu i zobacz, czy połączenie się nawiązuje. Jeśli nawet bezpośrednie połączenie z portem proxy nie przechodzi, a z innej sieci przechodzi, prawdopodobny jest korporacyjny filtr na połączenia wychodzące.

Wskazówka: sieci korporacyjne często przepuszczają tylko porty 80 i 443. Jeśli twoje proxy jest na niestandardowym porcie, zapytaj swojego administratora sieci, czy ten port jest otwarty na zewnątrz. To częsta i łatwa do rozwiązania przyczyna.

✅ Sprawdzenie: masz wypełnioną listę pięciu punktów o środowisku. Inżynier, czytając ją, wie, w jakich warunkach odtwarzać problem.

Krok 6: Zautomatyzować zbieranie diagnostyki jednym skryptem

Cel etapu: zebrać wszystkie informacje techniczne do jednego pliku tekstowego, nie przepisując ich ręcznie. Skrypt robi to samo, co robiłeś ręcznie, ale za jednym uruchomieniem.

Skrypt dla macOS i Linux

Utwórz plik diag.sh o następującej zawartości. Zastąp wartości zmiennych swoimi.

#!/bin/bash
PROXY="http://LOGIN:HASŁO@HOST:PORT"
TARGET="https://ADRES-DOCELOWY"
ALT="https://STABILNA-STRONA"
OUT="diag_result.txt"
echo "=== Data i czas ===" > $OUT
date >> $OUT
echo "=== Wersja curl ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Żądanie przez proxy do celu ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Żądanie przez proxy do alternatywnej strony ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Żądanie bezpośrednie do celu bez proxy ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Gotowe. Plik: $OUT"

Jak uruchomić skrypt

  1. Zapisz plik pod nazwą diag.sh.
  2. Wpisz swoje wartości do zmiennych PROXY, TARGET i ALT.
  3. W terminalu przejdź do folderu z plikiem.
  4. Nadaj plikowi prawo wykonania poleceniem 
    chmod +x diag.sh
  5. Uruchom go poleceniem 
    ./diag.sh
  6. Po zakończeniu otwórz plik diag_result.txt.

Skrypt dla Windows (PowerShell)

Utwórz plik diag.ps1 o analogicznej logice.

$Proxy = "http://LOGIN:HASŁO@HOST:PORT"
$Target = "https://ADRES-DOCELOWY"
$Alt = "https://STABILNA-STRONA"
$Out = "diag_result.txt"
"=== Data i czas ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== Wersja curl ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Przez proxy do celu ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Przez proxy do alternatywy ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Żądanie bezpośrednie ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

Uruchom go w PowerShell poleceniem 

.\diag.ps1
i otwórz powstały plik.

⚠️ Uwaga: plik diag_result.txt zawiera twój login i hasło w postaci jawnej, ponieważ były w zmiennej PROXY. Przed wysłaniem do pomocy technicznej KONIECZNIE oczyść go według instrukcji z kroku 7.

Wskazówka: przechowuj skrypt z pustymi zmiennymi, a wartości wstawiaj tylko przed uruchomieniem. Wtedy nie ryzykujesz przypadkowego udostępnienia pliku z sekretami w środku.

✅ Sprawdzenie: plik diag_result.txt został utworzony i zawiera kilka bloków: wersję curl, żądania przez proxy do dwóch stron i żądanie bezpośrednie. To gotowy pakiet diagnostyki technicznej.

Krok 7: Bezpiecznie oczyścić logi przed wysłaniem

Cel etapu: usunąć z zebranych danych wszystko tajne, zachowując przy tym ich wartość diagnostyczną. Wysyłanie logów z hasłami jest niedopuszczalne w żadnym wypadku.

Co wyciąć obowiązkowo

  • Hasło do proxy. W wyniku mogło trafić do wiersza połączenia. Znajdź i zamień.
  • Login, jeśli jest powiązany z danymi płatniczymi. Zwykle login można zostawić, ale jeśli jest częścią wrażliwego zestawu, jego też zamień.
  • Tokeny autoryzacyjne. Jeśli w nagłówkach żądania jest Authorization, tokeny Bearer, klucze API, cookie sesji — wszystko to wyciąć.
  • Dane osobowe. Wszelkie imiona, adresy, telefony, jeśli przypadkowo trafiły do treści żądania lub odpowiedzi.

Czym zastępować

Nie usuwaj wiersza w całości — w ten sposób traci się strukturę. Zastępuj sekret zrozumiałą zaślepką, zachowując w miarę możliwości długość i format. Przykłady zamian:

  • Hasło zamień na [HASŁO_UKRYTE].
  • Login na [LOGIN_UKRYTY].
  • Token na [TOKEN_UKRYTY].

W ten sposób inżynier widzi, że w tym miejscu był token, ale nie widzi jego wartości. Struktura zachowana, bezpieczeństwo też.

Kolejność czyszczenia

  1. Otwórz plik diag_result.txt w edytorze tekstu.
  2. Użyj wyszukiwania (Ctrl+F) po swoim haśle i zamień wszystkie wystąpienia na zaślepkę.
  3. To samo zrób z loginem, jeśli zdecydowałeś się go ukryć.
  4. Przejrzyj wiersze z nagłówkami Authorization, Cookie, api-key. Zamień wartości na zaślepki.
  5. Zapisz plik pod nową nazwą, na przykład diag_clean.txt, żeby nie pomylić go z oryginałem.

⚠️ Uwaga: sprawdź plik dwa razy przed wysłaniem. Hasło mogło wystąpić nie tylko w poleceniu, ale też w wierszach wyniku curl. Przeoczony sekret to wyciek, który może doprowadzić do kompromitacji twojego proxy.

Wskazówka: trzymaj oryginał diag_result.txt lokalnie, a wysyłaj tylko oczyszczoną kopię. Jeśli inżynier poprosi o uzupełnienie, masz pod ręką pełne dane.

✅ Sprawdzenie: otwórz oczyszczony plik i wyszukaj swoje hasło. Zero wyników — znaczy, że czyszczenie się udało. Struktura wyniku przy tym zachowana.

Krok 8: Wypełnić gotowy szablon zgłoszenia

Cel etapu: zebrać wszystko w jedno w mailu, który inżynier przeczyta i od razu zrozumie zadanie. Poniżej — szablon do skopiowania.

Szablon zgłoszenia do pomocy technicznej Proxeon

Temat: Problem z proxy [IDENTYFIKATOR] przy żądaniu do [CEL]

1. Identyfikator proxy: [na przykład PX-48213]
2. Typ proxy: [HTTP / HTTPS / SOCKS5]
3. Czas problemu: [12.03.2026, 14:32, UTC+1]
4. Adres docelowy: [https://api.example.com/v2/data]
5. Co robiłem: [wysyłałem żądanie GET z curl]
6. Oczekiwałem: [kodu 200 i danych]
7. Otrzymałem: [błąd połączenia / wolną odpowiedź / kod błędu]

Wyniki testów:
- Inna strona przez to proxy: [działa / nie działa]
- Połączenie bezpośrednie bez proxy: [działa / nie działa]
- Inne proxy do tego samego celu: [działa / nie działa / brak drugiego proxy]

Środowisko:
- System: [Windows 11]
- Klient: [curl 8.6.0]
- Konfiguracja proxy: [flaga -x w curl]
- Filtr korporacyjny: [nie / tak, porty 80 i 443]

Wynik diagnostyki (login i hasło ukryte) załączam w pliku diag_clean.txt.

Wniosek krótki: według moich testów problem jest na granicy [klient-proxy / proxy-serwer], ponieważ [połączenie bezpośrednie działa, a przez proxy nie].

Jak poprawnie wypełnić

  1. Skopiuj szablon do treści maila lub zgłoszenia.
  2. Zastąp każde pole w nawiasach kwadratowych swoimi danymi.
  3. Załącz oczyszczony plik diag_clean.txt.
  4. Przeczytaj mail w całości: czy jest zrozumiały dla osoby z boku.
  5. Wyślij.

Wskazówka: wiersz "Wniosek krótki" na końcu jest najbardziej przydatny. Sam formułujesz w nim hipotezę na podstawie testów. Nawet jeśli hipoteza jest niedokładna, pokazuje inżynierowi tok twojego myślenia i oszczędza czas.

✅ Sprawdzenie: w mailu nie ma ani jednego pola w nawiasach kwadratowych — wszystkie są wypełnione. Załączony jest oczyszczony plik. Jest krótki wniosek z hipotezą. Zgłoszenie jest gotowe do wysłania.

Sprawdzenie wyniku: lista kontrolna gotowości zgłoszenia

Przed wysłaniem przejdź po krótkiej liście kontrolnej. Gwarantuje, że niczego nie pominąłeś.

  • Podany jest dokładny identyfikator proxy, a nie opis.
  • Jest czas zdarzenia z wyraźną strefą czasową.
  • Podany jest pełny adres docelowy.
  • Opisane jest, co robiłeś, czego oczekiwałeś i co otrzymałeś.
  • Załączony jest pełny wynik curl w trybie szczegółowym.
  • Wykonane i opisane są co najmniej dwa testy wykluczające.
  • Podane są system, klient i jego wersja.
  • Z logów usunięto hasło i wszystkie tokeny.
  • Plik diagnostyczny jest załączony i jasno nazwany.
  • Jest krótki wniosek z twoją hipotezą.

Jeśli wszystkie punkty są odhaczone, twoje zgłoszenie należy do tych, które rozwiązuje się już w pierwszej odpowiedzi. Inżynier nie musi niczego dopytywać — ma pełny obraz.

✅ Sprawdzenie: wszystkie dziesięć punktów listy kontrolnej są spełnione. To właśnie wskaźnik sukcesu: zgłoszenie jest samowystarczalne.

Typowe błędy i ich rozwiązania

Omówmy częste problemy przy zbieraniu diagnostyki i sposoby ich usunięcia.

Problem 1: curl zwraca błąd od razu, bez połączenia z proxy

Przyczyna: błędny format adresu proxy lub literówka w schemacie (http zamiast socks5 lub odwrotnie).

Rozwiązanie: sprawdź typ proxy w panelu klienta Proxeon i podstaw właściwy schemat. Upewnij się, że port jest podany poprawnie i oddzielony dwukropkiem.

Problem 2: błąd autoryzacji na proxy

Przyczyna: błędny login lub hasło albo znaki specjalne w haśle nie zostały zaescapowane.

Rozwiązanie: sprawdź dane uwierzytelniające. Jeśli w haśle są znaki @, :, / — mogą psuć wiersz. W takim przypadku przekaż autoryzację osobną flagą 

--proxy-user LOGIN:HASŁO
zamiast wstawiania do URL.

Problem 3: skrypt nie uruchamia się w Windows

Przyczyna: polityka wykonywania PowerShell blokuje lokalne skrypty.

Rozwiązanie: uruchom PowerShell jako administrator i zezwól na wykonywanie dla bieżącej sesji poleceniem ustawiającym politykę RemoteSigned na poziomie procesu. Po zebraniu danych przywróć pierwotną politykę.

Problem 4: w wyniku nie ma szczegółów, tylko wiersz końcowy

Przyczyna: zapomniana flaga -v, która włącza tryb szczegółowy.

Rozwiązanie: dodaj -v zaraz po curl. To ona pokazuje wiersz po wierszu przebieg połączenia, bez którego diagnostyka jest bezużyteczna.

Problem 5: hasło przypadkowo zostało w wysłanym pliku

Przyczyna: czyszczenie wykonane nieuważnie, hasło wystąpiło w wierszu wyniku, a nie tylko w poleceniu.

Rozwiązanie: natychmiast zmień hasło do proxy w panelu klienta Proxeon. Na przyszłość zawsze wyszukuj hasło w oczyszczonym pliku przed wysłaniem.

Problem 6: problem nie odtwarza się w curl, ale występuje w przeglądarce

Przyczyna: przeglądarka dodaje nagłówki, cookie lub używa innego sposobu konfiguracji proxy.

Rozwiązanie: w zgłoszeniu uczciwie napisz, że w curl problem się nie powtarza, a w przeglądarce występuje. Załącz nazwę i wersję przeglądarki oraz sposób konfiguracji proxy w niej. To samo w sobie jest informacją diagnostyczną.

Problem 7: czas w logach nie zgadza się z twoim

Przyczyna: podałeś czas lokalny bez strefy czasowej, a serwer pracuje w UTC.

Rozwiązanie: zawsze podawaj strefę wprost. Jeśli masz wątpliwości, załącz oba znaczniki: swój czas lokalny i jego odpowiednik w UTC.

Dodatkowe możliwości: zaawansowana diagnostyka

Jeśli podstawowy zestaw to za mało, oto kilka narzędzi do głębszej analizy. Przydadzą się zaawansowanym użytkownikom.

Szczegółowe czasy dla problemów z szybkością

Kiedy proxy działa, ale wolno, ważne jest zrozumienie, na którym etapie ginie czas. Rozszerzona flaga -w pokaże rozbicie.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://LOGIN:HASŁO@HOST:PORT https://CEL

Te liczby pokazują, ile poszło na rozwiązanie nazwy, nawiązanie połączenia, szyfrowanie i otrzymanie pierwszego bajtu. Jeśli duży jest ttfb, opóźnienie jest po stronie celu. Jeśli duży jest connect, problem w sieci do proxy.

Powtarzalność problemu

Jeśli problem jest niestabilny, zbierz serię żądań i pokaż, że część przechodzi, a część nie. Prosta pętla kilku żądań z zapisem kodów odpowiedzi da statystykę. Stabilność lub jej brak to ważny fakt dla pomocy technicznej.

Sprawdzenie kilku celów naraz

Sporządź listę trzech-czterech adresów i przepuść je przez proxy jedną serią. Od razu zobaczysz, czy problem jest specyficzny dla jednego celu, czy ogólny.

Wskazówka: zaawansowane dane załączaj tylko wtedy, gdy podstawowa diagnostyka nie wystarczyła. Nadmiar informacji bez struktury jest tak samo szkodliwy jak ich brak. Zaczynaj od minimum, zagłębiaj się na życzenie inżyniera.

FAQ: częste pytania o zbieranie diagnostyki

Czy trzeba używać właśnie curl?

Nie, ale curl to najbardziej uniwersalne i zrozumiałe dla inżyniera narzędzie. Jego wynik jest taki sam we wszystkich systemach. Jeśli pracujesz przez bibliotekę w kodzie, załącz też jej wynik, ale test curl i tak jest cenny jako wzorzec.

Co zrobić, jeśli problem już minął i się nie powtarza?

Zapisz wszystko, co pamiętasz: przybliżony czas, cel, charakter błędu. Załącz logi swojej aplikacji z tego okresu. Nawet niepełne dane z dokładnym czasem pomogą znaleźć zapis na serwerze.

Czy trzeba załączać logi, jeśli błąd jest oczywisty z opisu?

Tak. To, co wydaje się oczywiste tobie, wymaga potwierdzenia faktami. Logi zdejmują domysły i pozwalają dać dokładną odpowiedź, a nie przypuszczenie.

Czy można wysłać login i hasło, żeby pomoc techniczna sama wszystko sprawdziła?

Nie. Sekretów nie przekazuje się w korespondencji. Pomoc techniczna Proxeon ma dostęp do twojego konta po identyfikatorze bez hasła. Identyfikator wystarczy do sprawdzenia po stronie serwera.

Jak szybko przychodzi odpowiedź, jeśli wszystko jest zebrane poprawnie?

Pełne zgłoszenie skraca czas do rozwiązania wielokrotnie, bo usuwa cykl dopytków. Dokładne terminy zależą od obciążenia pomocy technicznej, ale z pewnością unikasz kilku rund wymiany maili.

Co jeśli curl pokazuje sukces, a aplikacja mimo to nie działa?

To cenny fakt: problem nie tkwi w samym proxy, a w tym, jak aplikacja go używa. Wskaż to w zgłoszeniu, załącz ustawienia proxy w aplikacji i jej wersję.

Czy trzeba podawać adres docelowy, jeśli jest publiczny?

Tak, obowiązkowo. Zachowanie proxy może zależeć od konkretnego celu. Bez adresu inżynier nie będzie mógł odtworzyć właśnie twojego przypadku.

Jak zrozumieć, czy to mój port, czy potrzebny jest inny?

Port jest podany w karcie proxy w panelu klienta. Różne typy proxy używają różnych portów. Sprawdź w panelu klienta i nie podstawiaj portu na oślep.

Czy można zautomatyzować czyszczenie logów z sekretów?

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: