When purchasing a server, most people focus on a single metric: latency. They ping a test IP, see a figure like 50ms, and assume everything is solid. However, that number tells only half the story. It measures the total round-trip time—from your computer to the server and back—but reveals nothing about the specific paths taken during each leg of the journey. Yet, it is precisely the difference between these two paths that determines whether your server will suffer from the frustrating scenario where performance is fine during the day but collapses during evening peak hours.

　　What do "outbound" and "inbound" paths mean?

　　Network communication is bidirectional. When you visit a website, your request travels from your device to the server—this is the outbound path. After processing the request, the server sends data back to you—this is the inbound path.

　　In an ideal world, the outbound and inbound paths would be identical: the data would traverse the same routers in reverse order when returning from B to A as it did when traveling from A to B. This state is known as "symmetric routing." However, the reality of how the internet operates dictates that symmetry is the exception, while asymmetry is the norm.

　　A technical blog post by APNIC explains this clearly: traditional IP routing decisions are based solely on the destination address. When a network has multiple exit points and available paths, the outbound and inbound traffic can easily choose different routes. Asymmetric routing is a common phenomenon in enterprise environments with multiple network paths.

　　Data from academic research offers an even clearer picture. A large-scale measurement study by the IEEE found that over 90% of TCP flows experienced some form of asymmetric routing during transmission, and more than 70% of flows utilized different links for the outbound and inbound paths at the IP layer.

　　Why do outbound and inbound paths "part ways"?

　　The fundamental reason is that the internet is not a network under unified control; rather, it is formed by tens of thousands of Autonomous Systems (AS) that "negotiate" with one another using the BGP protocol. Each Autonomous System (AS) independently decides where to route its traffic, basing its decisions on its own cost structure and business strategy rather than on global, end-to-end optimization.

　　The most classic mechanism for this is "Hot Potato Routing." Imagine you are in California accessing a server in New York, and both your ISP and the server's ISP have nationwide network coverage. When data packets need to travel between the East and West Coasts, both ISPs want the other party to bear the cost of the expensive cross-country link. Consequently, your ISP will "toss" the packet to the other network as early as possible—handing it over while still in California. Conversely, when the server sends data back to you, its ISP applies the same logic, handing the packet back to your ISP while still in New York.

　　The result is that the outbound path might involve a handover in California, while the return path involves a handover in New York. The routers, links, and even the network operators involved in the two legs of the journey can be completely different. This is the underlying reason for the divergence between outbound and return paths.

　　Beyond "Hot Potato Routing," other factors exacerbate this asymmetry: BGP path selection rules (such as prioritizing routes with longer subnet masks), load-balancing strategies in multi-homed networks, and temporary routing adjustments following network failures can all cause outbound and return traffic to take different routes.

　　Why Focusing Only on the Outbound Path Can Lead You Astray

　　Once you understand that outbound and return paths can differ, it becomes clear why many people make mistakes when choosing a server.

　　A common scenario is pinging a US-based server from China and seeing a latency of 160ms—a figure that seems acceptable. However, that ping measures the round-trip time (outbound plus return), so you have no way of knowing which leg of the journey is the bottleneck. What is the actual user experience when the outbound path uses a premium route (such as CN2 GIA) but the return path uses the congested standard "163" backbone network? Your request reaches the server quickly and is processed rapidly, but the returning data gets stuck on the congested return link. From the user's perspective, it feels like "clicking once and waiting ages for a response."

　　Consider a real-world example: a Hong Kong server where the outbound path uses a direct CN2 connection, but the return path detours through the US or Singapore. This asymmetric routing causes high packet loss during the long-distance detour, manifesting to the user as frequent connection drops.

　　This is why a provider's "Looking Glass" tool is so important. A standard Ping test only measures the outbound path from your location, whereas Looking Glass allows you to run a traceroute from the server back to your location—essentially letting you see which nodes the data packets pass through on their way back to China from the server's perspective. Only by testing both directions can you determine if the route is "bidirectionally optimized."

　　The "Partial Optimization" Trap of CN2

　　The US-China route market offers the best example for understanding outbound/return path asymmetry.

　　CN2 is China Telecom's next-generation carrier network. Within this system, CN2 GIA represents the highest tier; it features a dedicated return channel to China and the highest priority, keeping packet loss rates extremely low even during evening peak hours. However, many US servers marketed as "CN2" actually only offer return-path optimization.

　　The reason lies in control: the return path (US to China) is controlled by the server's data center and its upstream bandwidth provider. By connecting to AS4809 (the Autonomous System number for CN2), a provider can ensure that data returning from the server to China travels via CN2. In contrast, the outbound path (China to US) is determined by China Telecom's routing policies; service providers have virtually no way to "force" China Telecom to route outbound traffic to their specific servers. This results in a "one-way CN2" phenomenon: the return path is fast, but the outbound path still utilizes the standard 163 backbone network. While the difference may not be noticeable during the day, during evening peak hours—when the 163 network is congested—your requests are sent out but get stuck on the outbound route, failing to reach the server in a timely manner.

