407 Proxy Authentication Required: che cosa significa e come risolverlo

Riceve HTTP 407 da un proxy? Capisca che cosa significa Proxy Authentication Required, poi controlli credenziali, allowlist IP e caratteri speciali nella password.

Ha impostato un proxy, ha inviato una richiesta e ha ricevuto 407 Proxy Authentication Required al posto di una pagina. Questa guida è per chi usa un proxy a pagamento in un browser, in uno scraper o in uno script e deve capire perché il proxy continua a rifiutarlo. Esaminiamo le cause nell'ordine in cui di solito compaiono. Top Proxy confronta servizi proxy; non vendiamo IP né diamo credenziali gratuite, quindi ogni esempio sotto usa valori placeholder.

01Che cosa significa 407 Proxy Authentication Required#

HTTP 407 è una challenge di autenticazione del proxy. MDN lo descrive come una richiesta fallita perché «manca di credenziali di autenticazione valide per il server proxy» (MDN, 407). Lo status è definito in RFC 9110, sezione 15.5.8.

Lo scambio funziona così. Il proxy risponde con 407 e un header Proxy-Authenticate che nomina lo schema che si aspetta, per esempio:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy"

Il client dovrebbe poi ripetere la richiesta con un header Proxy-Authorization che porta le credenziali. Questo significa che un singolo 407 non è automaticamente un fallimento: alcuni client inviano la prima richiesta senza credenziali, ricevono la challenge e poi ritentano con esse. Il problema è un 407 che continua a tornare dopo che il client ha risposto alla challenge, o un client che non la risponde mai.

Aiuta a distinguere 407 dal suo sosia, 401:

Un 401 di solito significa che la destinazione vuole un login proprio. È un indizio, non una prova, che il login del proxy ha funzionato. Allo stesso modo, un 407 le dice quale tipo di autenticazione è stato chiesto, ma il solo codice di stato non prova fino a dove è arrivata la richiesta. Qualsiasi intermediario sul percorso può restituire 407, compreso un proxy aziendale davanti a quello che ha configurato. Se la risposta non assomiglia a quella del suo fornitore, controlli se la rete instrada prima il traffico attraverso un altro proxy.

Alcuni client non mostrano affatto il numero. Un browser può aprire una finestra di login per il proxy, e una libreria può sollevare un errore che parla di tunnel fallito e 407. La causa è la stessa.

02Cause comuni a colpo d'occhio#

La maggior parte dei 407 persistenti si riduce a una lista corta di problemi. Usi questa tabella per scegliere da dove partire, poi legga la sezione corrispondente.

I fornitori trattano i piani scaduti in modo diverso: alcuni restituiscono 407, altri un altro errore o una connessione chiusa, quindi tratti l'ultima riga come qualcosa da escludere.

03Controlli prima username e password#

La causa più comune è la più semplice: il proxy non ha ricevuto le credenziali che si aspettava. Le esamini in ordine.

1. Copi le credenziali di fresco. Prenda username e password del proxy dalla dashboard del fornitore, non da un appunto vecchio. Molti fornitori emettono credenziali proxy separate, diverse dal login della dashboard.
2. Attenzione agli spazi bianchi di troppo. Uno spazio o un a capo in coda copiati con la password sono invisibili ma rendono le credenziali sbagliate.
3. Ricostruisca lo username se porta opzioni. Molti fornitori residenziali e mobili codificano il targeting nello username, per esempio un codice paese o un token di sessione. La sintassi è specifica del fornitore; un separatore sbagliato o un valore non supportato possono far rifiutare il login. Usi il formato della documentazione del suo fornitore, non uno copiato da un altro servizio.
4. Confermi che host e porta coincidano con le credenziali. Alcuni fornitori usano gateway o porte diverse per prodotti diversi, e le credenziali di uno possono non funzionare sull'altro.
5. Confermi come il client autentica. Alcune app non hanno un campo username o password. Possono comunque autenticarsi tramite impostazioni di sistema o un metodo negoziato come quello delle reti aziendali, oppure supportare le credenziali solo per alcuni tipi di proxy. Controlli nella documentazione del client quali metodi di autenticazione proxy supporta prima di assumere che possa o non possa rispondere alla challenge.

Per vedere che cosa succede sul filo, curl è un test rapido. Con valori placeholder:

curl -q -v --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy http://proxy.example.net:8000 \
  --proxy-user 'USERNAME:PASSWORD' \
  https://example.com/

-q deve stare per primo; fa ignorare a curl eventuali default di .curlrc che potrebbero cambiare il test. --noproxy '' sovrascrive un'impostazione NO_PROXY che altrimenti manderebbe la richiesta attorno al proxy, e i due timeout tengono il test delimitato. Il flag -v stampa gli header di richiesta e risposta, così può vedere il 407 insieme all'header Proxy-Authenticate del proxy e, per molti metodi, se curl ci ha risposto. curl usa Basic come metodo di autenticazione proxy di default, e --proxy-anyauth gli dice di scegliere un metodo adatto se il proxy ne chiede un altro (manuale curl).

