Ang koneksyon ay ni-reset ng peer sa pamamagitan ng proxy: hanapin ang nabigong yugto
Gamitin ang yugto ng koneksyon at mga sumusuportang ebidensya upang imbestigahan ang pag-reset ng proxy nang hindi tinatanggap ang maikling mensahe ng error ng operating system bilang pagtukoy sa dahilan.
“Connection reset by peer” ay nagpapahiwatig ng sirang koneksyon sa transportasyon. Hindi nito tinutukoy ang ISP, operator ng proxy o website bilang dahilan.
| Oras ng pag-reset | Saan mag-iimbestiga |
|---|---|
| Kaagad pagkatapos kumonekta ang TCP | Hindi pagkakatugma ng protocol o serbisyong tumatanggi sa pambungad na palitan |
| Pagkatapos magtagumpay ang CONNECT | Ang naitatag na daanan ng tunnel |
| Habang may tugon | Pagsasara sa itaas, patakaran sa haba ng buhay ng tagapamagitan at ang daanan ng paglilipat |
Pagkatapos, baguhin ang isang kaugnay na kondisyon habang nananatiling pareho ang proxy at destinasyon. Ihambing ang wastong naka-configure na naka-encrypt na koneksyon mula kliyente patungo sa proxy, kung sinusuportahan, o ang parehong kliyente mula sa ibang aprubadong network. Itanong kung maikokonekta ng operator ang pagtatangka sa mga log nito.
Ang ibang resulta ay nagpapaliit ng imbestigasyon nang hindi pinapatunayan ang isang dahilan. Ang pagpapadaan ng trapiko sa tunnel ay maaaring sabay na magbago ng oras, karga, patakaran at mga intermediate na kagamitan. Ang tagumpay lamang nito ay hindi makapagtatatag ng sadyang pagharang sa orihinal na daanan.
Kung may mga awtorisadong obserbasyon ng packet, ihambing ang mga ito sa mga log ng aplikasyon at ng proxy. Kahit ang inaasahang source address ng packet ay hindi nagpapaliwanag kung bakit ipinadala ang reset o aling sistema ang nagpatupad ng patakaran.
Ingatan ang numerical na error, timestamp, endpoint at huling natapos na yugto. Gamitin ang ebidensyang iyon bago baguhin ang mga kredensyal o setting ng TLS; ang maikling mensahe ng reset sa sarili nito ay walang dahilan upang baguhin ang alinman sa dalawa.