HTTP-prokura reĝimo de Ncat kontraŭ fiksa TCP-ripetilo

client → local TCP relay → existing forward proxy → destination

En ĉi tiu aranĝo, la ripetilo havas unu fiksan suprenfluon. Ĝi transdonas la peton de la kliento senŝanĝe al la ekzistanta antaŭa prokuro. Tiu prokuro legas la absolutan URL-on aŭ la celon CONNECT, aplikas regularon kaj malfermas la konekton al la celo.

Direkti la ripetilon rekte al retejo ŝanĝas la kontrakton. Antaŭa prokuro devas elekti celojn kaj pritrakti HTTP-kadrigon kaj konektan konduton; eltiri gastigantan nomon el la unua linio ne sufiĉas.

La Ncat de Nmap aparte proponas HTTP-konscian aŭskultan reĝimon:

ncat --listen 127.0.0.1 3128 --proxy-type http

Ĉi tiu loopback-ekzemplo uzas la prokuran efektivigon de Ncat, ne trajton komunan al ĉiu nc. Ĝia prokuro ĉe la aŭskulta flanko pritraktas HTTP-metodojn kaj CONNECT. Ĝiaj SOCKS-opcioj ĉe la klienta flanko ne starigas SOCKS-servilon en aŭskulta reĝimo. Daŭra kunhava servo ankaŭ bezonas intencan konektan prizorgon, alirkontrolon kaj protokoladon.

Por observado, lokigu la ĉifran limon. Ripetilo sur ordinara HTTP-prokura konekto povas vidi prokurajn petojn kaj respondojn. Post CONNECT, la HTTPS de la celo estas TLS-bajtoj, ne legebla paĝa enhavo. TLS al la prokuro eĉ kaŝas la komencan prokuran interŝanĝon sur tiu ligo. Uzu diagnozojn de kliento kaj prokuro por interpretitaj transakcioj, kaj protektu protokolojn, kiuj povas enhavi akreditaĵojn aŭ sentemajn URL-ojn.