Behind Azure Application Gateway or Azure Front Door, IIS logs the Azure service 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. Application Gateway and Front Door are reverse proxies, so IIS sees the connection from an Azure address (the gateway's private IP or a Front Door edge IP) and logs that in c-ip. Both services pass the visitor's address in X-Forwarded-For (Front Door also sends X-Azure-ClientIP). Install an ISAPI filter on IIS that reads the header and writes the real address into the standard c-ip field, trusting only the relevant Azure ranges.
Azure Application Gateway and Azure Front Door are reverse proxies: they terminate the client connection and open a new one to your backend. The connection your IIS backend receives comes from the Azure service (the Application Gateway's private IP, or a Front Door edge IP), so the IIS c-ip log field records Azure addresses rather than the visitor's, and geolocation, reporting and security tooling lose the real client.
This is expected for a layer-7 service. Azure preserves the original client address in HTTP headers:
X-Forwarded-For header (in ip:port form) on requests to the backend pool.X-Forwarded-For and also its own X-Azure-ClientIP and X-Azure-SocketIP headers. If the request already carried an X-Forwarded-For header, Front Door appends to it rather than replacing it, and the value it appends is the socket IP.So the client IP reaches IIS in a header. But IIS doesn't read X-Forwarded-For natively. The header arrives and is ignored. That's the gap Winfrasoft X-Forwarded-For for IIS fills.
Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the X-Forwarded-For header Azure adds and writes the real client address into the standard IIS c-ip log field, with no application changes. A Proxy Trust List of the Azure addresses ensures only the Azure hop is trusted, so the genuine client is logged and the header can't be spoofed.
X-Forwarded-For automatically: no switch to enable.AzureFrontDoor.Backend service tag). (See the Installation & Configuration Guide for the exact trust-list format.)IISRESET, then browse the site and confirm the IIS c-ip field shows real client addresses. Note that Application Gateway formats X-Forwarded-For as ip:port, so verify how the value lands in your logs.Lock down the backend. So a client can't reach your servers directly and forge an X-Forwarded-For header, restrict the backend's network security group to the Application Gateway subnet, or, for Front Door, to the AzureFrontDoor.Backend service tag (and validate the X-Azure-FDID header). Trusting only Azure's addresses is what keeps the logged client IP reliable.
SocketIP is the address that actually opened the TCP connection to the Front Door edge, so it cannot be forged. ClientIP is Front Door's view of who the original caller is, and it is taken from the inbound X-Forwarded-For header when one is present, so a caller can set it to anything. When the visitor connects to Front Door directly the two are identical. They diverge whenever the visitor is behind their own proxy, VPN or CDN, and they diverge deliberately when someone is spoofing.
The distinction appears twice: once in the headers sent to your origin, and once in the Front Door access log.
| Header to origin | Access log field | What Microsoft says it contains | Forgeable? |
|---|---|---|---|
X-Azure-SocketIP |
SocketIp |
The socket address of the TCP connection the request arrived on: "the IP address of the direct connection to the Azure Front Door edge". If the visitor came via their own proxy or load balancer, this is that proxy's address, not the person's. | No. It is observed from the connection. |
X-Azure-ClientIP |
ClientIp |
The client address associated with the request. Microsoft is explicit that "if the request includes an X-Forwarded-For header, the client IP address comes from the header". |
Yes. Microsoft notes the client IP "can be arbitrarily overwritten by a user". |
X-Forwarded-For |
n/a | Front Door appends the client socket IP. Any inbound chain is preserved and the socket IP is added to the end of it. | Earlier entries yes. The entry Front Door appends, no. |
Two consequences worth being clear about. First, X-Azure-ClientIP is the friendlier-sounding header and the wrong one to trust on its own: it is derived from attacker-controllable input by design, because its job is to be helpful about proxied callers, not to be authoritative. Second, the value Front Door itself appends to X-Forwarded-For is the same trustworthy address as X-Azure-SocketIP, which is why reading X-Forwarded-For with a correct Proxy Trust List gets you the reliable answer while keeping one configuration that also works behind Cloudflare, F5, AWS and everything else. That is the point of trusting the proxy rather than the header: the filter walks the chain from the right and stops at the first address that is not a trusted hop, so caller-supplied entries on the left are never logged. How the header chain is read.
Yes. Application Gateway adds the client's address to the X-Forwarded-For header (as ip:port) on requests to the backend pool. No configuration is required.
Front Door sends the client IP in X-Forwarded-For, and additionally in its own X-Azure-ClientIP and X-Azure-SocketIP headers. X-Forwarded-For is the cross-vendor standard and is what X-Forwarded-For for IIS reads.
For Application Gateway, the gateway subnet's private IPs. For Front Door, the Front Door backend IP ranges (the AzureFrontDoor.Backend service tag). X-Forwarded-For for IIS then logs the first untrusted address, the real client.
SocketIp is the address of the direct connection to the Front Door edge, so it cannot be forged, but if the visitor used their own proxy it is that proxy's address. ClientIp is the original caller's address and Microsoft takes it from the inbound X-Forwarded-For header when one is present, so it can be arbitrarily overwritten by the caller. They match when the visitor connects directly and differ when there is another proxy in between, or when someone is spoofing.
Neither on its own. X-Azure-ClientIP is derived from a caller-supplied header by design, and X-Azure-SocketIP is Azure-specific, so a configuration built on it does not carry over to Cloudflare, F5 or AWS. Front Door appends the same trustworthy socket address to X-Forwarded-For, so read X-Forwarded-For with the Front Door ranges in a Proxy Trust List. You get the reliable address and one configuration that works behind every vendor.
Restore real visitor IPs in your IIS logs behind Azure Application Gateway or Front Door. Available now for IIS 10 on Windows Server 2016–2025, with a free 14-day trial.
View the product or request a download →