Terug naar blog

SOCKS5 of HTTP-proxy: wat is het verschil, en hoe stel je ze in een fingerprintbrowser in?

Wie een proxy uitzoekt, kijkt meestal alleen naar regio, bandbreedte en prijs — het veld „type", HTTP of SOCKS5, wordt overgeslagen. Juist dat veld bepaalt drie dingen: van welke kant het DNS-verzoek vertrekt, of UDP-verkeer erdoor komt en of de proxy je requestheaders herschrijft. Bij gewoon browsen merk je daar weinig van, maar zodra de proxy in een omgeving als MakoBrowser zit, werkt hij direct door op de kwaliteit van de omgeving. Hieronder eerst het verschil, dan hoe je kiest en hoe je alles instelt en controleert.

Het kernverschil: de een begrijpt de taal van het web, de ander verplaatst alleen data

Een HTTP-proxy werkt op de applicatielaag, kan de HTTP-verzoeken die erdoorheen gaan lezen en ze dus ook herschrijven; SOCKS5 is een algemeen doorgeefkanaal dat niet naar de inhoud kijkt.

Bij het openen van een http-pagina ziet de HTTP-proxy het adres en de requestheaders; bij https stuurt de browser eerst een CONNECT-verzoek om een tunnel op te zetten, en daarna is de inhoud voor de proxy onzichtbaar — dat staat duidelijk beschreven in de MDN-uitleg over de CONNECT-methode. Met andere woorden: ook een HTTP-proxy gebruikt voor HTTPS een tunnel, maar zijn mogelijkheden blijven aan het HTTP-protocol gebonden.

SOCKS5 staat anders in elkaar. RFC 1928 beschrijft hem als een „tussenlaag tussen applicatie- en transportlaag" en definieert drie commando's: CONNECT, BIND en UDP ASSOCIATE. In gewone taal: hij leest de inhoud niet, maar bezorgt de data ongewijzigd op de bestemming — en niet alleen TCP.

In de praktijk komt het neer op deze punten:

  • Welk verkeer erdoor kan: een HTTP-proxy verwerkt HTTP en HTTPS; SOCKS5 kan willekeurig TCP-verkeer doorsturen en ondersteunt UDP standaard.
  • Of je verzoek wordt aangepast: op HTTP-niveau ziet de proxy de inhoud en sommige implementaties voegen headers als Via of X-Forwarded-For toe; SOCKS5 laat de applicatielaag ongemoeid.
  • Authenticatie: HTTP-proxys gebruiken vaak Basic-authenticatie, waarbij de inloggegevens alleen base64-gecodeerd zijn en de veiligheid van HTTPS afhangt; SOCKS5 heeft een eigen onderhandeling, en RFC 1929 definieert daarvoor gebruikersnaam plus wachtwoord.
  • Poortgebruik: SOCKS-diensten draaien traditioneel op poort 1080, maar gebruik gewoon de poort die je provider opgeeft.

Een beheerder stelt aan een bureau proxys in voor meerdere omgevingen, met op het scherm het proxytype en de controlestatus

In een fingerprintbrowser lopen vooral DNS en UDP mis

Kies je het verkeerde proxytype, dan is het eerste probleem meestal niet „geen verbinding", maar dat DNS-verzoeken stilletjes via het lokale netwerk lopen.

Aan welke kant DNS wordt opgelost, bepaalt of het lekt

Aan welke kant een domeinnaam wordt opgelost, hangt af van de instellingen van de client, niet van de naam van het proxytype. SOCKS5 kan de domeinnaam direct aan de proxy geven — RFC 1928 definieert daar zelfs een adrestype voor. Maar clients doen dat standaard niet altijd: in Firefox moet je bijvoorbeeld „DNS proxien bij gebruik van SOCKS v5" aanvinken voordat de resolutie via de proxy loopt; zonder dat vinkje lost de client de naam eerst lokaal op naar een IP en geeft die pas daarna aan de proxy, waardoor het DNS-verzoek bij je lokale provider belandt. Dat is de meest voorkomende bron van een proxylek via DNS.

