De grootste valkuil bij proxy-extensies voor de browser is het bereik: ze nemen alleen browserverkeer over en kunnen alsnog via een directe verbinding gaan als geen regel overeenkomt. Dit artikel verdeelt extensies naar gebruik, noemt beoordelingscriteria zoals protocol, authenticatie, rechten en onderhoudsstatus, en geeft zelftests voor het uitgaande IP en WebRTC-lekken.
Proxy-extensies voor de browser hebben een grens die vaak over het hoofd wordt gezien: ze nemen alleen de verzoeken over die de browser zelf verstuurt. Systeemupdates, desktopclients en andere apps blijven de oorspronkelijke route volgen. Bedenk eerst goed wat je precies via de proxy wilt laten lopen en kies daarna pas een hulpmiddel; dat scheelt later veel zoekwerk.
Begin met drie gebruiksscenario's
De meest voorkomende behoefte is schakelen per site: een paar domeinen via de proxy laten lopen en de rest direct laten verbinden. Zo'n scenario wordt gestuurd door een regellijst, en de waarde van de extensie zit in snel schakelen en het splitsen per domein.
Het tweede type is de globale proxy, waarbij al het browserverkeer via één uitgang naar buiten gaat. De instelling is het eenvoudigst, maar de prijs is direct merkbaar: valt de uitgang weg, dan is de browser feitelijk offline, wat het dagelijks gebruik onstabiel maakt.
Het derde type is gekoppeld aan een omgeving: elk browserprofiel krijgt een vaste uitgang en de profielen beïnvloeden elkaar niet. Deze aanpak hoort bij meerdere accounts of meerdere projecten naast elkaar; de extensie is hier vooral een aanvulling, omdat de uitgang zelf meestal op een lager niveau wordt ingesteld.
Waar je bij de beoordeling van een extensie op let
Protocolondersteuning staat voorop. HTTP- en HTTPS-proxy's verwerken alleen TCP, terwijl SOCKS5 algemener is, maar de ondersteuning voor UDP hangt van de implementatie af, en veel extensies laten UDP gewoon door of gooien het weg. Dat is later belangrijk, want het hangt direct samen met of WebRTC lekt.
Kijk goed naar de authenticatiemethode. Inloggen met gebruikersnaam en wachtwoord is handig, maar de inloggegevens die in de extensie worden bewaard, staan lokaal in platte tekst of met zwakke versleuteling, zodat anderen achter dezelfde computer ze kunnen lezen; authenticatie via een IP-allowlist bewaart niets in de extensie, maar dan moet je de lijst bij elke netwerkwijziging opnieuw bijwerken.
Het bereik is de plek waar het meest misgaat. In de regelmethode gaan domeinen die op geen enkele regel passen standaard direct naar buiten, en je weet niet altijd welke domeinen een pagina werkelijk opvraagt. Zodra een HTTPS-site de verbinding heeft opgezet, ziet de extensie alleen het domein en niet het exacte pad, dus het idee om op pad te splitsen is in de praktijk niet haalbaar.
Kijk ook naar de omvang van de rechten. Als een proxy-extensie daarnaast toegang vraagt tot gegevens van alle websites, tabbladinformatie of het klembord, vraag je dan af of die rechten iets te maken hebben met de functie die ze zegt te bieden. Ook de manifestversie-upgrades van browserextensies beperken de beschikbare interfaces verder, waardoor sommige oudere extensies hun architectuur hebben moeten aanpassen.
Voor onderhoudsactiviteit moet je niet kijken naar het aantal changelog-regels, maar of iemand de wijzigingen stroomopwaarts bijhoudt. Onder de proxy-extensies is de winkelversie van Proxy SwitchyOmega verwijderd, en een door de community onderhouden fork (zoals de ZeroOmega-lijn) nam de verdere aanpassing over; extensies zoals FoxyProxy hebben versies voor meerdere browsers. Dit zijn slechts neutrale voorbeelden; welke het beste past, hangt nog steeds van de bovenstaande punten af.
Het verkeer dat er niet onder valt
Na installatie loopt de browser zelf via de proxy, maar andere programma's op dezelfde computer, achtergrondupdatediensten en een deel van het verkeer binnen de browser dat het verzoekpad van de extensie niet volgt, kunnen nog steeds via de lokale machine naar buiten gaan. Netwerkconsistentie controleer je niet alleen in het extensiepaneel. Voor volledige isolatie moet je bij de systeemproxy of hogerop ingrijpen.
Zelftest: eerst de uitgang, dan lekken
De eerste stap is het uitgaande IP controleren. Open een paar pagina's die het bezoekers-IP en de locatie teruggeven, controleer één keer in een gewoon venster en één keer in een tabblad dat op je regels past, en vergelijk of de resultaten overeenkomen. Als een regel een proxy aangeeft en je krijgt nog steeds het lokale adres, dan werkt de regel niet of kwam het domein niet overeen. Door meerdere sites te testen ontdek je gevallen waarin slechts een deel van de verzoeken via de proxy loopt.
De tweede stap is WebRTC controleren. Speciale testpagina's tonen de lokale kandidaatadressen en de openbare kandidaatadressen die de browser verkrijgt; staat bij de openbare adressen je echte IP in plaats van de proxy-uitgang, dan loopt UDP niet via de proxy en kunnen paginascripts je werkelijke netwerklocatie nog steeds achterhalen.
De derde stap is DNS controleren. Als de locatie van de DNS-resolver heel ver van de locatie van de uitgang ligt, beschouwen sommige sites de omgeving als afwijkend.
De laatste stap is opnieuw testen in een incognitovenster. Veel extensies zijn standaard niet actief in de incognitomodus en moeten in de instellingen handmatig worden toegestaan; wie deze stap vergeet, trekt volledig verkeerde conclusies.
Bepaal het gebruik na de test
Zelftestresultaten zijn betrouwbaarder dan de documentatie van een extensie. Pas als de echte uitgang, de locatie van de DNS-resolutie en de WebRTC-blootstelling op één lijn liggen, besluit je of je de extensie blijft gebruiken of de uitgang naar een lager niveau verplaatst. Bij meerdere omgevingen naast elkaar kun je elke omgeving het beste een eigen, vaste uitgang geven, in plaats van één uitgang te delen met meerdere machines.
