Server IP per Redirect Hop

## Why it matters

"Which layer issued this redirect?" is the first question in any redirect investigation. The IP answers it. An edge IP on the http-to-https hop but an origin IP on the slug redirect tells you exactly which config file to open. It also exposes surprises: a loop that only occurs on one CDN POP, or a stale rule on one load-balancer member.

## How it works

Chrome reports the IP address of the server that answered each response. On a simple setup (one server, no CDN), every hop comes from the same IP. In production, you typically see multiple IPs:

• Edge IP: The CDN point-of-presence closest to you.
• Load-balancer IP: The pool's frontend, which may change per request (anycast, round-robin).
• Origin IP: The backend machine that computed the response.

A redirect chain may touch multiple layers. The http-to-https hop often comes from a CDN edge; the slug rewrite might come from the origin. The IPs tell you which layer owns each decision.

A null IP (no address shown) usually means the response came from cache (Chrome doesn't contact a server) or was an internal redirect like HSTS. That is itself information: an internal 307 from HSTS shows no IP because the browser generated it before touching the network.

## What does not matter

The same URL can answer from different IPs on different runs, especially behind a load balancer or anycast CDN. This is normal if the IPs belong to the same owner and you're hitting the same pool. The concern isn't consistency of IP, but attribution: does this IP belong to your CDN, your load balancer, or a third-party service?

A different IP doesn't mean a different server is breaking the redirect. It usually means routing balanced your request to a different pool member.

## Code example

An annotated redirect chain with layer attribution:

Hop 1: GET http://example.com
  -> 301 from 192.0.2.10 (Fastly CDN edge, via WHOIS)
  -> Location: https://example.com

Hop 2: GET https://example.com
  -> 301 from 192.0.2.10 (same Fastly edge)
  -> Location: https://www.example.com

Hop 3: GET https://www.example.com
  -> 301 from 203.0.113.50 (origin server, via DNS reverse lookup)
  -> Location: https://www.example.com/actual-page

Hop 4: GET https://www.example.com/actual-page
  -> 200 from 203.0.113.50
Copy

Reading this chain:

• Hops 1 and 2 (http to https, add www) are handled by your CDN at the edge.
• Hop 3 (trailing-slash or slug rewrite) comes from your origin.
• This split suggests: your CDN rewrites host+protocol, your origin handles paths.

A WHOIS lookup for the edge IP:

% whois 192.0.2.10
NetName: Fastly
Origin AS: AS54113
Copy

A reverse DNS lookup for the origin (if configured):

$ dig +short -x 203.0.113.50
origin-1.example.com.
Copy

## How Scalpel shows it

Scalpel Redirects displays the IP address on each hop, with a reverse-DNS result if available. For known CDNs and cloud providers, a country icon or provider name is shown alongside so you can quickly see which layer produced each response. A null IP on a cached or internal hop is also displayed, which helps you distinguish a browser-side optimisation from a server response.

If the IP changes unexpectedly mid-chain (for example, hops 1 and 2 from an edge, hop 3 from a different edge), you have found a routing boundary or a misconfiguration worth investigating.