Due cautele. L'output verbose può contenere credenziali encoded, cookie e token, quindi mascheri Proxy-Authorization, Cookie e qualsiasi valore di token prima di condividere un log. E una password digitata sulla riga di comando può finire nella history della shell ed è visibile per un attimo nella process list, come avverte il manuale di curl; espandere una variabile d'ambiente nell'argomento non cambia questo. Per qualsiasi cosa oltre un test usa e getta, usi l'ingresso credenziali protetto del suo strumento, per esempio un file di configurazione che può leggere solo lei.

Questo test tiene la verifica TLS normale. Non le serve -k né alcuno switch «insecure» per fare debug di un 407; disabilitare la verifica non sistema l'autenticazione del proxy e nasconde solo problemi veri.

04Allowlist IP e un IP esterno che è cambiato#

Molti fornitori offrono un altro modo di autenticarsi: registri il suo indirizzo IP pubblico e il proxy accetta le connessioni da lì senza password. Alcuni fornitori le fanno anche combinare con username e password, o applicano metodi diversi per endpoint. L'allowlist ha un modo di fallire che produce esattamente il rifiuto «ieri funzionava». A seconda del fornitore, quel rifiuto può essere un 407, un 403, una connessione caduta o un altro errore.

Il proxy vede l'IP da cui arriva la connessione, non l'indirizzo che il computer mostra sulla propria scheda di rete. Quell'IP di origine dipende dal percorso verso il proxy:

• Connessioni di casa e mobili spesso ricevono un nuovo IP pubblico dopo un riavvio del router, una riconnessione, o semplicemente col tempo.
• NAT e carrier-grade NAT significano che il fornitore vede l'indirizzo pubblico condiviso, non il suo 192.168.x.x o 10.x.x.x locale.
• Una VPN, una rete aziendale o un altro proxy davanti al fornitore cambia l'IP di origine nell'uscita di quella rete.
• IPv4 contro IPv6. Se ha messo in allowlist un indirizzo IPv4 ma la connessione raggiunge il fornitore su IPv6, o il contrario, il proxy potrebbe non riconoscerla. Se questo si applica dipende da se il gateway del fornitore accetta IPv6.

Per controllare, apra Il mio IP con il proxy spento in quel browser e confronti l'indirizzo che mostra con l'allowlist del fornitore. La pagina mostra l'IP di quella sola richiesta da quel solo browser. Se lo script gira su un server, dentro un container o attraverso una VPN, il suo IP di origine può differire, quindi controlli dalla stessa macchina e dallo stesso percorso di rete che usa il client che fallisce.

Se è passata dall'allowlist a una password, o il contrario, controlli anche che l'endpoint che sta usando si aspetti il metodo che sta inviando ora.

05Caratteri speciali nella password#

Le password con simboli come @, :, /, #, % o ? sono una fonte frequente di 407 che sembra casuale: le stesse credenziali funzionano in un tool e falliscono in un altro. Questi caratteri hanno significato dentro un URL, e molti strumenti prendono il proxy come un URL unico del tipo http://user:password@host:port.

Prenda la password placeholder p@ss:w/rd%#1. Dentro un URL proxy, la @ può essere letta come fine delle credenziali, e /, # o % possono tagliare o corrompere il resto. Come un : letterale nella password viene trattato varia tra i parser URL. Poiché il comportamento dei parser differisce, la regola sicura è fare il percent-encoding di ogni carattere riservato in username e password prima di metterli in un URL.

La correzione dipende da come lo strumento prende le credenziali:

Non faccia il percent-encoding alla cieca ovunque. Se fa il percent-encoding di una password e poi la digita in un campo password separato, il proxy riceve %40 invece di @ e la rifiuta.

curl. Il manuale dice che utente e password nella stringa del proxy sono URL-decoded, quindi può passare @ come %40 e i due punti come %3a (manuale curl). Con la password placeholder sopra:

curl -q --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy 'http://USERNAME:p%40ss%3Aw%2Frd%25%231@proxy.example.net:8000' \
  https://example.com/

In alternativa, tenga pulito l'URL del proxy e passi le credenziali a parte con --proxy-user, quotando il valore tra apici singoli così la shell non interpreta caratteri come $, ! o #. La stessa cautela sull'esposizione in riga di comando di sopra vale per entrambe le forme.

Python. Faccia il percent-encoding di ciascuna parte con la libreria standard, poi costruisca l'URL:

from urllib.parse import quote
import requests

username = "USERNAME"
password = "p@ss:w/rd%#1"  # placeholder; load the real one from a secret store

proxy = (
    f"http://{quote(username, safe='')}:{quote(password, safe='')}"
    "@proxy.example.net:8000"
)

try:
    response = requests.get(
        "https://example.com/",
        proxies={"http": proxy, "https": proxy},
        timeout=(10, 30),  # connect timeout, read timeout
    )
    print(response.status_code)
