-d level命令行選項指示squid去dump cache.log消息到終端（例如stderr）。level參數指明
dump出的消息的最大級別。注意你只會(huì )見(jiàn)到出現在cache.log里的消息，它遵循于debug_options
設置。例如，假如設置了debug_options ALL,1，然后運行squid -d2，你不會(huì )見(jiàn)到級別2的debug
消息。
-d level和-N選項在debug squid問(wèn)題或快速測試配置文件的改變時(shí)，特別有用。它們允許你容易啟
動(dòng)squid和觀(guān)察cache.log消息。在squid從crontab或類(lèi)似的設備啟動(dòng)時(shí)，該選項也有用，crontab
會(huì )捕獲squid的標準錯誤并將其報告回用戶(hù)。例如，可能有如下crontab，它自動(dòng)重配運行中的squid
進(jìn)程：
15 */4 * * * /usr/local/squid/sbin/squid -d1 -k reconfigure
13.2 access.log
Squid把關(guān)于HTTP事務(wù)的關(guān)鍵信息存放在access.log里。該文件是基于行的，也就是說(shuō)每行對應一個(gè)
客戶(hù)端請求。squid記錄客戶(hù)端IP（或主機名）、請求URL、響應size、和其他信息。
Squid在access.log里記錄所有HTTP訪(fǎng)問(wèn)，除了那些在還沒(méi)有發(fā)送數據前就斷開(kāi)的連接。Squid也記
錄所有的ICP（非HTCP）事務(wù)，除非你使用log_icp_queries指令關(guān)閉了這個(gè)功能。第13.2.4節描述
了其他影響access日志的squid.conf指令。
默認的access.log格式包含了10個(gè)域。如下是日志樣本，長(cháng)行分割并且縮進(jìn)排版：
1066037222.011 126389 9.121.105.207 TCP_MISS/503 1055 GET http://home.gigigaga.com/n8342133/Miho.DAT.019 - DIRECT/203.187.1.180 - 1066037222.011 19120 12.83.179.11 TCP_MISS/200 359 GET http://ads.x10.com/720x300/Z2FtZ3JlZXRpbmcxLmRhd/7/AMG - DIRECT/63.211.210.20 text/html 1066037222.011 34173 166.181.33.71 TCP_MISS/200 559 GET http://coursesites.blackboard.com:8081/service/collab/./1010706448190/ - DIRECT/216.200.107.101 application/octet-stream 1066037222.011 19287 41.51.105.27 TCP_REFRESH_MISS/200 500 GET http://fn.yam.com/include/tsemark/show.js - DIRECT/210.59.224.59 application/x-javascript 1066037222.011 19395 41.51.105.27 TCP_MISS/304 274 GET http://fnasp.yam.com/image/coin3.gif - DIRECT/211.72.254.133 - 1066037222.011 19074 30.208.85.76 TCP_CLIENT_REFRESH_MISS/304 197 GET http://ads.icq.com/content/B0/0/..bC6GygEYNeHGjBUin5Azfe68m5hD1jLk$/aol - DIRECT/64.12.184.121 - 1066037222.011 19048 12.83.179.11 TCP_MISS/200 261 GET http://ads.adsag.com/js.ng/...ne&cat=friendship&subcat=girltalk - DIRECT/209.225.54.119 application/x-javascript 1066037222.118 106 41.51.105.27 TCP_HIT/200 536 GET http://rcm-images.amazon.com/./images/G/01/rcm/privacy.gif - NONE/- image/gif 1066037222.352 19475 27.34.49.248 TCP_MISS/200 12387 GET http://espanol.geocities.com/lebastias/divulgacion/budismo-tarot.html - DIRECT/209.1.225.139 text/html 1066037222.352 132 144.157.100.17 TCP_MISS/504 1293 GET http://ar.atwola.com/image/93101912/aol - NONE/- -
如下是對每個(gè)域的詳細解釋?zhuān)?/font>
1.時(shí)間戳
請求完成時(shí)間，以Unix紀元（UTC 1970-01-01 00:00:00）以來(lái)的秒數表示，它是毫秒級的。
squid使用這種格式而不是人工可讀的時(shí)間格式，是為了簡(jiǎn)化某些日志處理程序的工作。
可以使用一個(gè)簡(jiǎn)單的perl命令來(lái)轉化Unix時(shí)間戳到本地時(shí)間，例如：
perl -pe 's/^\d+\.\d+/localtime(TCP_REFERSH_HITamp;)/e;' access.log
2.響應時(shí)間
對HTTP事務(wù)來(lái)說(shuō)，該域表明squid花了多少時(shí)間來(lái)處理請求。在squid接受到HTTP請求時(shí)開(kāi)始計時(shí)，
在響應完全送出后計時(shí)終止。響應時(shí)間是毫秒級的。
對ICP查詢(xún)來(lái)說(shuō)，響應時(shí)間通常是0。這是因為squid回答ICP查詢(xún)非常迅速。甚至，squid在接受到
ICP查詢(xún)和發(fā)送完響應之間，不會(huì )更新進(jìn)程時(shí)鐘。
盡管時(shí)間值是毫秒級的，但是精度可能是10毫秒。在squid負載繁重時(shí)，計時(shí)變得沒(méi)那么精確。
3.客戶(hù)端地址
該域包含客戶(hù)端的IP地址，或者是主機名--假如激活了log_fqdn。出于安全或隱私的理由，你可能
需要使用client_netmask指令來(lái)掩蓋客戶(hù)端地址的一部分。然而，這樣讓來(lái)自同一客戶(hù)端的組請求
變得不可能。
4.結果/狀態(tài)碼
該域包含2個(gè)token，以斜杠分隔。第一個(gè)token叫結果碼，它把協(xié)議和事務(wù)結果（例如TCP_HIT或
UDP_DENIED）進(jìn)行歸類(lèi)。這些是squid專(zhuān)有的編碼，在13.2.1節里有定義。以TCP_開(kāi)頭的編碼指
HTTP請求，以UDP_開(kāi)頭的編碼指ICP查詢(xún)。
第2個(gè)token是HTTP響應狀態(tài)碼（例如200,304,404等）。狀態(tài)碼通常來(lái)自原始服務(wù)器。在某些情形
下，squid可能有義務(wù)自己選擇狀態(tài)碼。這些編碼在HTTP的RFC里定義，在隨后的Table 13-1里有
概述。
5.傳輸size
該域指明傳給客戶(hù)端的字節數。嚴格的講，它是squid告訴TCP/IP協(xié)議棧去發(fā)送給客戶(hù)端的字節數。
這就是說(shuō)，它不包括TCP/IP頭部的overhead。也請注意，傳輸size正常來(lái)說(shuō)大于響應的
Content-Length。傳輸size包括了HTTP響應頭部，然而Content-Length不包括。
傳輸size可用于近似的帶寬使用分析，但并非精確的HTTP實(shí)體size計算。假如需要了解響應的
Content-Length，可在store.log里找到它。
6.請求方式
該域包含請求方式。因為squid客戶(hù)端可能使用ICP或HTTP，請求方式就可能是HTTP-或ICP-這2種。
最普通的HTTP請求方式是GET。ICP查詢(xún)總以ICP_QUERY的形式被記載。請見(jiàn)6.1.2.8節關(guān)于squid
了解的HTTP方式列表。
7.URI
該域包含來(lái)自客戶(hù)端請求的URI。大多數記錄下來(lái)的URI實(shí)際是URL（例如，它們有主機名）。
Squid對某些失敗使用特殊的記錄格式。例如Squid不能解析HTTP請求，或者不能決定URI，這時(shí)你
可能見(jiàn)到類(lèi)似于"error:invalid-request." 的字串出現在URI的位置。例如：
1066036250.603 310 192.0.34.70 NONE/400 1203 GET error:invalid-request - NONE/- -
另外在該域里，也請留心URI里的空格字符。取決于uri_whitespace設置，squid可能在日志文件里
打印URI時(shí)帶空格字符。若發(fā)生這種情況，則閱讀access.log文件的日志分析工具可能會(huì )遇到麻煩。
在記日志時(shí)，squid刪掉了在第一個(gè)問(wèn)號(?)之后的所有URI字符，除非禁用了strip_query_terms指
令。
8.客戶(hù)端身份
Squid有2種不同的辦法來(lái)決定用戶(hù)的身份。一種是RFC 1413身份協(xié)議，另一種來(lái)自HTTP驗證頭部。
Squid試圖基于ident_lookup_access規則進(jìn)行身份查詢(xún)，假如有的話(huà)。另外，假如使用代理驗證
（或在代理人模式下的規范服務(wù)驗證），squid會(huì )在該域放置給定的用戶(hù)名。假如2者都提供給squid
一個(gè)用戶(hù)名，并且你使用了原始access.log格式，那么HTTP驗證名字會(huì )記錄下來(lái)，RFC 1413名字
會(huì )忽略掉。普通日志文件格式會(huì )把兩者都獨立的記錄。
9.對端編碼/對端主機
對端信息包含了2個(gè)token，以斜杠分隔。它僅僅與cache丟失的請求有關(guān)。第一個(gè)token指示如何選
擇下一跳，第二個(gè)token是下一跳的地址。對端編碼列在13.2.3節里。
當squid發(fā)送一個(gè)請求到鄰居cache時(shí)，對端主機地址是鄰居的主機名。假如請求是直接送到原始服務(wù)
器的，則squid會(huì )寫(xiě)成原始服務(wù)器的IP地址或主機名--假如禁用了log_ip_on_direct。NONE/-這個(gè)值
指明squid不轉發(fā)該請求到任何其他服務(wù)器。
10.內容類(lèi)型
原始access.log的默認的最后一個(gè)域，是HTTP響應的內容類(lèi)型。squid從響應的Content-Type頭部
獲取內容類(lèi)型值。假如該頭部丟失了，squid使用一個(gè)橫杠(-)代替。
假如激活了log_mime_headers指令，squid在每行追加2個(gè)附加的域：
11.HTTP請求頭部
Squid編碼HTTP請求頭部，并且在一對方括號之間打印它們。方括號是必須的，因為squid不編碼空格
字符。編碼方案稍許奇怪?；剀?chē)（ASCII 13）和換行（ASCII 10）分別打印成\r和\n。其他不可打印
的字符以RFC 1738風(fēng)格來(lái)編碼，例如Tab（ASCII 9）變成了%09。
12.HTTP響應頭部
Squid編碼HTTP響應頭部，并且在一對方括號之間打印它們。注意這些是發(fā)往客戶(hù)端的頭部，可能不
同于從原始服務(wù)器接受到的頭部。
Squid只有在整個(gè)響應發(fā)送到客戶(hù)端完成以后，才寫(xiě)access.log日志。這點(diǎn)允許squid在日志文件里包
含請求和響應兩者信息。然而，需要花費數分鐘甚至數小時(shí)才能完成的事務(wù)，請求期間的日志在
access.log里不可見(jiàn)。當這類(lèi)型的事務(wù)呈現出性能或策略問(wèn)題時(shí)，access.log可能對你沒(méi)有幫助。代
替的，可使用cache管理器來(lái)瀏覽掛起事務(wù)的列表（見(jiàn)14章）。
相應于HTTP請求，下列標簽可能出現在access.log文件的第四個(gè)域。
TCP_HIT
Squid發(fā)現請求資源的貌似新鮮的拷貝，并將其立即發(fā)送到客戶(hù)端。
TCP_MISS
Squid沒(méi)有請求資源的cache拷貝。
___FCKpd___6
Squid發(fā)現請求資源的貌似陳舊的拷貝，并發(fā)送確認請求到原始服務(wù)器。原始服務(wù)器返回304（未修改
）響應，指示squid的拷貝仍舊是新鮮的。
TCP_REF_FAIL_HIT
Squid發(fā)現請求資源的貌似陳舊的拷貝，并發(fā)送確認請求到原始服務(wù)器。然而，原始服務(wù)器響應失敗，
或者返回的響應Squid不能理解。在此情形下，squid發(fā)送現有cache拷貝（很可能是陳舊的）到客戶(hù)
端。
TCP_REFRESH_MISS
Squid發(fā)現請求資源的貌似陳舊的拷貝，并發(fā)送確認請求到原始服務(wù)器。原始服務(wù)器響應新的內容，指
示這個(gè)cache拷貝確實(shí)是陳舊的。
TCP_CLIENT_REFRESH_MISS
Squid發(fā)現了請求資源的拷貝，但客戶(hù)端的請求包含了Cache-Control: no-cache指令。Squid轉發(fā)
客戶(hù)端的請求到原始服務(wù)器，強迫cache確認。
TCP_IMS_HIT
客戶(hù)端發(fā)送確認請求，Squid發(fā)現更近來(lái)的、貌似新鮮的請求資源的拷貝。Squid發(fā)送更新的內容到客
戶(hù)端，而不聯(lián)系原始服務(wù)器。
TCP_SWAPFAIL_MISS
Squid發(fā)現請求資源的有效拷貝，但從磁盤(pán)裝載它失敗。這時(shí)squid發(fā)送請求到原始服務(wù)器，就如同這
是個(gè)cache丟失一樣。
TCP_NEGATIVE_HIT
在對原始服務(wù)器的請求導致HTTP錯誤時(shí)，Squid也會(huì )cache這個(gè)響應。在短時(shí)間內對這些資源的重復
請求，導致了否命中。negative_ttl指令控制這些錯誤被cache的時(shí)間數量。請注意這些錯誤只在內
存cache，不會(huì )寫(xiě)往磁盤(pán)。下列HTTP狀態(tài)碼可能導致否定cache（也遵循于其他約束）：
204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504。
TCP_MEM_HIT
Squid在內存cache里發(fā)現請求資源的有效拷貝，并將其立即發(fā)送到客戶(hù)端。注意這點(diǎn)并非精確的呈現
了所有從內存服務(wù)的響應。例如，某些cache在內存里，但要求確認的響應，會(huì )以
TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式記錄。
TCP_DENIED
因為http_access或http_reply_access規則，客戶(hù)端的請求被拒絕了。注意被http_access拒絕的
請求在第9域的值是NONE/-，然而被http_reply_access拒絕的請求，在相應地方有一個(gè)有效值。
TCP_OFFLINE_HIT
當offline_mode激活時(shí)，Squid對任何cache響應返回cache命中，而不用考慮它的新鮮程度。
TCP_REDIRECT
重定向程序告訴Squid產(chǎn)生一個(gè)HTTP重定向到新的URI（見(jiàn)11.1節）。正常的，Squid不會(huì )記錄這些
重定向。假如要這樣做，必須在編譯squid前，手工定義LOG_TCP_REDIRECTS預處理指令。
NONE
無(wú)分類(lèi)的結果用于特定錯誤，例如無(wú)效主機名。
相應于ICP查詢(xún)，下列標簽可能出現在access.log文件的第四域。
UDP_HIT
Squid在cache里發(fā)現請求資源的貌似新鮮的拷貝。
UDP_MISS
Squid沒(méi)有在cache里發(fā)現請求資源的貌似新鮮的拷貝。假如同一目標通過(guò)HTTP請求，就可能是個(gè)
cache丟失。請對比UDP_MISS_NOFETCH。
UDP_MISS_NOFETCH
跟UDP_MISS類(lèi)似，不同的是這里也指示了Squid不愿去處理相應的HTTP請求。假如使用了-Y命令行
選項，Squid在啟動(dòng)并編譯其內存索引時(shí)，會(huì )返回這個(gè)標簽而不是UDP_MISS。
UDP_DENIED
因為icp_access規則，ICP查詢(xún)被拒絕。假如超過(guò)95%的到某客戶(hù)端的ICP響應是UDP_DENIED，并
且客戶(hù)端數據庫激活了（見(jiàn)附錄A），Squid在1小時(shí)內，停止發(fā)送任何ICP響應到該客戶(hù)端。若這點(diǎn)發(fā)
生，你也可在cache.log里見(jiàn)到一個(gè)警告。
UDP_INVALID
Squid接受到無(wú)效查詢(xún)（例如截斷的消息、無(wú)效協(xié)議版本、URI里的空格等）。Squid發(fā)送
UDP_INVALID響應到客戶(hù)端。
Table 13-1列出了數字HTTP響應CODE和理由短句。注意Squid和其他HTTP客戶(hù)端僅僅關(guān)注這些數
字值。理由短句是純解釋性的，不會(huì )影響響應的意義。對每個(gè)狀態(tài)碼，也提供了一個(gè)到RFC 2616的具
體節的索引。注意狀態(tài)碼0和600是squid使用的非標準的值，不會(huì )在RFC里提到。
Table 13-1. HTTP response status codes
| Code | Reason phrase | RFC 2616 section |
| 0 | No Response Received (Squid-specific) | N/A |
| 1xx | Informational | 10.1 |
| 100 | Continue | 10.1.1 |
| 101 | Switching Protocols | 10.1.2 |
| 2xx | Successful | 10.2 |
| 200 | OK | 10.2.1 |
| 201 | Created | 10.2.2 |
| 202 | Accepted | 10.2.3 |
| 203 | Non-Authoritative Information | 10.2.4 |
| 204 | No Content | 10.2.5 |
| 205 | Reset Content | 10.2.6 |
| 206 | Partial Content | 10.2.7 |
| 3xx | Redirection | 10.3 |
| 300 | Multiple Choices | 10.3.1 |
| 301 | Moved Permanently | 10.3.2 |
| 302 | Found | 10.3.3 |
| 303 | See Other | 10.3.4 |
| 304 | Not Modified | 10.3.5 |
| 305 | Use Proxy | 10.3.6 |
| 306 | (Unused) | 10.3.7 |
| 307 | Temporary Redirect | 10.3.8 |
| 4xx | Client Error | 10.4 |
| 400 | Bad Request | 10.4.1 |
| 401 | Unauthorized | 10.4.2 |
| 402 | Payment Required | 10.4.3 |
| 403 | Forbidden | 10.4.4 |
| 404 | Not Found | 10.4.5 |
| 405 | Method Not Allowed | 10.4.6 |
| 406 | Not Acceptable | 10.4.7 |
| 407 | Proxy Authentication Required | 10.4.8 |
| 408 | Request Timeout | 10.4.9 |
| 409 | Conflict | 10.4.10 |
| 410 | Gone | 10.4.11 |
| 411 | Length Required | 10.4.12 |
| 412 | Precondition Failed | 10.4.13 |
| 413 | Request Entity Too Large | 10.4.14 |
| 414 | Request-URI Too Long | 10.4.15 |
| 415 | Unsupported Media Type | 10.4.16 |
| 416 | Requested Range Not Satisfiable | 10.4.17 |
| 417 | Expectation Failed | 10.4.18 |
| 5xx | Server Error | 10.5 |
| 500 | Internal Server Error | 10.5.1 |
| 501 | Not Implemented | 10.5.2 |
| 502 | Bad Gateway | 10.5.3 |
| 503 | Service Unavailable | 10.5.4 |
| 504 | Gateway Timeout | 10.5.5 |
| 505 | HTTP Version Not Supported | 10.5.6 |
| 6xx | Proxy Error | N/A |
| 600 | Unparseable Response Headers (Squid-specific) | N/A |
假如Squid從原始服務(wù)器沒(méi)有接受到任何響應，你可在access.log里看到狀態(tài)碼0。假如Squid接受到
的響應沒(méi)有包含HTTP頭部，就會(huì )出現狀態(tài)碼600。在少數情況下，某些原始服務(wù)器僅發(fā)送響應body，
而忽略了任何頭部。
聯(lián)系客服
