Squid - Squid Result Codes

The Squid result code is composed of several tags (separated by underscore characters) which describe the response sent to the client.

One of these tags always exists to describe how it was delivered:

TCPRequests on the HTTP port (usually 3128).
UDPRequests on the ICP port (usually 3130) or HTCP port (usually 4128). If ICP logging was disabled using the log_icp_queries option, no ICP replies will be logged.
NONESquid delivered an unusual response or no response at all. Seen with cachemgr requests and errors, usually when the transaction fails before being classified into one of the above outcomes. Also seen with responses to CONNECT requests.

These tags are optional and describe why the particular handling was performed or where the request came from:

CFAt least one request in this transaction was collapsed. See collapsed_forwarding for more details about request collapsing. Support for this tag has been added to Squid v5 on 2018-06-18 (commit d2a6dc). It may not be available in earlier Squid versions.
CLIENTThe client request placed limits affecting the response. Usually seen with client issued a “no-cache”, or analogous cache control command along with the request. Thus, the cache has to validate the object.
IMSThe client sent a revalidation (conditional) request.
ASYNCThe request was generated internally by Squid. Usually this is background fetches for cache information exchanges, background revalidation from stale-while-revalidate cache controls, or ESI sub-objects being loaded.
SWAPFAILThe object was believed to be in the cache, but could not be accessed. A new copy was requested from the server.
REFRESHA revalidation (conditional) request was sent to the server.
SHAREDThis tag is not supported yet. This request was combined with an existing transaction by collapsed forwarding. NOTE: the existing request is not marked as SHARED.
REPLYThe HTTP reply from server or peer. Usually seen on DENIED due to http_reply_access ACLs preventing delivery of servers response object to the client.

These tags are optional and describe what type of object was produced:

NEGATIVEOnly seen on HIT responses. Indicating the response was a cached error response. e.g. “404 not found”
STALEThe object was cached and served stale. This is usually caused by stale-while-revalidate or stale-if-error cache controls.
OFFLINEThe requested object was retrieved from the cache during offline_mode. The offline mode never validates any object.
INVALIDAn invalid request was received. An error response was delivered indicating what the problem was.
FAILOnly seen on REFRESH to indicate the revalidation request failed. The response object may be the server provided network error or the stale object which was being revalidated depending on stale-if-error cache control.
MODIFIEDOnly seen on REFRESH responses to indicate revalidation produced a new modified object.
UNMODIFIEDOnly seen on REFRESH responses to indicate revalidation produced a 304 (Not Modified) status. The client gets either a full 200 (OK), a 304 (Not Modified), or (in theory) another response, depending on the client request and other details.
REDIRECTSquid generated an HTTP redirect response to this request. Only on Squid-3.2+ or Squid built with -DLOG_TCP_REDIRECTS compiler flag.

These tags are optional and describe whether the response was loaded from cache, network, or otherwise:

HITThe response object delivered was the local cache object.
MEMAdditional tag indicating the response object came from memory cache, avoiding disk accesses. Only seen on HIT responses.
MISSThe response object delivered was the network response object.
DENIEDThe request was denied by access controls.
NOFETCHA ICP specific type. Indicating service is alive, but not to be used for this request. Sent during “-Y” startup, or during frequent failures, a cache in hit only mode will return either UDP_HIT or UDP_MISS_NOFETCH. Neighbours will thus only fetch hits.
TUNNELA binary tunnel was established for this transaction. Only on Squid-3.5+

These tags are optional and describe some error conditions which occured during response delivery (if any):

ABORTEDThe response was not completed due to the connection being aborted (usually by the client).
TIMEOUTThe response was not completed due to a connection timeout.
IGNOREDWhile refreshing a previously cached response A, Squid got a response B that was older than A (as determined by the Date header field). Squid ignored response B (and attempted to use A instead). This “ignore older responses” logic complies with RFC 7234 Section 4 requirement: a cache MUST use the most recent response (as determined by the Date header field).

References

https://wiki.squid-cache.org/SquidFaq/SquidLogs