407 Proxy Authenticatie Vereist: Elke Oorzaak en Hoe het op te Lossen

HTTP 407 heeft precies één betekenis: de proxy voor je weigerde je inloggegevens. Dat enkele feit elimineert de meeste verkeerde afslagen — hier is de rest van de kaart.

HTTP 407 Proxy Authenticatie Vereist heeft precies één betekenis, en het is beperkter dan de meeste mensen aannemen: een proxy tussen jou en het internet weigerde het verzoek omdat het geen geldige inloggegevens voor de proxy zelf heeft. De doelwebsite werd nooit benaderd. Het heeft je verzoek nooit gezien, nooit een beslissing genomen, en kan niet de oorzaak zijn. Het oplossen van een 407 betekent daarom altijd het oplossen van je proxyconfiguratie — en de lijst van dingen die daarmee mis kunnen zijn is kort en volledig opsombaar. Deze gids loopt de hele lijst door, met de tool-specifieke oplossingen die mensen het meest in de war brengen.

Lees eerst de Proxy-Authenticate header

Volgens de HTTP-specificatie (RFC 9110) moet een 407 vergezeld gaan van een Proxy-Authenticate header die beschrijft hoe te authenticeren — meestal iets als Proxy-Authenticate: Basic realm="Access to internal site". Je client wordt dan verwacht het verzoek te herhalen met een Proxy-Authorization header. Dat paar is het waard om te onthouden, omdat het is wat 407 onderscheidt van zijn buur: een 401 komt van de oorspronkelijke server en koppelt WWW-Authenticate met Authorization, terwijl 407 van een tussenpersoon komt en de Proxy- voorvoegsels gebruikt. Als je naar een WWW-Authenticate header staart, ben je de verkeerde stap aan het debuggen.

# See exactly which hop is refusing you, and what scheme it wants
curl -v -x http://USER:PASS@gate.quantumproxies.io:8000 https://httpbin.org/ip

# Response you are looking for on failure:
#   HTTP/1.1 407 Proxy Authentication Required
#   Proxy-Authenticate: Basic realm="..."
#
# Response you want on success: your exit IP, not your own
#   {"origin": "203.0.113.45"}

Als curl -x met inloggegevens je exit-IP retourneert, zijn de proxy en de inloggegevens beide in orde — en elke 407 die je nog steeds in een applicatie ziet, is de eigen configuratie van die applicatie, niet die van de proxy. Die enkele test splitst het probleem in tweeën in ongeveer tien seconden.

Oorzaak 1: de inloggegevens ontbreken, zijn verkeerd, of staan op de verkeerde plaats

De meest voorkomende oorzaak is ook de saaiste. Inloggegevens horen in de proxy-URL, voor de host, in user:pass@host:port vorm — en de clientbibliotheek bouwt de Proxy-Authorization header ervan. Het kopiëren van een endpoint van een dashboard zonder de inloggegevens, of het plakken van je accountwachtwoord in plaats van het proxywachtwoord (ze zijn meestal verschillend), levert een onmiddellijke, permanente 407 op bij elk verzoek.

import requests

proxy = "http://USER:PASS@gate.quantumproxies.io:8000"
proxies = {"http": proxy, "https": proxy}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(r.status_code, r.json())   # 200 and the exit IP = auth is correct

Controleer ook de poort. Providers stellen verschillende poorten bloot voor roterende en vaste endpoints, en voor HTTP versus SOCKS5; de verkeerde raken met geldige inloggegevens kan nog steeds 407 retourneren omdat die luisteraar een ander identiteitsformaat verwacht. Als je niet zeker weet welk protocol je gebruikt, legt onze uitleg over SOCKS5 versus HTTP proxies de verschillen uit.

Oorzaak 2: speciale tekens die nooit percent-gecodeerd zijn

Deze kost mensen hele middagen. Een proxy-URL is een URL, dus elk gereserveerd teken in je gebruikersnaam of wachtwoord moet percent-gecodeerd zijn of de parser zal de string op de verkeerde plaats splitsen. Een wachtwoord met @ beëindigt de userinfo-sectie vroeg en je client probeert verbinding te maken met een host die niet bestaat; een : splitst gebruikersnaam van wachtwoord op de verkeerde plek.

from urllib.parse import quote

user = quote("team@example.com", safe="")   # team%40example.com
pwd  = quote("p@ss:w#rd", safe="")          # p%40ss%3Aw%23rd