except requests.exceptions.ProxyError:
    # Could be a 407 on the tunnel, a refused port, or another proxy failure
    print("Proxy connection failed; check the proxy address, auth, and allowlist.")

quote(..., safe='') trasforma la password placeholder in p%40ss%3Aw%2Frd%25%231, e requests decodifica username e password dall'URL del proxy prima di costruire l'header. Per una destinazione HTTPS, la challenge del proxy avviene mentre si apre il tunnel, quindi un 407 lì di solito emerge come ProxyError prima che esista un oggetto response. ProxyError però non è specifico dell'autenticazione: anche una porta proxy chiusa o sbagliata lo solleva, quindi il messaggio resta generico. L'esempio stampa quel messaggio breve invece dell'eccezione grezza, che può includere l'URL del proxy con le credenziali. I valori di timeout limitano il connect e l'attesa tra le letture; non sono un tetto sulla durata totale della richiesta. La verifica dei certificati resta accesa (il default) e non c'è un loop di retry: ritentare con le stesse credenziali non sistema un 407.

Che cosa abbiamo visto in un test controllato

Per controllare questi comportamenti, abbiamo eseguito Python Requests 2.34.2 su Python 3.14.4 contro un proxy di test locale sulla stessa macchina, usando credenziali dummy (demo con una password che contiene @, :, /, #, %) e verifica TLS accesa. Questo mostra come si comportano client e protocollo, non come performa un fornitore commerciale.

In questo test, l'helper HTTPProxyAuth ha autenticato le richieste HTTP in chiaro ma non il tunnel HTTPS, quindi per HTTPS metta le credenziali encoded nell'URL del proxy.

06Verifichi la correzione#

Parta dal controllo proxy. Inserisca i dati del proxy: lo strumento si collega dal nostro server e segnala se l'endpoint risponde. Legga il risultato con due avvertenze. Primo, il controllo si collega dal proprio IP, non dal suo. Se il fornitore usa l'allowlist IP e l'IP del controllo non è autorizzato, il check può essere rifiutato con un 407, un 403, una connessione caduta o un altro errore, e questo da solo non significa che la sua impostazione sia rotta. Secondo, un check riuscito mostra che l'endpoint ha accettato quelle credenziali dalla posizione del controllo. Non prova che il suo browser o lo script passino dal proxy.

Per la seconda parte, esegua il test curl dalla macchina con il problema, poi visiti Il mio IP attraverso il proxy configurato. Confronti l'IP che vede con l'IP di uscita, il range o l'endpoint che il fornitore dice che dovrebbe ottenere. Un IP diverso da solo non è prova del percorso giusto (anche una VPN lo cambierebbe), e un IP invariato da solo non prova che il proxy sia stato bypassato; lo confronti con l'uscita attesa e con il percorso che prende il client. Nemmeno paese o località da soli bastano, perché un proxy può uscire nel suo stesso paese.

Se il controllo passa ma il client riceve ancora 407, guardi che cosa differisce tra i due percorsi: l'IP di origine e la versione IP, l'endpoint e la porta, il metodo di autenticazione, come il client tratta i caratteri speciali, o un altro proxy sulla sua rete che risponde per primo.

07Quando è il momento di guardare un altro fornitore#

Se ha escluso le cause sopra e continua a perdere tempo su sintassi username non documentata o su setup di credenziali confusi, può valere la pena confrontare servizi che documentano con chiarezza le opzioni di auth. Può sfogliare i servizi di proxy mobili o partire da queste schede del catalogo. Elencarli qui non significa che li abbiamo testati contro il suo client specifico.

Bright Data — proxy residenziali e datacenter4.41442

Bright Data è una grande rete proxy per la raccolta dati: IP residenziali, mobile, ISP e datacenter in circa 195 paesi. Il traffico residenziale si può pagare a consumo senza abbonamento, e gli indirizzi datacenter e ISP arrivano in pacchetti da 10 IP. L'accesso residenziale e mobile richiede la verifica dell'identità.

10 paesi

5,00 USD

per 1 GB

Oxylabs — proxy residenziali e datacenter4.0771

Oxylabs vende proxy residenziali, mobile, ISP e datacenter sotto un unico abbonamento mensile da $30. Pagamenti: carte, bonifico, AliPay, PayPal.

10 paesi

0,45 USD

per 1 GB

SOAX — proxy residenziali e mobile3.8218

SOAX vende proxy residenziali e mobile a rotazione su un pool di crediti condiviso, con datacenter e ISP negli stessi piani. Il Builder parte da $200/mese + IVA (200 crediti); il traffico Tier 1 è $3/GB sul Builder.

85 paesi

3,00 USD

per 1 GB

Decodo (Smartproxy) — proxy residenziali e datacenter4.22118

Decodo (ex Smartproxy) vende proxy residenziali e datacenter. Residenziali: $4/GB senza piano mensile, o pacchetti mensili da $3.75/GB per 3 GB. Pagamenti: carte, PayPal, Alipay, Google/Apple Pay, crypto (con limiti).

83 paesi

0,38 USD

per 1 GB

08FAQ#