How to tell the IP class of every service you use, using IPCombo's per-target column

Most public IP checkers show you one IP. That is your exit, but you cannot tell what class it is. A single number — 45.33.x.x — could be a Linode VPS or a residential AT&T subscriber. Without more context you cannot tell, and guessing wrong means a hard block on the services that matter.

IPCombo's per-target IP column changes this. By probing a target through cdn-cgi/trace or the image probe, we get a different source IP per destination if your proxy has per-domain rules, and the same source IP if it does not. Either way, you see exactly which IP class each request exited from, target by target.

This is the only public tool that gives you per-target visibility. Everything else — whoer.net, browserleaks, whatismyip — collapses to a single number and forces you to infer.

Step 1 of the four-step process: read the ASN. Every IP belongs to an organization identified by an Autonomous System Number. Run a whois on the IP from IPCombo's per-target column. If the org name contains 'Linode', 'DigitalOcean', 'Vultr', 'Amazon', 'Google', 'Microsoft' — it is datacenter. If it contains a residential ISP name — it is residential. If it contains a mobile carrier name — it is mobile.

This is the only definitive check. IP ranges change ownership; the ASN record is the source of truth. The latency check and the soft-block check are corroborating signals — the ASN is the answer.

Step 2: look at the IP range. Datacenter IPs are dense — a contiguous /16 allocated within a few years. Residential IPs are sparse within a larger ISP block, allocated to individual subscribers over time. Mobile IPs sit in a few /16s per carrier, used by millions of subscribers.

Step 3: latency pattern. Datacenter IPs respond in single-digit milliseconds to a nearby probe. Residential IPs respond in 20-80ms because the last-mile ISP adds real network distance. Mobile IPs respond in 50-200ms because the carrier network has more hops. If the latency-to-the-service is suspiciously low for a residential claim, the claim is false.

IPCombo shows the per-target latency in the connectivity matrix. Cross-reference that with the ASN from step 1. If they disagree, treat the IP as misclassified.

Step 4: watch for soft-blocks. A soft-block is when the service responds, but with reduced functionality: ChatGPT gives you GPT-5 with reasoning disabled, Netflix serves a smaller catalog, a bank app shows a 'verify your identity' loop. None of these are hard failures; they are degradations the service applies silently to IPs it does not trust.

The exit-map view in IPCombo is built for this. Run a test, then look at which targets show degraded behavior (yellow, not red, not green). The pattern of degradation maps to the IP class the service has flagged. If only the residential-sensitive targets degrade, your exit is misclassified. If everything degrades, your region is wrong.

Combine the four steps and you can self-diagnose any IPCombo result. The diagnosis card automates this — but knowing the four steps lets you read the card, not just trust it.