The c-ip field in IIS logs

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)?

IIS 8.5 and later let you add a custom log field sourced from a request header, which appears as cs(X-Forwarded-For). This is free, native, and worth knowing about, but it does something different from what most people want: it adds a column and leaves c-ip alone.

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.

Adding the custom field, if that is what you need

1. In IIS Manager, select the site and open Logging.
2. Confirm the format is W3C, then choose Select Fields.
3. Choose Add Field, name it X-Forwarded-For, set the source type to Request Header and the source to X-Forwarded-For.
4. Apply, then recycle the application pool. New requests get the extra column.

Remember that the value is unvalidated. Anything that can reach IIS directly can set the header to whatever it likes, and the log will record it faithfully.

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.

Frequently asked questions