Malfermita TCP-pordo ne pruvas ke prokurilo funkcias
Sukcesa pordokontrolo nur establas konekton. Kontrolu ankaŭ la prokurilan manpremon kaj la atendatan respondon de la celo.
Malfermita TCP-pordo montras, ke aŭskultanto akceptis konekton. Ĝi povus esti prokurilo, ordinara retservilo aŭ alia servo; pordo 8080 ne identigas la protokolon.
Por finpunkto dokumentita kiel HTTP-prokurilo, uzu ĝian veran adreson en HTTPS-peto kun tempolimoj:
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/Anstataŭigu la dokumentan adreson per via HTTP-finpunkto aŭ kandidato el la listo de HTTP-prokuriloj. Por SOCKS uzu la koncernan SOCKS-klientreĝimon kaj kompletigu ĝian intertraktadon. Malĝusta manpremo povas malsukcesi tuj post TCP-akcepto.
| Observita etapo | Kion ĝi pruvas |
|---|---|
| TCP akceptita | La aŭskultanto estas atingebla. |
| Prokurila manpremo akceptita | La aŭskultanto akceptis ĉi tiun prokurilan operacion. |
| TLS de la celo kontrolita | La kliento kompletigis la celitan sekuran konekton laŭ siaj fidagordoj. |
| Atendataj stato kaj enhavo ricevitaj | La aplikaĵa peto produktis la atendatan rezulton. |
Por HTTPS tra HTTP-prokurilo, CONNECT al la cela pordo devas esti permesita. Eĉ CONNECT 200 estas meza etapo: la tunelo povas fermiĝi antaŭ ol TLS aŭ la fina peto sukcesas. Sukceso de neĉifrita HTTP ne pruvas tiun tunelkapablon.
Uzu celon kun antaŭvidebla enhavo, prefere sub via kontrolo, kaj inspektu ĝian petregistron kiam havebla. Neĉifrita HTTP-aŭskultanto povas redoni fiksan paĝon kun stato 200 sen kontakti la celon. Ricevi iun ajn sukcesan staton estas pli malforta pruvo ol kongruo kun la atendata respondo; HTTPS-identeca kontrolado donas plian protekton.
Registru la lastan sukcesan etapon. «Pordo malfermita, SOCKS-intertraktado rifuzita» donas utilan deirpunkton por la sekva esploro.