2021 — Global Proxy Nodes: Balancing Latency and Stability

What Happened That Year

In 2021, more Chinese companies expanded overseas -- cross-border e-commerce, overseas marketing, and global content collection. These businesses needed stable overseas proxy services. But cross-border proxies have two inherent challenges: high latency from physical distance and stability issues from complex international networks.

The most important thing we did that year was deploy our own service nodes in North America, Europe, and Asia-Pacific, enabling users to access proxy services with lower latency through nearby nodes.

Challenges of Cross-Border Proxy

Cross-border proxy services differ fundamentally from domestic proxies. When using a proxy domestically, requests travel from the client to the proxy server to the target website, typically passing through only two or three network nodes with stable and controllable latency. But once traffic crosses national borders, the network path becomes extremely complex.

A typical cross-border proxy request traverses: user -> local ISP -> national backbone network -> international egress -> submarine cable -> destination country backbone network -> target server. Every link along this path can become a bottleneck.

Scarcity of international bandwidth. International egress bandwidth is a very limited resource compared to domestic bandwidth. During peak hours, massive cross-border traffic competes for limited international bandwidth, causing significant latency increases. This is particularly noticeable when connecting to Southeast Asia, Europe, and South America.

Uncontrollable routing paths. The path cross-border traffic takes depends on carrier interconnection agreements and BGP routing policies. You cannot control which intermediate nodes your data packets traverse, nor can you predict whether a segment of the path is congested. Sometimes a seemingly "shortest" route path actually delivers worse latency than a longer detour, because of insufficient processing capacity at an intermediate node.

The Components of Latency

A cross-border proxy request's latency consists of several parts: physical latency (speed of light -- Shanghai to Los Angeles is at least 100ms round trip), transmission latency (each routing hop adds 1-5ms, cross-border paths typically have 15-30 hops), proxy processing latency (5-20ms), and target server latency (50-200ms).

A typical cross-border request has a total latency of around 200-400ms. For most web browsing scenarios, under 300ms is acceptable, over 500ms noticeably impacts experience, and over 1 second makes normal use difficult.

Physical Constraints: Submarine Cables and POP Points

The physical limit on cross-border latency comes from the speed of light in optical fiber. Taking the China-to-US West Coast route as an example, the actual submarine cable path is about 12,000 kilometers -- not the 9,000-kilometer straight-line distance, because cables must follow the seabed terrain, navigating around protected marine areas and obstacles. Light travels through fiber at roughly 65% of its speed in a vacuum, yielding a theoretical one-way latency of about 60ms and a round trip of at least 120ms. Adding processing delays from routers and repeaters on both ends, the actual physical latency lands between 130 and 150ms. This is a physical ceiling that no optimization technique can overcome.

The distribution of global submarine cables directly impacts proxy service quality. Major cables in the Asia-Pacific region include SEA-ME-WE 3/4/5 (connecting Southeast Asia, the Middle East, and Europe), the China-US cable (a direct link between China and the United States), and APCN-2 (Asia-Pacific interconnection). Cable landing points determine the optimal POP site selection. When choosing node locations, we prioritized data centers near major cable landing stations to minimize the last mile of terrestrial transmission.

Our POP distribution strategy calls for at least two Points of Presence in each core region, each connected to different carriers and cable systems. This way, if one cable or carrier experiences a fault, the other POP can continue serving traffic. In 2021, we deployed a pair of POPs on the US West Coast (Los Angeles, San Jose) and another pair on the East Coast (New York, Washington DC), ensuring the east and west coast paths serve as mutual backups.

Node Deployment Strategy

When deploying overseas nodes in 2021, we followed several core principles:

Proximity access. User requests should be routed to the nearest service node. A user in Japan should not have requests forwarded through a node in Europe. Proximity access not only reduces latency but also reduces the unpredictability of cross-border links.

Regional coverage. Node deployment needs to cover primary business regions. Our initial deployment covered core regions including North America (Los Angeles, New York), Europe (Frankfurt, London), and Asia-Pacific (Singapore, Tokyo). We gradually expanded to more regions based on user needs.

Redundancy. At least two available nodes are deployed in each region. When one node encounters problems, traffic automatically switches to other nodes in the same region. Cross-regional failover is maintained as an emergency plan.

Technical Considerations for Node Selection

When selecting specific node locations, we evaluated multiple factors:

Network quality. Network quality varies significantly between data centers. We continuously tested and compared latency and connectivity rates from each data center to major target websites, selecting the best-performing locations.

Target coverage. A node's value depends on its network quality to user targets. A US-based node that has low latency and high connectivity to major US target websites is valuable. Conversely, a node in a great location with poor routing to target websites has limited practical value.

Stability history. Data center stability is another important consideration. Some data centers have decent latency but experience frequent network fluctuations. We preferred data centers with a track record of consistent stability over those that are occasionally optimal but intermittently problematic.

Regional Network Characteristics Differences

Through our overseas node deployment, we accumulated extensive real-world data on network characteristics across different regions. These differences directly influenced our node deployment strategy and service quality.

North America has the most mature network infrastructure. Bandwidth between the US East and West Coasts is abundant, with numerous data center options and high-quality interconnection between major carriers (Level3, Cogent, CenturyLink, and others). However, in practice we found that last-mile quality varies significantly between US carriers -- users on regional ISPs could experience 50 to 100ms higher latency to our nodes compared to users on Comcast or AT&T. When deploying in North America, we prioritized data centers with multi-carrier connectivity and optimized routing strategies for each major carrier.

Europe is characterized by good cross-border network interconnection between countries. Frankfurt serves as Europe's network hub -- DE-CIX is one of the largest internet exchange points globally, connecting over 1,000 network operators. Our Frankfurt node can reach most European countries through DE-CIX with very low latency. The challenge in Europe, however, lies in data protection regulations (GDPR) restricting cross-border data transfers, requiring additional compliance efforts.

Asia-Pacific has the most complex network environment. Interconnection bandwidth between Southeast Asian countries is limited -- latency from Singapore to Vietnam might be as low as 20ms, but from Singapore to the Philippines it can exceed 100ms. Japan has excellent network infrastructure with low latency from Tokyo to major cities, but Japanese carriers enforce strict QoS policies on overseas traffic. Our strategy for Asia-Pacific was to deploy at least one local node in each key country, minimizing cross-border relays whenever possible.

How to Judge Proxy Stability (Part 5): Node Coverage and Proximity Routing

In 2021, we advised users to evaluate a provider's node coverage and proximity routing capabilities. Key questions:

• Which regions are covered? Does it cover the regions where your business operates?
• Is there proximity-based routing? Is your request routed to the nearest node?
• Does your actual connection use the optimal path or a fixed path?
• If a node in a region fails, how is traffic switched?

A provider claiming "global nodes" is not enough. What matters is whether those nodes can actually serve you.

What We Built That Year

• Deployed service nodes in core regions including North America, Europe, and Asia-Pacific
• Established regional node deployment with intelligent routing for proximity access
• At least two backup nodes in each region
• Cross-border business response times significantly reduced

One Piece of Advice

When choosing a cross-border proxy, do not just check if it connects. Check which node serves you and what the latency is in milliseconds. Multi-region coverage, proximity routing, and node redundancy are the three key indicators for evaluating cross-border proxy stability.

Cross-Border DNS Resolution Challenges

In cross-border proxy scenarios, DNS resolution is an often-overlooked but highly impactful factor. When domestic DNS servers resolve overseas domain names, they may return IP addresses of CDN nodes that are closer to China. However, those IPs may be inaccessible or very slow when reached through an overseas proxy. Therefore, cross-border proxies need special attention to DNS configuration -- using remote DNS resolution is often more reliable than local DNS.

DNS Resolution: Specific Problems and Solutions

In production operations, we encountered three typical types of cross-border DNS issues.

The first is DNS cache pollution. DNS servers in certain regions have been tampered with or configured with incorrect caching policies, returning wrong IP addresses. This is particularly noticeable when accessing specific target websites. Our solution is multi-layer DNS verification -- querying multiple independent DNS servers simultaneously and comparing results for consistency, accepting only resolutions that a majority of servers agree on.

The second is CDN routing bias. When domestic DNS servers resolve overseas domain names, they may return IP addresses of CDN edge nodes closer to China (such as Hong Kong or Singapore nodes). But when the proxy node is located in the US, this actually leads to worse performance. The solution is remote DNS resolution -- initiating DNS queries from the proxy node's region to obtain the optimal resolution for that region. We built a dedicated distributed DNS resolution cluster, deploying a set of DNS resolvers in the US West, US East, Europe, and Asia-Pacific.

