Squid调试和故障处理

http://blog.zhdata.com/tag/squid第16章 调试和故障处理

16.1 一些通用问题

在讨论通用debug前，我先提起一些经常发生的问题。

16.1.1 “Failed to make swap directory”

Failed to make swap directory /var/spool/cache: (13) Permission denied 

这点发生在你运行squid                -z，并且squid的用户ID没有对/var/spool目录的写权限的时候。记住假如以root来启动squid，并且没有增加cache_effective_user行，那么squid默认以nobody用户运行。解决方法很简单：

# chown nobody:nobody /var/spool 

16.1.2 “Address already in use”

commBind: Cannot bind socket FD 10 to *:3128: Address already in use 

这个消息出现在bind()系统调用失败时，因为请求端口已经被其他应用程序所打开。通常，若已有一个squid在运行，而又试图启动第2个squid实例，就会发生这种情况。假如你见到这个错误消息，请使用ps来观察是否squid已经在运行。

Squid使用SO_REUSEADDR         socket选项，以便bind()调用总能成功，即使仍有一些残余的socket位于TIME_WAIT状态。若该消息出现，尽管squid没有在运行，但你的操作系统可能在处理这个问题上有bug。重启操作系统是解决问题的一个方法。

另一个可能性是端口（例如3128）当前已被其他应用程序使用。假如你怀疑这点，就可使用lsof程序来发现哪个应用正在该端口上侦听。FreeBSD用户能使用sockstat代替。

16.1.3 “Could not determine fully qualified hostname”

FATAL: Could not determine fully qualified hostname. Please set 'visible_hostname' 

假如squid不能识别它自己的完整可验证域名，就会报这个错。如下是squid使用的算法：

• 1) 假如你将squid的HTTP端口绑定在指定的接口地址上，squid试图对该地址执行反向DNS查询。假如成功，查询答案就被用上。
• 2) Squid调用gethostname( )函数，然后使用 gethostbyname(                    )函数，试着解析其IP地址。假如成功，squid使用后者函数返回的官方主机名串。

假如以上2项技术都不能工作，squid以前面提到的致命错误消息退出。在该情形下，必须使用visible_hostname指令来告诉squid它的主机名。例如：

visible_hostname my.host.name 

16.1.4 “DNS name lookup tests failed”

默认情况下，squid在启动前执行一些DNS查询。这点确保你的DNS服务器可到达，并且运行正确。假如测试失败，可在cache.log或syslog里见到如下消息：

FATAL: ipcache_init: DNS name lookup tests failed 

假如你在内网里使用squid，squid可能不能查询到它的标准主机名列表。可使用dns_testnames指令来指定你自己的主机名。只要接受到响应，squid就会认为DNS测试成功。

假如你想完全跳过DNS测试，简单的在启动squid时，使用-D命令行选项：

% squid -D ... 

16.1.5 “Illegal character in hostname”

urlParse: Illegal character in hostname 'super_bikes.tripod.com' 

默认情况下，squid检查URL的主机名部分的字符，假如它发现了非标准的字符，squid会抱怨。参考RFC                1034和1035，名字必须由字母A-Z,数字0-9，以及短横线(-)组成。下划线(_)是最有问题的字符之一。

Squid验证主机名是因为，在某些情形下，DNS对畸形字符的解析会很困难。例如：

% host super_bikes.tripod.com super_bikes.tripod.com has address 209.202.196.70 % ping super_bikes.tripod.com ping: cannot resolve super_bikes.tripod.com: Unknown server error 

Squid事先检查主机名，这好过于以后返回Unknown server                error消息。然后它会告诉用户主机名包含畸形字符。

某些DNS解析器确实能处理下划线和其他非标准字符。假如你想让squid不检查主机名，请在运行./configure时，使用—disable-hostname-checks选项。假如你允许下划线作为唯一的例外，那么使用—enable-underscores选项。

16.1.6 “Running out of filedescriptors”

