Undersøk kroppen til en mislykket proxy CONNECT-respons med curl
Send en korrekt bygget diagnostisk CONNECT direkte til en HTTP-proxy, og lagre HTTP-feilens headere og kropp hver for seg.
En proxy som avviser CONNECT, kan returnere et HTTP-feildokument som forklarer policyen eller feilen i den videre forbindelsen. For en autorisert diagnostikk mot en vanlig HTTP-proxy kan curl sende forespørselen direkte og lagre svaret:
curl --proxy '' --http1.1 --max-time 10 \
--request CONNECT \
--request-target service.example:443 \
--header 'Host: service.example:443' \
--dump-header tunnel.headers \
--output tunnel.body \
http://proxy.example:8080/Den endelige URL-en adresserer proxyens lytter. For en tillatt sammenligning av offentlige proxyer gir HTTP-proxylisten kandidater for den lytter-URL-en. --request leverer metodetokenet; --request-target leverer CONNECT-autoriteten. Å holde dem atskilt gir CONNECT service.example:443 HTTP/1.1.
Det tomme proxy-alternativet hindrer curl i å rute denne diagnostikken gjennom en annen nedarvet proxy. Kommandoen utelater bevisst --fail slik at et HTTP-feildokument kan beholdes.
Et uautentisert forsøk kan stoppe ved 407 før det når feilen som undersøkes. Bruk proxyens tiltenkte autentiseringsoppsett når du gjenskaper en autentisert forespørsel.
Dette er for å undersøke feilresponser. Hvis proxyen returnerer 2xx, blir forbindelsen en tunnel i stedet for en vanlig HTTP-kroppsoverføring. Denne diagnostikken med egendefinert metode starter ikke destinasjonens TLS-utveksling og kan nå tidsgrensen på en akseptert åpen tunnel.
Bruk den vanlige --proxy-forespørselsflyten for et faktisk HTTPS-hent. Ta vare på diagnostikkens status og kropp sammen med deres spesifikke proxy og mål.