Per-server perpetual licences start at GBP 395 / USD 495. A site licence covering unlimited servers within a single legal entity is GBP 5,950 / USD 7,450. Volume discounts apply from 10 servers. Optional annual maintenance (20% of list) covers updates and email support.

X-Forwarded-For for IIS: Real Client IP on Windows Server

Q: Which IP in X-Forwarded-For is the real client — the first or the last?

The original client is the first entry in the X-Forwarded-For list; each proxy appends the next hop, so the closest proxy is last. Logging the first entry blindly is unsafe because a client can forge it. X-Forwarded-For for IIS instead parses the chain from right to left and logs the first address that is not on your Proxy Trust List — the genuine client.

Trusted in production at organisations including

Enel Swisscom NNIT SAF-Holland Nextel Canterbury University UMass RLI Corp Water Pik

…plus government agencies, banks and telcos across three continents.

The distinction that matters

Since IIS 8.5 it has been possible to add X-Forwarded-For as an extra custom column in the W3C log file. That is not what this product does, and for most organisations, the custom column approach does not actually solve the problem.

The purchase trigger for X-Forwarded-For for IIS is almost always a SIEM, compliance, or security-operations requirement for accurate source IPs. Every SIEM connector, log shipper, geo-IP lookup, intrusion detection system and compliance parser that processes IIS logs keys off the standard c-ip field. Adding a separate custom column means reconfiguring all of that downstream tooling, or accepting that it continues reading the wrong address.

What you are buying: direct replacement of the standard c-ip field with the real client address. Every existing tool (SIEM, log analyser, geolocation, compliance parser) keeps reading c-ip as normal. Nothing downstream changes.

Why choose a commercially supported solution?

Microsoft IIS has no native solution for replacing the c-ip field with the real client address. The options that practitioners reach for each have significant problems:

Option	Status	The problem
IIS 8.5+ custom log field	Supported	Adds an extra column. Does not replace the standard `c-ip` field. All downstream SIEMs, geo-IP tools and compliance parsers continue reading the proxy's address.
Microsoft IIS Advanced Logging	Deprecated	Writes to a separate log file, bypassing the standard W3C log entirely. Discontinued by Microsoft and no longer available.
ARR Helper workaround	Discouraged	Microsoft's own engineers have documented that this approach causes IIS application pool crashes in production. Not suitable for enterprise use.
Joe Pruitt's F5 ISAPI filter	Unsupported	Community tool published by F5, source archived in 2016 and unchanged since. Microsoft's guidance is that it does not work on IIS 10+. It also validates nothing, so a forged header is logged as fact. Still referenced widely in old forum posts and Stack Overflow threads.
Write your own HTTP module	DIY	Microsoft's default recommendation. Requires a developer, produces code with no commercial support, and leaves you responsible for compatibility with every future Windows Server release.
Winfrasoft X-Forwarded-For for IIS	Available now	Maintained, commercially supported, code-signed. Directly replaces `c-ip` in the standard W3C log. No downstream tooling changes required. The maintained successor to the community tools that no longer work.

Who is this for?

X-Forwarded-For for IIS is used by IT and security teams running load-balanced IIS estates where accurate source IP logging matters for operations, security or compliance. Common scenarios:

Exchange Server on-premises behind an F5 BIG-IP, Citrix NetScaler or Azure Application Gateway, where ActiveSync and OWA client IPs are logged as the load balancer's address rather than the device or user. See the Exchange guide →
SharePoint farms behind a reverse proxy, where access audit logs and security reports show proxy addresses instead of the actual requestors. See the SharePoint guide →
Regulated .NET Framework applications in financial services and government, where compliance frameworks require accurate source IPs in W3C audit trails, and the SIEM tooling already keys off c-ip.
Any IIS web farm fronted by a CDN, WAF, hardware load balancer or upstream proxy, where geolocation, threat detection or capacity reporting depends on real visitor IPs.

What is the X-Forwarded-For header?

X-Forwarded-For (XFF) is a standard HTTP header used to identify the originating IP address of a client connecting to a web server through a forward or reverse proxy. Without it, the web server only ever sees the IP address of the last proxy, load balancer or CDN in the chain, not the real visitor.

The header carries a comma-separated list of IP addresses, one appended by each proxy the request passes through, with the original client listed first:

X-Forwarded-For: <client>, <proxy-1>, <proxy-2>

