407 Proxy Authentication Required: co to znaczy i jak to naprawić

HTTP 407 od proxy? Warto zrozumieć, co znaczy Proxy Authentication Required, a potem sprawdzić dane logowania, listę dozwolonych IP oraz znaki specjalne w haśle.

Skonfigurowano proxy, wysłano żądanie, a zamiast strony wróciło 407 Proxy Authentication Required. Ten poradnik jest dla każdego, kto używa płatnego proxy w przeglądarce, scraperze albo skrypcie i musi ustalić, dlaczego proxy wciąż odrzuca. Przyczyny idą w kolejności, w jakiej zwykle się pojawiają. Top Proxy porównuje usługi proxy; nie sprzedajemy adresów IP i nie rozdajemy darmowych danych logowania, więc każdy przykład niżej używa wartości zastępczych.

01Co znaczy 407 Proxy Authentication Required#

HTTP 407 to wyzwanie uwierzytelniania proxy. MDN opisuje je jako żądanie, które się nie udało, bo „lacks valid authentication credentials for the proxy server” (MDN, 407). Status jest zdefiniowany w RFC 9110, sekcja 15.5.8.

Wymiana wygląda tak. Proxy odpowiada 407 i nagłówkiem Proxy-Authenticate, który nazywa oczekiwany schemat, na przykład:

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

Klient ma wtedy powtórzyć żądanie z nagłówkiem Proxy-Authorization niosącym dane logowania. To znaczy, że pojedyncze 407 nie jest automatycznie porażką: część klientów wysyła pierwsze żądanie bez danych, dostaje wyzwanie, a potem ponawia z danymi. Problem to 407, które wraca po odpowiedzi na wyzwanie, albo klient, który na nie nigdy nie odpowiada.

Warto oddzielić 407 od podobnego 401:

401 zwykle znaczy, że cel chce własnego logowania. To wskazówka, nie dowód, że logowanie do proxy zadziałało. Podobnie 407 mówi, jakiego uwierzytelniania zażądano, ale sam kod statusu nie dowodzi, jak daleko zaszło żądanie. 407 może zwrócić dowolny pośrednik na ścieżce, także korporacyjne proxy przed tym skonfigurowanym. Jeśli odpowiedź nie wygląda jak od dostawcy, sprawdzić, czy sieć najpierw prowadzi ruch przez inne proxy.

Część klientów w ogóle nie pokazuje liczby. Przeglądarka może wyskoczyć oknem logowania do proxy, a biblioteka rzucić błąd o nieudanym tunelu i 407. Przyczyna jest ta sama.

02Najczęstsze przyczyny w skrócie#

Większość uporczywych 407 sprowadza się do krótkiej listy problemów. Ta tabela pomaga wybrać, od czego zacząć, a potem przeczytać pasującą sekcję.

Dostawcy różnie obsługują wygasłe plany: jedni zwracają 407, inni inny błąd albo zamknięte połączenie, więc ostatni wiersz trzeba wykluczyć, a nie założyć.

03Najpierw sprawdzić nazwę użytkownika i hasło#

Najczęstsza przyczyna jest najprostsza: proxy nie dostało danych, których oczekiwało. Przejść te punkty w kolejności.

1. Skopiować dane na świeżo. Nazwę użytkownika i hasło proxy wziąć z panelu dostawcy, nie ze starej notatki. Wielu dostawców wydaje osobne dane proxy, inne niż logowanie do panelu.
2. Uważać na zbędne białe znaki. Końcowa spacja albo znak nowej linii skopiowany z hasłem jest niewidoczny, ale czyni dane złymi.
3. Zbudować nazwę użytkownika od nowa, jeśli niesie opcje. Wielu dostawców rezydenckich i mobilnych koduje targetowanie w nazwie użytkownika, na przykład kod kraju albo token sesji. Składnia jest specyficzna dla dostawcy; jeden zły separator albo nieobsługiwana wartość może prowadzić do odrzuconego logowania. Użyć formatu z dokumentacji własnego dostawcy, a nie skopiowanego z innej usługi.
4. Potwierdzić, że host i port pasują do danych. Część dostawców używa różnych bram albo portów dla różnych produktów, a dane jednego mogą nie działać na drugim.
5. Potwierdzić, jak klient się uwierzytelnia. Część aplikacji nie ma pola nazwy użytkownika ani hasła. Mogą nadal uwierzytelniać przez ustawienia systemowe albo negocjowaną metodę, taką jak w sieciach korporacyjnych, albo obsługiwać dane tylko dla niektórych typów proxy. Zanim założy się, że klient potrafi albo nie potrafi odpowiedzieć na wyzwanie, sprawdzić w jego dokumentacji, które metody uwierzytelniania proxy obsługuje.

