SOCKS5 of HTTP-proxy? Het verschil en hoe je kiest voor meerdere accounts

Kernconclusie: zowel SOCKS5- als HTTP-proxy veranderen het uitgaande IP-adres van je account; het verschil zit in hoe ze requests behandelen. Een HTTP-proxy werkt in de applicatielaag en begrijpt de requests; SOCKS5 legt alleen een doorstuurkanaal en raakt de applicatiedata niet aan. Voor puur webgebaseerde dashboards zijn beide voldoende, voor desktopclients en scripts kies je bij voorkeur SOCKS5. Het juiste protocol is echter maar één stap; in de antidetect browser volgt nog een compleet traject van invoeren, koppelen, verifiëren en troubleshooten. Dit artikel loopt dat hele pad met je door.

Velen zien beide typen proxy als twee namen voor hetzelfde. Ze geven allebei internettoegang en je kunt op allebei inloggen, dus de keuze lijkt vooral een prijsvraag. Pas wanneer een platform netwerkproblemen gaat melden of dezelfde batch accounts stuk voor stuk naar de hercontrole verdwijnt, kijkt men alsnog naar de proxylaag.

In werkelijkheid werken de twee protocollen al op een andere plek, ze verzoeken anders af en ook configureren en troubleshooten lopen langs andere wegen. Dit artikel pelt eerst de scheidslijn tussen de protocollen, bundelt de verschillen daarna in één tabel en beschrijft tot slot de complete werkvolgorde in MostMate plus de diagnose van drie veelvoorkomende storingen.

De scheidslijn tussen de protocollen: wie verwerkt jouw requests

Een HTTP-proxy werkt in de applicatielaag, SOCKS5 één laag daaronder. Andere positie, andere taakverdeling. Wie jouw requests kan lezen, kan ze ook aanpassen.

De HTTP-proxy is ontworpen voor webverkeer. Het begrijpt HTTP-requests: welk adres, welke headers, welke methode. Dat leesvermogen heeft twee kanten. Aan de pluszijde: cachen en filteren behoren tot de mogelijkheden. Aan de minzijde: het staat precies op de plek waar requests in leesbare vorm voorbijkomen.

In de toelichting op proxyservers en tunneling op MDN staat dat sommige HTTP-proxy's bij het doorsturen markeringsvelden als Via of Forwarded toevoegen of herschrijven; of dat gebeurt, hangt af van de implementatie en configuratie van het betreffende proxy. Requests die via zo'n proxy lopen, kunnen het spoor ‘via een proxy gegaan' meedragen en de site kan dat opmerken, maar het is geen vast gedrag van elke HTTP-proxy.

SOCKS5 hanteert een andere aanpak. Het protocol is gedefinieerd in RFC 1928 en doet één ding: het legt een doorstuurkanaal en stuurt de data ongewijzigd door. Het parst niet wat je verstuurt, dus het voegt ook niets aan je requests toe. De prijs is even duidelijk: cachen, filteren en routeren op inhoud kunnen allemaal niet. Een kanaal blijft een kanaal.

Vertaald naar het beheer van meerdere accounts betekent deze scheidslijn dat beide protocollen al qua vorm een ander netwerkspoor nalaten. Welke beter is, heeft geen algemeen antwoord; dat hangt ervan af naar welke signalen jouw platform kijkt en welk verkeer jouw business draait.

Eén tabel: van requestafhandeling tot de locatie van DNS-resolutie

Verspreid over alinea's zijn de protocolverschillen lastig te overzien, dus eerst in een tabel. Je keuzebasis hoort te bestaan uit een punt-voor-punt-vergelijking van wat beide protocollen kunnen, niet uit één enkel criterium:

De overige rijen spreek je letterlijk aan; de DNS-rij verdient een eigen uitweiding. Via een HTTP-proxy geeft de browser de domeinnaam doorgaans rechtstreeks aan de proxy mee, dus de resolutie gebeurt aan de proxykant en de resolutieverzoeken van je eigen machine verlaten huis niet. Bij SOCKS5 bestaat die standaardafspraak niet: de locatie van DNS-resolutie hangt af van hoe de client het doeladres doorgeeft. Sommige clients geven de domeinnaam eerst aan de proxy om hem op te lossen, andere lossen lokaal op en verbinden pas daarna. Bij dat laatste vertrekken de DNS-queries rechtstreeks vanuit je eigen netwerk naar de DNS-servers; de inhoud heeft niets te maken met de exit van de proxy.

Van dit scheurtje merk je normaal niets; het komt pas boven water als er iets misgaat. Vermoed je dat de resolutie niet met de proxy meereist, doorloop dan de procedure uit de gids voor het detecteren van DNS-lekken en kijk via welk netwerk de queries uiteindelijk naar buiten gaan. Alleen als de locatie van DNS-resolutie met de exit meebeweegt, blijft het domeinspoor van je account consistent.

Kiezen per scenario: drie lijnen

Terug naar de keuze zelf. De verkeerssamenstelling van de meeste multi-accountbusinesses is niet moeilijk in te schatten; kies langs drie lijnen:

1. Puur webgebaseerde dashboards: verkoperspanelen van marktplaatsen, webversies van social media, advertentiebeheer. Het verkeer bestaat uitsluitend uit webrequests, dus beide protocollen kunnen het aan. Kies dan gewoon de beste lijn in plaats van je over het protocoltype te buigen.

2. Desktopclients en scripts: clienten als Telegram, scraping-scripts, tools die tegen een API praten. Dat verkeer houdt zich niet per se aan HTTP-semantiek, dus het generieke doorsturen van SOCKS5 past beter. De gids voor de Telegram-proxy-instellingen legt die tweelaagse exitrelatie bij clients per ingang uit.

3. Realtime audio/video en UDP-verkeer: live-interactie, spraakgesprekken. SOCKS5 ondersteunt UDP-doorsturing, een HTTP-proxy heeft die mogelijkheid niet. Er blijft alleen SOCKS5 over.

Naast het verkeerstype is er nog iets dat je al bij de aankoop vastlegt: de autorisatiemethode. Login en wachtwoord koppelen de identiteit aan het account, dus een apparaat wisselen vraagt geen proxy-aanpassing. Een IP-whitelist koppelt de autorisatie aan de exit van je eigen machine; zodra die verbinding verandert, moet je de lijn in het providerpanel bijwerken. Als een team een batch proxy's deelt, scheelt de combinatie login-wachtwoord een aanzienlijk stuk onderhoud.

Protocol goed gekozen, koppelingsrisico nog niet opgelost

Eén gedachte is een eigen bespreking waard: omdat SOCKS5 de inhoud niet parst, zou het draaien van meerdere accounts erop stiekemer zijn en zou het platform ze niet herkennen. De eerste helft van die redenering klopt. De tweede sluit niet aan.

Platformen beoordelen accountkoppeling op de kwaliteit en historie van het uitgaande IP-adres, op de consistentie van de browserfingerprint en op de patronen in accountgedrag. Geen van die signalen verdwijnt doordat de requestheaders schoon zijn. Tien accounts op hetzelfde uitgaande IP-adres blijven tien accounts op hetzelfde adres, ook na overstap naar SOCKS5. Dat SOCKS5 de applicatielaag niet parst, betekent niet dat er elders op het netwerkpad geen herkenbare informatie zit; ook de exitkwaliteit en de verkeerskenmerken vallen binnen de waarneming.

Het IP-type en het protocol zijn twee onafhankelijke assen. De exitkwaliteit hangt ervan af of je residentiële of datacenterlijnen koopt; de gids over het verschil tussen residentiële en datacenter-IP's pelt die keuzelogica uit. En als het kanaal geregeld is, volgt nog de verificatie: de tweelaagse proxycontrole geeft de volgorde om exitconnectiviteit en parameterconsistentie na te kijken.

Proxy instellen in MostMate: van invoeren tot verifiëren