X-Forwarded-For is supported natively by Squid, Apache, NGINX, F5 BIG-IP, Blue Coat, Cisco and most major proxy platforms. Microsoft IIS does not log X-Forwarded-For natively. There is no built-in setting to record it in the standard log. Winfrasoft X-Forwarded-For for IIS fills that gap.

In one line: X-Forwarded-For for IIS reads the X-Forwarded-For request header and writes the true client IP address into the standard IIS c-ip log field, so your existing reporting, geolocation and SIEM tooling sees the real visitor, not your proxy.

X-Forwarded-For vs X-Real-IP and the Forwarded header

Three HTTP headers are commonly used to convey the original client address across proxies:

X-Forwarded-For: the de facto standard, supported by virtually every proxy, load balancer and CDN. It carries the full chain of IP addresses with the original client first, so the real visitor can be verified against a trust list.
X-Real-IP: a non-standard, single-value header set by some proxies (notably NGINX) containing just one address, usually the immediate client. It carries no chain, so it cannot be validated against a proxy trust list.
Forwarded: the standardised header defined in RFC 7239 (Forwarded: for=…; proto=…; by=…). More expressive, but far less widely adopted than X-Forwarded-For.

Because X-Forwarded-For is the most widely supported and preserves the entire proxy chain, it remains the most reliable basis for recovering the real client IP, and it is what X-Forwarded-For for IIS uses.

X-Forwarded-For on Windows Server

On Windows Server, web traffic is served by Internet Information Services (IIS). Unlike Apache or NGINX, neither Windows Server nor IIS records the X-Forwarded-For header out of the box. Any Windows web server placed behind a proxy, load balancer or CDN therefore logs the proxy's IP address instead of the real visitor's.

Winfrasoft X-Forwarded-For for IIS adds that capability to Windows Server, supported on Windows Server 2016, 2019, 2022 and 2025 (64-bit). It is the simplest way to get accurate client-IP logging on a Windows Server web farm, with no changes to your applications.

Overview

When client traffic reaches an IIS web server through a forward or reverse proxy, the IP address recorded in the IIS logs is the proxy's address, not the originating client's. Winfrasoft X-Forwarded-For for IIS solves this by reading the X-Forwarded-For HTTP header and logging the true client IP address in the standard IIS c-ip field, with no changes to your applications or downstream log analysis.

This is essential for geolocation services, accurate access reporting, security investigation and compliance requirements, particularly where branch offices, hardware load balancers, CDNs or upstream proxies sit in front of your web servers. It is ideal for log analysis when branch offices connect to the Internet via a head-office proxy, and wherever the real client IP is needed on the web server for accurate reporting.

How X-Forwarded-For logging works in IIS

X-Forwarded-For for IIS assembles the full X-Forwarded-For header together with the layer-4 routed source IP of the closest proxy into a single Proxy Chain List, then decides which address represents the real client and writes it to the IIS c-ip field. It can operate in two modes:

Real client IP mode: log the first non-trusted IP address from the header as the genuine client (recommended — see Proxy Trust List below).
Full chain mode: log the entire X-Forwarded-For list together with the layer-4 source IP, so the complete proxy path is recorded in the c-ip field.

Because the value lands in the standard c-ip field, every existing tool (IIS log analysers, geolocation lookups, SIEM ingestion and compliance reports) keeps working unchanged. There is no application code to modify and no custom log format to parse. Both HTTP and HTTPS reverse-proxy deployments are supported.

Anti-spoofing: the Proxy Trust List

The X-Forwarded-For header is clear text inside an HTTP request — it is not signed and not authenticated, so a client can place a forged address at the start of the list. Naïvely logging "the first IP in the header" is therefore unsafe and can poison your logs with spoofed addresses.

Winfrasoft X-Forwarded-For for IIS defends against this with a Proxy Trust List: the IP addresses of the proxies and load balancers you control. The Proxy Chain List is parsed right to left (starting closest to the web server); the first address that is not on the trust list is taken to be the real client, because that is the host that connected to your outermost trusted proxy.

Worked example

Suppose a request reaches IIS through two trusted reverse proxies. The web server receives:

X-Forwarded-For: 203.0.113.7, 198.51.100.23
Layer-4 source IP: 198.51.100.10
Proxy Trust List:  198.51.100.23, 198.51.100.10

The Proxy Chain List becomes 203.0.113.7, 198.51.100.23, 198.51.100.10. Parsing right to left, both 198.51.100.x addresses are trusted, so the first non-trusted address (203.0.113.7) is logged as the real client:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem s-port c-ip sc-status
2025-11-09 14:37:03 W3SVC1 192.0.2.10 GET /default.htm 443 203.0.113.7 200