Żeby zobaczyć, co dzieje się na przewodzie, curl jest szybkim testem. Przy wartościach-placeholderach:

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

-q musi być pierwsze; sprawia, że curl ignoruje domyślne .curlrc, które mogłyby zmienić test. --noproxy '' nadpisuje ustawienie NO_PROXY, które mogłoby inaczej puścić żądanie obok proxy, a dwa limity czasu trzymają test w ryzach. Flaga -v drukuje nagłówki żądania i odpowiedzi, więc widać 407 razem z nagłówkiem Proxy-Authenticate proxy oraz — przy wielu metodach — czy curl na nie odpowiedział. curl używa Basic jako domyślnej metody uwierzytelniania proxy, a --proxy-anyauth każe mu wybrać odpowiednią metodę, jeśli proxy prosi o coś innego (podręcznik curl).

Dwa zastrzeżenia. Wyjście verbose może zawierać zakodowane dane logowania, ciasteczka i tokeny, więc przed udostępnieniem logu zamaskować Proxy-Authorization, Cookie i wszelkie wartości tokenów. Hasło wpisane w wierszu poleceń może trafić do historii powłoki i przez chwilę jest widoczne na liście procesów, jak ostrzega podręcznik curl; rozwinięcie zmiennej środowiska do argumentu tego nie zmienia. Do czegokolwiek poza jednorazowym testem użyć chronionego wejścia danych narzędzia, na przykład pliku konfiguracyjnego czytelnego tylko dla operatora.

Ten test zostawia zwykłą weryfikację TLS. Do debugowania 407 nie potrzeba -k ani żadnego przełącznika „insecure”; wyłączenie weryfikacji nie naprawia uwierzytelniania proxy i tylko ukrywa prawdziwe problemy.

04Lista dozwolonych IP i zmieniony zewnętrzny IP#

Wielu dostawców oferuje inny sposób uwierzytelniania: rejestruje się publiczny adres IP, a proxy przyjmuje z niego połączenia bez hasła. Część dostawców pozwala też łączyć to z nazwą użytkownika i hasłem albo stosować różne metody per punkt końcowy. Lista dozwolonych ma tryb awarii, który daje dokładnie odrzucenie typu „wczoraj działało”. Zależnie od dostawcy to odrzucenie może być 407, 403, zerwanym połączeniem albo innym błędem.

Proxy widzi IP, z którego przychodzi połączenie, nie adres, który komputer pokazuje na własnej karcie sieciowej. Ten źródłowy IP zależy od ścieżki do proxy:

• Połączenia domowe i mobilne często dostają nowy publiczny IP po restarcie routera, ponownym połączeniu albo po prostu z czasem.
• NAT i CGNAT znaczą, że dostawca widzi współdzielony adres publiczny, nie lokalny 192.168.x.x albo 10.x.x.x.
• VPN, sieć korporacyjna albo inne proxy przed dostawcą zmienia źródłowy IP na wyjście tej sieci.
• IPv4 kontra IPv6. Jeśli na liście jest adres IPv4, a połączenie dochodzi do dostawcy po IPv6, albo odwrotnie, proxy może nie rozpoznać. Czy to dotyczy, zależy od tego, czy brama dostawcy przyjmuje IPv6.

