How to log X-Forwarded-For in IIS

How do I log X-Forwarded-For in IIS?

Pick the method that matches your IIS version. All three add a column; none of them alter c-ip.

IIS 8.5 and later (Windows Server 2012 R2 onwards)

1. Open IIS Manager and select the site in the Connections pane. It has to be the site: Microsoft documents that enhanced logging is available only for site-level logging, so with the server selected the Custom Fields section and Add Field are disabled. If those controls look greyed out, that is why. To apply it across every site at once, use the PowerShell method below instead.
2. Double-click Logging.
3. Confirm the format is W3C, then click Select Fields….
4. Click Add Field… and enter: Field Name X-Forwarded-For, Source type Request Header, Source X-Forwarded-For.
5. Click OK twice, then Apply in the Actions pane.

The change takes effect on the next log file, not the current one. If you want to see it immediately, recycle the application pool so IIS starts a new file.

Watch the filename. Once custom fields are configured, Microsoft documents that IIS "will create new text log files with _x appended to the file name". Anything ingesting logs by filename pattern can silently stop matching, or start reading two sets of files with different schemas. If a SIEM or log shipper goes quiet shortly after you add the column, check this first. There is also a cap: the total data across all custom fields cannot exceed 65,536 bytes, after which IIS truncates it.

IIS 7, 7.5 and 8 (Advanced Logging)

Custom fields were not built into IIS logging until 8.5. On IIS 7 to 8 the Advanced Logging module was the way to do this:

1. Open IIS Manager and double-click Advanced Logging.
2. Click Enable Advanced Logging.
3. Choose Edit Logging Fields, then Add Field: Field ID X-Forwarded-For, Source type Request Header, Source name X-Forwarded-For.
4. Edit the default log definition, tick the new field, and apply.
5. Generate some traffic so a new log file is created.

Advanced Logging writes its own files rather than extending the standard W3C log, so anything parsing the original path will not see the new column.

PowerShell, server-wide

To add the field to every site at once, set it on the site defaults in applicationHost.config:

Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' `
  -filter "system.applicationHost/sites/siteDefaults/logFile/customFields" `
  -name "." `
  -value @{logFieldName='X-Forwarded-For';sourceName='X-Forwarded-For';sourceType='RequestHeader'}

Run it from an elevated session. Sites that already override their logging configuration keep their own settings, so check those individually.

Reading the new column

Once the column appears, three things are worth knowing before you trust it:

• A dash means no header arrived. If cs(X-Forwarded-For) shows -, that request did not come through a proxy that sets the header. The connecting address is in c-ip and is the real client.
• Several addresses mean several proxies. The header is a comma-separated list appended to as it passes each hop, so 203.0.113.9, 10.1.1.4 means the client was 203.0.113.9 and one internal proxy added its own address. The left-most entry is the originating client.
• The left-most entry is also the easiest to forge. Nothing validates it, which is the subject of the section below.

Your proxy has to be sending the header in the first place. Most do not by default: on an F5 BIG-IP it is the Insert X-Forwarded-For setting on the HTTP profile, and other vendors use their own header names entirely. The reference of which client IP header each proxy sends covers what to look for and what to enable.

What does c-ip stand for?

Client IP. The W3C Extended Log File Format that IIS uses names its fields by prefix: c- for client, s- for server, cs- for client-to-server, and sc- for server-to-client. So c-ip is the client's address, s-ip is the server's, cs-method is the method the client sent, and sc-status is the status code the server returned.

Reading the prefix makes the rest of the log self-explanatory. Here are the fields you'll actually meet:

That distinction between a plain name and a parenthesised one matters more than it looks, and it is the root of the confusion this page exists to clear up. c-ip is a fact about the connection. cs(X-Forwarded-For) would be a header the client sent. They are filled from different places and they are not interchangeable.

Where are the IIS logs?

By default, one folder per site under:

C:\inetpub\logs\LogFiles\W3SVC1\