proxy = f"http://{user}:{pwd}@gate.quantumproxies.io:8000"
Checklist die 407 proxy authenticatie vereist symptomen koppelt aan hun echte oorzaken, inclusief tunnelstoringen, whitelist-wijzigingen en proxy-instellingen per tool
Dezelfde statuscode, zes verschillende fouten. Match het symptoom aan de linkerkant voordat je iets verandert.

Oorzaak 3: whitelist-authenticatie en een IP dat is verplaatst

De meeste providers ondersteunen twee authenticatiemodi: inloggegevens in de URL, of IP-whitelisting, waarbij je het openbare adres van je server autoriseert in het dashboard en helemaal geen inloggegevens verzendt. QuantumProxies ondersteunt beide. De faalmodus is specifiek en zeer herkenbaar: alles werkte wekenlang, toen begon elk verzoek 407 te retourneren zonder een codewijziging. Dat is je openbare IP dat verandert — een DHCP-leasevernieuwing op kantoor, een nieuwe NAT-gateway na een cloud-herimplementatie, een mobiele tether, of een CI-runner die bij elke taak een nieuw adres krijgt.

Bevestig dat voordat je iets anders debugt: haal je huidige openbare adres op met curl -sS https://api.ipify.org, vergelijk het met de whitelist, en voeg het opnieuw toe als het verschilt. Als je uitgaande IP niet stabiel is — CI-runners en autoscaling-groepen zijn dat zelden — schakel die omgeving dan over naar user:pass authenticatie, die meereist met de configuratie in plaats van het netwerk. De andere helft van deze val is het mixen van modi: sommige gateways weigeren inloggegevens op een alleen-whitelist-endpoint, dus het verzenden van beide kan mislukken waar het verzenden van geen van beide slaagt.

Oorzaak 4: HTTPS gaat door een CONNECT-tunnel

Een 407 die alleen verschijnt op https:// URL's, vaak als de Python-fout OSError: Tunnel connection failed: 407 Proxy Authentication Required, heeft een structurele oorzaak. Gewone HTTP-verzoeken worden door de proxy doorgegeven, maar HTTPS-verzoeken openen eerst een tunnel met een CONNECT verzoek — en die CONNECT draagt zijn eigen Proxy-Authorization header. Als je configuratie alleen een HTTP-proxy heeft ingesteld, of inloggegevens op één schema en niet op de andere, wordt de tunnel anoniem geprobeerd en geweigerd voordat TLS zelfs begint.

De regel is simpel: configureer altijd beide schema's met dezelfde inloggegevens. In Python betekent dat beide sleutels in de proxies dict; in de shell betekent het HTTP_PROXY en HTTPS_PROXY; in npm betekent het proxy en https-proxy. Let op dat HTTPS_PROXY bijna altijd een http:// schema gebruikt — het schema beschrijft hoe je met de proxy praat, niet wat je erdoorheen haalt.

// Node 18+ with undici: one dispatcher covers http and https targets
import { ProxyAgent, fetch } from "undici";

const dispatcher = new ProxyAgent(
  "http://USER:PASS@gate.quantumproxies.io:8000"
);

const res = await fetch("https://httpbin.org/ip", { dispatcher });
console.log(res.status, await res.json());

Oorzaak 5: de tool heeft zijn eigen proxyconfiguratie

Omgevingsvariabelen zijn niet universeel. Veel tools lezen hun eigen configuratiebestand en negeren de shell volledig, wat de gekmakende toestand produceert waarin curl werkt en je build niet. Een langlopend GitHub Desktop-probleem is de schoolvoorbeeld: een ontwikkelaar achter een bedrijfsproxy had de proxy ingesteld in .gitconfig en in de omgeving, maar aanmelden mislukte nog steeds met een 407 en net::ERR_TUNNEL_CONNECTION_FAILED — omdat de git-configuratie alleen git authenticeerde, terwijl de ingesloten browser die de OAuth-stroom deed geen eigen proxy-inloggegevens had. Elk subsysteem moet afzonderlijk worden geïnformeerd.

# shell-wide (respected by curl, wget, pip, most SDKs)
export HTTP_PROXY="http://USER:PASS@gate.quantumproxies.io:8000"
export HTTPS_PROXY="$HTTP_PROXY"
export NO_PROXY="localhost,127.0.0.1,.internal"

# npm - both keys, or https installs will 407
npm config set proxy       "$HTTP_PROXY"
npm config set https-proxy  "$HTTPS_PROXY"

# git
git config --global http.proxy  "$HTTP_PROXY"
git config --global https.proxy "$HTTPS_PROXY"

