Selenium Proxy Setup

6 min read

Use this guide to connect InstantProxies to Selenium and validate that browser traffic is actually going through the proxy.

For most users, the right goal is simple: start the browser with the proxy, confirm the connection works, then move into the real automation flow. Do not start with a large test suite or scraping workflow before the baseline browser path is proven.

Use this page when

Use this page when:

  • you want to use InstantProxies in Selenium
  • your workflow depends on a real browser instead of raw HTTP requests
  • you need WebDriver-based browser control
  • you want to verify that Selenium is using the proxy before building a larger automation or testing flow

If your workload is mostly request-based, use a language integration guide instead of browser automation.

Before you start

Have these details ready:

  • proxy host
  • proxy port
  • authentication method
  • a simple test URL

The two common access methods are:

  • username and password authentication
  • source IP authorization

If you are using IP authorization, make sure the public IP of the real runtime environment is already authorized.

Basic Selenium proxy setup

In Selenium, proxy configuration is usually applied through browser options before the WebDriver session starts.

Python example with Chrome

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument('--proxy-server=http://YOUR_PROXY_HOST:PORT')

driver = webdriver.Chrome(options=options)
driver.get('https://httpbin.org/ip')
print(driver.page_source)
driver.quit()

Use this first to confirm:

  • the browser starts successfully
  • Selenium can reach the proxy
  • the proxy is actually being used for browser traffic
  • one simple page load completes cleanly

Selenium with IP authorization

If your account is configured to allow traffic from an approved public IP, this is often the simplest Selenium setup.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument('--proxy-server=http://YOUR_PROXY_HOST:PORT')

driver = webdriver.Chrome(options=options)
driver.get('https://httpbin.org/ip')
print(driver.page_source)
driver.quit()

This works only when the real runtime environment is already authorized.

A local machine, server, container, CI runner, or Selenium grid node may all use different public IPs.

Selenium with username and password

Credential-based proxy authentication in Selenium is more tool-specific than in Playwright or Puppeteer.

Whether it works cleanly depends on:

  • browser type
  • WebDriver behavior
  • local versus remote execution
  • how the browser handles authenticated proxy prompts or extensions

Because of that, the safer guidance is:

  • use IP authorization when possible for Selenium workloads
  • if credentials are required, validate the exact browser and driver path in the real runtime before building a larger workflow
  • keep credentials out of test logic and source files

Store credentials in environment-aware configuration, not inside the test code itself.

If your Selenium setup must use credentials, validate the smallest possible browser path first before assuming the same pattern will work across grids, containers, or CI environments.

Validate the proxy before building the workflow

Before adding logins, test flows, or scraping logic, validate in this order:

  1. browser and driver startup
  2. one simple page load
  3. returned IP or baseline response
  4. repeated execution of the same path
  5. only then add real browser actions

This keeps setup issues separate from workflow issues.

If you have not yet validated the proxy outside Selenium, start with First Request with cURL and Authentication and Access.

Keep browser setup separate from test logic

Do not rebuild proxy configuration inside page actions or test steps.

Keep these separate:

  • browser options and capabilities
  • proxy settings
  • authentication values
  • timeout and wait behavior
  • test or page interactions
  • workflow logic

This makes Selenium easier to debug and easier to reuse.

Treat browser and driver state as part of the setup

Selenium depends on both the browser and the WebDriver layer.

Check:

  • whether the browser starts consistently
  • whether the driver and browser are compatible
  • whether options are being applied the way you expect
  • whether the failure starts at startup, navigation, or later in the workflow

A Selenium run can fail because of the browser, the driver, the proxy path, or the workflow built on top of them.

Make waits and timeouts explicit

Selenium workflows depend on more than browser startup.

You should think about timing at these boundaries:

  • driver startup
  • browser startup
  • page load
  • element readiness
  • script execution
  • repeated workflow steps

Use explicit waits when the next step depends on page state or DOM readiness.

If timing is the main issue, continue to Timeouts, Retries, and Backoff.

Test repeated runs

One successful browser run is not enough.

Repeat the same simple path several times and check:

  • whether startup stays consistent
  • whether navigation timing drifts
  • whether the same driver setup continues to work
  • whether the runtime still behaves correctly after repeated execution

Repeated-run stability is a much better signal than first-run success.

Common Selenium proxy mistakes

Typical issues include:

  • validating only one successful page load
  • using the wrong runtime IP for allowlisting
  • assuming credential-based proxy auth works the same way in every Selenium environment
  • mixing proxy configuration into test logic
  • hardcoding credentials
  • starting with a large workflow before the proxy path is validated
  • treating a browser workflow failure as if it were only a simple request failure

Basic troubleshooting checks

If the Selenium run fails, check these first:

  • host and port are correct
  • the real runtime IP is authorized if using IP allowlisting
  • the same proxy works with cURL from the same environment
  • the failure happens at browser startup, navigation, or later in the workflow
  • the browser and WebDriver are compatible and starting correctly

If the problem is still unclear, continue to Authentication and Allowlist Errors or Connectivity Troubleshooting.

Use this sequence:

  1. confirm the access method
  2. configure the proxy before the WebDriver session starts
  3. validate one simple page load
  4. repeat the same path from the same environment
  5. make waits and timeouts explicit
  6. only then expand into a larger Selenium workflow

Key points

  • configure proxy behavior before the Selenium session starts
  • match the authentication method to the real runtime environment
  • use IP authorization when possible for simpler Selenium proxy setups
  • validate the proxy path before building the full workflow
  • keep browser and driver setup separate from test logic
  • repeated runs matter more than one successful page load

Next step

If you need another browser framework, continue to Playwright Proxy Setup or Puppeteer Proxy Setup.

If Selenium starts correctly but the browser flow still fails, continue to Browser Automation Troubleshooting.