Behind the Akamai edge, IIS logs an Akamai server instead of your visitor. Akamai gives you two headers to fix that, they are not equally trustworthy, and the more authoritative-looking one is the one that can be renamed or forged.
Short answer. Akamai sends X-Forwarded-For to your origin by default. True-Client-IP is off unless somebody turned it on: it is the Send True Client IP Header option inside the Origin Server behavior in Property Manager. Neither changes the IIS c-ip field, which is filled from the TCP connection and therefore records the Akamai edge server. Getting the visitor into c-ip needs something in IIS that reads the header and rewrites the field, validating it against the addresses Akamai actually connects from.
Do not assume. The two headers behave differently and only one of them is on by default.
| Header | Default | Contents |
|---|---|---|
X-Forwarded-For |
On | The usual comma-separated chain. Akamai passes it through and appends rather than replacing it, so an inbound value that arrived with the request survives to your origin. |
True-Client-IP |
Off by default | A single address, added only when Send True Client IP Header is enabled in the Origin Server behavior. The name is configurable, so it may not be called this on your property. |
The quickest way to settle it is to look, rather than to read the property configuration. Add both as custom log fields on the site temporarily, or capture request headers with Failed Request Tracing, and make one request through the Akamai hostname. If you go down the custom-field route, read the custom field troubleshooting guide first, because the log file name changes underneath you and that trips up almost everybody.
This is the part worth slowing down for, because the intuition runs the wrong way. A single clean address looks authoritative next to a comma-separated chain of unknown provenance. In practice the chain is the one you can validate and the single value is the one you have to take on faith.
Three things follow from Akamai's own Property Manager documentation:
True-Client-IP. Akamai's documentation notes that the default header name is used "unless you set a custom name for the header in the True Client IP Header Name field". Anything you write that hardcodes the default name breaks silently on a property where somebody renamed it. In Terraform terms the field is trueClientIpHeader.trueClientIpClientSetting, which per Akamai "determine[s] if the client name for this header is passed through and accepted, or whether to apply the value you defined in the True Client IP Header Name field instead". Where that is on, a caller can send the header and have it reach your origin. Akamai's page describes the toggle's behaviour without drawing out the consequence, so it is easy to leave in a state nobody has examined.X-Forwarded-For you can read from the right and stop at the first address that is not a proxy you control. With a single value you either trust the whole path or you do not.None of this makes True-Client-IP useless. It makes it conditional: trustworthy when the client-set toggle is off and your origin cannot be reached except through Akamai. Both halves matter, and the second one is the half people forget.
Every header-based approach rests on the same assumption, that requests reaching IIS came through Akamai. If your origin also answers on its public address, anyone can connect to it directly with an X-Forwarded-For or True-Client-IP header of their choosing, and nothing downstream can tell the difference.
Akamai's answer to this is Site Shield, which its documentation describes as leveraging "a defined set of IP subnet ranges to route traffic to the origin", so that once those ranges are allowlisted at the perimeter it "helps prevent attackers from bypassing cloud-based defenses and directly targeting the application origin". Akamai also offers Site Shield Stable CIDRs, using larger and more static blocks so the firewall ACL needs updating less often.
Whether or not you use Site Shield, the same two addresses lists do the work: the firewall decides who may connect, and the trust list in IIS decides whose forwarded header to believe. Keep them consistent.
The c-ip field in an IIS W3C log is taken from the TCP connection. Behind Akamai the only connection IIS ever sees is the one an Akamai edge server opened, so c-ip records Akamai. The visitor's address is present on the very same request, sitting in a header, but no version of IIS reads it. Not IIS 7, not IIS 8.5, not IIS 10 on Windows Server 2025. The background is in X-Forwarded-For and IIS.
The native IIS custom log field will put the header into your logs as an extra column, and it is worth knowing about, but it leaves c-ip untouched. Everything that already reads c-ip, which is most SIEM content, geo-IP reporting and audit tooling, carries on seeing an Akamai address.
Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the header Akamai sends and writes the real client address into the standard IIS c-ip field. Same log file, same W3C schema, same column your collector already parses, now containing the visitor rather than the edge server. No application changes and no second log file.
X-Forwarded-For, which is the portable choice anyway.True-Client-IP is enabled, check the True Client IP Header Name field for a custom name, and check whether Allow Clients To Set True Client IP Header is on. If it is on and you did not intend it, that is a property change to make before you rely on the value.c-ip now holds the client address.Plenty of estates run Akamai in front of something else, an on-premises load balancer or a WAF, and then IIS. That is fine, and it is exactly the case the chain exists for: each hop appends the address it received the connection from, so X-Forwarded-For arrives with several entries. Add every internal hop to the trust list, not just the outermost. Miss one and the filter stops walking at your own load balancer and logs that instead. The ordering is worked through in the header reference.
X-Forwarded-For by default, and True-Client-IP only if the Send True Client IP Header option has been enabled in the Origin Server behavior in Property Manager. Akamai originated the True-Client-IP convention and Cloudflare also emits it on Enterprise plans. If both headers arrive they should agree, and X-Forwarded-For remains the portable choice.
Not inherently, and often less so. It holds a single address with no chain, so there is nothing to validate against a trust list, the header name is configurable and may have been changed on your property, and a separate toggle controls whether a client-supplied value is passed through and accepted. X-Forwarded-For gives you every hop, which is what lets you decide which entry to believe.
It can, in two circumstances. If Allow Clients To Set True Client IP Header is enabled on the property, a caller can send the header and have it reach your origin. And if your origin is reachable without going through Akamai at all, anyone can connect directly and send whatever they like. Closing the second case is what Site Shield and origin firewall rules are for.
Because c-ip is filled from the TCP connection and the only connection IIS sees is the one the Akamai edge server opened. The visitor's address arrives in a header on the same request, but IIS has never read forwarding headers natively in any version, so nothing joins the two together.
The addresses Akamai actually connects to your origin from, plus every internal hop between the edge and IIS. If you use Site Shield you already have that set as a defined list of IP CIDR ranges, which is the same list your perimeter firewall should be allowing. Internal load balancers and WAFs count as hops and need to be included, otherwise the chain walk stops at your own equipment.
You can, on IIS 8.5 and later, and it costs nothing. It gives you an extra column holding the raw header and leaves c-ip unchanged, so anything already reading c-ip still sees Akamai. It also makes IIS start writing log files with _x appended to the name, which can quietly break a log collector matching the old pattern.
Log the real client IP in the standard IIS c-ip field behind Akamai, with a Proxy Trust List so the value is validated rather than merely copied. IIS 10 on Windows Server 2016–2025, with a free 14-day trial.