Żeby sprawdzić, otworzyć Jaki jest mój adres IP z wyłączonym proxy w tej przeglądarce i porównać pokazany adres z listą dozwolonych u dostawcy. Strona pokazuje IP tego jednego żądania z tej jednej przeglądarki. Jeśli skrypt działa na serwerze, w kontenerze albo przez VPN, jego źródłowy IP może być inny, więc sprawdzać z tej samej maszyny i ścieżki sieci, której używa zawodzący klient.

Jeśli nastąpiło przejście z listy dozwolonych na hasło albo odwrotnie, sprawdzić też, że używany punkt końcowy oczekuje metody, która jest teraz wysyłana.

05Znaki specjalne w haśle#

Hasła ze znakami takimi jak @, :, /, #, % albo ? to częste źródło 407, które wygląda losowo: te same dane działają w jednym narzędziu i zawodzą w innym. Te znaki mają znaczenie wewnątrz URL, a wiele narzędzi bierze proxy jako jeden URL w stylu http://user:password@host:port.

Weźmy hasło-placeholder p@ss:w/rd%#1. Wewnątrz URL proxy @ może zostać odczytane jako koniec danych logowania, a /, # albo % mogą uciąć albo zepsuć resztę. Jak parser URL traktuje literał : w haśle, bywa różne. Ponieważ zachowanie parserów się różni, bezpieczna reguła to percent-encode każdego zastrzeżonego znaku w nazwie użytkownika i haśle, zanim trafią do URL.

Naprawa zależy od tego, jak narzędzie przyjmuje dane:

Nie należy percent-encode wszędzie na ślepo. Jeśli zakoduje się hasło, a potem wpisze je w osobne pole hasła, proxy dostanie %40 zamiast @ i odrzuci.

curl. Podręcznik mówi, że użytkownik i hasło w ciągu proxy są dekodowane z URL, więc @ można podać jako %40, a dwukropek jako %3a (podręcznik curl). Przy haśle-placeholderze powyżej:

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/

Albo zostawić URL proxy czysty i podać dane osobno przez --proxy-user, cytując wartość w pojedynczych cudzysłowach, żeby powłoka nie interpretowała znaków takich jak $, ! albo #. To samo zastrzeżenie o ekspozycji w wierszu poleceń z wyżej dotyczy obu form.

Python. Zakodować każdą część biblioteką standardową, a potem zbudować 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='') zamienia hasło-placeholder w p%40ss%3Aw%2Frd%25%231, a requests dekoduje nazwę użytkownika i hasło z URL proxy, zanim zbuduje nagłówek. Dla celu HTTPS wyzwanie proxy następuje przy otwieraniu tunelu, więc 407 tam zwykle wychodzi jako ProxyError, zanim powstanie jakikolwiek obiekt odpowiedzi. ProxyError nie jest jednak specyficzny dla uwierzytelniania: zamknięty albo zły port proxy też go rzuca, więc komunikat zostaje ogólny. Przykład drukuje ten krótki komunikat zamiast surowego wyjątku, który może zawierać URL proxy z danymi logowania. Wartości timeout ograniczają łączenie i oczekiwanie między odczytami; nie są limitem całkowitego czasu trwania żądania. Weryfikacja certyfikatu zostaje włączona (domyślnie) i nie ma pętli ponowień: ponawianie z tymi samymi danymi nie naprawi 407.

Co zobaczyliśmy w kontrolowanym teście

