When IIS Application Request Routing (ARR) acts as a reverse proxy, your backend content servers log the ARR server's IP instead of your real visitors. Here's why, and how to record the true client IP in the standard IIS log using the X-Forwarded-For header.
Short answer. ARR makes a fresh request to the backend on the client's behalf, so the backend IIS server logs the ARR server's IP in c-ip. ARR forwards the visitor's address in X-Forwarded-For when the Preserve client IP proxy setting is on. Install an ISAPI filter on the backend that reads the header and writes the real address into the standard c-ip field, trusting only your ARR servers.
Application Request Routing (ARR) turns IIS into a reverse proxy / load balancer in front of one or more backend content servers. ARR receives the client request and makes a new request to the backend on the client's behalf, so the backend IIS server sees the connection coming from the ARR server. The backend's c-ip log field therefore records the ARR server's IP for every request, and geolocation, reporting and security tooling lose the real visitor.
The backend's network peer is the ARR server, not the client. ARR can carry the original client address to the backend in an HTTP header:
X-Forwarded-For by default, so ARR adds the client's IP to the X-Forwarded-For header on each request it forwards.X-ARR-LOG-ID, and it is worth knowing what that one is not. It carries a per-request correlation GUID for tracing a request from ARR through to the backend, not an address. If you are hunting for the visitor's IP, X-Forwarded-For is the header to read.So the client IP reaches the backend in a header. But IIS doesn't read X-Forwarded-For natively. The header arrives at the content server and is ignored. That's the gap Winfrasoft X-Forwarded-For for IIS fills.
Install Winfrasoft X-Forwarded-For for IIS on the backend content servers (the ones doing the logging). It's an ISAPI web filter that reads the X-Forwarded-For header ARR adds and writes the real client address into the standard IIS c-ip log field, with no application changes. A Proxy Trust List of your ARR server IPs ensures only the ARR hop is trusted, so the genuine client is logged and the header can't be spoofed.
X-Forwarded-For (IIS Manager → server node → Application Request Routing Cache → Server Proxy Settings).IISRESET on the backend, then browse the site and confirm the backend IIS c-ip field shows real client addresses.Lock down the backend. So a client can't reach the content servers directly and forge an X-Forwarded-For header, restrict the backend (firewall or IIS IP restrictions) to accept traffic only from your ARR servers. Trusting only the ARR addresses is what keeps the logged client IP reliable.
Yes — ARR's server proxy settings include Preserve client IP in the following header, set to X-Forwarded-For by default. ARR adds the client's IP to that header on each forwarded request; the backend just needs to log it.
On the backend content servers, because those are the servers whose IIS logs you want to show the real client. The ARR server only needs the "preserve client IP" header setting enabled.
No. X-ARR-LOG-ID is a correlation GUID that Application Request Routing attaches to each forwarded request so you can match an entry in the ARR server's log to the matching entry on the backend. The name misleads people into treating it as a logging value for the client, but it holds no address at all. The client IP travels in X-Forwarded-For. Logging both is useful: X-ARR-LOG-ID traces the request across the hop, c-ip tells you who made it.
The IP address(es) of your ARR server(s): the source the backend servers see. X-Forwarded-For for IIS then treats those as trusted and logs the first untrusted address, the real client.
Restore real visitor IPs in your backend IIS logs behind ARR. Available now for IIS 10 on Windows Server 2016–2025, with a free 14-day trial.
View the product or request a download →