Een gekozen proxy wordt pas zinvol als hij in een omgeving terechtkomt. MostMate is een antidetect browser waarin proxy en fingerprintparameters per omgeving apart worden bewaard, zodat elk account een eigen, niet-overlappende exit krijgt. Van de aankoop van een proxy tot het moment waarop de omgeving hem echt gebruikt, loopt de route in zes stappen.

Stap 1: controleer de proxygegevens van je provider. Leg vooraf alles klaar: protocoltype, adres, poort, authenticatiemethode. Neem het protocoltype over zoals de provider het aangeeft en raad niet vanaf het poortnummer: dat 1080 vaak bij SOCKS5 hoort, is branchegebruik, geen regel. Vul je het type verkeerd in, dan slaagt geen enkele controle.

Stap 2: voer de proxy in de proxylijst in. In MostMate beheer je proxy's in een eigen menu; de instap bestaat uit nieuw proxy en proxy importeren, en de lijst legt per regel de proxygegevens, de notitie, het uitgaande IP-adres en de aanmaakdatum vast. Vul bij het invoeren meteen de notitie in: waarvoor de lijn dient, bij welke provider, welk lijnnummer. De notitie is er voor wie het werk na je overneemt.

Stap 3: koppel de proxy aan de omgeving. Ga naar het formulier voor het aanmaken of bewerken van een omgeving; bij de proxy-instellingen zijn er drie opties: geen proxy, eigen proxy, of direct een al ingevoerde proxy kiezen. De typelijst omvat SOCKS5, HTTP, HTTPS en SSH. De keuze moet kloppen met het echte protocol. Bij een eigen proxy volg je de formaataanwijzing in het formulier; geeft de provider het voorvoegsel socks5, kies dan SOCKS5.

Stap 4: controleer de proxyverbinding. In het formulier staat de knop proxy controleren: die test de connectiviteit en checkt via het IP lookup-kanaal waar de exit zich bevindt. Een geslaagde test is nog maar de eerste drempel. DNS en WebRTC vallen buiten het bereik van de knop; die verifieer je na het starten van de omgeving via externe testpagina's.

Stap 5: start de omgeving en controleer de echte exit. Als de test is geslaagd, open je de omgeving, ga je naar de IP-testpagina en bevestig je dat de echte exit aan de verwachting voldoet; kijk indien nodig DNS en tijdzone meteen mee. Wijkt het resultaat af, dan noteer je eerst het verschijnsel en verander je daarna per poging precies één instelling. Pas je tegelijk meerdere dingen aan, dan valt niet meer te zeggen waar het probleem zit.

Stap 6: onderhoud de koppeling tussen omgevingen en lijnen. In de omgevingslijst zijn de kolommen proxy en uitgaand IP-adres regel voor regel zichtbaar, dus je ziet bij elk openen welk account op welke lijn rijdt. Na een proxywissel hoort de notitie mee te worden bijgewerkt. Bij teamoverdracht loop je langs deze twee kolommen om te voorkomen dat een proxy bij de verkeerde omgeving terechtkomt.

De interfaces en velden van de diverse modules vergelijk je scherm voor scherm op de pagina wat is MostMate. Een ingestelde proxy is maar een deel van het opzetten van een omgeving; de volledige volgorde loop je na langs de checklist voor een nieuwe omgeving.

Ingesteld maar onbereikbaar: diagnose van drie verschijnselen

Als de configuratierondgang klaar is, blijft het afhandelen van storingen over. De diagnose loopt van het verschijnsel terug naar de oorzaak, niet vanaf het opnieuw intikken van de hele configuratie. In multi-accountsituaties kom je vooral drie typen tegen. Noteer eerst het verschijnsel, zoek dan de oorzaak.

Verschijnsel één: controle geslaagd, exitregio klopt niet

De proxy verbindt, maar de locatie is niet de regio die de provider beloofde. Er zijn drie mogelijke oorzaken: de toegekende lijn hoort niet bij de bestelling, de IP-geolocatiedatabase zit ernaast, of het ontvangen adresblok is verkeerd gelabeld. Controleer door het IP lookup-kanaal te vervangen door een externe testpagina en beide uitkomsten naast elkaar te leggen. Blijft de afwijking terugkomen, vraag dan direct een andere lijn bij de provider in plaats van zelf eindeloos aan de configuratie te draaien.

