Akamai IP in the access logs of webserver or appserver

If your website is akamized either by Edge Content Delivery or Dynamic Site Accelerator your webserver or appserver access logs will always shows the IP of the akamai edge server instead of the actual client ip, but with the exception if the client is using the origin server domain address to reach the server , which usaully happens when you are testing the server for problems isolating akamai. During any outage issues you will be curious to know whose ip is logged , where the ip came from and how many requests are made during the time. Unfortunately like many other isp's, akamai doesn't provide any reverse lookup on their servers to easily isloate ip's of akamai to that of others. so here is the little trick you can use to find whether a particular ip belongs to an akamai server. Just get the ip address from the logs and make a request using your browser like http://77.67.85.65/ , since akamai servers listens on port 80 you will usually get a 400 Bad Request http response with Invalid URL message and if you inspect the headers with the live http headers firefox plugin, you will notice that the "Server:" header will have a value of AkamaiGHost as show below which can confirm that the particular ip is from an akamai server, Note Akamai also give us the ability to get the client ip address in a custom IP header called True-Client-IP, with custom logging enabled you should be able to print the real client ip in the access log as well.

Invalid URL

The requested URL "/", is invalid.

Reference #9.3d55434d.1248071422.0

---------------------------------------------------------------------------------------------
http://77.67.85.65/

GET / HTTP/1.1
Host: 77.67.85.65
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no

HTTP/1.x 400 Bad Request
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 187
Expires: Mon, 20 Jul 2009 06:17:42 GMT
Date: Mon, 20 Jul 2009 06:17:42 GMT
Connection: close
----------------------------------------------------------

Understanding Akamai Headers to debug slowness or cache related problems

If your website is akamaized or basically cached by akamai, you would expect to see your web pages loaded faster, but in some cases you won't find the difference which might be related to your akamai settings or the response headers that your website is sending via akamai. Hence in order to debug and fine tune, it is necessary to understand the headers that akamai send along with the regular HTTP headers. To inspect those headers you can download the latest version of EdgeSuite Booster for Internet Explorer on Akamai’s portal (https://control.akamai.com/) under Support > Documentation > EdgeSuite > Tools or use Live HTTP Headers firefox plugin. Here is a sample of a response headers via akamai where the highlighted ones are akamai specific headers,

http://www.example.com/common/global.html

GET /common/global.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no
Cache-Control: max-age=0

HTTP/1.x 200 OK
Content-Type: text/html
Etag: W/"26100-124692218130400"
Cache-Control: max-age=120
Date: Tue, 14 Jul 2009 18:01:27 GMT
X-Cache: TCP_MEM_HIT from a69-174-50-208 (AkamaiGHost/5.7.2-5726413) (-)
X-Cache-Key: S/L/2649/75069/6h/www.example.com/common/global.html
X-True-Cache-Key: /L/www.example.com/common/global.html
X-Serial: 2649
Connection: keep-alive
Vary: Accept-Encoding
X-Check-Cacheable: YES

The X-Cache headers are related to akamai and here are the different headers you might get to see and their respective meanings,

X-Cache HTTP Response Header
Returned from request using "Pragma: akamai-x-cache-on":

TCP_HIT: The object was fresh in cache and object from disk cache.
TCP_MISS: The object was not in cache, server fetched object from origin.
TCP_REFRESH_HIT: The object was stale in cache and we successfully refreshed with the origin on an If-Modified-Since request.
TCP_REFRESH_MISS: Object was stale in cache and refresh obtained a new object from origin in response to our IF-Modified-Since request.
TCP_REFRESH_FAIL_HIT: Object was stale in cache and we failed on refresh (couldn't reach origin) so we served the stale object.
TCP_IMS_HIT: IF-Modified-Since request from client and object was fresh in cache and served.
TCP_NEGATIVE_HIT: Object previously returned a "not found" (or any other negatively cacheable response) and that cached response was a hit for this new request.
TCP_MEM_HIT: Object was on disk and in the memory cache. Server served it without hitting the disk.
TCP_DENIED: Denied access to the client for whatever reason
TCP_COOKIE_DENY: Denied access on cookie authentication (if centralized or decentralized authorization feature is being used in configuration)

X-Cache-Key HTTP Response Header
Returned from request using "Pragma: akamai-x-get-cache-key"; the value is the internal cache key for the page or object on the Akamai server.