Żeby sprawdzić te zachowania, odpaliliśmy Python Requests 2.34.2 na Pythonie 3.14.4 wobec lokalnego testowego proxy na tej samej maszynie, z atrapami danych (demo z hasłem zawierającym @, :, /, #, %) i włączoną weryfikacją TLS. To pokazuje zachowanie klienta i protokołu, nie wydajność żadnego komercyjnego dostawcy.

W tym teście pomocnik HTTPProxyAuth uwierzytelnił zwykłe żądania HTTP, ale nie tunel HTTPS, więc dla HTTPS zakodowane dane kłaść w URL proxy.

06Zweryfikować naprawę#

Zacząć od sprawdzania proxy. Po wpisaniu szczegółów proxy narzędzie łączy się z naszego serwera i zgłasza, czy punkt końcowy odpowiada. Wynik czytać z dwoma zastrzeżeniami. Po pierwsze, sprawdzanie łączy się z własnego IP, nie z IP operatora. Jeśli dostawca używa listy dozwolonych IP, a IP sprawdzania nie jest dozwolone, sprawdzenie może zostać odrzucone 407, 403, zerwanym połączeniem albo innym błędem, i samo to nie znaczy, że konfiguracja jest zepsuta. Po drugie, udane sprawdzenie pokazuje, że punkt końcowy przyjął te dane z lokalizacji sprawdzania. Nie dowodzi, że przeglądarka albo skrypt idzie przez proxy.

Do drugiej części uruchomić test curl z maszyny z problemem, a potem odwiedzić Jaki jest mój adres IP przez skonfigurowane proxy. Porównać widziany IP z adresem wyjścia, zakresem albo punktem końcowym, który według dostawcy powinien wyjść. Inny IP sam w sobie nie jest dowodem właściwej trasy (VPN też by go zmienił), a niezmieniony IP sam w sobie nie dowodzi ominięcia proxy; zestawić go z oczekiwanym wyjściem i trasą, którą bierze klient. Sam kraj albo lokalizacja też nie wystarcza, bo proxy może wychodzić we własnym kraju.

Jeśli sprawdzanie przechodzi, a klient nadal dostaje 407, spojrzeć, co różni obie ścieżki: źródłowy IP i wersja IP, punkt końcowy i port, metoda uwierzytelniania, jak klient obsługuje znaki specjalne, albo inne proxy w sieci odpowiadające pierwsze.

07Kiedy warto spojrzeć na innego dostawcę#

Jeśli powyższe przyczyny są wykluczone, a czas nadal ucieka na nieudokumentowaną składnię nazwy użytkownika albo mylącą konfigurację danych, może warto porównać usługi, które jasno dokumentują opcje uwierzytelniania. Można przeglądać usługi proxy mobilnych albo zacząć od tych wpisów katalogu. Wymienienie tutaj nie znaczy, że testowaliśmy którąkolwiek wobec konkretnego klienta.

Bright Data — proxy rezydenckie i datacenter4.41442

Bright Data to duża sieć proxy do zbierania danych: IP rezydenckie, mobilne, ISP i datacenter w około 195 krajach. Ruch rezydencki można płacić na bieżąco bez subskrypcji, a adresy datacenter i ISP przychodzą w pakietach od 10 IP. Dostęp rezydencki i mobilny wymaga weryfikacji tożsamości.

10 krajów

5,00 USD

za 1 GB

Oxylabs — proxy rezydenckie i datacenter4.0771

Oxylabs sprzedaje proxy rezydenckie, mobilne, ISP i datacenter w jednej subskrypcji miesięcznej od $30. Płatności: karty, przelew, AliPay, PayPal.

10 krajów

0,45 USD

za 1 GB

SOAX — proxy rezydenckie i mobilne3.8218

SOAX sprzedaje rotacyjne proxy rezydenckie i mobilne na wspólnej puli kredytów, z datacenter i ISP w tych samych planach. Builder od $200/mies. + VAT (200 kredytów); ruch Tier 1 to $3/GB na Builderze.

85 krajów

3,00 USD

za 1 GB

Decodo (Smartproxy) — proxy rezydenckie i datacenter4.22118

Decodo (dawniej Smartproxy) sprzedaje proxy rezydenckie i datacenter. Rezydenckie: $4/GB bez planu miesięcznego albo pakiety miesięczne od $3.75/GB za 3 GB. Płatności: karty, PayPal, Alipay, Google/Apple Pay, krypto (z ograniczeniami).

83 kraje

0,38 USD

za 1 GB

08FAQ#