Connessione reimpostata dal peer attraverso un proxy: individuare la fase fallita
Usare la fase di connessione e prove di riscontro per indagare un reset del proxy senza considerare il breve messaggio di errore del sistema operativo come attribuzione della causa.
«Connection reset by peer» indica una connessione di trasporto interrotta. Non identifica il provider, l'operatore del proxy o il sito web come causa.
| Momento del reset | Dove indagare |
|---|---|
| Subito dopo la connessione TCP | Una discrepanza di protocollo o un servizio che rifiuta lo scambio iniziale |
| Dopo il successo di CONNECT | Il percorso del tunnel stabilito |
| Durante una risposta | Chiusura a monte, una politica di durata di un intermediario e il percorso di trasferimento |
Poi modificate una condizione rilevante mantenendo fissi proxy e destinazione. Confrontate una connessione cifrata client-verso-proxy configurata correttamente, dove supportata, o lo stesso client da un'altra rete approvata. Chiedete se l'operatore può correlare il tentativo nei propri log.
Un risultato diverso restringe l'indagine senza provare una causa. Far passare il traffico attraverso un tunnel può cambiare insieme tempistica, carico, politica e apparati intermedi. Il suo successo da solo non può stabilire un blocco deliberato sul percorso originale.
Dove sono disponibili osservazioni autorizzate dei pacchetti, confrontatele con i log dell'applicazione e del proxy. Nemmeno l'indirizzo di origine atteso del pacchetto spiega perché è stato inviato un reset o quale sistema abbia applicato una politica.
Conservate l'errore numerico, la marca temporale, l'endpoint e l'ultima fase completata. Usate quelle prove prima di cambiare credenziali o impostazioni TLS; il breve messaggio di reset di per sé non fornisce alcun motivo per cambiare nessuno dei due.