SOCKS5 vs HTTP-proxy: hoe ze verschillen en welke je moet gebruiken

Hoe vervoert een HTTP-proxy HTTPS-verkeer?

Een HTTP-proxy vervoert HTTPS-verkeer via een tunnel die je client opent met de CONNECT-methode uit RFC 9110. De client noemt de host en poort, de proxy maakt verbinding en antwoordt 200, en vanaf dat moment geeft hij alleen versleutelde bytes door.

De uitwisseling ziet er zo uit, met documentatie-inloggegevens:

CONNECT api.ipify.org:443 HTTP/1.1
Host: api.ipify.org:443
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

HTTP/1.1 200 Connection established

Hoe opent een SOCKS5-proxy een verbinding?

Een SOCKS5-proxy opent een verbinding in drie korte binaire uitwisselingen die zijn gedefinieerd in RFC 1928: een begroeting waarin een authenticatiemethode wordt afgesproken, de login en een verbindingsverzoek met het doeladres. De tabel toont de bytes voor een login met gebruikersnaam en wachtwoord (RFC 1929) en een verzoek voor api.ipify.org op poort 443.

RFC 1929 verstuurt de gebruikersnaam en het wachtwoord in platte tekst, elk tot 255 bytes. Net als Basic-authenticatie over HTTP beschermt het op zichzelf niets; de TLS-sessie naar de website loopt daarna binnen de relay. Een IP-allowlist voorkomt dat er überhaupt een wachtwoord wordt verstuurd. Loginopties: Gebruikersnaam en wachtwoord, of een IP-allowlist (tot 10 IP's).

Wat is het verschil tussen socks5 en socks5h?

Met socks5:// lost je eigen machine de hostnaam op en stuurt de proxy een IP-adres; met socks5h:// ontvangt de proxy de hostnaam en lost deze die op. De "h" staat voor hostname. De namen komen van curl en worden ook gebruikt door Python requests met PySocks.

Het verschil is op twee manieren van belang. Ten eerste stuurt lokale resolutie een DNS-query vanaf je eigen netwerk, wat je resolver vertelt welke sites je bezoekt. Ten tweede kan het DNS-antwoord dat je lokaal krijgt wijzen naar een server bij jou in de buurt, niet bij de proxy, waardoor een CDN je de verkeerde regio kan leveren. Gebruik socks5h:// tenzij je een reden hebt om dat niet te doen. HTTP-proxy's lossen altijd aan de proxyzijde op, omdat CONNECT de hostnaam meedraagt.

curl -x socks5h://USERNAME:[email protected]:PORT https://api.ipify.org
curl -x http://USERNAME:[email protected]:PORT https://api.ipify.org

Ondersteunt SOCKS5 UDP?

De SOCKS5-standaard definieert UDP-relaying via een commando genaamd UDP ASSOCIATE, maar de ondersteuning hangt af van de server en de client. Veel proxydiensten en veel clientbibliotheken implementeren alleen TCP.

RackProxies verkoopt zijn IP's voor HTTP, HTTPS (CONNECT) en SOCKS5, en we beloven geen UDP. Als je gebruik UDP nodig heeft, test het dan op het 1 IP-plan voordat je meer koopt, en vraag eerst support. Voor webverzoeken, API's en monitoring via HTTPS heb je alleen TCP nodig.

Welke moet ik kiezen voor mijn tool?

Kies HTTP wanneer je tool HTTP spreekt, en SOCKS5 wanneer dat niet zo is of wanneer deze alleen SOCKS ondersteunt. In de praktijk:

• Python requests, Node.js fetch met undici, Playwright, Scrapy: HTTP werkt out of the box. SOCKS5 vereist een extra pakket bij requests (requests[socks]).
• curl en wget: curl ondersteunt beide; wget gebruikt HTTP-proxy's.
• Browsers: beide, maar de ingebouwde SOCKS5-client van Chromium heeft historisch geen gebruikersnaam- en wachtwoordauthenticatie ondersteund, dus de veilige keuze is de HTTP-vorm of de allowlist.
• Niet-HTTP TCP-clients (databasetools, aangepaste protocollen): SOCKS5.

De codevoorbeelden tonen elk geval, en de quickstart test beide protocollen met curl.