WARNING! Your cache is running out of filedescriptors 

上述消息出现在squid用完了所有可用文件描述符时。假如这点发生在正常条件下，就有必要增加内核的文件描述符限制，并且重新编译squid。请见3.3.1章。

假如squid成为了拒绝服务攻击的目标，那也会见到这条消息。某些人可能有意或无意的，同时对squid发送成百上千条请求。在这种情形下，可以增加一条包过滤规则，阻止来自恶意地址的TCP进入连接。假如攻击是分布式的，或使用假冒源地址，就很难阻止它们。

转发循环（见10.2章）也可能耗尽squid的所有文件描述符，但仅仅发生在squid不能检测到死循环时。Via头部包含了某个请求遍历过的所有代理的主机名。squid在头部里查找它自己的主机名，假如发现了，就报告这个循环。假如因为某些理由，Via头部从外出或进入HTTP请求里过滤掉了，squid就不能检测到循环。在该情形下，所有文件描述符被循环遍历squid的同一请求迅速耗完。

16.1.7 “icmpRecv: Connection refused”

假如pinger程序没有正确的安装，可见到下列消息：

icmpRecv: recv: (61) Connection refused 

不过看起来更象是因为没有打开ICMP                socket的权限，pinger立刻退出了。因为该进程未在运行，当squid试图与它会话时，会接受到I/O错误。为了解决该问题，请到源代码目录以root运行：

# make install-pinger 

假如成功，你可见到pinger程序有下列文件属主和许可设置：

# ls -l /usr/local/squid/libexec/pinger -rws--x--x 1 root squid 140728 Sep 16 19:58 /usr/local/squid/libexec/pinger 

16.1.8 在运行一段时间后，Squid变慢了

看起来更象squid与其他进程，或与它自己，在竞争系统中的内存。当squid进程的内存不再充足时，操作系统被迫从交换空间进行内存读写。这对squid的性能有强烈影响。

为了证实这个想法，请使用top和ps等工具检查squid的进程大小。也检查squid自己的页面错误计数器，见14.2.1.24章的描述。一旦你已确认内存耗费是问题所在，请执行下列步骤来减少squid的内存使用：

• 1. 减少cache_mem值，见附录B。
• 2. 关掉内存池，用该选项：

  memory_pools off 

• 3. 通过降低一个或多个cache目录的size，减少磁盘cache大小。

16.1.9 调试访问控制

假如访问控制不能正确工作，如下是一些有用帮助。编辑squid.conf文件，设置debug_options行如下：

debug_options ALL,1 33,2 

然后，重配置squid:

% squid -k reconfigure 

现在，对每个客户端请求以及每个响应，squid都写一条消息到cache.log。该消息包含了请求方式，URI，是否请求/响应被允许或拒绝，以及与之匹配的最后ACL的名字。例如：

2003/09/29 20:22:05| The request GET http://images.slashdot.org:80/topics/topicprivacy.gif is ALLOWED, because it matched 'localhost'  2003/09/29 20:22:05| The reply for GET http://images.slashdot.org/topics/topicprivacy.gif is ALLOWED, because it matched 'all' 

知道ACL的名字，并非总能知道相应的http_access行，但也相当接近了。假如必要，可以复制acl行，并给予它们唯一的名字，以便给定的ACL名字仅仅出现在一个http_access规则里。

16.2 通过cache.log进行调试

从13.1章已了解到，cache.log包含了不同的操作消息，squid认为这些消息足够重要，从而告诉了你。我们也将这些作为debug消息考虑。可以使用debug_options指令来控制出现在cache.log里的消息的冗长度。通过增加debug等级，可以见到更详细的消息，有助于理解squid正在做什么。例如：

debug_options ALL,1 11,3 20,3 

