Reputation is inferred, not read
There is no reliable public number that says one exit IP is trusted and another is burned. In production proxy work, reputation is inferred from outcomes: accepted requests, soft blocks, hard blocks, small response bodies, challenge pages, and repeated non-200 status codes.
Proxy access can be technically fine. DNS resolves, TLS completes, the client sends the same request shape as yesterday. Then the target refuses the exit because the IP, ASN, or subnet looks bad enough to filter before the page is served.
Test one route first. If the result is bad, scaling only hides which part failed and makes the provider meter harder to read.
This is the log format I keep when the same target starts failing unevenly. Route, status, ASN, subnet, body size, and provider-metered bytes — not a dashboard screenshot.
ts,route,asn,subnet,status,body_bytes,provider_metered_bytes
2025-09-03T09:13:11Z,datacenter-route,AS14618,3.224.0.0/12,403,9214,18837
2025-09-03T09:13:14Z,datacenter-route,AS14618,3.224.0.0/12,403,9214,18792
2025-09-03T09:13:19Z,residential-route,AS7922,73.44.0.0/16,200,48211,63104
2025-09-03T09:13:23Z,residential-route,AS7018,99.12.0.0/15,429,3176,11992
2025-09-03T09:13:27Z,residential-route,AS22773,174.56.0.0/14,200,47702,62881
2025-09-03T09:14:02Z,residential-route,AS7018,99.12.0.0/15,200,9041,20318
note: 9 KB 200s were block pages, not content pagesOne bad row proves nothing. A pattern does: same ASN, same subnet, same target, same request shape, same 403 or 429. That is when I stop blaming the parser and start treating it as an IP reputation problem.
Datacenter exits get judged by neighborhood
The ASN is usually a hosting provider. The subnet may sit near other ranges used for automation, spam, or scanners — categories tracked by blocklist operators such as Spamhaus. That does not make every datacenter route useless. It means some targets start the conversation with less trust for those ranges.
Residential proxies usually start from a better baseline because the exits sit on consumer ISP networks rather than obvious hosting networks. That can help with reputation, but it is not a guarantee. A residential exit can still carry a bad history. A target can still rate-limit it. A 200 can still be a small block page dressed as success.
For broad public collection where reputation problems are mild, Volume Residential at $0.89/GB is the first test. If the pattern points hard at IP reputation, Premium Residential at $5.00/GB is the next comparison point. The question is not which plan always wins. It is whether status codes, body sizes, provider-metered bytes, and usable output actually change when you switch.
Some failures are not reputation at all. A provider blocking a traffic category is a policy problem. The same simple page failing across every route and every subnet is usually a bad request, broken auth, a dead parser, or a target rule no proxy would fix. I do not want those in the same bucket.
Group failures by ASN and subnet before drawing any conclusion. Same endpoint plus different ASN plus different outcome is evidence of a reputation problem. Same failure code across every route is evidence of something else.
App dashboards undercount; provider meters do not
App dashboards count saved JSON, final HTML, or rows that made it to storage. They hide retries, redirects, block pages, challenge pages, and failed attempts. Provider-metered bytes are the billing-side view — every byte transferred through the gateway. When reputation trouble starts wasting money, that is the number to watch.
app_saved_bytes=1.8GB
app_dashboard_requests=42,000
provider_metered_bytes=4.9GB
top_status_codes=403,429,200
note=app counted saved pages only; provider counted all transferred proxy trafficThe Proxynade dashboard network logs show host, outcome, latency, and byte totals per request. Usage logs export as CSV. Running both side by side makes the waste visible: when provider-metered bytes run well ahead of app-saved bytes, the gap is almost always retries, block pages, and redirects that never produced usable output.
The separation test is straightforward. Check the same request from a clean direct connection. Compare route types. Group failures by ASN and subnet. Compare body size, not just status code. A 200 with 9 KB is not the same as a 200 with 48 KB.
IP reputation is history you inherit at the exit. You do not clean it from your client after the request leaves. Good logs make that visible. Without them, every block becomes a proxy mystery and every byte spike becomes a billing argument.
IP reputation FAQ
What is IP reputation? It is the history a target site associates with an exit IP, ASN, or subnet — inferred from past traffic patterns. You see it as 403s, 429s, challenge pages, or undersized 200 responses.
How do I tell if a block is an IP reputation problem? Group failures by ASN and subnet. If the same endpoint fails on one ASN and succeeds on another with the same request shape, the exit's reputation is the variable.
Do residential proxies always have better reputation than datacenter? They usually start from a better baseline because the exits sit on consumer ISP ranges. A residential exit can still carry a bad history, and a 200 can still be a block page.
Why does my provider bill more bytes than my app recorded? App dashboards count saved output. Providers meter all transferred traffic including retries, redirects, challenge pages, and failed attempts.
Which Proxynade plan should I test when reputation is the problem? Run the same sample on Volume Residential ($0.89/GB) first, then compare on Premium Residential ($5.00/GB). Check status codes, body sizes, and provider-metered bytes across both.