Undersøk kroppen til eit mislukka proxy CONNECT-svar med curl

Send ein korrekt bygd diagnostisk CONNECT direkte til ein HTTP-proxy, og lagre HTTP-feilens hovud og kropp kvar for seg.

Ein proxy som avviser CONNECT, kan returnere eit HTTP-feildokument som forklarer policyen eller feilen i den vidare sambindinga. For ein autorisert diagnostikk mot ein vanleg HTTP-proxy kan curl sende denne førespurnaden 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 endelege URL-en adresserer lyttaren til proxyen. For ein tillaten samanliknad av offentlege proxyar gir HTTP-proxylista kandidatar for den lyttar-URL-en. --request gir metodetokenet; --request-target gir CONNECT-autoriteten. Å halde dei skilde gir CONNECT service.example:443 HTTP/1.1.

Det tomme proxy-valet hindrar curl i å rute denne diagnostikken gjennom ein annan arva proxy. Kommandoen utelèt med vilje --fail slik at eit HTTP-feildokument kan haldast.

Eit uautentisert forsøk kan stoppe ved 407 før det når feilen som blir undersøkt. Bruk det tiltenkte autentiseringsoppsettet til proxyen når du gjer om ein autentisert førespurnad.

Dette er for å undersøke feilsvar. Viss proxyen svarar 2xx, blir sambindinga ein tunnel i staden for ei vanleg HTTP-kroppsoverføring. Denne diagnostikken med eigen metode startar ikkje TLS-utvekslinga til målet og kan nå tidsgrensa si på ein godteken open tunnel.

Bruk den vanlege --proxy-førespurnadsflyten for eit faktisk HTTPS-hent. Ta vare på statusen og kroppen til diagnostikken saman med den spesifikke proxyen og målet deira.

Relaterte artiklar