在squid源代码里的每个debug消息有2个数字特征：1个节和1个等级。节范围从0到100，等级范围从0到10。通常来说，节号对应着源代码的组成成分。换句话说，在单一源文件里的所有消息，有相同的节号。在某些情形下，多个文件使用同一debug节，这意味着某个源文件变得太大，从而被拆分成多个小块。

每个源文件的顶部有一行，用于指示debug节。它看起来如此：

* DEBUG: section 9 File Transfer Protocol (FTP) 

我不指望你通过查看源文件来查找节号，所有相关信息定义在表16-1里。

Table 16-1. Debugging section numbers for the debug_options directive

Number	Description	Source file(s)
0	Client Database	client_db.c
1	Startup and Main Loop	main.c
2	Unlink Daemon	unlinkd.c
3	Configuration File Parsing	cache_cf.c
4	Error Generation	errorpage.c
5	Socket Functions	comm.c
5	Socket Functions	comm_select.c
6	Disk I/O Routines	disk.c
7	Multicast	multicast.c
8	Swap File Bitmap	filemap.c
9	File Transfer Protocol (FTP)	ftp.c
10	Gopher	gopher.c
11	Hypertext Transfer Protocol (HTTP)	http.c
12	Internet Cache Protocol	icp_v2.c
12	Internet Cache Protocol	icp_v3.c
13	High Level Memory Pool Management	mem.c
14	IP Cache	ipcache.c
15	Neighbor Routines	neighbors.c
16	Cache Manager Objects	cache_manager.c
17	Request Forwarding	forward.c
18	Cache Manager Statistics	stat.c
19	Store Memory Primitives	stmem.c
20	Storage Manager	store.c
20	Storage Manager Client-Side Interface	store_client.c
20	Storage Manager Heap-Based Replacement	repl/heap/store_heap_replacement.c
20	Storage Manager Logging Functions	store_log.c
20	Storage Manager MD5 Cache Keys	store_key_md5.c
20	Storage Manager Swapfile Metadata	store_swapmeta.c
20	Storage Manager Swapin Functions	store_swapin.c
20	Storage Manager Swapout Functions	store_swapout.c
20	Store Rebuild Routines	store_rebuild.c
21	Misc Functions	tools.c
22	Refresh Calculation	refresh.c
23	URL Parsing	url.c
24	WAIS Relay	wais.c
25	MIME Parsing	mime.c
26	Secure Sockets Layer Proxy	ssl.c
27	Cache Announcer	send-announce.c
28	Access Control	acl.c
29	Authenticator	auth/basic/auth_basic.c
29	Authenticator	auth/digest/auth_digest.c
29	Authenticator	authenticate.c
29	NTLM Authenticator	auth/ntlm/auth_ntlm.c
30	Ident (RFC 1413)	ident.c
31	Hypertext Caching Protocol	htcp.c
32	Asynchronous Disk I/O	fs/aufs/async_io.c
33	Client-Side Routines	client_side.c
34	Dnsserver Interface	dns.c
35	FQDN Cache	fqdncache.c
37	ICMP Routines	icmp.c
38	Network Measurement Database	net_db.c
39	Cache Array Routing Protocol	carp.c
40	Referer Logging	referer.c
40	User-Agent Logging	useragent.c
41	Event Processing	event.c
42	ICMP Pinger Program	pinger.c
43	AIOPS	fs/aufs/aiops.c
44	Peer Selection Algorithm	peer_select.c
45	Callback Data Registry	cbdata.c
45	Callback Data Registry	leakfinder.c
46	Access Log	access_log.c
47	Store COSS Directory Routines	fs/coss/store_dir_coss.c
47	Store Directory Routines	fs/aufs/store_dir_aufs.c
47	Store Directory Routines	fs/diskd/store_dir_diskd.c
47	Store Directory Routines	fs/null/store_null.c
47	Store Directory Routines	fs/ufs/store_dir_ufs.c
47	Store Directory Routines	store_dir.c
48	Persistent Connections	pconn.c
49	SNMP Interface	snmp_agent.c
49	SNMP Support	snmp_core.c
50	Log File Handling	logfile.c
51	File Descriptor Functions	fd.c
52	URN Parsing	urn.c
53	AS Number Handling	asn.c
54	Interprocess Communication	ipc.c
55	HTTP Header	HttpHeader.c
56	HTTP Message Body	HttpBody.c
57	HTTP Status-Line	HttpStatusLine.c
58	HTTP Reply (Response)	HttpReply.c
59	Auto-Growing Memory Buffer with printf	MemBuf.c
60	Packer: A Uniform Interface to Store Like Modules	Packer.c
61	Redirector	redirect.c
62	Generic Histogram	StatHist.c
63	Low Level Memory Pool Management	MemPool.c
64	HTTP Range Header	HttpHdrRange.c
65	HTTP Cache Control Header	HttpHdrCc.c
66	HTTP Header Tools	HttpHeaderTools.c
67	String	String.c
68	HTTP Content-Range Header	HttpHdrContRange.c
69	HTTP Header: Extension Field	HttpHdrExtField.c
70	Cache Digest	CacheDigest.c
71	Store Digest Manager	store_digest.c
72	Peer Digest Routines	peer_digest.c
73	HTTP Request	HttpRequest.c
74	HTTP Message	HttpMsg.c
75	WHOIS Protocol	whois.c
76	Internal Squid Object handling	internal.c
77	Delay Pools	delay_pools.c
78	DNS Lookups; interacts with lib/rfc1035.c	dns_internal.c
79	Squid-Side DISKD I/O Functions	fs/diskd/store_io_diskd.c
79	Storage Manager COSS Interface	fs/coss/store_io_coss.c
79	Storage Manager UFS Interface	fs/ufs/store_io_ufs.c
80	WCCP Support	wccp.c
82	External ACL	external_acl.c
83	SSL Accelerator Support	ssl_support.c
84	Helper Process Maintenance	helper.c