Had a client tried to spoof an address by injecting it ahead of 203.0.113.7, the trust-list logic would still resolve the correct first non-trusted hop. If no trust list is configured, the full chain is logged instead so no information is lost.

For what c-ip records by default, and why an unmodified IIS server writes the proxy address into it, see the c-ip field in IIS logs.

Configuring the trust list

The trust list lives in a plain-text XFF4IIS.ini file in the installation folder. List the IP addresses of your trusted proxies and load balancers, comma-separated, on a single line:

[Config]
TrustList=198.51.100.23, 198.51.100.10

Only valid IP addresses are accepted (host names are ignored), and the file is parsed exactly as shown. Run IISRESET for trust-list changes to take effect. Leave the list empty to log the complete proxy chain instead.

Security note: never trust X-Forwarded-For information that originates from outside your organisation, and always verify the whole list against the layer-4 source rather than blindly logging the first entry. In forward-proxy scenarios the header is withheld where appropriate to avoid revealing internal IP addresses to the Internet.

Works behind any proxy, load balancer or CDN

X-Forwarded-For for IIS reads the header regardless of which device set it, so it works behind the proxies, load balancers and CDNs that enterprises actually run — including Cloudflare, F5 BIG-IP, AWS Elastic Load Balancing (ELB / ALB), Azure Application Gateway and Front Door, NGINX, HAProxy and Microsoft IIS Application Request Routing (ARR). Wherever the X-Forwarded-For header is added upstream, the filter resolves the originating client and writes it to the IIS c-ip log field.

Add each upstream device's IP address to the Proxy Trust List so its hop is treated as trusted and the real visitor is logged accurately, even through a multi-tier chain such as Cloudflare in front of an F5 load balancer in front of IIS.

Step-by-step guides for each:

What's new in this release

Windows Server 2025 support. Rebuilt and tested against the current Windows Server platform and modern IIS.
ISAPI web filter. Registers automatically across all IIS web sites with per-site enable/disable, and no IIS restart required to activate it.
Hardened Proxy Trust List. Only X-Forwarded-For values arriving via trusted upstream proxies are honoured; spoofed headers from untrusted sources are discarded.
Full proxy-chain logging. Optionally record the entire X-Forwarded-For header alongside the layer-4 source IP to capture every hop.
HTTP & HTTPS, forward & reverse proxy, hardware load balancers and transparent network devices — all supported.

Platform support

Web server IIS 10

Operating system Windows Server 2016 · 2019 · 2022 · 2025 (x64)

Filter type ISAPI web filter

Licensing Per server · commercial

Support Commercial · with upgrade path

Status Available now

Looking for the original Forefront TMG and ISA Server filter? That version is end-of-life and retained for reference on its legacy product page.

Licensing & pricing

Perpetual per-server licensing. No subscription, no ongoing billing infrastructure, no usage metering. Pay once, own the licence.

SKU	GBP	USD	Notes
Per-server, perpetual	£395	$495	Production use on one server
Site licence, perpetual	£5,950	$7,450	Single legal entity, unlimited servers
Non-production use	Free	Free	Bundled with any production licence (dev, test, staging)
Annual maintenance (optional)	20% of list	20% of list	Updates + email support for the licence term
Priority support (optional)	£495/yr	$595/yr	Named contact, 1-business-day response SLA

Volume discounts

Quantity	Discount off list price
1–9 servers	—
10–24 servers	15%
25–99 servers	25%
100+ servers	35%, or switch to site licence

How licensing works

Licences are file-based. No activation server, no call-home, no internet connectivity required on the licensed server. When you purchase, a licence file is delivered by email; drop it into the installation directory and the product activates. This works in air-gapped environments and secure government networks with no firewall exceptions required.

A 14-day evaluation licence is available on request: same installation, same feature set, time-limited. Request a download →

Frequently asked questions

Can't I just use the IIS 8.5 custom log field for X-Forwarded-For?

You can add X-Forwarded-For as an extra custom column in the IIS W3C log, but this does not replace the standard c-ip field. All SIEM connectors, log shippers, geo-IP services, intrusion detection systems and compliance parsers that process your IIS logs key off c-ip specifically. Adding a new column means reconfiguring every one of those downstream tools, or accepting that they keep reading the proxy's address. X-Forwarded-For for IIS writes directly to c-ip so nothing downstream needs to change.

