Elke proxyverbinding heeft een manier nodig om te bewijzen dat u gemachtigd bent deze te gebruiken. De twee standaardbenaderingen: registreer uw IP en sla inloggegevens over, of authenticeer bij elke aanvraag met een gebruikersnaam-wachtwoord-authenticatiepaar voor de proxyserver.
IP-only authenticatie werkt prima als uw adres nooit verandert. Maar op een thuisverbinding, een laptop die tussen netwerken wisselt, of een VPS met een dynamisch IP — heeft u iets nodig dat niet breekt wanneer het adres verschuift. Daar komt login/wachtwoord om de hoek kijken.
Hoe authenticatie met inloggegevens werkt
Wanneer uw software verbinding maakt met een proxy, vraagt de proxy om bewijs van toegang. Bij HTTP-proxy-authenticatie stuurt de client een Proxy-Authorization-header met uw gebruikersnaam en wachtwoord gecodeerd in Base64. De proxy controleert de inloggegevens en als ze overeenkomen — stroomt het verkeer. Hier is een kort voorbeeld met curl: curl -x http://username:password@proxy-address:port https://example.com — of in Python requests: requests.get("https://example.com", proxies={"https": "http://username:password@proxy-address:port"}).
Bij SOCKS5-proxy-authenticatie met gebruikersnaam en wachtwoord verloopt het proces iets anders. SOCKS5 verwerkt de inloggegevens tijdens zijn eigen handshake — een aparte stap vóórdat enig webverkeer begint. De client geeft aan dat hij wil authenticeren, stuurt de login en het wachtwoord, en de proxy reageert met succes of fout. Pas daarna begint de daadwerkelijke verbinding.
Beide methoden bereiken hetzelfde doel: bewijzen dat u gemachtigd bent om de proxy te gebruiken, ongeacht vanaf welk IP-adres u verbinding maakt.
Waarom inloggegevens gebruiken in plaats van alleen IP
De IP-only modus is eenvoudiger — geen geheimen, niets om in uw software te configureren. Maar het vereist een statisch publiek adres. Zodra uw ISP uw IP roteert, valt de toegang weg totdat u de whitelist bijwerkt.
Login/wachtwoord-authenticatie elimineert die afhankelijkheid. Uw proxygegevens werken vanaf elk netwerk: het kantoor, een koffiezaak, een ander land. Zolang de inloggegevens kloppen en uw IP binnen het /21-subnet van uw geregistreerde adres valt, komt de verbinding tot stand. De meeste proxyproviders beperken credential-authenticatie tot één enkel gewhitelist IP of een klein /32-bereik — de /21-subnetbenadering van FineProxy dekt 2.048 adressen, zodat dynamische IP-rotaties uw sessie vrijwel nooit verbreken. Dat biedt u een mate van flexibiliteit die zeldzaam is op de markt.
Dit is van belang voor:
- Laptops en apparaten die tussen Wi-Fi-netwerken wisselen
- Thuisverbindingen waarbij de ISP dagelijks een nieuw adres toewijst
- Teams waarbij meerdere personen vanuit verschillende locaties verbinding maken
- CI/CD-pipelines die draaien op cloudinstances met wisselende IP's
Hoe het werkt bij FineProxy
IP-registratie is verplicht op ons platform — het vormt de basis van hoe ons systeem klanten identificeert. Wanneer u login/wachtwoord-authenticatie daarbovenop toevoegt, accepteert de proxy verbindingen van elk IP binnen het /21-subnet van uw geregistreerde adres.
Dat zijn 2.048 adressen. De meeste ISP's roteren dynamische IP's binnen een veel smaller bereik, dus in de praktijk blijft uw verbinding werken zonder handmatige aanpassingen.
FineProxy ondersteunt inloggegevens via alle protocollen die wij aanbieden: HTTP, HTTPS en SOCKS5. Bij HTTPS heeft elk IP een eigen SSL-certificaat, zodat de versleutelde verbinding tussen uw client en de proxy ook met credential-gebaseerde authenticatie veilig blijft.
Uw inloggegevens zijn direct na aankoop beschikbaar in het dashboard. Het formaat is eenvoudig: username:password@proxy-address:port voor HTTP/HTTPS, of configureerbaar in de authenticatie-instellingen van uw SOCKS5-client.
Na aankoop verschijnen de inloggegevens direct in uw dashboard — het formaat is gebruikersnaam:wachtwoord@adres:poort, klaar om te plakken in uw browser, script of automatiseringstool.
Inloggegevens veilig bewaren
Het nadeel van login/wachtwoord-authenticatie is dat er inloggegevens bestaan — en alles wat bestaat, kan uitlekken. Een paar praktische regels:
Gebruik omgevingsvariabelen in plaats van inloggegevens hard te coderen in scripts. export HTTPS_PROXY="http://user:pass@proxy:port" houdt het wachtwoord buiten uw broncode.
Commit proxy-inloggegevens nooit naar een Git-repository. Zelfs privérepo's worden gedeeld, gekloond en geback-upt naar plekken waar u geen controle over hebt.
Als uw tool het ondersteunt, haal de inloggegevens dan tijdens runtime op uit een secrets manager in plaats van ze in configuratiebestanden op te slaan.