Konekto restarigita de la samtavolano tra prokurilo: trovu la malsukcesan etapon
Uzu la konektan etapon kaj apogajn pruvojn por esplori restarigon de prokurilo, ne traktante la mallongan erarmesaĝon de la operaciumo kiel atribuon.
“Connection reset by peer” indikas rompitan transportan konekton. Ĝi ne identigas la provizanton, la prokurilan operatoron aŭ la retejon kiel kaŭzon.
| Tempo de restarigo | Kie esplori |
|---|---|
| Tuj post kiam TCP konektiĝas | Protokola malkongruo aŭ servo, kiu malakceptas la malferman interŝanĝon |
| Post kiam CONNECT sukcesas | La establita tunela vojo |
| Dum respondo | Fermiĝo supre, vivdaŭra politiko de peranto kaj la transiga vojo |
Poste ŝanĝu unu gravan kondiĉon, tenante la prokurilon kaj la celon fiksaj. Komparu ĝuste agorditan ĉifritan klient-al-prokurilan konekton, kie ĝi estas subtenata, aŭ la saman klienton el alia aprobita reto. Demandu, ĉu la operatoro povas kunligi la provon en siaj protokoloj.
Malsama rezulto mallarĝigas la esploron sen pruvi unu kaŭzon. Trapasigi trafikon tra tunelo povas samtempe ŝanĝi tempigon, ŝarĝon, politikon kaj mezajn aparatojn. Ĝia sukceso sole ne povas establi intencan blokadon sur la origina vojo.
Kie haveblas rajtigitaj pakedaj observoj, komparu ilin kun la protokoloj de la aplikaĵo kaj de la prokurilo. Eĉ la atendata fontadreso de la pakedo ne klarigas, kial restarigo estis sendita aŭ kiu sistemo aplikis politikon.
Konservu la numeran eraron, la tempomarkon, la finpunkton kaj la laste finitan etapon. Uzu tiujn pruvojn antaŭ ol ŝanĝi akreditaĵojn aŭ TLS-agordojn; la mallonga restariga mesaĝo mem donas neniun kialon ŝanĝi ĉiun el ili.