The third is DNS-over-HTTPS (DoH) compatibility. Some target websites have adopted DoH, which traditional DNS query methods cannot correctly resolve. We upgraded the proxy's DNS handling module to support DNS resolution over HTTPS, ensuring compatibility.

Node Deployment Priority

When deploying overseas nodes in 2021, we prioritized regions with the most urgent user demand. The first batch covered core regions including North America (Los Angeles, New York), Europe (Frankfurt, London), and Asia-Pacific (Singapore, Tokyo), with at least two redundant nodes per region. Subsequent deployment expanded to more regions based on user feedback.

When selecting specific data centers, we compared multiple metrics: network quality (latency and connectivity to major targets), target coverage (path quality from node to target websites), and stability history (historical network fluctuation records).

Regional Operations Differences

Operating overseas nodes differs significantly from domestic nodes. Network infrastructure levels vary greatly between regions, as does the responsiveness of local carriers. Some data centers provide fast operational response, while others require scheduling maintenance windows hours in advance. These differences directly impact fault response speed.

We also noticed significant differences in user usage patterns by region. North American users tend to use the service during daytime hours, while Asia-Pacific spans multiple time zones with different working hours. This means there is no true "off-peak" period -- the system must maintain high availability 24/7.

Considerations When Choosing a Cross-Border Proxy

Based on our 2021 experience, here are several recommendations for users who need cross-border proxies:

First, choose a provider with clear regional node coverage, not one that vaguely claims to "have overseas nodes."

Second, confirm whether the proxy nodes support proximity routing -- whether your traffic will be routed to the nearest node.

Third, pay attention to node redundancy -- if a node in a particular region fails, will your business be affected?

Fourth, test with your actual business scenarios, not just latency test data. Different types of businesses have different sensitivity to latency and stability.

Typical Application Scenarios for Cross-Border Proxy

The cross-border users we served in 2021 covered a wide range of business scenarios, each with very different requirements for proxy services.

Cross-border e-commerce operations formed the largest user group. These users needed to manage multiple overseas storefronts simultaneously, with each store requiring an independent IP environment to avoid being flagged as linked accounts by e-commerce platforms. They demanded high IP purity and stability, and had specific requirements for "IP warm-up time" -- after switching to a new IP, they would not immediately initiate high-volume traffic, but instead start with low traffic to let the IP establish normal access records with the storefront.

Overseas ad verification was the fastest-growing scenario. Advertisers needed to view ads from local IPs in the target market to verify correct ad delivery and content accuracy. This scenario was less sensitive to latency (300-500ms was acceptable) but had extremely strict requirements for IP geolocation accuracy -- ad verification must use city-level IPs from the target area, otherwise the verification results are invalid.

Public data scraping had intermediate latency and stability requirements. Scraping tasks were typically large-scale and automated; individual request latency was not critical, but overall success rate directly impacted scraping efficiency. These users were characterized by stable traffic patterns, price sensitivity, and low tolerance for failure rates (since every 1% failure in millions of requests means a massive number of retries).

After understanding these scenario differences, we made targeted optimizations in node configuration and resource allocation: static IPs and longer IP usage cycles for e-commerce users, city-level IP geolocation tagging for ad verification users, and batch APIs with automatic retry mechanisms for data scraping users.

Global Node Operations System

Operating overseas nodes is significantly more complex than domestic nodes -- spanning time zones, languages, and cultures, each requiring different approaches. We established a region-based operational collaboration mechanism: each major region has local operational support, complemented by a unified global monitoring and alerting center.

The issue response flow: monitoring detects anomaly -> global center performs initial diagnosis -> synchronizes to local team -> local team handles on-site or remotely -> global center confirms recovery.

In 2021 operations, the most common issues were not severe faults like node outages, but sub-health problems such as network quality degradation -- nodes were online with acceptable latency, but packet loss rates had noticeably increased. These problems are the hardest to diagnose because they rarely trigger alerts in most monitoring systems.

We specifically added packet loss monitoring and path quality analysis for these cases. When packet loss on a node's path exceeds a threshold, the system automatically marks the node's service quality as degraded and triggers the investigation process.

Evolution of Node Scheduling Strategy

Before 2021, node scheduling was primarily based on the "static proximity" principle -- users were assigned to the geographically nearest node. But in production we found that geographic proximity does not always mean optimal performance. Consider a user in Japan: assigning them to the Tokyo node would indeed give the lowest latency, but if the path from the Tokyo node to the user's target website is congested, the actual experience could be worse than routing through the Singapore node instead.