debug等级这样分配：重要消息有较低值，非重要消息有较高值。0等级是非常重要的消息，10等级是相对不紧要的消息。另外，关于等级其实并没有严格的向导或要求。开发者通常自由选择适应的debug等级。

debug_options指令决定哪个消息出现在cache.log，它的语法是：

debug_options section,level section,level ... 

默认设置是ALL,1，这意味着squid会将所有等级是0或1的debug消息打印出来。假如希望cache.log里出现更少的debug消息，可设置debug_options为ALL,0。

假如想观察某个组件的其他debug信息，简单的将相应的节号和等级增加到debug_options列表的末端。例如，如下行对FTP服务端代码增加了等级5的debug:

debug_options ALL,1 9,5 

如同其他配置指令一样，可以改变debug_options，然后给squid发送重置信号：

% squid -k reconfigure 

注意debug_options参数是按顺序处理的，后来的值会覆盖先前的值。假如使用ALL关键字，这点尤其要注意。考虑如下示例：

debug_options 9,5 20,9 4,2 ALL,1 

在该情形下，最后的值覆盖了所有先前的设置，因为ALL,1对所有节设置了debug等级为1。

选择合适的debug节号和等级有时非常困难，尤其是对squid新手而言。许多更详细的debug消息仅对squid开发者和熟悉源代码的用户有意义。无经验的squid用户会发现许多debug消息无意义和不可理解。进一步的说，假如squid相对忙的话，你可能对某个特殊请求或事件进行独立debug有困难。假如你能一次用一个请求来测试squid，那么高的debug等级通常更有用。

若以高debug等级来运行squid较长时间，需要特别谨慎。假如squid繁忙，cache.log增长非常快，并可能最终耗尽它的分区的剩余空间。假如这点发生，squid以致命消息退出。另一个关注点是性能可能下降明显。因为有大量的debug消息，squid要耗费许多CPU资源来格式化和打印字符串。将所有debug消息写往cache.log，也浪费了大量的磁盘带宽。

