Modul proxy HTTP al Ncat față de un releu TCP fix

client → local TCP relay → existing forward proxy → destination

În această aranjare, releul are un singur upstream fix. Transmite cererea clientului neschimbată proxy-ului direct existent. Acel proxy citește URL-ul absolut sau ținta CONNECT, aplică politica și deschide conexiunea către destinație.

Direcționarea releului direct către un site web schimbă contractul. Un proxy direct trebuie să selecteze destinații și să gestioneze încadrarea HTTP și comportamentul conexiunilor; extragerea unui nume de gazdă din prima linie nu este suficientă.

Ncat din Nmap oferă separat un mod de ascultare conștient de HTTP:

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

Acest exemplu loopback folosește implementarea proxy a Ncat, nu o caracteristică partajată de fiecare nc. Proxy-ul său din partea de ascultare gestionează metodele HTTP și CONNECT. Opțiunile sale SOCKS din partea clientului nu stabilesc un server SOCKS în modul de ascultare. Un serviciu partajat permanent necesită și gestionare deliberată a conexiunilor, control al accesului și jurnalizare.

Pentru observare, localizați granița criptării. Un releu pe o conexiune proxy HTTP simplă vede cererile și răspunsurile proxy. După CONNECT, HTTPS-ul destinației este format din octeți TLS, nu din conținut de pagină lizibil. TLS către proxy ascunde chiar și schimbul inițial al proxy-ului pe acea legătură. Folosiți diagnostice de client și proxy pentru tranzacții interpretate și protejați jurnalele care pot conține acreditări sau URL-uri sensibile.