Based on this finding, we gradually evolved our scheduling strategy from "static proximity" to "dynamic real-time optimization" in 2021. Specifically, we built a global node health matrix that tracks latency, packet loss, and availability from each node to major target network regions in real time. When a user initiates a proxy request, the system considers not just the distance from the user to the node, but also the overall network quality from each node to the user's target, selecting the node with the highest composite score.

After the dynamic optimization strategy went live, the end-to-end availability rate for cross-border requests improved by approximately 2 percentage points. More importantly, it made node load more balanced -- previously, popular nodes were consistently overloaded while less popular ones sat idle. After dynamic scheduling, node utilization improved by about 30%.

Cross-Border Routing Configuration and Optimization

Cross-border proxy routing configuration differs significantly from domestic proxy routing. In domestic scenarios, the network path between client and proxy server is relatively controllable, leaving limited room for routing optimization. In cross-border scenarios, however, the optimization potential is much greater -- and considerably more complex.

Our core approach is BGP-based multi-path routing. By connecting to different carrier networks across multiple data centers and dynamically advertising IP prefixes via the BGP protocol, we let internet routers automatically select the optimal path to reach our nodes. When a carrier link experiences issues, BGP automatically converges to other available links. However, this approach relies on a multi-homing network architecture, requiring each node to be connected to at least two independent carriers, which carries higher operational costs.

Another commonly used optimization technique is TCP protocol optimization. Packet loss rates on cross-border links are typically higher than on domestic links (0.5% to 2% versus under 0.1%), and standard TCP congestion control algorithms perform poorly in such environments. We enabled the BBR congestion control algorithm on our proxy nodes -- it adapts better than the traditional CUBIC algorithm to high-latency, high-packet-loss environments. Measured data shows that BBR can improve throughput by 30-50% in cross-border scenarios.

Additionally, we deployed connection reuse pools. For scenarios with a large number of short-lived connections (such as web scraping), establishing a new TCP connection for each request significantly increases latency. The connection reuse pool maintains a set of persistent connections to target websites, allowing new requests to reuse existing connections directly, reducing TCP handshake and slow-start overhead. This optimization reduced request latency by approximately 40% in short-connection scenarios.

Cross-Border Network Changes in 2021

Several significant changes occurred in the international network environment in 2021 that directly impacted cross-border proxy services.

International egress bandwidth prices continued to rise. Driven by the global pandemic, demand for international bandwidth surged in 2020-2021 -- remote work, video conferencing, and cross-border data transmission all saw massive growth. Meanwhile, new submarine cable capacity typically takes two to three years to become operational, so supply could not keep pace. This supply-demand imbalance drove international bandwidth leasing prices up by approximately 15-30%. Since bandwidth is one of the primary operational costs for proxy services, this directly impacted service providers' cost structures. Some smaller providers were forced to scale back their overseas node deployments or raise prices. This further widened the experience gap between providers with self-built overseas nodes and those relying on relay transit.

Some countries and regions strengthened network censorship and content restrictions. In 2021, multiple countries introduced new internet data management policies that affected cross-border traffic routing paths and stability. Several previously stable cross-border routing paths became intermittently unreliable, with data packets potentially being intercepted or redirected. We established a "dynamic routing avoidance" mechanism for this situation -- when anomaly rates on a path exceed a threshold, traffic is automatically rerouted through alternative paths, and the problematic path is logged for subsequent analysis.

Major global cloud providers expanded their data center footprint. In 2021, AWS, Google Cloud, Azure, and other major cloud providers opened data centers in more regions, including Jakarta, Hyderabad, Melbourne, and other areas that were previously under-covered. This gave us more options for node placement. In the second half of 2021, we leveraged these newly opened regions to add nodes in Southeast Asia and South Asia, effectively reducing average latency for users in those areas.

Reflection and Outlook

In 2021, we invested significant resources in overseas nodes, but also recognized some issues we had not fully considered.

Global node coverage does not equal global service quality. Some nodes were deployed, but their routing paths to certain target networks were suboptimal, resulting in user experiences that were hardly better than not having the node. We adjusted our node evaluation criteria -- no longer measuring success by "whether we have a node" but by "network quality to major targets."

At the end of 2021, we conducted a comprehensive global node network assessment and identified optimization directions for 2022: further improve network quality across all regional nodes, and expand more product types to match diverse user needs.

