English
繁體中文
Deutsch
Français
Español
日本語
Tiếng Việt
Português
Step 1: Define "genuine"
For a useful Python workflow, "genuine" should mean more than "this string is a valid IP address." A usable definition is: the IP is syntactically valid, behaves like a consumer-network address rather than obvious hosting infrastructure, and is not already tied to a known residential proxy service in the datasets you trust.
That layered definition matters because residential proxies are designed to look like normal ISP traffic, while detection systems still look for ASN and ISP context, known proxy-service fingerprints, rotation patterns, mismatched telemetry, and behavior correlation. Byteful's proxy reputation guidance makes the same point from an operator's side: ASN, geolocation, usage type, abuse signals, and blocklist or fraud checks all matter when you judge whether a proxy IP is truly fit for use.
Use this simple decision model in the article:
Pass: valid IP, no residential-proxy attribution returned, expected consumer-network context, and no obvious geo or trust mismatch.
Review: valid IP, but a detector has seen it in a residential proxy network recently or intermittently.
Fail: known residential proxy attribution, hosting-style network context for a "residential" claim, or strong mismatch between the IP's metadata and the use case you expected.
Step 2: Build the Python verifier
Python's standard ipaddress module is the best first step for validating whether the input is actually a legal IPv4 or IPv6 address before you waste API calls on bad data. Then query IPinfo's residential proxy detection endpoint, because its documented sample response returns fields like service, last_seen, and percent_days_seen, which are directly useful for deciding whether an IP has already been observed as part of a residential proxy service.
Here is a working Python script that does exactly that:
import ipaddress
import requests
from dataclasses import dataclass
from typing import Optional
IPINFO_TOKEN = "YOUR_IPINFO_TOKEN"
@dataclass
class VerificationResult:
ip: str
valid: bool
verdict: str
service: Optional[str] = None
last_seen: Optional[str] = None
percent_days_seen: Optional[int] = None
notes: Optional[str] = None
def validate_ip(ip_text: str) -> str:
return str(ipaddress.ip_address(ip_text))
def check_resproxy(ip: str, token: str) -> dict:
url = f"https://ipinfo.io/resproxy/{ip}?token={token}"
r = requests.get(url, timeout=15)
r.raise_for_status()
return r.json()
def verify_residential_ip(ip_text: str, token: str) -> VerificationResult:
try:
ip = validate_ip(ip_text)
except ValueError:
return VerificationResult(
ip=ip_text,
valid=False,
verdict="FAIL",
notes="Invalid IPv4/IPv6 format."
)
data = check_resproxy(ip, token)
service = data.get("service")
last_seen = data.get("last_seen")
percent_days_seen = data.get("percent_days_seen")
if service:
return VerificationResult(
ip=ip,
valid=True,
verdict="REVIEW" if percent_days_seen in (None, 0) else "FAIL",
service=service,
last_seen=last_seen,
percent_days_seen=percent_days_seen,
notes="This IP has residential-proxy attribution in the dataset."
)
return VerificationResult(
ip=ip,
valid=True,
verdict="PASS",
notes="No residential-proxy attribution returned by this dataset."
)
if __name__ == "__main__":
target_ip = input("Enter IP address: ").strip()
result = verify_residential_ip(target_ip, IPINFO_TOKEN)
print(result)This script solves the core problem directly: it rejects malformed IP input with ipaddress.ip_address() and then checks the target IP against IPinfo's residential proxy dataset using the documented /resproxy/{ip} pattern. It is also intentionally conservative, because an IP that comes back with a service value has already been associated with a residential proxy provider in that dataset, so treating it as "review" or "fail" is safer than assuming it is clean.
Step 3: Interpret the result correctly
A successful API response is not the same thing as a clean result. If the response contains a provider name such as service, plus fields like last_seen and percent_days_seen, that means the IP has been observed as part of a residential proxy service and should not be treated as unquestionably genuine just because it belongs to a consumer-looking range.
Spur's residential proxy detection guidance explains why this happens: even when an IP comes from a real household ISP range, detection systems can still identify it over time through proxy-service fingerprints, rapid ISP or geography shifts, short-lived session patterns, and mismatched browser or device telemetry. Byteful adds an operator-friendly checklist: the ASN should match a consumer ISP rather than a hosting company, the geolocation should match what the provider promised, and the usage type should look like ISP or mobile rather than datacenter when you are paying for residential traffic.
Use this interpretation table in practice:
PASS: the IP is valid and the residential-proxy dataset returns no service attribution for it.
REVIEW: the IP is valid, but you see attribution that is old, sparse, or inconsistent with what you expected, so you should cross-check ASN, ISP type, and geography before you trust it.
FAIL: the IP is valid, but clearly mapped to a residential proxy service or clearly mismatched to the "residential" claim you were sold.
A useful operational rule is to avoid treating any one dataset as absolute truth. Byteful explicitly recommends combining multiple reputation and classification signals, and Spur's model also depends on correlating IP intelligence with session and behavior context rather than declaring every residential-looking IP automatically safe or unsafe.
Step 4: Add the checks that make the script production-useful
If you are verifying IPs for a real proxy workflow, log more than the final verdict. Keep the input IP, the validation result, any service value, last_seen, percent_days_seen, and your own expected country, ASN, or provider metadata next to the result so you can review false positives or stale proxy attribution later.
You should also treat unexpected flags seriously on home or office networks. IPinfo's support guidance says a flagged IP may reflect sharing or unwanted software behavior, and it recommends removing unnecessary apps, monitoring DNS and firewall behavior, and contacting the ISP if the address appears to be part of a residential proxy network unexpectedly.
A small production-ready extension is to write results to CSV after every check:
import csv from datetime import datetime def append_result_to_csv(result, filename="ip_verification_log.csv"): with open(filename, "a", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow([ datetime.utcnow().isoformat(), result.ip, result.valid, result.verdict, result.service, result.last_seen, result.percent_days_seen, result.notes, ])
That logging step adds real E-E-A-T value because it turns a one-off lookup into an auditable verification process instead of a screenshot-driven guess. It also gives you a repeatable record for deciding whether a specific IP should be retired, rechecked later, or kept for lower-risk workloads only.
CTA
If you want a provider you can evaluate alongside this verification workflow, use proxy001.com as a comparison point because its public residential proxy page lists real-time usage and performance monitoring, sub-user management, IP whitelisting, global coverage, and country-level inventory examples such as the United States, United Kingdom, Germany, India, Malaysia, and Vietnam. That kind of visibility is useful when you are not just checking whether an IP is syntactically valid, but deciding whether a residential route is stable, attributable, and worth keeping in a production pool.
