This Python-based automation workflow helps you screen proxy IPs by testing availability, measuring response latency, and identifying anonymity level. It addresses common issues in both free and paid proxies, including unstable quality, real IP leakage, and low efficiency in bulk screening. Keywords: proxy testing, anonymous proxies, elite proxy validation.
This article provides a minimum viable solution for proxy IP quality testing
| Parameter | Description |
|---|---|
| Language | Python 3 |
| Core Protocols | HTTP, HTTPS, ICMP |
| Runtime Goal | Bulk proxy IP quality testing |
| Stars | Not provided in the original source |
| Core Dependencies | requests, pythonping |
| Key Metrics | Availability, latency, anonymity |
This script is well suited for web scraping, multi-account operations, and geo-access validation. Compared with manual trial and error, it breaks proxy evaluation into three repeatable metrics and quickly filters out dead, high-latency, or low-anonymity proxies.
The original approach is straightforward and practical: first send an HTTP request to verify connectivity through the proxy, then record round-trip time, and finally determine whether the proxy leaks the real IP from the server-side perspective. For small to medium-sized proxy pools, this is already highly usable.
The three core proxy quality metrics must be evaluated separately
Availability testing answers a simple question: can this proxy actually be used? The safest method is not a standalone Ping check, but direct access to a target site through the proxy. Many servers disable ICMP while still serving real traffic over HTTP or HTTPS.
Latency testing answers a different question: is this proxy worth using? In practice, total HTTP request time is usually the primary metric because it better reflects the real application path. ICMP Ping should only serve as a fallback signal to help determine whether the network layer is reachable.
import requests
import time
from contextlib import closing
TEST_URL = "https://httpbin.org/get" # Use an endpoint that echoes request details for better testing
TIMEOUT = 3
def test_proxy_availability(proxy: str):
try:
proxies = {"http": proxy, "https": proxy} # Configure the proxy for both protocols
with closing(requests.head(TEST_URL, proxies=proxies, timeout=TIMEOUT, verify=False)):
return True, "Available"
except requests.exceptions.Timeout:
return False, "Request timed out"
except requests.exceptions.ConnectionError:
return False, "Connection failed"
This code uses a HEAD request to quickly verify whether the proxy is reachable, making it a good first-layer filter.
Anonymity detection depends on the server-side view rather than local assumptions
Anonymity is the easiest part to implement incorrectly. If the testing endpoint cannot return the source IP and request headers as seen by the server, you cannot accurately determine whether the proxy exposes the client’s real address.
In the original logic, TEST_URL was set to Baidu, but the anonymity code later called response.json() and tried to read the origin and headers fields. This is clearly inconsistent: the Baidu homepage does not return that JSON structure. A much better choice is https://httpbin.org/get.
import requests
TEST_URL = "https://httpbin.org/get" # Returns JSON so origin and headers can be extracted
TIMEOUT = 3
def test_proxy_anonymity(proxy: str, local_ip: str):
proxies = {"http": proxy, "https": proxy}
response = requests.get(TEST_URL, proxies=proxies, timeout=TIMEOUT, verify=False)
data = response.json() # This depends on the endpoint returning JSON
server_ip = data.get("origin", "").split(",")[0].strip() # The outbound IP observed by the server
xff = data.get("headers", {}).get("X-Forwarded-For", "")
via = data.get("headers", {}).get("Via", "")
if local_ip and (local_ip in server_ip or local_ip in xff):
return "Transparent Proxy"
if via or "proxy" in xff.lower():
return "Anonymous Proxy"
return "Elite Proxy"
The key value of this code is that it infers anonymity level from what the server returns, rather than merely checking whether the local proxy settings were applied.
Environment setup should cover both request-layer and network-layer testing
The dependency list is small: you only need requests and pythonping. The first handles HTTP and HTTPS checks, while the second supplements network-path latency information when requests fail.
pip install requests pythonping
This command installs the two essential libraries required to run the script.
Proxy format should be standardized as protocol://IP:port, for example http://123.45.67.89:8080 or https://98.76.54.32:443. If the format is inconsistent, batch testing will produce many false failures.
You should manage proxy inputs and test configuration separately
For batch runs, keep the proxy list, timeout values, and test endpoints in a configuration section instead of changing the core logic every time. This makes it much easier to extend the workflow later to read from files, databases, or external APIs.
PROXY_LIST = [
"http://111.11.22.33:8080",
"https://222.22.33.44:443",
"http://333.33.44.55:9090",
]
TEST_URL = "https://httpbin.org/get" # Use one endpoint consistently for availability and anonymity testing
TIMEOUT = 3 # Too short causes false negatives; too long reduces throughput
PING_COUNT = 5 # Sample multiple times to reduce one-off jitter
This configuration block centralizes tunable parameters so you can switch quickly across business scenarios.
The batch execution flow should follow an availability-first strategy
The right sequence is: test availability first, then latency, and finally anonymity. There is no reason to continue evaluating an unusable proxy, and this order saves a significant amount of request time.
At the same time, latency grading should use thresholds that match your workload. For example, less than 100 ms may be considered excellent, less than 200 ms acceptable, and more than 200 ms better suited to low-frequency jobs rather than high-concurrency scraping.
def score_delay(delay: int) -> str:
if delay == -1:
return "Unavailable"
if delay < 100:
return f"{delay}ms (Excellent)"
if delay < 200:
return f"{delay}ms (Average)"
return f"{delay}ms (Poor)" # High-latency proxies should be downgraded or removed
This logic converts raw latency numbers into easier-to-read quality labels.
The original script needs three key fixes in real-world use
First, the anonymity testing endpoint must be replaced with one that supports JSON echoing; otherwise, response.json() will fail immediately. Second, although verify=False is convenient during testing, it disables SSL verification and should only be used in a controlled test environment. Third, exception handling should not suppress everything, or you lose critical troubleshooting details.
If you want to improve batch performance, you can add concurrent execution, retry logic, and result persistence. For hundreds of proxies, serial requests noticeably slow down screening. For a production proxy pool, writing results to CSV or a database also makes later analysis easier.
Result interpretation should not stop at “available”
A high-quality proxy usually satisfies three conditions at once: it is available, highly anonymous, and has acceptable latency. Connectivity alone does not make a proxy production-ready. A transparent proxy may leak the real IP, and a high-latency proxy can significantly increase application timeout rates.
A practical filtering rule is straightforward: prioritize proxies that are “Available + Elite Proxy + latency < 200 ms"; exclude transparent proxies immediately; and keep anonymous proxies only after evaluating business risk.
FAQ structured Q&A
FAQ 1: Why not use Ping instead of HTTP checks?
Because many target sites or proxy nodes disable ICMP while still forwarding business traffic over HTTP or HTTPS. HTTP checks are much closer to real application behavior and produce fewer false negatives.
FAQ 2: Why is httpbin recommended for anonymity testing instead of a normal webpage?
Because anonymity testing requires the source IP and request headers as seen by the server. Endpoints like httpbin.org/get return fields such as origin and headers, which makes it possible to distinguish transparent, anonymous, and elite proxies accurately.
FAQ 3: How can this script be extended to a large-scale proxy pool?
You can add concurrency with asyncio or a thread pool, then write results to CSV, Redis, or a database. You should also add retries, blacklists, and multiple target endpoints to avoid false judgments caused by a single endpoint failure.
AI Readability Summary: This article refactors a basic proxy IP testing script into a high-density technical guide. It explains the detection logic behind availability, latency, and anonymity, and provides practical Python code, configuration patterns, result interpretation guidance, and optimization suggestions. It is a strong fit for web scraping, fraud detection, multi-account operations, and geo-targeted access validation.
