Traffic routing is the process of directing incoming web requests to appropriate destinations, servers, content variants, geographic locations, or entirely different URLs, based on attributes of the request, the requesting client, or configured business rules. Every web request that arrives at a network infrastructure component, a DNS resolver, a CDN edge node, a load balancer, a reverse proxy, or a web server: is subject to routing decisions that determine where it goes next.

Traffic routing operates at multiple layers of the internet infrastructure stack simultaneously. At the DNS layer routing determines which IP addresses are returned for a domain, directing users to different server clusters based on geographic location. At the CDN layer routing determines which edge node handles a request, directing users to the nearest point of presence. At the load balancer layer routing distributes requests across backend server pools, balancing load across available capacity. At the application layer routing determines which specific content or redirect response is returned, matching request attributes against configured rules to produce the appropriate response.

Redirect management is a specific application of traffic routing, routing incoming requests for specific URLs to different destination URLs through HTTP redirect responses. Understanding traffic routing more broadly, the full range of mechanisms through which web requests are directed, provides context for how redirects fit into web infrastructure and how sophisticated routing logic can be implemented at different infrastructure layers.

Traffic routing at the DNS layer

DNS-based routing is the first routing decision a web request encounters, before any HTTP connection is established the client must resolve the domain to an IP address and the DNS response determines which server the request reaches.

GeoDNS: returning different IP addresses in DNS responses based on the geographic location of the requesting resolver. A user in Europe receives European server IP addresses, a user in Asia receives Asian server IP addresses, each connecting to the nearest infrastructure without any application-layer routing logic. GeoDNS is the foundation of global load distribution for multinational services, directing users to the nearest infrastructure purely through DNS before any HTTP connection is made.

GeoDNS is implemented at the authoritative DNS level, the DNS provider that serves the authoritative records for a domain configures geographic routing rules. DNS providers with GeoDNS capabilities, AWS Route 53 Geolocation Routing, Cloudflare Load Balancing, allow associating different DNS records with different geographic regions.

DNS failover routing: returning different IP addresses in DNS responses based on server health. When a primary server fails health checks its IP address is removed from DNS responses, users are automatically routed to healthy backup servers through updated DNS records. DNS failover is slower than load balancer failover, DNS TTL limits how quickly the routing change propagates, but provides geographic redundancy that load balancers within a single data centre cannot.

Weighted DNS routing: distributing traffic across multiple server endpoints by returning different IP addresses with different frequencies. Weighted routing enables gradual traffic migration, routing 10% of traffic to a new server while routing 90% to the existing server, and canary deployments, exposing a small percentage of users to new infrastructure before full rollout.

Latency-based routing: routing requests to the server endpoint that provides the lowest network latency for the requesting client, measured through ongoing latency monitoring between routing infrastructure and server endpoints. AWS Route 53’s Latency-Based Routing routes requests to the AWS region with the lowest measured latency from the requesting resolver, automatically selecting the fastest server endpoint for each user.

Traffic routing at the CDN and edge layer

CDN and edge network routing happens after DNS resolution but before requests reach origin servers, at the infrastructure layer between users and origins.

Anycast routing: the mechanism that enables CDN edge nodes to serve nearby users from the same IP address. Anycast assigns the same IP address to multiple servers at different geographic locations, network routing protocols automatically direct traffic to the nearest server with that address. A user in Tokyo connecting to an anycast IP reaches the Tokyo edge node. A user in London connecting to the same IP reaches the London edge node. Anycast routing is transparent to users, they connect to the same IP address but reach different physical servers based on their location.

