cURL: proxyport kontra destinationsport
Behåll en HTTPS-tjänsts port i dess destinations-URL och mellanledets port i proxy-URL:en, utan att skriva över dem via CURLOPT_PORT.
En HTTPS-tjänst på port 8443 nås via en HTTP-proxy på port 8080. Dessa siffror beskriver olika anslutningar:
$handle = curl_init('https://api.example:8443/status');
curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);Programmet ansvarar fortfarande för körningen, felhanteringen och handtagets livscykel. Utdraget håller routing-indata tillsammans utan att ändra certifikatverifieringen.
cURL ansluter först till proxy.example:8080. För denna HTTPS-destination anger tunnelbegäran api.example:8443, och TLS-identiteten förblir api.example.
CURLOPT_PORT är en överskrivning av destinationsporten, inte proxyns port. Att sätta den till 443 varje gång en URL börjar med https kan skriva över en tjänst som medvetet ligger på 8443. libcurl rekommenderar att välja porten i URL:en i stället för att använda det alternativet.
När du återanvänder ett handtag måste du även räkna med en tidigare uttrycklig portöverskrivning. En ny URL gör inte motstridiga bevarade alternativ lättare att tolka.
Mellanledet måste tillåta CONNECT till den valda destinationsporten. Ett avslag för 8443 är inte skäl att flytta proxylistenaren eller stänga av TLS-valideringen.