16.3 Coredump，断点，和堆栈跟踪

假如不幸，squid可能在运行时遭遇致命错误。这类型的错误来自3个风格：断点，总线错误，和异常分片。

断点是源代码里的正常检测。它是一个工具，被开发者用来确认在处理某事情前，相应的条件总为真。假如条件为假，程序退出并创建一个core文件，以便开发者能分析形势。如下是个典型的示例：

int some_array[100]; void some_func(int idx) { ... assert(idx < 100); some_array[idx]++; ... } 

这里，断点确保数组索引的值位于数组范围内。假如去访问大于或等于100的数组元素，就会遇到错误。假如不知何故，idx的值不小于100，程序运行时会打印如下消息：

assertion failed: filename.c:123: "idx < 100" 

假如这点发生在squid上，就可在cache.log里见到”assertion                failed”消息。另外，操作系统会创建一个core文件，这对事后分析有用。在本节结尾，我会解释如何去处理core文件。

总线错误是：由于处理器检测到其总线上的异常条件，会引发机器语言指令执行时致命失败。当处理器试图操作非连续的内存地址时，通常会发生这种错误。在64位处理器系统上可能更容易见到总线错误，例如Alpha和某些SPARC                    CPU。幸运的是，它们容易修复。

异常分片错误不幸的更常见，且有时难以修复。SEGV通常发生在进程试图访问无效内存区域时（可能是个NULL指针，或超出进程空间之外的内存地址）。当bug原因和SEGV影响在不同时间呈现时，它们特别难于捕获到。

Squid默认捕获总线错误和异常分片，当它们发生时，squid试图执行一个clean                shutdown（清理关闭）。可在cache.log里见到类似的语句：

FATAL: Received Bus Error...dying. 2003/09/29 23:18:01| storeDirWriteCleanLogs: Starting... 

大多数情形下，squid能够写swap.state文件的clean版本。在退出前，squid调用abort()函数来创建core文件。core文件可以帮助你或其他开发者来捕获和修复bug。

在错误发生时马上创建core文件，而不是先调用clean                shutdown过程，这样更利于调试。使用-C命令行选项，可以告诉squid不去捕获总线错误和异常分片：

% squid -C ... 

注意某些操作系统使用文件名core，而另外一些优先考虑进程名（例如squid.core）。一旦找到core文件，请使用调试器来进行堆栈跟踪。gdb是GNU调试器–GNU                C编译器的配套工具。假如没有gdb，可试着运行dbx或adb代替。如下显示如何使用gdb来进行堆栈跟踪：

% gdb /usr/local/squid/sbin/squid /path/to/squid.core ... Core was generated by 'squid'. Program terminated with signal 6, Abort trap. ... 

然后，敲入where来打印堆栈轨迹：

(gdb) where #0 0x28168b54 in kill ( ) from /usr/lib/libc.so.4 #1 0x281aa0ce in abort ( ) from /usr/lib/libc.so.4 #2 0x80a2316 in death (sig=10) at tools.c:301 #3 0xbfbfffac in ?? ( ) #4 0x80abe0a in storeDiskdSend (mtype=4, sd=0x82101e0, id=1214000, sio=0x9e90a10, size=4096, offset=-1, shm_offset=0) at diskd/store_io_diskd.c:485 #5 0x80ab726 in storeDiskdWrite (SD=0x82101e0, sio=0x9e90a10, buf=0x13e94000 "...", size=4096, offset=-1, free_func=0) at diskd/store_io_diskd.c:251 #6 0x809d2fb in storeWrite (sio=0x9e90a10, buf=0x13e94000 "...", size=4096, offset=-1, free_func=0) at store_io.c:89 #7 0x80a1c2d in storeSwapOut (e=0xc5a7800) at store_swapout.c:259 #8 0x809b667 in storeAppend (e=0xc5a7800, buf=0x810f9a0 "...", len=57344) at store.c:533 #9 0x807873b in httpReadReply (fd=134, data=0xc343590) at http.c:642 #10 0x806492f in comm_poll (msec=10) at comm_select.c:445 #11 0x8084404 in main (argc=2, argv=0xbfbffa8c) at main.c:742 #12 0x804a465 in _start ( ) 

