Gdy połączenie proxy nie działa, sprawdzaj trzy warstwy: najpierw zmianę IP i lokalizację wyjścia, następnie DNS, timeout i certyfikat, a na końcu uwierzytelnianie, port i protokół.
Proxy jest skonfigurowane, nazwa użytkownika i hasło są poprawne, a mimo to test zgłasza błąd połączenia. Wiele osób od razu kontaktuje się z dostawcą proxy, zmienia węzeł, port albo ponagla pomoc techniczną. Zwykle nie jest to wydajne, ponieważ przyczyna może znajdować się w dowolnym miejscu całego łańcucha połączenia, a proxy jest tylko jednym z jego elementów.
Zamiast losowo zmieniać ustawienia, warto stosować stałą kolejność od zewnątrz do wewnątrz: najpierw potwierdzić, że wyjście rzeczywiście działa, potem sprawdzić drożność ścieżki sieciowej, a dopiero na końcu uwierzytelnianie i protokół w warstwie aplikacji. Te trzy warstwy wystarczają do zlokalizowania większości problemów.
Czy wyjście rzeczywiście działa?
Ten krok łatwo pominąć, ponieważ konfiguracja wygląda na udaną. Poprawne zapisanie konfiguracji i rzeczywisty ruch przez proxy to jednak dwie różne rzeczy.
Sprawdź dwie kwestie. Po pierwsze: czy IP się zmienił? Zapisz publiczny adres IP bez proxy, włącz proxy i sprawdź ponownie. Jeśli oba adresy są takie same, ruch w ogóle nie wychodzi przez proxy, więc dalsza diagnostyka nie ma sensu. Po drugie: czy lokalizacja jest prawidłowa? Szczegóły proxy zwykle zawierają kraj, region, stan lub prowincję, miasto, współrzędne do sześciu miejsc po przecinku i kod pocztowy. Porównaj je z kupionym regionem. Wyraźnie niepasująca strefa czasowa systemu do regionu wyjścia również jest sygnałem ostrzegawczym.
Jeśli wyjście nie działa, przyczyną często są pozostawione ustawienia lokalne, a nie dostawca. Gdy wcześniej używane narzędzie sieciowe nie posprzątało ustawień przy zamknięciu, w systemie mogą pozostać zmienne środowiskowe takie jak HTTP_PROXY lub HTTPS_PROXY, a w macOS wciąż mogą być włączone przełączniki Web Proxy lub SOCKS Proxy. Klient może wtedy uważać, że korzysta z proxy systemowego, podczas gdy żądania faktycznie je omijają. Usunięcie tych pozostałości i ponowny test są zwykle bardziej przydatne niż konfiguracja proxy od początku.
Trzy częste błędy na ścieżce sieciowej
Po potwierdzeniu wyjścia sprawdź, czy żądanie rzeczywiście dociera do celu.
Rozwiązywanie DNS to pierwszy możliwy punkt awarii. Objawem może być błąd rozwiązywania albo wyraźnie nieprawidłowy wynik, gdy domena mająca wskazywać usługę docelową prowadzi do dziwnego adresu. Spróbuj ponownie z publicznym serwerem DNS albo wyczyść lokalną pamięć DNS i sprawdź, czy problem ustąpił.
Drugi typ to przekroczenie czasu połączenia. Jeśli zapora lub oprogramowanie zabezpieczające blokuje port, żądanie może długo się ładować, a potem zakończyć timeoutem. Sprawdź reguły zezwalające na port i ograniczenia samego środowiska, na przykład sieci firmowej lub publicznego Wi-Fi. Szybki test to połączenie bezpośrednie bez proxy. Jeśli również wtedy nie otwiera się żadna strona, problem leży w podstawowej sieci, a nie w proxy. Uruchom ponownie router albo przełącz się na hotspot w telefonie, aby to potwierdzić.
Błędy certyfikatu trzeba potraktować osobno. Przy komunikacie o niezaufanym certyfikacie lub nieudanym handshake wiele osób od razu podejrzewa odszyfrowywanie ruchu albo podmianę certyfikatu. To możliwe, ale istnieje też mniej oczywista przyczyna: nieprawidłowy czas lokalny. Wiele mechanizmów uwierzytelniania i sesji zależy od znaczników czasu. Jeśli lokalny czas różni się od czasu serwera o ponad 5 minut, weryfikacja podpisu może się nie udać, a połączenie zostanie odrzucone; w HTTPS wygląda to jak błąd walidacji certyfikatu. Przy błędzie certyfikatu sprawdź więc także synchronizację czasu systemu. Jeśli jest nieprawidłowa, włącz automatyczną synchronizację, natychmiast skoryguj czas, uruchom klienta ponownie i wykonaj test jeszcze raz.
Nie pomyl uwierzytelniania z protokołem
Jeśli można połączyć się z serwerem proxy, ale ruch nadal nie działa, problem zwykle znajduje się w warstwie aplikacji.
Najczęściej chodzi o dane uwierzytelniające. Nazwa użytkownika, hasło i metoda uwierzytelniania muszą odpowiadać danym od dostawcy; częsty jest też przypadek zmiany hasła bez aktualizacji konfiguracji. W trybie ręcznym sprawdź również, czy wpisany port jest zgodny z portem, na którym nasłuchuje samo narzędzie proxy. Numery mogą wyglądać podobnie, ale zły port całkowicie uniemożliwia połączenie.
Druga kategoria to niezgodność protokołu. HTTP, HTTPS i SOCKS5 nie są zamienne: jeśli dostawca udostępnia SOCKS5, a w konfiguracji ustawiono HTTP, test się nie powiedzie. Sprawdź również, czy proxy zezwala na dostęp do docelowej strony i portu, ponieważ niektóre proxy ograniczają cele lub protokoły.
Najszybszy sposób na odróżnienie problemu węzła od problemu konfiguracji to przetestowanie innego węzła. Jeśli nowy działa, winny jest poprzedni. Jeśli nadal nie działa, wróć do konfiguracji i ścieżki sieciowej. Nie zmieniaj wielu parametrów naraz; zmieniaj jedną zmienną i zapisuj wynik, bo inaczej własne działania mogą ukryć prawdziwą przyczynę.
Połączenie nie oznacza jeszcze, że środowisko nadaje się do użycia
Jest jeszcze jedna częsta pułapka. Proxy może pokazywać prawidłowe połączenie, a konto nadal często uruchamia mechanizmy kontroli ryzyka. Problem może nie dotyczyć samej możliwości połączenia, lecz tego, czy wyjście wygląda jak środowisko zwykłego użytkownika.
Sprawdź te same podstawowe kwestie: czy lokalizacja wyjścia odpowiada regionowi rejestracji konta; czy typ IP jest odpowiedni, ponieważ platformy mogą różnie ufać adresom z centrów danych i adresom rezydencyjnym; oraz czy ten adres IP był wcześniej oznaczony przez serwis docelowy. Jeśli z tego samego IP wykonywano wcześniej dużo nietypowych działań, późniejsi użytkownicy mogą odczuć skutki. Po udanym teście połączenia poświęć więc kilka minut także na ocenę „czystości” wyjścia.
Jeśli na jednym urządzeniu działa kilka środowisk, najlepiej przypisać wyjścia jeden do jednego: każde środowisko powinno mieć własne wyjście. Problemy można wtedy diagnozować osobno, a oznaczenie jednego wyjścia wpłynie tylko na odpowiadające mu środowisko, nie na wszystkie. PurpleMark właśnie w ten sposób osobno konfiguruje i izoluje wyjścia dla poszczególnych środowisk w zarządzaniu wieloma środowiskami.
Te metody diagnostyczne służą wyłącznie wymianie wiedzy technicznej. Korzystaj z powiązanych narzędzi i usług zgodnie z obowiązującym prawem i regulacjami.
