Verbinding gereset door de peer via een proxy: vind de mislukte fase
Gebruik de verbindingsfase en ondersteunend bewijs om een proxy-reset te onderzoeken zonder de korte foutmelding van het besturingssysteem als oorzaaktoekenning te behandelen.
‘Connection reset by peer’ meldt een verbroken transportverbinding. Het noemt de provider, de proxy-operator of de website niet als oorzaak.
| Moment van de reset | Waar te onderzoeken |
|---|---|
| Direct na het tot stand komen van TCP | Een protocolafwijking of een dienst die de openingsuitwisseling weigert |
| Nadat CONNECT is geslaagd | Het opgezette tunnelpad |
| Tijdens een antwoord | Sluiting stroomopwaarts, een levensduurbeleid van een tussenpartij en het overdrachtspad |
Wijzig daarna één relevante voorwaarde terwijl de proxy en de bestemming vast blijven. Vergelijk een correct geconfigureerde versleutelde client-naar-proxy-verbinding, waar ondersteund, of dezelfde client vanaf een ander goedgekeurd netwerk. Vraag of de operator de poging in zijn logs kan correleren.
Een ander resultaat vernauwt het onderzoek zonder één oorzaak te bewijzen. Verkeer door een tunnel leiden kan timing, belasting, beleid en tussenliggende apparatuur tegelijk veranderen. Het succes alleen kan geen opzettelijke blokkering op het oorspronkelijke pad vaststellen.
Waar geautoriseerde pakketwaarnemingen beschikbaar zijn, vergelijk die met de logs van de applicatie en de proxy. Zelfs het verwachte bronadres van het pakket verklaart niet waarom een reset is verzonden of welk systeem een beleid heeft afgedwongen.
Bewaar de numerieke fout, de tijdstempel, het eindpunt en de laatst voltooide fase. Gebruik dat bewijs voordat u inloggegevens of TLS-instellingen wijzigt; het korte resetbericht geeft op zichzelf geen reden om een van beide te wijzigen.