你可见到，堆栈轨迹打印了每个函数的名字，它的参数，以及源代码文件名和行数。当捕获bug时，这些信息特别有用。然而在某些情形下，这些还不够。可能要求你在调试器里执行其他命令，例如打印来自某个函数的变量的值：

(gdb) frame 4 #4 0x80abe0a in storeDiskdSend (mtype=4, sd=0x82101e0, id=1214000, sio=0x9e90a10, size=4096, offset=-1, shm_offset=0) at diskd/store_io_diskd.c:485 485 x = msgsnd(diskdinfo->smsgid, &M, msg_snd_rcv_sz, IPC_NOWAIT); (gdb) set print pretty (gdb) print M $2 = { mtype = 4, id = 1214000, seq_no = 7203103, callback_data = 0x9e90a10, size = 4096, offset = -1, status = -1, shm_offset = 0 } 

在报告了某个bug后，请保留core文件一些天，可能还需要从它获取其他信息。

16.3.1 不能找到core文件？

core文件写在进程的当前目录。squid在启动时默认不改变其当前目录。这样你的core文件（如果有的话），会写在启动squid的目录。假如文件系统没有足够的自由空间，或进程属主没有对该目录的写权限，就无法产生core文件。可以使用coredump_dir指令来让squid使用指定的coredump目录–位于其他地方的有充足自由空间和完全权限的目录。

进程资源限制也会阻止产生core文件。进程限制参数之一是coredump文件的大小。大部分操作系统默认设置这个值为”无限”。在当前shell里使用limits或ulimit命令，可以检查当前限制。然而请注意，你的shell的限制可能不同于squid的进程限制，特别是当squid随系统启动而自动启动时。假如怀疑进程限制阻止了core文件的产生，试试这样：

csh% limit coredumpsize unlimited csh% squid -NCd1 

在FreeBSD上，某个sysctl参数控制了操作系统对调用了setuid()或setgid()函数的进程，是否产生core文件。假如以root启动，squid会用到这些函数。这样为了得到coredump，必须告诉内核创建core文件，用这个命令：

# sysctl kern.sugid_coredump=1 

请见sysctl.conf的manpage，关于在系统启动时如何自动设置变量的信息。

16.4 重现问题

有时候可能遇到这样的问题：某个请求，或原始服务器看起来不能与squid协调工作。可以使用下面的技术来确定问题在于squid，客户端，或原始服务器。技巧就是捕获HTTP请求，然后用不同的方法响应它，直到你验证了问题。

捕获HTTP请求意味着获取除了URL外的更多信息，包括请求方式，HTTP版本号，和所有请求头部。捕获请求的一个方法是，短期激活squid的完整debug模式。在squid主机上，敲入：

% squid -kdebug 

然后，到web浏览器上发布请求。squid几乎会立刻接受到请求。在若干秒后，回到squid主机，并发布同样的命令：

% squid -kdebug 

现在cache.log文件包含了上述客户端的请求。假如squid繁忙，cache.log会包含大量的请求，所以你必须查找它。它看起来如下：

