Een proxyverbinding die werkt, is niet automatisch bruikbaar. Deze gids geeft vijf herhaalbare controles: locatie en provider, residential of datacenter, connectiviteit en pakketverlies, DNS- en WebRTC-lekken en signalen dat het IP op langere termijn wordt gemarkeerd.
Na het instellen van een proxy is een melding dat de verbinding tot stand is gebracht alleen de eerste stap. Of de omgeving echt bruikbaar is, hangt af van details die vaak worden gemist: van wie het exit-adres is, of het bereik residential of datacenter is, waar DNS-verzoeken vandaan worden verstuurd en of WebRTC het echte adres blootlegt.
De volgende vijf controles kun je met concrete methoden één voor één in ongeveer tien minuten uitvoeren.
1. Kloppen locatie en provider?
Open een willekeurige pagina die je huidige IP toont en controleer drie zaken: komen het land en de stad overeen met de gewenste regio, klopt de providernaam met de dienst die je hebt gekocht en komt het ASN overeen met wat is beloofd?
Deze stap vindt een veelvoorkomend probleem: de leverancier zegt dat een node in Duitsland staat, terwijl de daadwerkelijke exit in de Verenigde Staten ligt. IP-databases kunnen ook van elkaar verschillen, waardoor verschillende zoeksites andere resultaten tonen. Vergelijk twee of drie bronnen en gebruik de geregistreerde organisatie in het whois-record als referentie.
Controleer ook IPv6. In sommige omgevingen loopt browserverkeer via de proxy, terwijl IPv6 nog steeds lokaal naar buiten gaat. Gebruik een pagina die alleen IPv6 test om te bevestigen dat ook dat resultaat naar de proxy-exit wijst. Als nog steeds je echte adres verschijnt, is de omgeving slechts gedeeltelijk afgeschermd.
2. Residential bereik of datacenterbereik?
Het IP-type wordt nog makkelijker over het hoofd gezien dan de locatie, maar de impact kan directer zijn. Residential IP’s zijn geregistreerd bij breedbandproviders, terwijl datacenter-IP’s bij cloudproviders of IDC-adresblokken horen. Dit verschil is openbaar zichtbaar in databases voor IP-typen.
De eenvoudigste methode is de organisatie te controleren die bij het ASN geregistreerd staat. Namen met termen als Cloud, Hosting, Data Center of VPS duiden meestal op een datacenterbereik; Telecom, Broadband, Cable of Communications komt vaker voor bij residential- of ISP-bereiken. Kijk ook naar reverse DNS: residential IP’s hebben vaak een door de provider toegewezen reverse record, terwijl PTR-records van datacenter-IP’s vaak het domeinpatroon van een cloudprovider volgen.
Gebruik je een eigen cloudserver als proxy, dan zal de exit per definitie een datacenter-IP zijn. Dat komt door de infrastructuur en kun je niet met configuratie veranderen. De voordelen zijn stabiliteit, controle en exclusief gebruik van het IP; het nadeel is het IP-type. Wat zwaarder weegt, hangt af van de strengheid van de risicocontroles van het doelplatform: bij soepelere controles kan een datacenterbereik prima zijn, terwijl strengere situaties een residential- of ISP-proxy kunnen vereisen.
3. Connectiviteit en pakketverlies
Connectiviteit is niet hetzelfde als stabiliteit. Een korte ping laat niet altijd een probleem zien; je moet de verbinding enige tijd doorlopend observeren.
Voer honderden continue pings of herhaalde verzoeken naar een vast doel uit en bekijk het pakketverlies en de variatie in latency. Nul pakketverlies en latency die binnen dezelfde orde van grootte blijft, zijn gewenst. Incidenteel pakketverlies of sterk schommelende latency wijst meestal op congestie of te weinig bandbreedte. Wil je het probleem lokaliseren, test dan per segment: eerst de latency van je lokale apparaat naar de proxyserver en daarna van de server naar de doelwebsite. Het duidelijk slechtere segment bevat de bottleneck.
Ook het proxyprotocol moet kloppen. SSH, SOCKS5 en HTTP kun je niet zomaar door elkaar gebruiken; het protocol dat in de client is gekozen moet overeenkomen met wat de server werkelijk aanbiedt, anders kan de verbinding wel tot stand komen terwijl verkeer niet goed doorloopt. Hetzelfde geldt voor poorten. Als een standaardpoort zoals SSH-poort 22 bij de provider is geblokkeerd, pas dan eerst de firewallregels aan voordat je het wachtwoord verdenkt.
4. Lekken DNS of WebRTC?
Deze twee controles bepalen of je echte locatie via een andere route kan uitlekken.
Bezoek voor een DNS-lekcontrole een pagina met een DNS-lektest en kijk vanaf welke node de resolutieverzoeken worden verstuurd. Als de uiteindelijke resolver nog lokaal is, is het niet genoeg dat het verkeer via de proxy gaat: een platform kan je echte regio afleiden uit de locatie van DNS-resolutie en die vergelijken met de IP-locatie. De oplossing is externe DNS-resolutie in de omgeving in te schakelen of een proxytype te kiezen dat DNS via de proxy kan oplossen.
WebRTC-lekken zijn minder zichtbaar. Voor peer-to-peercommunicatie verzamelen browsers informatie over lokale netwerkinterfaces en onder bepaalde instellingen kan dat de proxy omzeilen en een privé- of zelfs openbaar adres onthullen. Open een WebRTC-testpagina en kijk of je echte IP tussen de kandidaatadressen staat. Zo ja, schakel WebRTC uit in de browser of omgevingsinstellingen, of beperk het zodat alleen de proxy wordt gebruikt.
5. Zijn tijdzone en taal consistent?
Als de exit in de Verenigde Staten lijkt te liggen, terwijl de browser Beijing-tijd gebruikt, Chinees als taal heeft en lettertypen volgens Chinese opmaak rendert, ontstaat een duidelijke inconsistentie. Stel tijdzone, taal en interfaceregio in volgens de IP-locatie. Het is niet nodig om bewust een specifieke stad exact na te bootsen.
Hoe zie je op langere termijn of het IP is gemarkeerd?
De vorige controles kun je dezelfde dag afronden, maar de reputatie van een IP kun je alleen in de tijd beoordelen. Let op signalen zoals vaker voorkomende CAPTCHAs op de doelsite, logins die steeds vaker een tweede verificatie vragen, functies die eerder normaal werkten maar worden beperkt, of dezelfde site die na wisselen van netwerk direct weer normaal functioneert.
Als na slechts enkele handelingen herhaaldelijk verificaties verschijnen, zijn er meestal twee oorzaken: het IP-type is niet geschikt of het adresbereik is eerder door veel gebruikers gebruikt en heeft daardoor een geschiedenis opgebouwd. Anti-abusedatabases kunnen laten zien of het bereik eerder is gemarkeerd. Hier heeft een zelf beheerde server een voordeel: vanaf de aankoopdatum gebruik jij het IP exclusief en begint de historie schoon.
Er zijn twee praktische opties: overstappen op een residential proxy of een regionale node kiezen met minder gebruikers.
Volgorde op de dag van configuratie
- Controleer op een IP-zoekpagina locatie, provider en ASN en kijk daarna of IPv6 lekt
- Gebruik de ASN-registratie en reverse DNS om te bepalen of het bereik residential of datacenter is
- Stuur honderden doorlopende verzoeken en beoordeel pakketverlies en latencyvariatie; test zo nodig per segment
- Gebruik een DNS-lektest en een WebRTC-test om te bevestigen dat de echte exit niet zichtbaar is
- Stem tijdzone, taal en interfaceregio af op de IP-locatie
Controleer daarna elke één à twee weken opnieuw hoe vaak CAPTCHAs en tweede verificaties verschijnen en leg dit vast. Als een team meerdere omgevingen beheert, scheelt het veel werk om per omgeving de koppeling met exit en parameters vast te leggen. Multi-environmentbeheer met tools zoals PurpleMark kan in deze fase worden gebruikt.
Een proxy die werkt en een proxy die geschikt is, zijn twee verschillende dingen. Voor het eerste volstaat correcte configuratie; voor het tweede moet elk onderdeel worden gecontroleerd. Juist de niet-gecontroleerde punten — DNS-lekken, WebRTC en IP-type — kunnen ongemerkt de geloofwaardigheid van de hele omgeving verlagen.
