407 Proxy Authentication Required: what it means and how to fix it

• No credentials sent. The client knows the proxy's host and port but not the login. Some settings screens have nowhere to enter a proxy username and password (Android's Wi-Fi proxy screen, for example), so apps that rely on them can't sign in.
• A wrong username or password. A typo, a space picked up when copying, or credentials from another account or product.
• Special characters in the password. Characters such as @, :, / and # break a proxy URL unless they are percent-encoded (@ becomes %40).
• Credentials sent to the site instead of the proxy. In curl, -u logs in to the website; the proxy login goes in the -x URL or in --proxy-user. In Python requests, auth= is for the site too.
• A hand-edited username. Many proxy services put targeting options in the username, so one typo there makes the whole login invalid.
• The wrong host or port for those credentials, such as one product's username sent to another product's gateway.
• A client that drops the login on HTTPS tunnels. Java's built-in HTTP client, for example, disables Basic authentication for CONNECT tunnels by default (the jdk.http.auth.tunneling.disabledSchemes system property), so HTTPS requests get a 407 while plain HTTP ones work.

A 407 always comes from a proxy. HTTP keeps the two logins apart: a website that wants you to sign in answers 401 Unauthorized with a WWW-Authenticate header, while a proxy answers 407 with Proxy-Authenticate. If you see 407, look at your proxy settings, not at the site.

How it shows up depends on the URL. For an https:// URL, the 407 is the reply to the CONNECT request your client sends to open a tunnel: curl prints it right after the CONNECT line in its verbose output, and Python requests raises a ProxyError instead of returning a response. For a plain http:// URL, the 407 comes back as an ordinary response with status 407.

Because the proxy forwarded nothing, a 407 tells you nothing about the website. The site never saw the request.

1. Copy the line again. Take the host, port, username and password straight from your dashboard or API response instead of retyping them, and check for spaces at either end.
2. Test the line on its own. Send one request with curl to a simple endpoint such as https://api.ipify.org (examples below). If that works, the line is fine and the problem is in how your app passes the credentials.
3. Encode special characters. Percent-encode reserved characters in the proxy URL, or pass the username and password separately: curl's --proxy-user, or your tool's proxy username and password fields.
4. Put the credentials on the proxy, not on the request. Use the proxy URL or the tool's proxy login settings, not a site login or a header you add yourself.
5. Match the protocol. An HTTP proxy line needs an http:// proxy URL in your client. A failed SOCKS5 login is not a 407 at all: SOCKS5 has its own username and password exchange (RFC 1929), so the client reports a SOCKS error instead.
6. Check that your client can sign in to a proxy. If an app or device has no place for a proxy username and password, it can't use a line that needs them.

Don't retry a 407 in a loop. The same credentials get the same answer, so fix the login first.

# Proxy login inside the proxy URL (-x). -v shows the CONNECT exchange with the proxy.
curl -v -x "http://USERNAME:PASSWORD@HOST:PORT" https://api.ipify.org

# Or keep the login out of the URL, so characters such as @ and # need no encoding
curl -v -x "http://HOST:PORT" --proxy-user "USERNAME:PASSWORD" https://api.ipify.org

# Wrong: -u logs in to the website, not the proxy, so the proxy still answers 407
curl -x "http://HOST:PORT" -u "USERNAME:PASSWORD" https://api.ipify.org

from urllib.parse import quote

import requests

username = quote("USERNAME", safe="")
password = quote("PASSWORD", safe="")  # percent-encodes @ : / # and other reserved characters
proxy = f"http://{username}:{password}@HOST:PORT"

try:
    r = requests.get(
        "https://api.ipify.org?format=json",
        proxies={"http": proxy, "https": proxy},
        timeout=30,
    )
    print(r.status_code, r.text)
except requests.exceptions.ProxyError as err:
    # On an https:// URL a 407 arrives here: the proxy refused the CONNECT request
    print("The proxy refused the request:", err)

Headless browsers usually take the proxy login as separate settings rather than inside the proxy URL. In Playwright it goes in the proxy option:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        "server": "http://HOST:PORT",
        "username": "USERNAME",
        "password": "PASSWORD",
    })
    page = browser.new_page()
    page.goto("https://api.ipify.org")
    print(page.text_content("body"))
    browser.close()

BuyProxy authenticates every request by the username and password in your proxy line. The username also carries the line's settings: in the docs example user-country-us, the country-us part is the targeting, and a sticky line adds a session ID to the username (on Premium Residential, the session length too). That makes the username easy to break by hand. To change the country or the session, generate a new line with the settings you want instead of editing an old one. Sticky sessions shows how sessions are written into a line.

The host and port depend on the product: Premium Residential lines, for example, use a different host and port from Core Residential lines. Keep each username with its own host and port. Each line is either HTTP, which also carries HTTPS, or SOCKS5, and SOCKS5 lines use their own port, shown on the line.

Rotating and sticky lines sign in the same way. If a line that worked starts returning 407, copy it again from the dashboard. If it still fails, contact support with the time it happened and the line's host and port. Never send your password.