Gdy połączenie z proxy nie działa, sprawdzaj kolejno usługę proxy, uwierzytelnianie i protokół, konfigurację klienta oraz witrynę docelową. Na każdym etapie użyj konkretnej wskazówki, aby najpierw ustalić warstwę problemu, a dopiero potem zmieniać ustawienia.
Po wpisaniu proxy przycisk testu zgłasza błąd. Najgorszym rozwiązaniem jest wtedy losowe zmienianie konfiguracji: portu, protokołu lub węzła, aż coś zadziała, bez wiedzy, która zmiana faktycznie pomogła.
Przyczyny zwykle mieszczą się w czterech warstwach: sama usługa proxy, uwierzytelnianie i protokół, konfiguracja klienta oraz witryna docelowa. Sprawdzaj je właśnie w tej kolejności, od proxy na zewnątrz.
Najpierw przetestuj samo proxy
Nie zaczynaj od narzędzia biznesowego. Wprowadź proxy bezpośrednio do zwykłej przeglądarki obsługującej ręczną konfigurację proxy albo do ustawień proxy systemu i sprawdź, czy zapewnia dostęp do Internetu. W ten sposób oddzielasz proxy od środowiska roboczego.
Jeśli również tam nie ma połączenia, problem leży po stronie samego proxy: mogło wygasnąć, zostać wyłączone, mieć awarię węzła wyjściowego albo podlegać ograniczeniom dostawcy. W takim przypadku nie ma sensu wykonywać dalszych kroków — sprawdź bezpośrednio u dostawcy stan i wykorzystanie proxy.
Jeśli w tym środowisku działa, proxy jest aktywne. Problem znajduje się więc w konfiguracji albo ścieżce połączenia i należy przejść dalej.
Prosta zasada brzmi: jeśli te same dane logowania działają w innym miejscu, same dane logowania prawdopodobnie są poprawne.
Dopasuj uwierzytelnianie i protokół
Jeśli dane logowania są poprawne, ale połączenie nadal się nie udaje, kolejnym podejrzanym jest protokół. Typowe niezgodności są trzy: dostawca udostępnia SOCKS5, a środowisko ustawiono na HTTP; utworzono tunel SSH, ale skonfigurowano go jako SOCKS5; albo jedno proxy obsługuje kilka protokołów na różnych portach i wpisano port innego protokołu.
Kieruj się treścią błędu. Jeśli komunikat mówi o błędzie uwierzytelniania lub nieprawidłowych danych logowania, sprawdź nazwę użytkownika i hasło. Zwróć uwagę na spacje lub znaki nowego wiersza dodane podczas kopiowania oraz na wymagane escapowanie znaków specjalnych w nazwie użytkownika. Jeśli pojawia się błąd protokołu albo handshake, sprawdź typ protokołu i port.
Pola takie jak nazwa użytkownika i hasło warto raz wpisać ręcznie dla porównania. Niewidoczne znaki mogą powodować błąd, którego nie da się zauważyć wzrokowo.
Sprawdź, czy konfiguracja klienta naprawdę działa
Ten krok odpowiada na mniej oczywiste pytanie: ustawienia są poprawne, ale czy zostały faktycznie zastosowane?
Częste są dwa przypadki. Po pierwsze, konfiguracja w ogóle nie została zastosowana: zmiany nie zostały zapisane, edytowano inne środowisko albo nadal działa poprzednia sesja. Po drugie, konfiguracja działa, ale inne ustawienie ją nadpisuje: w środowisku może być dodatkowy przełącznik sieciowy, rozszerzenie może przejąć obsługę proxy albo ustawienia proxy na poziomie systemu mogą mieć wyższy priorytet.
Sprawdź adres wyjściowy. Po połączeniu otwórz stronę pokazującą aktualny adres wyjściowy. Powinien być widoczny adres proxy, a nie adres lokalny. Jeśli nadal widać adres lokalny, żądanie nie przechodzi przez proxy, nawet jeśli test pokazuje powodzenie.
Porównanie jest proste: w tym samym środowisku raz włącz proxy, raz je wyłącz i sprawdź, czy adres wyjściowy się zmienia. Jeśli nie, problem jest po stronie klienta. Gdy równolegle działa kilka środowisk, sprawdź wyjście każdego z nich osobno. Narzędzia izolujące środowiska według konta, takie jak PurpleMark, właśnie na to zwracają uwagę przy przypisywaniu proxy.
Rozpoznaj odrzucenie po stronie witryny docelowej
Jeśli wszystkie warstwy działają, a proxy jest rzeczywiście aktywne, lecz strona biznesowa nadal się nie otwiera, obserwuj reakcję witryny docelowej zamiast dalej zmieniać proxy.
Takie przypadki mają zwykle wyraźne objawy: połączenie i handshake są poprawne, ale żądanie zwraca 403 lub jest resetowane; strona się otwiera, ale działania takie jak logowanie czy publikowanie są odrzucane; to samo wyjście działa na innych stronach i zawodzi tylko na jednej; albo błędy pojawiają się okresowo, co może wskazywać na limit szybkości po stronie wyjścia lub trasy albo limit równoległych połączeń.
Kluczowe jest oddzielenie warstwy połączenia od warstwy biznesowej. Jeśli w ogóle nie można się połączyć, problem prawdopodobnie dotyczy proxy. Jeśli połączenie działa, lecz dostęp jest odrzucany, często chodzi o jakość adresu wyjściowego albo częstotliwość żądań. Adresy IP centrów danych i intensywnie używane współdzielone IP są częściej blokowane na warstwie biznesowej. Adresy rezydencyjne mogą działać lepiej, ale nie są gwarancją: częstotliwość żądań, liczba równoległych połączeń i pora dostępu również mają znaczenie.
Zachowaj trzy nawyki podczas diagnostyki
Zmieniaj tylko jedną rzecz naraz. Jeśli jednocześnie zmienisz protokół i węzeł, nawet po uzyskaniu połączenia nie będziesz wiedzieć, co rozwiązało problem, i możesz popełnić ten sam błąd ponownie.
Najpierw zapisuj, potem zmieniaj. Zachowaj działającą konfigurację z adresem, portem, protokołem i metodą uwierzytelniania. Przy kolejnym problemie bezpośrednie porównanie będzie znacznie szybsze niż diagnoza od zera.
Test porównawczy jest lepszy niż wielokrotne ponawianie. Jeśli konfiguracja wygląda poprawnie, ale połączenie nadal nie działa, ciągłe naciskanie przycisku testu nie dostarczy nowych informacji. Lepiej sprawdzić inne środowisko sieciowe lub inne proxy jako punkt odniesienia.