　　Practical Issues Caused by Asymmetric Routing

　　The discrepancy between outbound and return paths involves more than just "slowness"; it triggers a chain reaction of issues.

　　Stateful firewalls may drop valid packets. Firewalls are "stateful" devices: when they see the initial packet of a traffic flow pass through, they record connection details in a state table and subsequently permit packets that match those records. However, if a return packet arrives via a different interface—one where the firewall lacks a record of the connection—it treats the packet as illicit traffic and drops it immediately. 

　　Source address verification may yield false positives. The uRPF (Unicast Reverse Path Forwarding) mechanism prevents IP spoofing by verifying whether a packet's source address arrives via the "correct" interface. With asymmetric routing, however, legitimate return traffic might enter through an unexpected interface; strict uRPF settings would classify this as forged traffic and discard it. 

　　Troubleshooting becomes extremely difficult. If you perform a traceroute from only one end, you see only the outbound path. If the issue lies with a node on the return path—such as link congestion or a router failure—it will not appear in the outbound traceroute at all. This is why "bidirectional tracing" is essential for troubleshooting: tracing from both ends allows you to piece together the complete path map.

　　How exactly do you conduct a bidirectional test?

　　Having covered the theory, the actual execution is straightforward. The core principle is to perform a traceroute from both directions, rather than simply pinging from one end.

　　Specifically, you need to do two things:

　　Test the outbound path (from local to server). Run `traceroute` or `mtr` from your own computer or a domestic test node to the server's IP address. Observe the nodes along the path to determine if the traffic is taking the expected route (e.g., CN2's 59.43.x.x range, China Unicom's 9929 range, or China Mobile's CMIN2 range).

　　Test the return path (from server to local). This is the step most people overlook. You need to run `traceroute` from the server to your local IP address (or a well-known domestic test node). The return path test should be performed using the service provider's "Looking Glass" tool, as this effectively allows you to "view the world from the server's perspective."

　　A practical tip: Use MTR instead of a standard traceroute. MTR combines the functions of traceroute and ping, displaying latency and packet loss rates for each hop, making it easier to pinpoint exactly which node is causing a bottleneck.

　　Timing is also crucial. Results obtained during the day can differ significantly from those during peak evening hours (20:00–23:00). Many issues related to asymmetric routing do not surface during periods of low load; they only become apparent when the network is congested.

　　FAQs

　　Q: Why is my ping latency to the server very low, yet access remains slow?

　　A: Ping measures total round-trip latency but does not reflect packet loss rates or path quality. If there is hidden packet loss (e.g., 1–3%) on either the outbound or inbound path, the average ping time might appear normal; however, actual TCP transmission will suffer from frequent retransmissions, resulting in perceived "stuttering" or "lag spikes" rather than just high latency. You need to use MTR to test both the outbound and inbound paths separately and examine the packet loss rate at each hop to identify the actual issue.

　　Q: A provider claims "CN2 optimization"—how can I tell if it is bidirectional?

　　A: Ask the provider for a Looking Glass URL or a test IP address. Run a traceroute from a domestic location to the server to test the outbound path, and then run a traceroute from the server back to a domestic location to test the inbound path. If the inbound path shows IP ranges starting with 41.144 or 183, it is likely using the "163" network for the return trip rather than true bidirectional CN2 GIA. With bidirectional CN2 GIA, the entire inbound path should utilize the 59.43.x.x IP range.

　　Q: What is the practical impact of asymmetric routing on my business?

　　A: It depends on the type of business. For content-heavy services (images, videos, static web pages), the quality of the inbound path is more critical because users are primarily "receiving" data. For interactive services (SSH sessions, database queries, online gaming), the quality of the outbound path is equally important, as your commands need to reach the server quickly. If the service involves heavy two-way interaction, both the outbound and inbound paths must be stable.

　　Q: Why do some providers guarantee CN2 routing for the inbound path but not the outbound path?

　　A: Because the outbound path is determined by the routing policies of ISPs like China Telecom, China Unicom, and China Mobile; a service provider cannot "force" these ISPs to route traffic into their specific network. What a provider *can* do is connect to a CN2 upstream carrier to ensure that the traffic they originate travels via CN2 (the inbound path). Optimizing the outbound path requires cooperation from the ISPs, which is something a single service provider cannot fully control. Q: Can using a CDN bypass the issue of asymmetric routing?

　　A: Partially. The fundamental function of a CDN is to cache static content at edge nodes closer to the user; requests for dynamic content still require a connection back to the origin server. If there are issues with the path back to the origin, dynamic requests will still be affected. However, the loading speed of static resources will improve significantly, leading to an overall better user experience. For interaction-intensive applications (such as online editing or real-time collaboration), a CDN cannot replace the need to optimize the connection to the origin server itself.