Free proxies can carry a Selenium session through public pages, as long as the script expects most of them to fail. We tested that on 28 September 2026 at 13:37 UTC. We took 300 free proxies that our list showed as alive. Through each, we loaded one page of our own site and the 25 files its HTML names, the way Chrome loads a page through a proxy. 111 delivered the whole page, at a median of about 23 seconds. Directly, the same page took 0.4 to 2.0 seconds.
This page covers what the test showed, the Chrome setup and the timeout that follow from it, certificates, WebRTC, and what a free proxy should never carry.
What happened to 300 page loads
A browser does not send one request for a page. It sends one for the HTML and more for the scripts, styles and images the HTML names. Through an HTTP proxy, Chrome first asks for a tunnel with the CONNECT method, which RFC 9110 describes as a request to "establish a tunnel to the destination origin server". Through a SOCKS5 proxy, it opens the tunnel with SOCKS5. Our test did both, then ran TLS and HTTP/2 inside the tunnel, as Chrome does, and gave each load 300 seconds, the WebDriver default.
- A page is slow even when it arrives. Of 200 entries with the https flag, 63 delivered the whole page, at a median of 23.9 seconds. Of 100 SOCKS5 entries, 48 did, at a median of 22.1 seconds. None of those pages had a changed file.
- Many never answered. 114 of the 300 entries never accepted the connection. On our Linux server the operating system gave up after 136 seconds each, well inside the 300 seconds WebDriver waits by default.
- Ten certificates were not ours. Of the 131 proxies that finished TLS, 10 handed back a certificate that was not ours: 9 SOCKS5 entries and 1 HTTP entry. Chrome stops at such a certificate, and Selenium reports it as an error. That is the safe outcome, and the next section keeps it that way.
- The list was not fresh. Our list had last checked these entries a median of 30 minutes before the test. An entry stays on it as alive until its next check fails.
Set the page load timeout to about 30 seconds
In the WebDriver standard, the page load timeout "is initially set to 300,000" milliseconds, five minutes. We replayed the 300 loads at shorter limits. A browser working through the entries one at a time would have loaded 33.8 whole pages per hour at 30 seconds, and 16.3 at the default. A shorter limit gives up on some slow pages that would have arrived. It also stops waiting on dead entries and moves on to the next one, which pays off with thousands of entries on a list. At 10 seconds, too many good pages were cut off. The Python bindings of Selenium show the call in their own example: driver.set_page_load_timeout(30).
A Chrome setup for free entries
import urllib.request
from selenium import webdriver
from selenium.common.exceptions import InsecureCertificateException, WebDriverException
# entries alive on their last check that can tunnel HTTPS (use protocol=socks5 and "socks5" for SOCKS5 entries)
LIST_URL = "https://hproxy.com/api/proxy-list?format=txt&protocol=https"
SCHEME = "http"
with urllib.request.urlopen(LIST_URL, timeout=30) as response:
entries = response.read().decode().split()
def open_through(entry):
options = webdriver.ChromeOptions()
options.add_argument(f"--proxy-server={SCHEME}://{entry}")
# keep WebRTC to TCP through the proxy instead of UDP from your own address
options.add_argument("--force-webrtc-ip-handling-policy=disable_non_proxied_udp")
driver = webdriver.Chrome(options=options)
driver.set_page_load_timeout(30) # the WebDriver default is 300 seconds
return driver
for entry in entries:
driver = open_through(entry)
try:
driver.get("https://example.com/")
except InsecureCertificateException:
driver.quit() # a certificate that is not the one of the site: drop the entry
continue
except WebDriverException:
driver.quit() # dead, slow or refused, timeouts included: try the next entry
continue
print(entry, driver.title)
driver.quit()
break
Our free proxy list API returns one address and port per line, with no key and no signup. Four details matter here:
- One browser per entry. The switch applies to the browser it launches, so a new entry means a new driver. For a dead entry, the Chromium documentation says requests "would fail with
ERR_PROXY_CONNECTION_FAILED", which Selenium raises as an error. Our guide to ERR_PROXY_CONNECTION_FAILED covers that error. - The scheme. Write
http://for an entry with the https flag, since it is an HTTP proxy that can open CONNECT tunnels. Writesocks5://for a SOCKS5 entry. In Chrome, the name of the site is then resolved by the proxy, and the Chromium documentation adds that "No authentication methods are supported for SOCKSv5 in Chrome". Free entries need none. - SOCKS5 entries held up well here. In our test, 48 of 100 SOCKS5 entries delivered the whole page, against 63 of 200 with the https flag. Nine of the SOCKS5 entries also handed back a certificate that was not ours, which Chrome caught.
- No login in the switch. The Chromium documentation says Chrome "will not use any credentials embedded in the proxy settings". That matters only for paid gateways, covered in how to use proxies in Selenium. Selenium Wire, often suggested for that, says in its own README: "Selenium Wire is no longer being maintained." Its last release, 5.1.0, dates from 15 October 2022.
Never accept insecure certificates
WebDriver has a capability for certificates, acceptInsecureCerts. The standard describes it in one line: "Indicates whether untrusted and self-signed TLS certificates are implicitly trusted on navigation for the duration of the session." It is off by default. With it off, Chrome stops at a certificate that is not the one of the site. Selenium then raises InsecureCertificateException, which its source describes as thrown when the browser "hits a certificate warning (expired or invalid TLS certificate)".
In our test, that happened 10 times in 131. Nine of those entries were SOCKS5 proxies whose certificate came from an issuer named "None, LLC" and had expired. Our earlier certificate test found the same issuer through free SOCKS5 proxies. With acceptInsecureCerts on, or any switch that ignores certificate errors, those pages would have loaded with nothing on the screen to show it. The proxy could then have read and changed them. Treat the error as the answer: drop the entry and take the next one.
Keep WebRTC off your own address
A proxy carries the page, not every connection the page opens. WebRTC, the real-time part of a browser used for calls and video, can open its own connections over UDP, and those can leave from your own IP address. RFC 8828 describes the case of a browser behind a proxy that may also reach the internet directly. There, "WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client". Chrome lets WebRTC use every network interface by default. The Chromium policy for this has a mode in which "WebRTC uses either UDP SOCKS proxying or will fallback to TCP proxying". Chrome takes the same setting as a switch, the one in the code above.
UDP through a free proxy is rare in any case. RFC 8828 notes that UDP is not supported by "all HTTP and most SOCKS" proxies. The Chromium documentation adds that SOCKS5 in Chrome "cannot be used to relay UDP traffic". When we tested 200 working free SOCKS5 proxies on 27 September 2026, 2 carried a UDP packet.
What no setting fixes
- Logins and personal data. Never sign in, pay or type personal details in a browser behind a free proxy. In 10 of the 131 TLS sessions of our test, the certificate was not ours.
- The rules of the site. A free proxy changes the address a request comes from, not what the site allows. Read the terms of the site, and stop where they forbid automated access.
- Speed. A page took a median of about 23 seconds through a free proxy, against 2 seconds or less directly. That is enough for a look at a page, not for a long run.
When free is not enough
For a session that has to work on time, such as checking your own site from other countries, a residential proxy is the better tool. Its address belongs to a home connection, and it stays up while you work. Ours start at $0.44/GB, pay as you go, and purchased traffic has no scheduled expiry date. The choices for a paid setup, from proxy type to sessions, are in proxies for Selenium. A crawler without a browser is covered in free proxies for Scrapy.
The plain answer
Free proxies can carry Selenium, slowly. In our test of 300, 111 delivered a whole page, at a median of about 23 seconds, and 10 handed back a certificate that was not ours. Pass the entry to Chrome with --proxy-server, set the page load timeout to 30 seconds, start a new driver for each entry, and drop every entry that fails. Keep acceptInsecureCerts off, keep WebRTC to the proxy, and never sign in through a free proxy.
How we measured
On 28 September 2026 between 13:37 and 13:42 UTC, a script on our Linux server in the United States took a random sample from our free list API. It took 200 entries with the https flag and 100 SOCKS5 entries, all alive on their last check. Through each, it opened a tunnel to our site and ran TLS with HTTP/2. It then loaded one page and the 25 files its HTML names, about 497 KB, with the accept-encoding of a browser. Each load had 300 seconds in all. Three direct loads gave the certificate and the files to compare against. The rates at shorter limits replay the same timings, and Chrome may give up on a slow proxy sooner than our script did. The UDP test comes from our research on free proxies for gaming. We store no proxy addresses, and every time is in UTC.
Sources
- W3C, WebDriver, latest draft, read 28 September 2026: timeouts, acceptInsecureCerts and the insecure certificate error.
- Selenium documentation: Browser Options, and the Python bindings of Selenium 4.49.0, released 9 September 2026.
- Chromium documentation: Proxy support in Chrome, and the WebRTC IP handling policy in the Chromium source.
- IETF, RFC 8828: WebRTC IP Address Handling Requirements, January 2021.
- IETF, RFC 9110: HTTP Semantics, June 2022, section 9.3.6 on CONNECT.
- HProxy documentation: the free proxy list API, read 28 September 2026.
