Most people who need this solved didn't come looking for a logging feature. They came because a SIEM is alerting on the wrong address, a geo-IP report is meaningless, or an auditor asked where the source IPs in the W3C logs come from. Here's why the standard c-ip field is the one that has to be right.
Short answer. Every SIEM connector, log shipper, geo-IP lookup and compliance parser that consumes IIS logs reads the standard c-ip field. Behind a proxy that field contains your load balancer, so correlation, threat detection and audit trails are all keyed to the wrong address. Adding X-Forwarded-For as an extra column doesn't fix it: the connector still reads c-ip, and an unvalidated header is worse than none, because a forged value is indistinguishable from a real one.
Since IIS 8.5 you can add X-Forwarded-For as a custom W3C logging field. It's a genuine feature and it costs nothing, so it's the usual first answer. It's also the point at which most projects stall, for a reason that only becomes apparent downstream.
Log consumers don't read your log file the way you do. A SIEM connector ships with a parser mapping W3C fields to its own schema: c-ip becomes the source-address entity that correlation rules, threat intelligence matching, user-behaviour analytics and dashboards all reference. A new column at the end of the line isn't in that mapping. To use it you would have to:
In a regulated estate that's not a config change, it's a project (with change control, testing and sign-off). Meanwhile every product that can't be customised at all, and there are always some, continues reporting the load balancer.
| Capability | Behind a proxy, unfixed |
|---|---|
| Threat detection & correlation | Every request appears to originate from a handful of internal addresses, so brute-force, credential-stuffing and scanning patterns that rely on grouping by source can't form. Rules keyed to source reputation never match. |
| Geo-IP and anomaly reporting | All traffic geolocates to your own data centre or cloud region. Impossible-travel and unusual-location detections are inert. |
| Rate limiting and blocking | Controls keyed to source address see one client. Blocking it blocks everyone behind the proxy. |
| Incident response | The question an investigation opens with (which address did this request come from) cannot be answered from the logs. Reconstructing it means correlating IIS logs against proxy logs by timestamp, if the proxy logs were retained. |
| Audit and evidence | The W3C log is frequently the retained artefact. If the source address in it is the load balancer, the record doesn't show who accessed what. |
Logging X-Forwarded-For without validating it is not a neutral improvement over logging nothing. The header is client-supplied. Anyone who can reach the web server directly can set it to any value, and proxies in the path append rather than replace, so a forged entry sits at the front of the chain looking exactly like a genuine client.
Feed that into a SIEM and forged addresses become audit records. An attacker can attribute their own activity to an arbitrary address, and the false entries are indistinguishable from real ones after the fact. For an audit trail, that's a worse position than an obviously-wrong-but-consistent load balancer address, because the log now looks correct while being untrustworthy.
Validation is what makes the logged value evidence rather than a claim: walk the chain from the nearest hop outward, discard the addresses you know to be your own infrastructure, and record the first address you didn't put there. That's what a Proxy Trust List does. Pair it with an origin firewall that only accepts traffic from your proxies, and the header can't arrive by any other route.
X-Forwarded-For for IIS writes the validated client address into the standard c-ip field rather than adding a column beside it. That choice is the whole point: nothing downstream has to be told. Your SIEM connector, log shipper, geo-IP enrichment, retention pipeline and compliance parser keep reading the field they already read, and start getting the right answer: no new parsers, no rule rewrites and no change to your log schema.
For most of our customers that's the deciding factor. The requirement isn't "log the header somewhere", it's "make the source IP in the audit trail correct without re-engineering the tooling around it".
Some can, with work. The connector's parser maps standard W3C fields to its schema, and a custom column isn't in that mapping, so you'd need a custom field extraction plus rewrites of any rule, search or dashboard referencing the source address, maintained through every upgrade, and not applied to historical data. Some tooling can't be customised at all.
For an audit trail, arguably not. The header is client-supplied, so without trust validation an attacker can insert any address and it will be recorded as fact, indistinguishable from genuine entries. A log that looks correct but can be poisoned is a weaker evidential position than one that's consistently wrong in a known way.
No. The address is written into the existing c-ip field in the standard W3C log. The format, the field list and the files are unchanged, so retention, shipping and archival are unaffected.
It does. ASP.NET Core can correct its own view of the client address with the forwarded headers middleware, but that only affects the application. It doesn't write to the IIS log, and it does nothing for classic ASP.NET, static content or non-.NET workloads on the same instance. Correcting c-ip covers everything IIS serves.
X-Forwarded-For for IIS writes the validated client address into the standard c-ip field, so your existing SIEM, log analysis and compliance tooling needs no reconfiguration. IIS 10 on Windows Server 2016–2025, with a free 14-day trial.