# apt - /etc/apt/apt.conf.d/95proxies
# Acquire::http::Proxy  "http://USER:PASS@gate.quantumproxies.io:8000";
# Acquire::https::Proxy "http://USER:PASS@gate.quantumproxies.io:8000";

Eén beveiligingsopmerking terwijl je al deze bestanden aan het bewerken bent: inloggegevens in een globale git- of npm-configuratie eindigen in platte tekst, en proxy-URL's met ingebedde wachtwoorden lekken in shell-geschiedenis, CI-logs en fouttraceringen. Op machines met een stabiel adres vermijdt IP-whitelisting het geheim volledig.

Vergelijking van user:pass proxy authenticatie versus IP-whitelist authenticatie, met de portabiliteits- en geheimverwerking-afwegingen
Inloggegevens reizen mee met je configuratie; whitelists reizen mee met je netwerk. Kies per omgeving, nooit beide tegelijk.

Een 407 is nooit de fout van de doelwebsite

Het is het waard om te herhalen, omdat het je bespaart van het najagen van spoken. Als je 407's krijgt, zal geen enkele hoeveelheid roterende user agents, het toevoegen van headers of het veranderen van exit-landen helpen — het verzoek heeft je proxy nog niet verlaten. Blokkades die van de doelwebsite komen zien er anders uit: een 403 Forbidden betekent dat de site je weigerde, en een 429 Too Many Requests betekent dat je te snel ging. Diagnoseer welke van de drie je daadwerkelijk hebt voordat je code schrijft. En als Python ProxyError of SSLError gooit in plaats van een schone 407, behandelt onze gids voor debuggen van ProxyError in Requests de transportlaag-fouten.

Veelgestelde vragen

Hoe los ik 407 Proxy Authenticatie Vereist op?

Plaats geldige inloggegevens in de proxy-URL als http://user:pass@host:port, percent-encode alle gereserveerde tekens, en configureer zowel de HTTP- als HTTPS-proxy-instellingen. Als je provider in plaats daarvan IP-whitelisting gebruikt, autoriseer dan je huidige openbare IP en stuur geen inloggegevens. Verifieer met curl -x tegen een IP-echo-service voordat je je applicatiecode aanraakt.

Wat betekent 407 Proxy Authenticatie Vereist?

Het betekent dat een tussenliggende proxy het verzoek weigerde vanwege het ontbreken van geldige proxy-inloggegevens. De reactie bevat een Proxy-Authenticate header die het schema benoemt, en de client wordt verwacht opnieuw te proberen met Proxy-Authorization. Het is anders dan 401, dat komt van de bestemmingsserver in plaats van de proxy ertussen.

Hoe los ik npm fout 407 op?

Stel beide sleutels in: npm config set proxy en npm config set https-proxy, elk met de volledige http://user:pass@host:port URL. Registry-verkeer is HTTPS, dus een alleen-HTTP-instelling faalt bij de CONNECT-tunnel. Percent-encode speciale tekens in het wachtwoord, en controleer op een projectniveau .npmrc dat je globale overschrijft.

Waarom geeft Python Tunnel connection failed: 407?

Omdat het HTTPS-verzoek een CONNECT-tunnel opende die geen proxy-inloggegevens droeg. Stel zowel de http als https sleutels van de proxies dict in op dezelfde geauthenticeerde URL. Controleer ook of HTTP_PROXY of HTTPS_PROXY in de omgeving je dict overschrijft — stel session.trust_env = False in om dat uit te sluiten.

Hoe stel ik proxy-authenticatie in Postman in?

Open Instellingen, ga naar het Proxy-tabblad, schakel de aangepaste proxyconfiguratie in, voer host en poort in, vink dan het proxy-auth vakje aan en voeg de gebruikersnaam en het wachtwoord toe. Vertrouwen op de systeemproxy-schakelaar is de gebruikelijke fout — het leidt verkeer door de proxy maar levert nooit inloggegevens, dus elk verzoek retourneert 407.

Vijf oorzaken dekken in wezen elke 407 in het wild: ontbrekende inloggegevens, niet-gecodeerde speciale tekens, een gewhitelist IP dat is veranderd, een niet-geauthenticeerde CONNECT-tunnel, en een tool met zijn eigen configuratie. Werk ze in die volgorde af en de statuscode verdwijnt — dan kun je je zorgen gaan maken over wat de doelwebsite van je vindt.

Krijg residentiële proxies met user:pass of IP-whitelist authenticatie