BGP Routing and Proxy Exit Nodes: What Actually Happens Between AS Numbers
When a packet leaves a proxy exit node bound for a target website, it does not take the route that looks shortest on a map. It takes the route that the Border Gateway Protocol (BGP) has selected based on AS path length, local preference, and a handful of tiebreakers defined in RFC 4271. For a proxy operator, those BGP decisions determine latency, reliability, and whether a given IP appears to the target as coming from a residential ISP or from a tier-one transit provider. This post walks through how BGP decisions interact with proxy infrastructure, the difference between anycast and unicast exit strategies, and a real traceroute that shows the path selection in action.
BGP in One Paragraph
The Internet is a network of Autonomous Systems (AS), each identified by a 32-bit ASN. Every AS announces the prefixes it owns or transits to its neighbors using BGP. Neighbors select one best path per prefix based on a sequence of rules: highest local preference, shortest AS path, lowest origin type, lowest MED, eBGP over iBGP, lowest IGP cost, lowest router ID. The resulting forwarding table at each router is the Internet's distributed source of truth for "how do I reach 203.0.113.0/24."
A proxy provider that owns its own infrastructure either operates its own ASN (like Hex Proxies operates for ISP proxy exits) or leases addresses from an upstream that announces them. The difference matters: a provider with its own ASN controls prefix announcements, can deaggregate for traffic engineering, and presents a stable AS path to the target. A provider leasing capacity is at the mercy of the upstream's routing policy and may see paths change without notice.
ASN Ownership Affects Reputation
IP reputation systems inspect the originating ASN as part of their risk scoring. An IP announced by AS 7922 (Comcast Cable) carries a different residential-likelihood score than the same IP announced by AS 16509 (Amazon). Anti-bot vendors classify ASNs into categories: residential ISP, business ISP, hosting, transit, mobile, VPN, and unknown. A proxy provider that advertises prefixes out of a hosting ASN cannot claim residential status no matter how the IPs were acquired.
This is why the distinction between datacenter proxies, ISP proxies, and residential proxies is ultimately a BGP question. A datacenter proxy lives in a prefix announced by a hosting ASN. An ISP proxy lives in a prefix announced by, or SWIPed to, a consumer ISP ASN. A residential proxy rides on top of a genuine residential consumer line whose ASN is the consumer ISP's.
Anycast Versus Unicast Exit Nodes
A proxy operator with points of presence in multiple cities has two ways to present exit IPs to clients.
Unicast: Each PoP has its own distinct IP ranges. A client who wants to exit from Chicago connects to an IP announced only from Chicago. BGP routes traffic to that IP along whatever path is shortest to Chicago. The provider knows where every packet is going because each destination IP is anchored to exactly one location.
Anycast: Multiple PoPs announce the same prefix. BGP routes traffic to whichever PoP is closest in AS path terms. A client connecting to a single anycast endpoint might land in Frankfurt or Singapore depending on their upstream. Cloudflare, Fastly, and Google all use anycast for their edge networks. It is rare for proxy exit nodes because a proxy user usually wants a specific exit location, and anycast does not give them that guarantee.
A hybrid model uses anycast for the control plane (authentication, session setup) and unicast for data path (actual proxied traffic). This gives low-latency authentication regardless of client location while still allowing geographically specific exits. The Hex Proxies control plane at auth.hexproxies.com uses this pattern; the exit pools do not.
A Real Traceroute
Here is a traceroute from a test client in Amsterdam to an ISP proxy exit node in Ashburn, Virginia, taken during Hex Proxies internal testing in April 2026. ASN lookups added manually:
traceroute to 5.161.x.x (5.161.x.x), 30 hops max
1 gw.local (10.0.0.1) 0.3 ms
2 ams-core1.isp.nl (213.x.x.x) 1.2 ms AS1136 KPN
3 nl-ix.as8218.net (193.239.117.1) 1.8 ms AS8218 Zayo
4 ae-1.ams.zayo.net (64.125.x.x) 2.1 ms AS6461 Zayo
5 ae-7.lon.zayo.net (64.125.x.x) 8.4 ms AS6461 Zayo
6 ae-0.nyc.zayo.net (64.125.x.x) 71.2 ms AS6461 Zayo
7 ae-2.ashburn.zayo.net (64.125.x.x) 77.9 ms AS6461 Zayo
8 equinix-dc.hetzner.com (206.x.x.x) 78.3 ms AS24940 Hetzner
9 exit.hexproxies.com (5.161.x.x) 78.7 ms AS24940 Hetzner
Hop 5 is London. The BGP path from Amsterdam to Ashburn goes via London because Zayo's internal routing (via IGP metrics) prefers the LON-NYC transatlantic link over the AMS-NYC link for this destination. A user who assumed the path was geodesic would be surprised. The cross-Atlantic hop from London to New York accounts for 63 ms of the 78 ms total. That is the floor on latency imposed by speed of light and cable routing, and no amount of proxy tuning removes it.
Route Flapping and MTR
Traceroute shows one snapshot. For production monitoring, use mtr (My Traceroute) which runs the trace continuously and reports per-hop loss and jitter. A path with 0.1 percent loss at hop 4 and 0 percent elsewhere points to a specific transit provider having a congested link, and the appropriate response is to talk to your upstream about BGP LOCAL_PREF or communities that would steer traffic away from that path.
Proxy operators who monitor the BGP control plane directly (via a looking glass or a feed from RIPE RIS) can catch prefix hijacks and route leaks in real time. In June 2019, Verizon accidentally leaked a large number of prefixes from a small BGP optimizer in Pennsylvania, briefly black-holing Cloudflare, Facebook, and Amazon traffic. Proxy operators who were watching RIS saw the leak within seconds; those relying only on end-to-end monitoring saw it as a latency spike and only after probes failed.
MED and AS Path Prepending
A proxy operator with multiple upstreams at a single PoP can influence inbound traffic path selection using two tools.
AS path prepending artificially lengthens the AS path on one announcement so the other wins the BGP best path selection. Prepending 1-2 times is usually enough to shift traffic; prepending 5+ times is cargo-cult and may be ignored by large transits that filter excessive prepends.
MED (Multi-Exit Discriminator) is a hint to a single upstream about which of multiple parallel links they should use. It is only compared between announcements from the same AS, which limits its usefulness for multi-upstream scenarios.
For proxy traffic specifically, the interesting case is outbound: you want your proxy exit traffic to take a specific path to the target. Outbound path selection is controlled by your local routing policy, not by BGP announcements. Tools like Cisco PfR or the open source BIRD route server give you fine-grained outbound control.
What This Means for Choosing a Provider
When evaluating a proxy provider, ask three questions about their BGP posture:
- Do you own the ASN that announces your exit prefixes? If yes, you control reputation and routing. If no, your provider is reselling transit and any routing change at the upstream reflects in your traffic.
- Do you peer directly at major IXes? Direct peering at LINX, DE-CIX, AMS-IX, or Equinix-Ashburn bypasses transit hops and reduces latency and packet loss.
- How do you handle BGP route leaks? A provider that cannot answer this question has not thought about the failure mode that has broken production multiple times in the last decade.
Conclusion
BGP is the layer where proxy performance is either made or undone. A beautiful application-layer proxy implementation is worthless if the underlying BGP path takes your packets through a congested transit provider with 2 percent packet loss. When you see inconsistent latency from a proxy service, do not assume the application is slow. Run a traceroute. Look at the AS path. The answer is almost always visible in hops 2 through 6.