Conexiunea a fost resetată de cealaltă parte printr-un proxy: găsiți etapa care a eșuat
Folosiți etapa conexiunii și dovezi coroborante pentru a investiga un reset al proxy-ului fără a lua scurtul mesaj de eroare al sistemului de operare drept atribuire a cauzei.
„Connection reset by peer” indică o conexiune de transport întreruptă. Nu identifică furnizorul, operatorul proxy-ului sau site-ul web drept cauză.
| Momentul resetării | Unde să investigați |
|---|---|
| Imediat după conectarea TCP | O nepotrivire de protocol sau un serviciu care respinge schimbul inițial |
| După reușita CONNECT | Calea tunelului stabilit |
| În timpul unui răspuns | Închiderea în amonte, o politică de durată de viață a unui intermediar și calea de transfer |
Apoi modificați o condiție relevantă păstrând proxy-ul și destinația fixe. Comparați o conexiune criptată client-la-proxy configurată corect, acolo unde este acceptată, sau același client dintr-o altă rețea aprobată. Întrebați dacă operatorul poate corela încercarea în jurnalele sale.
Un rezultat diferit restrânge investigația fără a dovedi o cauză. Trecerea traficului printr-un tunel poate schimba simultan sincronizarea, încărcarea, politica și echipamentele intermediare. Succesul său singur nu poate stabili o blocare deliberată pe calea originală.
Acolo unde există observații de pachete autorizate, comparați-le cu jurnalele aplicației și ale proxy-ului. Nici chiar adresa sursă așteptată a pachetului nu explică de ce a fost trimis un reset sau ce sistem a impus o politică.
Păstrați eroarea numerică, marcajul temporal, punctul final și ultima etapă finalizată. Folosiți aceste dovezi înainte de a schimba acreditările sau setările TLS; scurtul mesaj de reset în sine nu oferă niciun motiv să schimbați vreuna dintre ele.