Een HTTP-proxy geeft de hostnaam meestal aan de proxy om op te lossen, maar ook hier geldt: niet zomaar aannemen. WebRTC-verbindingen, het vooraf ophalen door de browser en verkeer dat de proxy omzeilt, kunnen de resolutie terug naar lokaal sturen.

Controleren is niet ingewikkeld. Open na het starten van de omgeving een willekeurige DNS-lektestpagina en kijk bij welke regio de resolver hoort. Staat daar je lokale provider, dan volgt de resolutie de proxy niet.

Wanneer UDP-ondersteuning pas echt telt

Bezoekt de browser een site met HTTP/3, dan probeert hij QUIC, en QUIC draait op UDP. Ondersteunt de proxy alleen TCP, dan valt het verkeer automatisch terug op TCP, laadt de pagina gewoon en merk je in het dagelijks gebruik niets. SOCKS5 is pas echt nodig als er in de omgeving ook tools draaien die van UDP afhankelijk zijn.

Voor alleen webbeheer is UDP geen beslissend punt; met extra tools in de omgeving wel.

HTTP-proxy en SOCKS5 vergeleken: zichtbare headers en alleen TCP tegenover geen inhoudsanalyse, TCP en UDP, en DNS op afstand

Wanneer kies je SOCKS5 en wanneer volstaat HTTP

Bij de keuze gaat het niet om welk type „geavanceerder" is, maar om je verkeersmix en welk type je provider levert.

Een paar richtlijnen om direct naast elkaar te leggen:

  1. De provider levert alleen HTTP en je gebruikt de proxy enkel voor browserverkeer: neem de HTTP-proxy, dat is ruim voldoende.
  2. Naast de browser draaien er UDP-afhankelijke tools, of je wilt je DNS-blootstelling verkleinen: geef dan SOCKS5 voorrang.
  3. De proxy moet cachen, content filteren of toegang auditen: een HTTP-proxy past beter, want zijn waarde zit juist in het begrijpen van de aanvraaginhoud.
  4. Je beheert alleen meerdere accounts voor social media of shops: beide typen voldoen; het echte verschil zit niet in het protocol.

Twee hardnekkige misverstanden verdienen het om uit elkaar te worden gehaald. Het eerste: „SOCKS5 is altijd sneller" — de snelheid hangt af van bandbreedte, belasting en afstand van de proxyserver, niet direct van het protocoltype. Het tweede: „SOCKS5 is anoniemer" — hij verandert alleen de inhoud niet; hij verbergt niet wie je bent, en of logs worden bewaard bepaalt de provider.

Nog één opmerking: het proxytype is maar één parameter in de keuze. Of de proxy exclusief is, of de regio stabiel blijft en of het IP vaak wisselt, heeft vaak meer invloed op de omgevingsisolatie dan het protocoltype. Lang tobben over het type terwijl je een gedeelde proxy gebruikt die steeds van IP springt, keert de volgorde om.

Een proxy instellen in de fingerprintbrowser: van type tot controle

Het instellen zelf is maar een paar stappen, maar de verkeerde volgorde kost herwerk: test eerst buiten de omgeving, stel dan in de omgeving in en controleer tot slot in de browser.

  1. Controleer eerst of de proxy zelf werkt. Zodra je host, poort, type en inloggegevens hebt, test je de verbinding buiten de omgeving, zodat je „proxy werkt niet" kunt onderscheiden van „omgeving verkeerd ingesteld".

  2. Open de proxy-instellingen van de omgeving en kies het type. Het type moet overeenkomen met wat de provider heeft gegeven. Een SOCKS5-proxy als HTTP invullen levert direct geen verbinding op, en de foutmelding is meestal zo vaag dat je het voor een omgevingsfout aanziet.

    Koppelen en controleren van de omgevingsproxy in de MakoBrowser fingerprintbrowser

  3. Vul host, poort en inloggegevens in. Vul gebruikersnaam en wachtwoord in als je die hebt, en let op dat je geen overbodige spaties meekopieert — dat is de meest voorkomende beginnersfout.

    Het configuratiepaneel voor de proxy van een omgeving in de MakoBrowser fingerprintbrowser

  4. Voer na het opslaan eerst de proxycontrole binnen de omgeving uit en bevestig dat exit-IP, land en regio kloppen.

  5. Controleer na het starten van de omgeving nog eens in de browser. Let vooral op drie punten: exit-IP, locatie van de DNS-resolutie en WebRTC.

  6. Zet het vast. Eén account, één vaste exit — wissel niet vaak van node alleen om „veiliger te lijken", want vaak wisselen is zelf een signaal.

