Połączenie zresetowane przez drugą stronę przez proxy: znajdź nieudany etap
Użyj etapu połączenia i potwierdzających dowodów, aby zbadać reset proxy, nie traktując krótkiego komunikatu błędu systemu operacyjnego jako przypisania przyczyny.
„Connection reset by peer” wskazuje na zerwane połączenie transportowe. Nie wskazuje dostawcy internetu, operatora proxy ani strony internetowej jako przyczyny.
| Czas resetu | Gdzie badać |
|---|---|
| Natychmiast po połączeniu TCP | Niezgodność protokołu lub usługa odrzucająca początkową wymianę |
| Po udanym CONNECT | Ustanowiona ścieżka tunelu |
| Podczas odpowiedzi | Zamknięcie po stronie nadrzędnej, polityka czasu życia pośrednika i ścieżka przesyłu |
Następnie zmień jeden istotny warunek, zachowując proxy i cel bez zmian. Porównaj poprawnie skonfigurowane szyfrowane połączenie klient–proxy, jeśli jest obsługiwane, albo tego samego klienta z innej zatwierdzonej sieci. Zapytaj, czy operator może powiązać próbę w swoich logach.
Inny wynik zawęża badanie, ale nie dowodzi jednej przyczyny. Przepuszczanie ruchu przez tunel może jednocześnie zmienić synchronizację, obciążenie, politykę i urządzenia pośredniczące. Sam sukces nie może wykazać celowego blokowania na pierwotnej ścieżce.
Tam, gdzie dostępne są autoryzowane obserwacje pakietów, porównaj je z logami aplikacji i proxy. Nawet oczekiwany adres źródłowy pakietu nie wyjaśnia, dlaczego wysłano reset ani który system zastosował politykę.
Zachowaj liczbowy kod błędu, znacznik czasu, punkt końcowy i ostatni ukończony etap. Użyj tych dowodów, zanim zmienisz dane uwierzytelniające lub ustawienia TLS; krótki komunikat o resecie sam w sobie nie daje powodu do zmiany któregokolwiek z nich.