Verification

Verifying a Free Proxy Before You Trust It With Real Traffic

3 min read Published Updated 470 words

Free proxies fail more often than they work. A public list cycles through tens of thousands of candidates and your job is to find the small subset that is currently alive, fast enough, and not actively malicious. Five tests, each cheap, run in order.

Test 1: TCP Reachability

curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
     -s -o /dev/null -w "%{http_code}\n" \
     https://api.ipify.org

A non-zero exit code or a blank response means the proxy is dead. About 60–80% of any free list will fail this test at any given moment. Skip immediately and do not retry.

Test 2: Egress IP Verification

The same call returns the public IP the request emerged from. If it equals 1.2.3.4 — the proxy's address — the proxy is forwarding traffic correctly. If it equals your local IP, the proxy is broken or transparent: it accepted the connection but did not actually relay through itself. Treat that as a failure even though TCP succeeded.

Test 3: Header Transparency

curl --proxy http://1.2.3.4:8080 https://httpbin.org/headers

The response echoes back the headers the destination received. Look for X-Forwarded-For, Via, or Forwarded with your real IP. If you find them, the proxy is in transparent or anonymous mode rather than elite. For HTTPS via CONNECT this is moot — the destination only sees the TLS handshake, no application headers — but for plaintext HTTP it determines whether the proxy is fit for purpose.

Test 4: Latency Under Load

Single-shot timing is noisy. Run ten serial requests through the proxy and take the median. Anything above two seconds is unusable for interactive work. Under 500 milliseconds is competitive with no proxy at all. Between those numbers, the proxy is suitable for batch scraping but not for browsing.

Test 5: TLS Fingerprint Integrity

Connect through the proxy to a known TLS endpoint and verify the certificate chain matches what you get without the proxy. A mismatch means the proxy is intercepting TLS — running a man-in-the-middle and your "encrypted" traffic is not actually encrypted from the proxy onwards. This is rare on properly configured SOCKS proxies (they cannot see TLS) but appears on misconfigured corporate HTTPS proxies and on the occasional malicious public node. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 prints the chain.

A Practical Workflow

Pull the list, filter by country and protocol, fan out the five tests across a parallel pool of around 50 workers, and keep the survivors. From 100 raw candidates a typical run yields 5–15 usable entries. The decay rate is roughly 30–60 minutes for HTTP and HTTPS, slightly longer for SOCKS — schedule a refresh at that cadence and feed the surviving set into your scraper or browser configuration. Cache the test results for the lifetime of one batch and re-test on the next.