Content-based routing at the edge: CDN edge nodes route requests to different backend origins based on request content, URL path, request headers, query parameters. A CDN rule that routes /api/* requests to an API server cluster and /static/* requests to an object storage origin implements content-based routing at the CDN layer, different content types served from optimised backends without application-layer logic.

Edge function routing: Cloudflare Workers and equivalent edge computing platforms implement arbitrary routing logic at edge nodes. An edge function can inspect any request attribute, URL, headers, cookies, geographic data, device type, and route to different backends, serve cached content, or return direct responses, including redirect responses: based on complex logic.

Cache-based routing: CDN edge nodes serve cached responses without forwarding requests to origins, a routing decision that keeps traffic at the edge rather than forwarding to backends. Cache hit rate, the proportion of requests served from edge cache, directly affects the distribution of traffic between edge and origin. High cache hit rates mean most traffic is handled entirely at the edge, origins receive only cache miss traffic.

Traffic routing at the load balancer layer

Load balancer routing distributes traffic across multiple backend servers, ensuring no single server bears the full burden of handling all requests.

Algorithm-based routing: load balancers implement several distribution algorithms. Round-robin, distributing requests sequentially across the server pool. Least connections, routing each request to the server with fewest active connections. Weighted distribution, routing more requests to higher-capacity servers. IP hash, consistently routing the same client IP to the same server for session persistence.

Health-based routing: load balancers continuously monitor backend server health through health checks, HTTP requests to health check endpoints that verify servers are responding correctly. Unhealthy servers are removed from the routing pool automatically, traffic redistributes to healthy servers without human intervention. Health-based routing provides automatic failover, server failures are detected within seconds and traffic is rerouted before users experience sustained errors.

Content-based load balancing: Layer 7 load balancers route requests based on HTTP content, URL path, Host header, cookie values. Different URL paths can route to different backend service pools, /api/* requests to API servers, /admin/* requests to admin servers, all other traffic to web servers. Content-based load balancing enables microservices architectures, routing requests to specialised backend services based on the service indicated by the URL path.

Sticky sessions: routing all requests from a specific client consistently to the same backend server, necessary for applications that store session state on individual servers rather than in shared storage. Sticky sessions are implemented through cookies, the load balancer sets a cookie identifying the target backend server and uses it to route subsequent requests from that client.

Traffic routing in redirect management

Redirect management is fundamentally a traffic routing application, incoming requests are routed to different URL destinations based on the request’s URL and other attributes.

URL-based redirect routing: the core redirect management routing pattern. Incoming requests are matched against configured redirect rules, each rule specifying a source URL pattern and a destination URL. Matched requests receive redirect responses directing the client to the configured destination. Unmatched requests either pass through to origin or receive a fallback redirect.

The routing logic evaluates rules in priority order, exact URL matches before prefix matches before wildcard matches before global fallback. This priority ordering ensures that specific rules take precedence over broader rules, a specific redirect for /old-page overrides a global redirect for /*.

Domain-based redirect routing: routing incoming requests to different redirect rule sets based on the request’s Host header, the domain the request was addressed to. A redirect management platform serving multiple customer domains maintains separate redirect rule configurations for each domain, the Host header determines which rule set to apply to each request. Domain-based routing enables multi-tenant redirect management, one platform serving thousands of customer domains each with independent redirect configurations.

Geo-redirect routing: routing requests to different redirect destinations based on the geographic location of the requesting client. A site that serves different regional content versions redirects users to their regional version based on IP-derived geolocation. example.com routes European visitors to example.com/eu/ and North American visitors to example.com/us/ through geographic routing rules. Geographic routing at the edge, implemented in Cloudflare Workers or CDN redirect rules, executes the routing decision near the user for minimal latency.

Device-based redirect routing: routing to different destinations based on the requesting client’s device type, detected through user agent string analysis or User-Agent Client Hints. Mobile device users may be routed to mobile-optimised content or app deep links. Desktop users receive the standard web experience. Device-based routing must be consistent for both users and search engine crawlers, routing Googlebot to different destinations than human users constitutes cloaking.

A/B testing traffic routing: randomly routing a configured percentage of traffic to different destination variants for experimentation. 50% of traffic to example.com/page-variant-a, 50% to example.com/page-variant-b. A/B routing at the edge, implemented in edge functions, enables experimentation without client-side JavaScript, eliminating flicker and providing accurate test conditions.

Traffic routing configuration approaches

Different infrastructure components provide different routing configuration mechanisms, the appropriate approach depends on where in the infrastructure stack the routing should be implemented.

Nginx routing configuration: server block directives route incoming requests based on Host header, directing traffic to appropriate virtual host configurations. Location blocks within server configurations route requests to different backends based on URL path. Return and rewrite directives implement redirect routing, matching URL patterns and returning redirect responses.

Apache routing configuration: VirtualHost containers route incoming requests by Host header. RewriteRule directives in conjunction with RewriteCond conditions implement complex URL-based routing..htaccess files enable directory-level routing overrides without server configuration access.

CDN routing rules: CDN platforms provide dashboard-based routing configuration, Cloudflare Redirect Rules, AWS CloudFront Behaviours, Fastly VCL, implementing content-based routing at the CDN layer. CDN routing rules execute at edge nodes, faster than origin-based routing for matching traffic.

Edge function routing: arbitrary routing logic implemented in JavaScript or other languages, executing at edge nodes globally. Edge functions provide the most flexibility, any request attribute can inform routing decisions, with execution at the edge for minimal latency.

Load balancer routing rules: Layer 7 load balancer configurations route requests to different backend pools based on URL path, Host header, or other request attributes. AWS Application Load Balancer listener rules implement content-based routing, forward rules send traffic to target groups, redirect rules return redirect responses directly from the load balancer.

Traffic routing monitoring and analytics

Understanding how traffic is flowing through routing infrastructure, and identifying routing anomalies, requires monitoring and analytics capabilities.

Request distribution analysis: monitoring how incoming traffic is distributed across routing destinations reveals whether routing rules are working as intended. An unexpected concentration of traffic at one destination may indicate a misconfigured routing rule. Traffic distribution that does not match expected geographic patterns may indicate GeoDNS misconfiguration.

Redirect traffic analytics: for redirect-specific routing analysing which redirect source URLs are receiving traffic reveals which legacy URLs are still being accessed, through bookmarks, backlinks, or archived content. High-traffic redirect sources may warrant special attention, updating linking sites to use canonical destination URLs eliminates the redirect hop for significant traffic volumes.

Error rate monitoring: routing decisions that send traffic to unavailable or misconfigured destinations generate errors. Monitoring error rates by routing destination identifies destinations that are returning unexpected responses, broken redirect chains, unavailable origin servers, misconfigured backend services.

Latency impact of routing decisions: routing through multiple hops, DNS to CDN to load balancer to origin, accumulates latency at each step. Monitoring end-to-end latency for different routing paths identifies bottlenecks, routing decisions that add disproportionate latency relative to the value they provide.