Als een proxyverbinding mislukt, controleer dan achtereenvolgens de proxydienst, authenticatie en protocol, de clientconfiguratie en de doelsite. Gebruik per stap een duidelijke aanwijzing om eerst de probleemlaag te vinden voordat je instellingen wijzigt.
Nadat je de proxy hebt ingevuld, geeft de testknop een fout. Het slechtste wat je dan kunt doen is instellingen willekeurig wijzigen: een andere poort, een ander protocol of een ander knooppunt kiezen totdat iets werkt, zonder te weten welke wijziging het verschil maakte.
De oorzaken zitten meestal in vier lagen: de proxydienst zelf, authenticatie en protocol, de clientconfiguratie en de doelsite. Controleer ze in die volgorde, van de proxy naar buiten toe.
Test eerst alleen de proxy
Begin niet in een zakelijke tool. Configureer de proxy rechtstreeks in een gewone browser die handmatige proxy-instellingen ondersteunt, of in de proxy-instellingen van het systeem, en controleer of internettoegang werkt. Zo scheid je de proxy van de zakelijke omgeving.
Als de verbinding daar ook mislukt, ligt het probleem bij de proxy zelf: hij kan verlopen of uitgeschakeld zijn, het exit-knooppunt kan defect zijn, of de provider kan toegangsbeperkingen hebben ingesteld. De volgende stappen zijn dan niet nodig; controleer status en verbruik rechtstreeks bij de proxyprovider.
Werkt de proxy daar wel, dan is hij actief. Het probleem zit dan in de configuratie of het verbindingstraject, dus ga verder.
De vuistregel is eenvoudig: werken dezelfde inloggegevens elders wel, dan zijn de inloggegevens zelf waarschijnlijk in orde.
Laat authenticatie en protocol overeenkomen
Zijn de inloggegevens correct maar lukt verbinden nog steeds niet, kijk dan als volgende naar het protocol. Drie veelvoorkomende mismatches zijn: de provider levert SOCKS5 terwijl de omgeving op HTTP staat; je gebruikt een zelfgemaakte SSH-tunnel maar configureert die als SOCKS5; of één proxy ondersteunt meerdere protocollen met verschillende poorten en je hebt de poort van een ander protocol ingevuld.
Gebruik de foutmelding als aanwijzing. Bij een authenticatiefout of onjuiste inloggegevens controleer je gebruikersnaam en wachtwoord. Let op spaties of regeleinden die via kopiëren en plakken zijn meegekomen en controleer of speciale tekens in de gebruikersnaam correct moeten worden escaped. Bij een protocolfout of mislukte handshake controleer je het protocoltype en de poort.
Typ velden zoals gebruikersnaam en wachtwoord een keer handmatig als vergelijking. Onzichtbare tekens kunnen een fout veroorzaken die je niet met het blote oog ziet.
Controleer of de clientconfiguratie echt actief is
Deze stap beantwoordt een minder zichtbare vraag: de instellingen zijn correct, maar zijn ze daadwerkelijk toegepast?
Twee situaties komen vaak voor. Ten eerste is de configuratie helemaal niet toegepast: wijzigingen zijn niet opgeslagen, je hebt een andere omgeving aangepast, of de vorige sessie draait nog. Ten tweede is de configuratie wel actief maar wordt die door andere instellingen overschreven: er kan nog een netwerkschakelaar in de omgeving staan, een extensie kan de proxy zelf overnemen, of proxy-instellingen op systeemniveau kunnen een hogere prioriteit hebben.
Kijk naar het exit-adres. Open na het verbinden een pagina die het huidige uitgaande adres toont. Daar moet het proxyadres staan en niet het lokale adres. Zie je nog steeds het lokale adres, dan loopt het verzoek niet via de proxy, ook al meldt de testknop succes.
De vergelijking is eenvoudig: zet de proxy in dezelfde omgeving één keer aan en één keer uit en kijk of het exit-adres verandert. Verandert het niet, dan zit het probleem aan de clientkant. Als je meerdere omgevingen tegelijk gebruikt, controleer dan elke uitgang afzonderlijk. Tools die omgevingen per account isoleren, zoals PurpleMark, letten precies hierop bij het koppelen van proxies.
Herken weigering door de doelsite
Als alle lagen bereikbaar zijn en de proxy aantoonbaar actief is, maar de zakelijke pagina nog steeds niet opent, kijk dan naar de reactie van de doelsite in plaats van de proxy opnieuw te blijven wijzigen.
Dit soort gevallen heeft meestal duidelijke patronen: de verbinding en handshake slagen, maar het verzoek geeft 403 terug of wordt gereset; de pagina opent, maar acties zoals inloggen of publiceren worden geweigerd; dezelfde exit werkt op andere sites en faalt alleen op deze site; of de fouten zijn onregelmatig, wat kan wijzen op snelheidsbeperkingen op de exit of het verbindingstraject, of op limieten voor gelijktijdige verzoeken.
Het belangrijkste is de verbindingslaag en de zakelijke laag uit elkaar te houden. Als je helemaal niet kunt verbinden, ligt het waarschijnlijk aan de proxy. Kun je wel verbinden maar wordt toegang geweigerd, dan zijn de kwaliteit van de exit of de toegangsfrequentie vaak de oorzaak. Datacenter-IP's en veelgebruikte gedeelde IP's worden op de zakelijke laag eerder geblokkeerd. Residentiële IP's kunnen beter werken, maar zijn geen garantie: verzoekfrequentie, gelijktijdigheid en toegangstijd hebben ook invloed.
Houd drie gewoonten aan bij het oplossen van problemen
Wijzig steeds maar één ding. Als je tegelijk van protocol en knooppunt wisselt, weet je zelfs na een succesvolle verbinding niet welke wijziging het probleem heeft opgelost, en loop je later mogelijk tegen hetzelfde aan.
Eerst vastleggen, daarna aanpassen. Bewaar een werkende configuratie met adres, poort, protocol en authenticatiemethode. Bij het volgende probleem is direct vergelijken veel sneller dan vanaf nul beginnen.
Geef voorkeur aan vergelijkende tests boven steeds opnieuw proberen. Als de configuratie correct lijkt maar de verbinding nog steeds mislukt, levert herhaaldelijk op de testknop drukken geen nieuwe informatie op. Test liever een andere netwerkomgeving of een andere proxy als gecontroleerde vergelijking.