2003/09/29 10:37:40| parseHttpRequest: Method is 'GET' 2003/09/29 10:37:40| parseHttpRequest: URI is 'http://squidbook.org/' 2003/09/29 10:37:40| parseHttpRequest: Client HTTP version 1.1. 2003/09/29 10:37:40| parseHttpRequest: req_hdr = { User-Agent: Mozilla/5.0 (compatible; Konqueror/3) Pragma: no-cache Cache-control: no-cache Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 Accept-Language: en Host: squidbook.org 

注意squid把首行元素分开打印，必须手工组合它们如下：

GET http://squidbook.org/ HTTP/1.1 

捕获完整请求的另一个方法是使用工具例如netcat或socket (http://www.jnickelsen.de/socket/                )。启动socket程序侦听在某个端口，然后配置浏览器使用该端口作为代理地址。当再次发起请求时，socket打印出HTTP请求：

% socket -s 8080 GET http://squidbook.org/ HTTP/1.1 User-Agent: Mozilla/5.0 (compatible; Konqueror/3) Pragma: no-cache Cache-control: no-cache Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 Accept-Language: en Host: squidbook.org 

最后，还可以使用网络包分析工具例如tcpdump或ethereal。使用tcpdump捕获到一些包后，可以使用tcpshow来查看它们：

# tcpdump -w tcpdump.log -c 10 -s 1500 port 80 # tcpshow -noHostNames -noPortNames < tcpdump.log | less ... 

Packet 4 TIME: 08:39:29.593051 (0.000627) LINK: 00:90:27:16:AA:75 -> 00:00:24:C0:0D:25 type=IP IP: 10.0.0.21 -> 206.168.0.6 hlen=20 TOS=00 dgramlen=304 id=4B29 MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=15DC TCP: port 2074 -> 80 seq=0481728885 ack=4107144217 hlen=32 (data=252) UAPRSF=011000 wnd=57920 cksum=EB38 urg=0 DATA: GET / HTTP/1.0. Host: www.ircache.net. Accept: text/html, text/plain, application/pdf, application/ postscript, text/sgml, */*;q=0.01. Accept-Encoding: gzip, compress. Accept-Language: en. Negotiate: trans. User-Agent: Lynx/2.8.1rel.2 libwww-FM/2.14. 

.

注意tcpshow按数据里的新行字符为周期来进行打印。

一旦捕获到了某个请求，就将它存到文件。然后可以使用netcat或socket来让它重新通过squid：

% socket squidhost 3128 < request | less 

假如响应看起来正常，问题可能在于用户代理。否则，可以改变不同事情来孤立问题。例如，假如你看到一些古怪的HTTP头部，那就从请求里删除它们，然后再试一次。让请求直接到达原始服务器，而不是经过squid，这样做也可调试。方法就是从请求里删除http://host.name/，并将请求发送到原始服务器：

% cat request GET / HTTP/1.1 User-Agent: Mozilla/5.0 (compatible; Konqueror/3) Pragma: no-cache Cache-control: no-cache Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 Accept-Language: en Host: squidbook.org % socket squidbook.org 80 < request | less 

以这种方式使用HTTP时，请参考RFC 2616和Oreilly的HTTP:The Definitive Guide这本书。

16.5 报告Bug

假如你的squid版本已经有几个月未更新了，在报告bug前你应该更新它。因为其他人可能也注意了同样的bug，并且它已被修复。

假如你发现了squid的合理bug，请将它填入到squid的bug跟踪数据库：http://www.squid-cache.org/bugs/ 。         它当前是个”bugzilla”数据库，需要你创建一个帐号。当bug被squid开发者处理了时，你会接到更新通知。

假如你对报告bug很陌生，请先花时间阅读Simon                Tatham写的”How to Report Bugs Effectively” (http://www.chiark.greenend.org.uk/~sgtatham/bugs.html )。

当报告bug时，确认包含下列信息：

• 1) Squid版本号。假如bug发生在不止一个版本上，就也要写上其他版本号。
• 2) 操作系统名字和版本。
• 3) bug每次都发生，还是偶尔发生。
• 4) 所发生事情的精确描述。类似于”它不能工作”，”请求失败”之类的语句，本质上对bug修复者无用。记得要非常详细。
• 5) 对断点，总线错误，或异常分片的堆栈跟踪。

记住squid开发者通常是无报酬的义务劳动，所以要有耐心。严重bug比小问题享有更高的解决优先级。