How to Validate Client IP Preservation Before Production Without Trusting the Wrong Signal

Most client IP preservation failures do not come from missing features. They come from teams trusting the wrong identity signal at the wrong hop. Edge logs show one address, the app reads another, and rate limiting quietly keys off something else. If you want the broader framework behind these choices, start with Proxy Protocols vs PROXY protocol in production and how to preserve client IP correctly . The dangerous part is that these rollouts often look healthy at first. Requests succeed. Dashboards stay green. But once incident response, abuse controls, or geo-based policy depends on the preserved client identity, the mismatch becomes expensive. This post is not a generic setup guide. It is a validation workflow for operators who need proof on the wire, proof at the listener, and proof in downstream consumers before rollout. Verify the sender, the receiver, and the first bytes on the wire Before touching a listener, verify three things. First, identify exactly which hop emits the clie