Stap 4 en stap 5 controleren twee verschillende dingen: de controle in de omgeving bevestigt of de proxyketen werkt, de controle in de browser of er ergens anders verkeer weglekt. Doe je alleen het eerste, dan mis je makkelijk DNS en WebRTC.

Drie controles die na het instellen verplicht zijn

Een ingestelde proxy is nog geen werkende: exit-IP, locatie van de DNS-resolutie en WebRTC moeten alle drie apart worden bevestigd.

  • Exit-IP en regio: open een willekeurige IP-opzoekpagina en controleer dat daar het IP van de proxy staat en niet dat van je machine, en dat de regio overeenkomt met de beschrijving van de provider.
  • Locatie van de DNS-resolutie: gebruik een DNS-lektestpagina om te zien waar de resolver geregistreerd is. Dit punt is ook bij SOCKS5 belangrijk, want de resolutiekant hangt af van de clientinstellingen — niet zomaar aannemen.
  • WebRTC: controleer of de browser je echte IP via WebRTC blootgeeft. In gewone browsers waar alleen de proxy is aangepast en geen omgevingsisolatie is gedaan, komt dit heel vaak voor.

Nog iets dat makkelijk wordt vergeten: tijdzone, taal en systeemregio moeten aansluiten bij de exit-regio. Een Amerikaanse proxy draaien terwijl de tijdzone nog UTC+8 is, valt eerder op dan een verkeerd protocoltype.

MakoBrowser fingerprintparameters afgestemd op het proxy-IP

Heb je een stuk of tien, of zelfs tientallen omgevingen in te stellen, dan scheelt een herbruikbaar profiel voor type, exit en regio meer werk dan alles elke keer handmatig invullen. Daarom beheert MakoBrowser proxys samen met de omgevingen — omgeving, account en netwerkuitgang staan op één plek, zodat bij een overdracht niemand hoeft te vragen aan welke node een account hangt. Wil je eerst één omgeving werkend krijgen, installeer dan de client via de downloadpagina.

Veelgestelde vragen

Wat is sneller, SOCKS5 of HTTP?

Daar is geen vast antwoord op. De snelheid hangt af van de bandbreedte, belasting en afstand van de proxyserver en van de doelsite, en nauwelijks van het protocoltype. Tob liever niet over het type, maar kijk eerst naar de lijnkwaliteit van de proxy.

Moet een fingerprintbrowser SOCKS5 gebruiken?

Nee. Draai je alleen browserverkeer en levert je provider alleen HTTP, dan werkt een HTTP-proxy net zo goed. De voordelen van SOCKS5 zitten in UDP-ondersteuning en beheersbare DNS-resolutie op afstand; geef hem voorrang als er in de omgeving UDP-afhankelijke tools draaien.

Ik heb de proxy ingevuld, waarom zie ik toch mijn echte IP?

Drie veelvoorkomende oorzaken: het verkeerde type waardoor de proxy niet echt actief is, de browser die direct via WebRTC verbindt, of DNS dat nog lokaal wordt opgelost. Loop de punten in de volgorde van de vorige sectie langs, dan vind je meestal welke schakel het probleem is.

Kan een HTTP-proxy HTTPS-websites openen?

Ja. De browser zet via de CONNECT-methode eerst een tunnel op bij de proxy; het verkeer in de tunnel is versleuteld, dus de proxy ziet de pagina-inhoud niet. Dat is de standaardmanier waarop een HTTP-proxy HTTPS verwerkt.

Beïnvloedt het proxytype de accountveiligheid?

Het type bepaalt op zichzelf niet de uitkomst voor een account; wat telt is of de exit stabiel is, of de regio bij het account past en of er vaak wordt gewisseld. Geen enkel hulpmiddel kan garanderen dat een account nooit wordt gecontroleerd — de omgeving schoon houden en abnormale schommelingen vermijden is het deel dat je zelf in de hand hebt.