A SharePoint farm published through a load balancer or reverse proxy (for high availability across web front-end servers, SSL offload, or a WAF) has the same underlying problem as any load-balanced IIS estate: the standard log field records the proxy, not the visitor.
Short answer. SharePoint's web front-end (WFE) servers are ordinary IIS sites, so behind a reverse proxy or hardware load balancer (F5, NetScaler, ARR, Azure Application Gateway), the standard W3C c-ip field logs the proxy's address for every request, exactly as it would for any other IIS workload. X-Forwarded-For for IIS fixes that field the same way it does elsewhere: read the header, validate it against a Proxy Trust List, write the genuine client address into c-ip. What we can't tell you in general terms is whether SharePoint's own internal audit and usage-analytics features (as opposed to the IIS log itself) draw the IP from the same place in your specific farm and version. See the note below before treating this as a complete compliance fix.
Farms with more than one web front-end server are normally published through a load balancer or reverse proxy, so that requests can be spread across WFEs and a server can be taken out for maintenance without an outage. That proxy terminates the client's connection and opens its own connection to whichever WFE handles the request. From the WFE's point of view, every visitor (internal or external, one person or the whole organisation) appears to connect from the same handful of proxy addresses. The standard c-ip field in the IIS W3C log records that address, not the actual requestor.
This is normal, expected behaviour for a load-balanced deployment, not a misconfiguration: the address has simply moved one hop further away, into whatever the proxy is willing to forward, and SharePoint doesn't restore it by itself.
Anything that keys off the IIS log's source address inherits the problem: access reporting that's supposed to show who used which site collection, security investigations trying to trace a compromised account back to a device, and any SIEM or log-shipping pipeline reading the W3C log for correlation. The general case is the same one covered in why the standard c-ip field is the one that has to be right — a custom logging column doesn't fix it, because the tooling consuming the logs is keyed to the standard field, and an unvalidated header is worse than none because a forged value is indistinguishable from a real one.
It's worth being precise about what this guide covers. Everything above is about the IIS W3C log (the file-based access log any IIS site produces), and that part is straightforward: it's a generic IIS behaviour, unrelated to anything SharePoint-specific. SharePoint separately has its own auditing (Site Collection audit logs) and Usage and Health Data Collection, which are application-level features, not the IIS log. Whether those draw a request's source IP from the same underlying value, and whether that value is affected by fixing c-ip, depends on your farm's version and configuration in a way we can't state in general terms. If your compliance requirement is specifically about SharePoint's own audit trail rather than the IIS access log, confirm with whoever owns that requirement how it sources the address before assuming this guide closes the gap, and ask us if you'd like a second opinion on your specific farm.
X-Forwarded-For for IIS installs on each web front-end the same way it would on any other IIS 10 server; there's no farm-wide component and no dependency on SharePoint's own services. Each WFE reads the X-Forwarded-For header the proxy inserted, validates the chain against a Proxy Trust List so a client-supplied value can't be taken on trust, and writes the real address into the standard c-ip field. Because every WFE writes to the same field in the same standard log format, your existing log aggregation across the farm keeps working without changes to parsers, dashboards or retention.
Alternate Access Mappings (AAM) are a separate concern. AAM governs how SharePoint maps an incoming request to a zone and rewrites URLs for that zone. It has nothing to do with where the client IP is logged, and configuring it correctly doesn't affect this problem either way.
Some SharePoint deployments (an extranet-facing site collection, a partner portal) apply IIS's IP Address and Domain Restrictions to control who can reach them. That's a generic IIS feature, not a SharePoint one, so it behaves exactly as it does anywhere else behind a proxy: rules evaluate the connecting address unless you turn on Enable Proxy Mode (built into IIS since version 8.0, free, no third-party component), and add the load balancer's own addresses as an Allow entry so IIS knows to look past them when walking the X-Forwarded-For chain:
appcmd set config "Default Web Site" ^
-section:system.webServer/security/ipSecurity ^
/enableProxyMode:"True" /commit:apphostSee the Exchange guide for a fuller walkthrough of Enable Proxy Mode and the Allow-list requirement: the mechanism is identical, only the IIS site changes.
Yes. Each WFE is its own IIS instance handling its own share of requests, so each one needs the filter installed to write the real client IP into its own logs. There's no central farm-wide configuration point for this.
Not directly — this fixes the IIS W3C log's c-ip field. Whether SharePoint's own Site Collection auditing or Usage and Health Data Collection sources the address from the same place depends on your farm's version and configuration; confirm with whoever owns that specific compliance requirement rather than assuming it's covered.
No. AAM controls zone mapping and URL rewriting; it's unrelated to where the client IP is logged, and this fix doesn't require any AAM change.
Yes, ARR forwards the client IP the same way any reverse proxy does. See the ARR guide for the proxy-side configuration and trust settings.
X-Forwarded-For for IIS writes the validated client address into the standard c-ip field on every web front-end, so your existing log aggregation, SIEM and reporting keep working unchanged. IIS 10 on Windows Server 2016–2025, with a free 14-day trial.
View the product or request a download →