Verschijnsel twee: test geslaagd, pagina's openen niet

De knoptest is groen, maar in de omgeving laden sommige sites fout. Zo'n verschil zit meestal in de exit zelf: het doelplatform heeft het adresblok geblokkeerd waar deze lijn in ligt, of de proxybandbreedte wisselt te veel. Controleer door in dezelfde omgeving van lijn te wisselen of tijdelijk het protocoltype te veranderen; zo scheid je een kanaalprobleem van een herkende exit. Werkt de testpagina wél en het doelplatform niet, dan wijst dat meestal op een herkende exit.

Verschijnsel drie: twee omgevingen tonen hetzelfde uitgaande IP-adres

Dit gebeurt het makkelijkst bij grote aantallen omgevingen: bij het koppelen werd twee keer dezelfde proxy gekozen, of het klonen van een omgeving kopieerde de configuratie meteen mee. Controleer door in de omgevingslijst de kolommen proxy en uitgaand IP-adres regel voor regel langs te gaan en bij gedeeld gebruik direct om te koppelen. Twee accounts die lang op dezelfde lijn rijden, zijn het meest directe signaal bij de beoordeling van koppeling. Deze kolom verdient het regelmatig bekeken te worden.

Veelgestelde vragen

Kun je SOCKS5- en HTTP-proxy door elkaar gebruiken binnen dezelfde set omgevingen?

Ja. Gemengd gebruik waar nodig is normaal: de proxy van elke omgeving staat op zichzelf, dus omgevingen voor webdashboards rijden op het ene type en omgevingen voor clients en scripts op het andere, zonder onderlinge invloed. Voorwaarde is wel dat binnen elke omgeving het type klopt met het echte protocol.

Waar staat een HTTPS-proxy in dit verhaal?

Hij behandelt versleutelde webpagina's door bovenop de HTTP-proxy een tunnel te bouwen, dus voor webverkeer is hij net zo bruikbaar als SOCKS5. De keuzelogica hierboven geldt ook voor hem. De ruimte gaat naar de grootste verschillen; de rest wordt niet herhaald.

Welke is sneller: SOCKS5 of HTTP-proxy?

Snelheid hangt vooral af van lijnkwaliteit, afstand en bandbreedte; de verwerkingsoverhead van het protocol zelf verschilt onder de huidige netwerkcondities nauwelijks. Voor dezelfde prijs is een HTTP-proxy op een goede lijn duidelijk sneller dan een SOCKS5 op een slechte. Het protocol als snelheidscriterium nemen, stuurt de keuze makkelijk de verkeerde kant op.

Heb je met SOCKS5 nog steeds een antidetect browser nodig?

Ja, want het zijn twee dingen op verschillende lagen. Een proxy wisselt alleen de netwerkexit; de browserfingerprint, cookies en lokale data bepaalt nog steeds de browser. Bij meerdere accounts draait het om een exit en een identiteit die elk apart zijn; dat is precies waar de omgevingen van een antidetect browser voor zorgen. Een volledige toelichting staat op de pagina mogelijkheden en grenzen van de antidetect browser.

Tot slot

De scheidslijn tussen SOCKS5 en HTTP-proxy loopt langs de requestafhandeling en de locatie van DNS-resolutie: het ene begrijpt requests en kan sporen nalaten, het andere legt alleen een doorstuurkanaal en stuurt ongewijzigd door. Voor webdashboards werken beide, voor clients en scripts is SOCKS5 de betere keuze, en de autorisatiemethode leg je al bij de aankoop vast. Na de keuze: de proxy in de centrale lijst invoeren, aan de omgeving koppelen, pas na een geslaagde verificatie inloggen, en bij afwijkingen van het verschijnsel terugredeneren naar de oorzaak. Dan is de kanaallaag pas echt afgerond. Wil je het exitverschil zelf een keer naast elkaar zetten, download dan de gratis versie van MostMate, open twee omgevingen met elk een eigen lijn en de test wijst het vanzelf aan.