Undersøg brødteksten i et mislykket proxy CONNECT-svar med curl

En proxy, der afviser CONNECT, kan returnere et HTTP-fejldokument, der forklarer dens politik eller den videre forbindelsesfejl. Til en autoriseret diagnostik mod en almindelig HTTP-proxy kan curl sende denne anmodning direkte og gemme 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 adresserer proxyens lytter. Til en tilladt sammenligning af offentlige proxyer giver HTTP-proxylisten kandidater til den lytter-URL. --request leverer metodetokenet; --request-target leverer CONNECT-autoriteten. At holde dem adskilt giver CONNECT service.example:443 HTTP/1.1.

Den tomme proxy-indstilling forhindrer curl i at sende denne diagnostik gennem en anden nedarvet proxy. Kommandoen udelader bevidst --fail, så et HTTP-fejldokument kan bevares.

Et uautentificeret forsøg kan stoppe ved 407, før det når den fejl, der undersøges. Brug proxyens tilsigtede godkendelsesopsætning, når du genskaber en autentificeret anmodning.

Dette er til at undersøge fejlsvar. Hvis proxyen returnerer 2xx, bliver forbindelsen en tunnel i stedet for en almindelig HTTP-brødtekstoverførsel. Denne diagnostik med brugerdefineret metode starter ikke destinationens TLS-udveksling og kan nå sin tidsgrænse på en accepteret åben tunnel.

Brug det normale --proxy-anmodningsforløb til et faktisk HTTPS-hent. Opbevar diagnostikkens status og brødtekst sammen med deres specifikke proxy og mål.