Regional Network Characteristics Comparison

Network characteristics vary significantly across regions. North America has the most mature network infrastructure, abundant data center options, and ample bandwidth -- though interconnection issues between different carriers can occasionally arise. Europe has good cross-border network interconnection between countries, with Frankfurt serving as the European network hub. Asia-Pacific has the most complex network environment, with Singapore as the regional network hub offering the shortest routes to Southeast Asia, though links between some countries remain unstable.

South America has relatively limited network infrastructure with constrained international egress bandwidth. Brazil serves as the regional network center, but latency to Asia typically exceeds 300-400ms. Users in South America generally experience poor performance when accessing Asian target websites -- a physical limitation that is difficult to improve in the short term. Our 2021 strategy for South America was to deploy edge nodes focused on protocol optimization (connection reuse, data compression) rather than pursuing low latency.

The Middle East presents a highly uneven network landscape. The UAE and Israel have good network infrastructure with ample data center options, while some other countries in the region have heavily restricted networks with limited cross-border traffic. Middle Eastern users' proxy needs are primarily focused on social media and content access, with relatively low sensitivity to latency (accepting 200-400ms) but high requirements for connectivity reliability. Our strategy in the Middle East prioritized connectivity rate as the primary goal, with latency as a secondary consideration.

Specific Global Operations Challenges

Operating overseas nodes follows a completely different playbook from domestic nodes. The operational challenges we faced in 2021 came from three main areas.

Time zone coverage. Our global nodes span multiple time zones, requiring 24/7 coverage from our operations team. We structured the team across three main time zones (China, Europe, US East Coast), providing round-the-clock coverage through a handoff model. However, information transfer during shift changes was a weak point -- if issues from the previous shift were not fully handed over, the next shift could spend significant time re-diagnosing problems. We established structured handoff templates and an issue status tracking system to ensure every ongoing issue had a clear current status and next steps.

Language and communication overhead. Data center technical support teams in different regions speak different languages. North American and European data centers primarily use English, making communication smooth. However, some Asia-Pacific data centers require local languages (Japanese, Korean, Thai, and others) for timely responses. We built standardized fault-ticketing templates that include machine-translated core technical parameters, reducing communication delays caused by language differences.

Local compliance requirements. Some countries have specific compliance requirements for data center operations. Russia, for example, requires data storage localization, and South Korea requires user data protection certification. Before deploying nodes in any new region, we engaged local legal counsel to assess compliance requirements and ensure lawful operations.

Global Operations Challenges

Overseas node operations are more complex than domestic operations. Data centers in different regions have different operational procedures -- some support remote management, while others require on-site intervention. We established a region-based operational collaboration mechanism: each major region has local operational support, complemented by a unified global monitoring and alerting center. When issues arise, the global center performs initial diagnosis, then coordinates with the local team for follow-up.

2021 Reflection

The biggest lesson from 2021 was recognizing that global coverage does not equal global service quality. Some nodes were deployed, but their routing paths to certain targets were suboptimal, making the actual experience hardly better than not having the node. We adjusted our evaluation criteria -- no longer aiming for "having a node" but measuring "network quality to major targets."

Looking Ahead to 2022

The 2021 global node deployment laid the foundation for subsequent development. The direction for 2022 was to further enrich product offerings by introducing residential proxies and datacenter proxies, catering to users' more granular requirements.

Cross-Border Compliance Considerations

In 2021, as global data protection regulations became increasingly stringent, compliance issues for cross-border proxy services also came into focus. Different regions have varying requirements for cross-border data transfers -- Europe has GDPR, the US has state-level data protection laws, and Asia-Pacific countries are successively introducing similar regulations. While proxy services help users access overseas resources, they must also ensure their own operations are compliant.

We took several measures: first, segregating user operational logs by region at the data storage level to avoid compliance risks from cross-regional data transfer; second, responding to local data requests within each region's legal framework; and third, clearly stating data storage locations and processing methods in our user agreements. While these compliance measures added operational costs, they provided assurance for the long-term stable development of the business.

One Piece of Advice

When choosing a cross-border proxy, do not just check if it connects. Check which node serves you and what the latency is in milliseconds. Multi-region coverage, proximity routing, and node redundancy are the three key indicators for evaluating cross-border proxy stability. If a provider claims to have global nodes, ask further: in which regions? What is the latency from each region to major targets? What happens if a node in one region fails?