How to Handle Proxy Authentication in Selenium Webdriver

HTTP proxies understand web traffic and are commonly configured with separate HTTP and HTTPS values. SOCKS proxies operate at a lower level and can carry different kinds of TCP traffic without interpreting the application protocol. SOCKS5 additionally supports authentication and is usually the preferred SOCKS version.

The browser and proxy provider must support the same method. A valid endpoint does not guarantee that Selenium can complete a native username/password dialog automatically.

For a proxy that does not require interactive authentication, Selenium 4 can assign a Proxy object to ChromeOptions. The current official Selenium browser-options documentation demonstrates this capability-based approach.

import org.openqa.selenium.Proxy;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

Proxy proxy = new Proxy();
proxy.setHttpProxy("proxy.example.test:8080");
proxy.setSslProxy("proxy.example.test:8080");

ChromeOptions options = new ChromeOptions();
options.setProxy(proxy);

WebDriver driver = new ChromeDriver(options);
driver.get("https://example.com");

For SOCKS5, set the SOCKS endpoint and version instead:

Proxy proxy = new Proxy();
proxy.setSocksProxy("proxy.example.test:1080");
proxy.setSocksVersion(5);

ChromeOptions options = new ChromeOptions();
options.setProxy(proxy);

Authenticated proxies require extra planning. Embedding credentials in a URL may be rejected by modern browsers and can expose secrets. Prefer these approaches:

1. IP allowlisting: authorize the fixed public IP of your CI runner or Selenium Grid node so no browser dialog appears.
2. Local gateway: place a trusted forwarding proxy on the test machine. Selenium connects locally without credentials, and the gateway authenticates upstream.
3. Controlled browser extension: create an internal Chrome extension that configures the proxy and answers authentication challenges. Load it only from a protected test artifact.
4. Grid-level configuration: configure networking and secrets on the Selenium node rather than distributing credentials to every test.

Read credentials from a secret manager or environment-specific test configuration. Never commit them to Git, print them to console output, or include them in screenshots. After launch, verify the exit IP with an approved test endpoint before continuing the suite.

AutoIt can automate Windows dialogs by locating a window, typing credentials, and pressing a button. It was once a common Selenium workaround because WebDriver could not operate browser-owned authentication windows.

The method is fragile: it is Windows-only, requires an unlocked interactive desktop, depends on window titles and timing, and usually fails in headless containers or remote CI agents. It can also reveal passwords through scripts or process arguments.

If a legacy environment leaves no alternative, compile the AutoIt script, store it in a controlled test-artifact location, retrieve credentials securely at runtime, and wait for the exact dialog rather than using a fixed sleep. Restrict this technique to an isolated Windows runner. For maintainable suites, IP allowlisting, a gateway, or centrally configured Grid nodes are safer choices.

Selenium can handle JavaScript alerts created by webpage code:

Alert alert = new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.alertIsPresent());
alert.accept();

However, a proxy authentication dialog is normally browser chrome, not a JavaScript alert. Therefore, driver.switchTo().alert() often throws NoAlertPresentException even when a credential prompt is visible. The same limitation applies to many HTTP basic-auth dialogs.

Use the alert API only after confirming that WebDriver recognizes the prompt. If it does not, remove the prompt through network configuration or use one of the authenticated-proxy approaches described above. This is more stable than coordinating keystrokes with a window that Selenium cannot inspect.