Ncat HTTP-proxytilstand kontra et fast TCP-relæ

client → local TCP relay → existing forward proxy → destination

I denne opsætning har relæet én fast upstream. Det sender klientens anmodning uændret videre til den eksisterende videresendelsesproxy. Den proxy læser den absolutte URL eller CONNECT-målet, anvender politik og åbner forbindelsen til destinationen.

At pege relæet direkte mod et websted ændrer kontrakten. En videresendelsesproxy skal vælge destinationer og håndtere HTTP-indramning og forbindelsesadfærd; det er ikke nok at udtrække et værtsnavn fra første linje.

Nmps Ncat tilbyder separat en HTTP-bevidst lyttetilstand:

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

Dette loopback-eksempel bruger Ncats proxyimplementering, ikke en funktion som alle nc deler. Dets proxy på lytte-siden håndterer HTTP-metoder og CONNECT. Dets SOCKS-muligheder på klient-siden opretter ikke en SOCKS-server i lyttetilstand. En vedvarende delt tjeneste kræver også bevidst forbindelseshåndtering, adgangskontrol og logning.

For at observere, find krypteringsgrænsen. Et relæ på en almindelig HTTP-proxyforbindelse kan se proxyanmodninger og -svar. Efter CONNECT er destinationens HTTPS TLS-bytes, ikke læsbart sideindhold. TLS til proxyen skjuler endda den indledende proxyudveksling på den forbindelse. Brug klient- og proxydiagnostik til fortolkede transaktioner, og beskyt logfiler, der kan indeholde legitimationsoplysninger eller følsomme URL’er.