There is a second, less obvious problem: no trust list. The X-Forwarded-For header is entirely client-controlled, so any request can include a fabricated XFF value before it reaches your proxy. Without right-to-left Proxy Trust List parsing, the native custom log field simply records whatever is in the header, so a spoofed X-Forwarded-For: 1.2.3.4 entry will appear as 1.2.3.4 in your log regardless of where the request actually came from. X-Forwarded-For for IIS uses a configurable Proxy Trust List that parses the chain right-to-left, discarding any entries before the first trusted proxy, preventing fabricated client IPs from poisoning your c-ip field.

How does the licence work, and is there activation or call-home?

No. Licences are file-based. When you purchase, a licence file is delivered by email; you drop it into the installation directory and the product activates immediately. There is no activation server, no call-home, and no internet connectivity required on the licensed server. It works in air-gapped environments and secure government networks without any firewall exceptions.

What does it cost?

Per-server perpetual licences start at £395 / $495. A site licence covering unlimited servers within a single legal entity is £5,950 / $7,450. Volume discounts apply from 10 servers. Optional annual maintenance (20% of list) covers updates and email support. See the full pricing table →

Does IIS support X-Forwarded-For natively?

Partially. Since IIS 8.5 you can add X-Forwarded-For as an extra custom column in the W3C log, so the header can be recorded. However, this does not replace the standard c-ip field, which is what every SIEM connector, log shipper, geo-IP service and compliance parser reads. It also has no Proxy Trust List, so the custom column will faithfully log spoofed XFF headers sent by clients. For most organisations with existing log infrastructure, the native option solves neither problem. Community workarounds also exist: an F5-authored ISAPI filter (written for IIS 6/7, incompatible with IIS 10+), Microsoft's IIS Advanced Logging extension (discontinued), or hand-rolled HTTP modules, but none provide commercial support or a tested upgrade path. Winfrasoft X-Forwarded-For for IIS writes the real client IP directly into the standard c-ip field, with full Proxy Trust List anti-spoofing.

Does Windows Server support X-Forwarded-For?

Not natively. Windows Server serves web traffic through IIS, which has no built-in X-Forwarded-For logging. Winfrasoft X-Forwarded-For for IIS adds it on Windows Server 2016, 2019, 2022 and 2025, writing the real client IP into the IIS c-ip log field.

How do I log the real client IP address in IIS behind a load balancer or reverse proxy?

Install X-Forwarded-For for IIS on the web server. It reads the X-Forwarded-For header added by your proxy or load balancer and records the originating client IP in the IIS c-ip field, so logs, geolocation and reports show the real visitor instead of the proxy address.

What is a Proxy Trust List?

It is the list of IP addresses of the proxies and load balancers you control. X-Forwarded-For for IIS parses the proxy chain from right to left and logs the first address that is not on the trust list as the real client, preventing spoofed values from polluting your logs.

Can the X-Forwarded-For header be spoofed?

Yes. The header is clear text and is neither signed nor authenticated, so a client can forge entries. This is exactly why the Proxy Trust List matters: it lets the web server identify the genuine client rather than trusting the first value in the header.

Which IP in X-Forwarded-For is the real client — the first or the last?

The original client is the first entry in the X-Forwarded-For list; each proxy appends the next hop, so the closest proxy is last. Logging the first entry blindly is unsafe because a client can forge it. X-Forwarded-For for IIS instead parses the chain from right to left and logs the first address that is not on your Proxy Trust List — the genuine client.

Which versions of Windows Server and IIS are supported?

The current release supports IIS 10 on Windows Server 2016, 2019, 2022 and 2025. The earlier TMG/ISA-era product covered IIS 6–8.5 and is now end-of-life.

Does it work with HTTPS and multi-hop proxy chains?

Yes. Both HTTP and HTTPS reverse-proxy deployments are supported, as are chains of multiple proxies and load balancers. The full chain can be logged where required.

Will it change my applications or log format?

No. The real client IP is written into the standard IIS c-ip field, so existing log analysis, SIEM ingestion and compliance reporting continue to work without any changes.

Documentation

X-Forwarded-For for IIS: Installation & Configuration Guide (PDF) Version 2.0.4 · Deployment scenarios · Proxy Trust List · W3C logging
Guides & knowledge base How-to articles, including IIS behind Cloudflare

Get started: stop logging your proxy's IP

From £395 per server, perpetual. 14-day evaluation available. Get in touch for a trial licence, a multi-server quote, or help sizing a deployment across your IIS estate. We'll respond within one business day.

Request a trial or quote or email [email protected]

Azure Marketplace listing coming soon. Register interest above to be notified at launch.