Selenium Proxy Settings in Python require more than simply passing a proxy address to WebDriver. A stable setup should verify the proxy path outside the browser first, configure the manual proxy correctly in Chrome or another WebDriver session, confirm the exit IP, and only then debug the target page. This order matters because browser automation failures, SSL prompts, authentication issues, and selector bugs can easily be confused with proxy failures.
This guide uses Python, Selenium’s documented proxy capability, and a small exit-IP preflight so you can tell whether the network path is correct before the first browser navigation.
What Selenium can and cannot solve directly
Selenium can set the browser’s proxy configuration through WebDriver options. That is the right layer for browser traffic. What Selenium does not standardize is every provider-specific authentication workflow. If your provider issues a browser-compatible endpoint and credentials, use that exact format. If your browser session still triggers a proxy-auth dialog, solve that credential path first rather than trying to patch around it with brittle browser UI automation.
Install the libraries
python -m pip install selenium requests
Keep proxy credentials in environment variables:
export PROXY_USERNAME="YOUR_USERNAME"
export PROXY_PASSWORD="YOUR_PASSWORD"
export PROXY_HOST="GATEWAY_HOST"
export PROXY_PORT="PORT"
Step 1: verify the proxy path before launching Chrome
This preflight uses requests with explicit timeouts, credential encoding, and raise_for_status(). It tells you whether the authenticated gateway works before Selenium adds browser complexity on top.
import os
from urllib.parse import quote
import requests
def required(name: str) -> str:
value = os.environ.get(name)
if not value:
raise RuntimeError(f"Missing environment variable: {name}")
return value
user = quote(required("PROXY_USERNAME"), safe="")
password = quote(required("PROXY_PASSWORD"), safe="")
host = required("PROXY_HOST")
port = required("PROXY_PORT")
proxy_url = f"http://{user}:{password}@{host}:{port}"
proxies = {"http": proxy_url, "https": proxy_url}
response = requests.get(
"https://httpbin.org/ip",
proxies=proxies,
timeout=(10, 30),
)
response.raise_for_status()
print(response.text)
If this step fails, stop there. Rechecking credentials, gateway host, and port is faster than trying to debug a browser session that never had a valid proxy path.
Step 2: pass a manual proxy into Selenium
Selenium’s options documentation exposes a manual proxy capability. In Python, the easiest path is to build a Proxy object, attach it to the browser options, and then launch the driver.
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.proxy import Proxy, ProxyType
proxy = Proxy()
proxy.proxy_type = ProxyType.MANUAL
proxy.http_proxy = "GATEWAY_HOST:PORT"
proxy.ssl_proxy = "GATEWAY_HOST:PORT"
options = webdriver.ChromeOptions()
options.proxy = proxy
options.add_argument("--headless=new")
options.add_argument("--window-size=1440,900")
driver = webdriver.Chrome(options=options)
try:
driver.get("https://httpbin.org/ip")
print(driver.find_element(By.TAG_NAME, "body").text)
driver.get("https://example.com")
print(driver.title)
finally:
driver.quit()
The example intentionally keeps the browser-side proxy value as host:port. Do not invent an authenticated URL format for Selenium if your provider documents a different browser path. Copy the browser-compatible endpoint from the dashboard you are actually using.
Why do the preflight and browser step separately?
Because they answer different questions:
- The
requestspreflight proves whether the authenticated proxy credentials and network path work. - The Selenium run proves whether the browser traffic is using the expected proxy route.
- Together they tell you whether a failure belongs to the gateway, the browser setup, or the target page.
This split is especially useful when a target page loads slowly or shows an interstitial. Without the preflight, teams often change WebDriver settings when the real issue is a wrong proxy endpoint or a page-level challenge.
Common failures and what they actually mean
| Failure | Likely layer | Fastest next check |
|---|---|---|
407 Proxy Authentication Required in the preflight | Credential or endpoint issue | Recopy the credentials and confirm they belong to the intended proxy product. |
| Browser opens but the IP does not change | Browser proxy setting did not apply | Check http_proxy and ssl_proxy, then reload the IP-check page in Selenium. |
| HTTPS pages fail but HTTP pages work | Only the HTTP proxy was set | Set both http_proxy and ssl_proxy. |
| The target page times out | Could be the proxy path or the target site | Retest the IP-check endpoint inside Selenium first, then the target page. |
| Unexpected certificate or auth prompt | Browser-specific proxy auth path is incomplete | Use the exact provider-supported browser endpoint; do not script around prompts until the network path is documented. |
Selenium Proxy Settings for Production Browser Jobs
- Keep the exit-IP check at session startup, not on every page, unless the workflow is explicitly testing rotation.
- Log status codes, page titles, and driver version, but never log raw proxy passwords.
- Use responsible rate limits and only automate pages you are authorized to access.
- If a proxy issue appears only in Selenium and not in the preflight, review the browser endpoint format before changing the target-site logic.
Where ColaProxy fits
ColaProxy’s public site states support for HTTP(S) and SOCKS5 protocols plus multiple proxy product types. That makes it a reasonable fit for browser validation workflows, but the exact browser endpoint syntax and any region or session controls should always come from the current dashboard rather than from a copied blog snippet.
If your workflow is not browser-heavy, the Python proxy health checker is a faster way to validate gateways. If you are comparing browser stacks instead of fixing Selenium specifically, the Playwright proxy authentication guide shows the equivalent setup in Playwright.
Next step
Get the preflight stable first, then launch one headless browser, confirm the exit IP, and only after that add the real target flow or parallel workers.