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:
- browser and driver startup
- one simple page load
- returned IP or baseline response
- repeated execution of the same path
- 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.
Recommended setup sequence
Use this sequence:
- confirm the access method
- configure the proxy before the WebDriver session starts
- validate one simple page load
- repeat the same path from the same environment
- make waits and timeouts explicit
- 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.