The number after W3SVC is the site ID from IIS Manager, so a server hosting several sites has several folders. Each file opens with a #Fields: line naming the columns in order, which is what tells you (and your log parser) which position c-ip occupies:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query
s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status
sc-substatus sc-win32-status time-taken

If c-ip isn't in that line, the field has been switched off in the site's logging configuration. In IIS Manager that is Logging, then Select Fields.

Why does c-ip show my load balancer's address?

Because a reverse proxy terminates the client's connection and opens its own to IIS. IIS records the peer of the connection it accepted, which is the proxy. The visitor's address never reaches the TCP layer, so c-ip has no way to know it.

The proxy usually does pass the original address along, in the X-Forwarded-For request header. The gap is that IIS does not read it. Microsoft never built X-Forwarded-For handling into IIS logging, so the header arrives, sits in the request, and is discarded unless something reads it and acts on it. Our reference of which header each proxy sends covers what your particular device puts where.

The symptom is unmistakable once you know it: every line in the log carries one of a small set of addresses, matching the number of proxies or SNAT addresses in front of the estate.

How do I check what my c-ip actually contains?

Open the newest log file and look at the column. If you want to be quicker about it, this counts the distinct values so you can see the problem rather than infer it:

$log = Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1 |
       Sort-Object LastWriteTime | Select-Object -Last 1

$fields = (Select-String '^#Fields:' $log.FullName |
           Select-Object -Last 1).Line -replace '^#Fields: ' -split ' '
$i = [Array]::IndexOf($fields, 'c-ip')

Get-Content $log.FullName |
    Where-Object { $_ -notmatch '^#' } |
    ForEach-Object { ($_ -split ' ')[$i] } |
    Group-Object | Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

A healthy internet-facing site returns a long tail of distinct addresses. A handful of values covering every request means c-ip is recording your infrastructure.

What is the difference between c-ip and cs(X-Forwarded-For)?

This is the distinction that decides whether the steps at the top of this page actually solve your problem. The custom field is free and native, but it adds a column and leaves c-ip alone, and c-ip is what the rest of your tooling reads.

So the custom field answers "what did the proxy claim?" while leaving the field everything else reads still pointing at the proxy. If you own the log analysis end to end and can repoint it, that may be enough. If a SIEM, a compliance requirement or a packaged reporting tool is involved, it usually isn't, because those key off c-ip and many cannot be told otherwise. That trade-off is covered in more depth in why SIEM and compliance tooling needs the c-ip field.

The forgery problem

The custom field records the header exactly as sent, with no trust check of any kind. Anything that can open a connection to IIS can set X-Forwarded-For to any value it likes, and the log will record it faithfully. On a server reachable only through the proxy that is a theoretical concern. On one that is also reachable directly, whether by design, by a firewall gap or by an internal network route, it means the column can be written by the visitor rather than by your proxy.

This is the practical reason the custom field is a diagnostic aid rather than an audit record. It tells you what the proxy claimed. It does not tell you it was the proxy that claimed it.

Getting the real client address into c-ip

The only way to make c-ip itself correct is for something to read the forwarded header and write the address into the field as IIS records it. That is what an ISAPI filter does, and it is why the approach has been in use since the IIS 6 era.

The important part is the trust check. Because a header can be forged, a filter worth using validates the forwarding chain against a list of proxies you trust, and ignores the header when it arrives from anywhere else. Without that, correcting c-ip would trade a wrong-but-honest log for a confidently-wrong one, which is worse for an audit trail than no change at all.

That is what X-Forwarded-For for IIS does. It reads the forwarded header, checks each hop against a Proxy Trust List, and writes the validated client address into the standard c-ip field, so the log keeps its default layout and SIEM connectors, log analysers and geo-IP tooling need no changes. It runs on IIS 10 on Windows Server 2016 to 2025, and you can request a download to try it against your own logs.

Frequently asked questions