Why might a CDN, reverse proxy or load balancer appear instead of the original source?¶
title: "Why might a CDN, reverse proxy or load balancer appear instead of the original source?" card_id: "IP-104" status: "complete" source_document: "https://docs.google.com/document/d/1hPxQEOJpLl7xDxfanSjcbzfMsFXcgbY2JOeiAg7mou8/edit?usp=drivesdk"
Why might a CDN, reverse proxy or load balancer appear instead of the original source?¶
A service’s log shows an IP address belonging to a content delivery network, reverse proxy or load balancer. That may be the system that passed the request onwards, not the connection that originally contacted the service.
Many online services place infrastructure in front of their application servers. A content delivery network can deliver content and absorb unwanted traffic. A reverse proxy can receive requests and forward them to internal services. A load balancer can distribute traffic across several servers.
From the application server’s viewpoint, the immediate network connection may come from that fronting system. If the application simply records the address at the other end of its connection, its “source IP” field may contain the proxy or load balancer.
The original address may be passed onwards in another field, often in a header or platform-specific metadata. Names such as Forwarded and X-Forwarded-For are common, but the field name alone doesn’t make the value reliable. A client can sometimes supply its own header. The service needs a trusted configuration that removes, replaces or correctly extends untrusted values as traffic passes through its own infrastructure.
Ask the system owner to explain the route. Which component first received the external connection? Which address did it record? Which fields were added or changed? Which proxies were trusted? Were logs retained at the fronting layer, the application layer, or both?
Preserve the complete record and any associated request or session identifier. A copied IP address without the surrounding fields can remove the very information needed to identify the original observation point.
Also check the event time. Infrastructure and configurations change. A current network diagram or present-day ownership lookup may not describe the route used when the event occurred.
The appearance of a CDN, proxy or load balancer isn’t evidence that the user deliberately hid their address. It may be ordinary service architecture. You may be able to recover a better origin indicator from trusted fronting logs or correctly populated metadata, but don’t simply treat the leftmost or last address in a chain as the user. Its meaning depends on how that particular service created it.