Thanks to @wannaCSmajor for the original question:

People say route quality should matter more than node count and recommend IPLC/IEPL, multi-entry BGP relays, or CN2 over an ordinary public-network relay. How can I tell which route a provider actually uses?

The short answer is that an outside user usually cannot prove a commercial transport contract from one traceroute. You can collect signals about the visible IP path, origin networks, latency, loss, and peak-hour behavior, then compare those signals with the provider's claim. A true private or Layer-2 segment may deliberately be invisible to ordinary IP-level tools.

1. Start with a testable provider claim

Read the provider's route description and save a dated copy before purchase.

• Useful claims name the ingress location, egress location, carrier, and whether the label applies to every node or only a subset.
• Terms such as “enterprise optimized,” “premium relay,” and “dedicated route” have no standardized technical meaning by themselves.
• IPLC, IEPL, CN2 GIA, and BGP relay are often used as product labels. A label is not evidence that every packet follows that route.

Search technical forums and the provider's public status channel for observations from users on the same access carrier and region. Feedback from another country or ISP may describe a completely different path.

2. Identify what you are actually testing

A subscription can expose several layers:

1. a public subscription domain;
2. an ingress hostname or IP reached by the client;
3. one or more hidden relays;
4. an overseas egress IP seen by websites.

The public egress address alone does not reveal the ingress or the transport between them. Resolve the actual server hostname used by the selected node, where the client configuration permits it, and avoid publishing credentials or a private subscription URL.

3. Run traceroute in both useful directions

Use tracert on Windows or traceroute on Linux and macOS:

traceroute example-ingress-host

Run several traces from the network that will use the service. If possible, have the provider supply a Looking Glass or another authorized measurement from the far side.

Traceroute can show responding IP hops and their round-trip times, but it has important limits:

• routers may suppress or rate-limit ICMP responses;
• the forward and return paths may be different;
• load balancing can change hops between probes;
• NAT, tunnels, and MPLS can hide internal hops;
• a short path is not proof of IPLC or IEPL.

APNIC's guide to interpreting traceroute and MTR explains why missing or slow intermediate replies do not automatically mean data loss. Cisco also documents how an MPLS core can be hidden from ordinary traceroute.

Common but non-conclusive signals

• A domestic-looking ingress followed by an overseas endpoint with few visible IP hops is consistent with a hidden relay or private segment, but does not identify its commercial product.
• Addresses in 59.43.x.x have historically been associated with China Telecom's CN2 infrastructure. Seeing one is evidence that the visible path touched that address range, not proof that the entire route is CN2 GIA.
• A path through ordinary public-carrier addresses is evidence of a public IP segment. It does not reveal every hidden segment before or after it.

4. Check IP registration and routing data

Look up each visible endpoint and significant hop with an IP/ASN service. RIPEstat combines registration and observed routing data, while IP.SB and IPWhois offer convenient summaries.

Record:

• the announced prefix;
• the observed origin ASN;
• the registered organization;
• reverse DNS, when present;
• the result timestamp.

An ASN tells you which network originates a prefix in the observed BGP data. It does not prove ownership of the physical cable, the service tier purchased by the provider, or the complete internal path. Cloud-hosted ingress can also sit in one ASN while traffic is carried onward by another network.

For command-line checks, a routing-data service is generally more useful than treating a registry object's origin field as ground truth:

whois -h riswhois.ripe.net example-ip-address

RIPE NCC describes RIS as a distributed collection of observed BGP routing data and exposes current prefix-to-ASN mappings through RIS and RIPEstat.

5. Measure performance repeatedly

Route labels matter only insofar as the service performs reliably for the intended user. Test the smallest plan or trial from the actual device and network.

MTR, latency, and loss

Run MTR for several minutes during both quiet and busy periods. Focus on loss that continues through the destination, not an isolated intermediate hop that deprioritizes probes.

mtr -rwzc 100 example-ingress-host

Test several times around the local evening peak, such as 20:00–22:00. Compare the median and worst-case latency, jitter, destination loss, and outages. Do not use a universal “under 1% means IPLC” rule: performance depends on distance, carrier, congestion, probe handling, and the selected endpoint.

Throughput and application behavior

Use a reputable speed test and then the real workload:

• video startup, seeking, and sustained bitrate;
• voice or video-call stability;
• source-code or package downloads;
• the specific AI or streaming service required.

A single high speed-test result does not prove route type. Repeat tests at the same times over several days and retain the raw results.

6. What packet capture can and cannot tell you

Wireshark can confirm the client protocol, destination, reconnects, retransmissions, and timing visible on the local interface. It normally cannot reveal hidden relay hops or prove that the operator purchased IPLC/IEPL. Encryption also prevents inspection of protected application content.

Capture only traffic you are authorized to inspect, and redact server credentials before sharing a trace.

7. A practical evidence table

Provider label	Evidence you may observe	What remains unproven
IPLC / IEPL	Domestic ingress, overseas egress, stable performance, few visible hops, operator documentation	The underlying contract and whether every node uses it
CN2 / CN2 GIA	Visible CN2-associated hops, carrier and ASN evidence, repeatable path behavior	The exact purchased service tier and full bidirectional path
Multi-entry BGP relay	Different ingress networks or paths for different access carriers	Whether path selection is active, well engineered, or stable
Public-network relay	Visible public-carrier hops and normal Internet routing	Hidden tunnels or private segments elsewhere in the path
Direct overseas node	Client connects directly to an overseas server IP	Future routing and peak-hour quality

Treat advertised latency, loss, hop-count, and throughput thresholds as examples tied to a particular location—not fingerprints of a route product.

8. Using an AI assistant

An AI assistant can explain traceroute, MTR, and ASN output, but it cannot run a valid test from your network merely from a node name or marketing screenshot.

1. Collect a traceroute or MTR result from the actual connection.
2. Look up the visible addresses with IPWhois or RIPEstat.
3. Remove subscription credentials and personal IP information.
4. Ask the assistant to distinguish observations from inferences and list alternative explanations.

The screenshots use DeepSeek. Any model can misidentify an ASN, overstate what a hop proves, or rely on stale routing data, so verify important conclusions in the current measurement.

Final checklist

1. Save the provider's exact route claim and the date.
2. Test the real ingress, not only the public egress IP.
3. Collect traceroute or MTR results on several days and at peak time.
4. Check visible prefixes and ASNs in current routing data.
5. Compare application performance on the same carrier and location.
6. Treat a route label as unverified unless several independent signals agree.
7. Prefer monthly billing while evaluating an unfamiliar provider.

For current provider comparisons, see the proxy-service selection and review guide.

Contributors: ermaozi

Previous page✈️ Qingyunti Review—An Established, High-Value Proxy Service

Next pageInstall and Configure Zsh with Oh My Zsh