🔗 Squid 故障排除
如果您的 Squid 版本早于 2.6，那么它已经非常过时了。这些版本中遇到的许多问题在 2.6 及更高版本中都已得到修复。
您首先应该尝试使用更新的*受支持*版本进行测试，并解决该安装中存在的任何剩余问题。
当前版本可以从 https://squid.org.cn/Versions 或您的操作系统发行版处获取。具体操作方法在特定系统帮助页面中有概述。
您特定系统可能遇到的其他问题和解决方法可以在特定系统帮助故障排除中找到。
一些常见情况有其自己的详细解释和解决方法。
🔗 为什么我收到“代理访问被拒绝”？
您可能需要设置*http_access*选项以允许来自您的 IP 地址的请求。有关详细信息，请参阅 SquidAcl。
或者，您可能错误配置了您的某个 ACL。请检查*access.log*和*squid.conf*文件以获取线索。
🔗 连接到同级时收到“连接被拒绝”
当缓存尝试检索位于同级上的对象时，我收到*Connection Refused*，尽管同级认为它已将对象传输到我的缓存。
如果 HTTP 端口号错误但 ICP 端口正确，您将正确发送 ICP 查询，ICP 回复会欺骗您的缓存，使其认为配置是正确的，但大对象会失败，因为您的*squid.conf*文件中没有同级的正确 HTTP 端口。如果您的同级更改了其*http_port*，您可能会在一段时间后才注意到此问题。
🔗 文件描述符耗尽
如果您看到*Too many open files*错误消息，您很可能遇到了文件描述符耗尽。这可能是由于在文件描述符限制较低的操作系统上运行 Squid 所致。此限制通常可以在内核中或使用其他系统调优工具进行配置。您可以通过两种方式耗尽文件描述符：第一，您可以达到每个进程的文件描述符限制。第二，您可以达到系统中所有进程的总文件描述符限制。
Squid 3.x 提供了一个 ./configure 选项 –with-filedescriptors=N
即使 Squid 构建为支持大量 FD 并且系统配置默认设置为允许使用大量 FD，ulimit 或等效工具也可以随时更改 Squid 下的这些限制。在报告此问题或错误之前，请仔细检查您的启动脚本和用于运行或管理 Squid 的任何工具，以确定它们是否设置了较低的 FD 限制。
🔗 Linux
Linux 内核 2.2.12 及更高版本支持“无限”数量的打开文件，无需修补。大多数 glibc-2.1.1 及更高版本也是如此（据我所知，Squid 所触及的所有区域都是安全的，在后来的 glibc 版本中更是如此）。但您仍然需要采取一些措施，因为内核默认只允许进程使用多达 1024 个文件描述符，而 Squid 在构建时会获取此限制。
- 在配置 Squid 之前，请运行
ulimit -HS -n XXXX（其中 XXXX 是您需要支持的文件描述符数量）。如果您已经运行了 configure，请务必在 configure 之前运行make clean，因为脚本可能缓存了先前的结果。 - 按正常方式配置、构建和安装 Squid。
- 确保您的启动 Squid 的脚本包含上述*ulimit*命令以提高文件描述符限制。您可能还需要允许更大的出站连接端口范围（在* /proc/sys/net/ipv4/*中设置，例如在
echo 1024 32768 > /proc/sys/net/ipv4/ip_local_port_range中）。
请注意，*-n*选项与*-HS*选项是分开的。在某些系统上，如果您尝试组合它们，ulimit 将会失败。或者您可以
- 使用您所需的 configure 选项运行 configure。
- 编辑 include/autoconf.h 并将 SQUID_MAXFD 定义为您的所需限制。请确保将其设为一个不错的、干净的模 64 值（64 的倍数），以避免 libc 头文件中出现的各种错误。
- 按正常方式构建和安装 Squid。
- 在启动 Squid 时，请按照上述说明设置运行时 ulimit。
如果无法以 root 身份运行，请让您的系统管理员在 /etc/inittscript（参见 man initscript）中安装所需的 ulimit 命令，安装一个修补的内核，其中 include/linux/fs.h 中的 INR_OPEN 已更改为您所需的数量，或者让他们安装一个小的 suid 程序来设置限制（参见下面的链接）。
🔗 FreeBSD
此信息已过时，可能不再相关。
Eliezer Croitoru：参考 FreeBSD 手册中关于 Tuning Kernel Limits 的内容，基于 Adrian Chadd 的 文章。
- 文档描述了基本的“服务器接受”套接字限制为 128 个连接的队列。
- 您可能会看到类似“connection reset by peer”的消息，您需要将*kern.ipc.somaxconn*增加到 2048，以匹配大约 300 个用户的生产网络。
- 如果服务器负载很高，您需要将其增加到超过 16384 的限制。
🔗 通用 BSD
对于大多数 BSD 派生系统（SunOS、4.4BSD、OpenBSD、FreeBSD、NetBSD、BSD/OS、386BSD、Ultrix），您也可以使用“暴力”方法在内核中增加这些值（需要重新构建内核）。
- 如何检查我的最大文件描述符？
- 运行*pstat -T*并查找*files*值，通常表示为*当前*最大值的比率。
- 如何轻松增加它们？
- 一种方法是在内核配置文件中增加*maxusers*变量的值并构建新内核。此方法快速简便，但也会增加各种其他变量，您可能不需要或不想增加这些变量。
- 有更精确的方法吗？
- 另一种方法是找到内核构建区域中的*param.c*文件，并更改*maxusers*与最大打开文件数之间关系的算术。
以下是一些示例，应该能为您指明正确的方向。
🔗 FreeBSD（来自 2.1.6 内核）
与 SunOS 非常相似，编辑* /usr/src/sys/conf/param.c*并修改*maxusers*与*maxfiles*和*maxfilesperproc*变量之间的关系。
int maxfiles = NPROC*2;
int maxfilesperproc = NPROC*2;
其中 NPROC 定义为：*#define NPROC (20 + 16 * MAXUSERS)* 每个进程的限制也可以在内核配置文件中使用以下指令直接调整：*options OPEN_MAX=128*
🔗 BSD/OS（来自 2.1 内核）
编辑* /usr/src/sys/conf/param.c*并在此处调整*maxfiles*的计算。
int maxfiles = 3 * (NPROC + MAXUSERS) + 80;
其中 NPROC 定义为：*#define NPROC (20 + 16 * MAXUSERS)* 您还应该在内核配置文件中设置*OPEN_MAX*值以更改每个进程的限制。
🔗 之后重新配置
在您使用更多文件描述符重新构建/重新配置内核后，必须重新编译 Squid。Squid 的 configure 脚本确定有多少文件描述符可用，因此您必须确保 configure 脚本也再次运行。例如：
cd squid-1.1.x
make realclean
./configure --prefix=/usr/local/squid
make
🔗 关于移除对象的奇怪日志行是什么意思？
例如
97/01/23 22:31:10| Removed 1 of 9 objects from bucket 3913
97/01/23 22:33:10| Removed 1 of 5 objects from bucket 4315
97/01/23 22:35:40| Removed 1 of 14 objects from bucket 6391
这些日志条目是正常的，并不表示*squid*已达到*cache_swap_high*。
在*cachemgr.cgi*中查阅您的缓存信息页面，其中应有一行如下所示：
Storage LRU Expiration Age: 364.01 days
在指定时间段内未使用的对象将作为常规维护的一部分被移除。您可以使用配置文件中的*reference_age*来设置*LRU Expiration Age*值的上限。
🔗 我可以将 Windows NT FTP 服务器更改为以 Unix 格式列出目录吗？
是的，您可以！选择以下菜单：
- 开始
- 程序
- Microsoft Internet Server (Common)
- Internet Service Manager
这将打开一个框，其中包含您各种服务的图标。其中一个应该是一个小型的 ftp “文件夹”。双击它。
然后您需要选择服务器（应该只有一个）。选择它，然后从菜单中选择“属性”，然后选择顶部的“目录”选项卡。
底部将有一个名为“目录列表样式”的选项。选择“Unix”类型，而不是“MS-DOS”类型。
作者：*Oskar Pearson*
🔗 为什么我收到“忽略来自非同级 x.x.x.x 的 MISS”？
您正在从父缓存或同级缓存接收 ICP MISS（通过 UDP），而您的缓存不知道该缓存的 IP 地址。这可能发生在两种情况下。
如果对等节点是多宿主的，它通过 DNS 中未宣传的接口发送数据包。不幸的是，这是对等节点上的配置问题。您可以要求他们将 IP 地址接口添加到其 DNS，或使用 Squid 的“udp_outgoing_address”选项强制数据包从特定接口发出。例如：*在您的父级 squid.conf 上：*
udp_outgoing_address proxy.parent.com
在您的 squid.conf 上
cache_peer proxy.parent.com parent 3128 3130
在向多播地址发送 ICP 查询时，您也可以看到此警告。出于安全原因，Squid 要求您的配置列出所有侦听多播组地址的其他缓存。如果未知缓存侦听该地址并发送回复，您的缓存将记录警告消息。要解决此情况，请告知未知缓存停止侦听多播地址，或者如果它们是合法的，则将它们添加到您的配置文件中。
🔗 对带有下划线 (_) 的域名进行 DNS 查找总是失败。
主机命名标准（*RFC 952*和*RFC 1101*）不允许域名中使用下划线。
“名称”（网络、主机、网关或域名）是一个最多 24 个字符的文本字符串，取自字母表（A-Z）、数字（0-9）、连字符（-）和句点（。）。
最新版本的 BIND 附带的解析器库强制执行此限制，对于任何带有下划线的域名都会返回错误。最佳解决方案是向受影响站点的负责人抱怨，并要求他们重命名其主机。
另请参阅 comp.protocols.tcp-ip.domains FAQ。
一些人注意到*RFC 1033*暗示下划线*是*允许的。然而，这是一个*信息性* RFC，举了一个糟糕的例子，绝非*标准*。
🔗 为什么 Squid 说：“主机名中的非法字符；不允许使用下划线？”
请参阅上面的问题。下划线字符对于主机名无效。
一些 DNS 解析器允许使用下划线，所以是的，当您不使用 Squid 时，该主机名可能正常工作。
要让 Squid 允许在主机名中使用下划线，请在 squid.conf 中添加：enable_underscores on
🔗 为什么我收到来自同级缓存的访问被拒绝？
这个答案有点复杂，请耐心等待。
ICP 查询不包含任何父级或同级标识，因此接收者实际上无法得知对等缓存如何配置使用它。当一个缓存愿意为任何人提供缓存命中，但只为其付费用户或客户处理缓存未命中时，此问题变得很重要。换句话说，是否允许请求取决于结果是命中还是未命中。为此，Squid 在 1996 年 10 月获得了*miss_access*功能。
“miss access”的必要性使生活有点复杂，不仅仅是因为实现起来很麻烦。Miss access 意味着 ICP 查询回复必须是后续 HTTP 请求结果的极其准确的预测。确定此结果实际上非常困难，如果不是不可能的话，因为 ICP 请求无法传输完整的 HTTP 请求。此外，HTTP 请求的结果类型比 ICP 的要多。ICP 查询回复将是命中或未命中。然而，HTTP 请求可能导致源服务器发送“*304 Not Modified*”回复。这样的回复严格来说不是命中，因为对等节点需要将条件请求转发给源。同时，它也不是严格的未命中，因为本地对象数据仍然有效，而且 Not-Modified 回复非常小。
缓存层次结构的一个严重问题是陈旧性参数不匹配。考虑一个使用“严格”陈旧性参数的缓存*C*，以使其用户获得最大程度的当前数据。*C*有一个陈旧性参数不那么严格的同级*S*。当在*C*上请求对象时，*C*可能会发现*S*已经通过 ICP 查询和 ICP HIT 响应拥有该对象。*C*然后从*S*检索对象。
在 HTTP/1.0 世界中，*C*（以及*C*的客户端）将收到一个对象，该对象从未受其本地陈旧性规则的约束。HTTP/1.0 和 ICP 都提供了一种方法来只请求小于特定年龄的对象。如果检索到的对象根据*C*的规则已过时，它将被从*C*的缓存中移除，但只要它在*S*上仍然是新的，它将随后从*S*获取。这种配置不匹配问题是建立父级和同级关系的一个重大障碍。
HTTP/1.1 提供了许多请求头来指定陈旧性要求，这实际上为缓存层次结构带来了另一个问题：ICP 在查询或回复中仍然不包含任何年龄信息。因此*S*可能会返回一个 ICP HIT，如果其对象副本根据其配置参数是新的，但后续的 HTTP 请求可能会由于*Cache-control:*头（由*C*或*C*的客户端发出）而导致缓存未命中。现在出现了 ICP 回复不再与 HTTP 请求结果匹配的情况。
最终，根本问题在于 ICP 查询没有提供足够的信息来准确预测 HTTP 请求是否会是命中或未命中。事实上，当前的 ICP Internet Draft 在此主题上非常含糊。ICP HIT 到底是什么意思？它意味着“我对这个 URL 略知一二，并拥有该对象的一些副本吗？”或者它意味着“我有一个有效的对象副本，并且您允许从我这里获取吗？”
那么，如何解决这个问题？我们确实需要更改 ICP，以便包含陈旧性参数。在此之前，缓存层次结构的成员只有两个选项可以完全消除来自同级缓存的“访问被拒绝”消息：
- 确保所有成员都具有相同的*refresh_rules*参数。
- 根本不要使用*miss_access*。向您的同级缓存管理员保证*您的*缓存配置正确，并且您不会滥用他们的慷慨。同级缓存管理员可以检查他们的日志文件，以确保您信守承诺。*
如果以上两者都不现实，那么同级关系就不应该存在。
🔗 无法将套接字 FD NN 绑定到 *:8080 (125) 地址已在使用中
这意味着另一个进程已在端口 8080（或您正在使用的任何端口）上监听。这可能意味着您已经有一个 Squid 进程在运行，或者它来自另一个程序。要验证，请使用*netstat*命令。
netstat -antup | grep 8080
如果您发现某个进程已绑定到您的端口，但不确定是哪个进程，您可能可以使用优秀的*lsof*程序。它将显示您系统上每个打开的文件描述符的进程。
🔗 icpDetectClientClose：错误 xxx.xxx.xxx.xxx：(32) Broken pipe
这意味着客户端在 Squid 完成发送数据给它之前，客户端套接字已被客户端关闭。Squid 通过尝试从套接字*read(2)一些数据来检测此情况。如果*read(2)*调用失败，那么 Squid 就知道套接字已被关闭。通常*read(2)*调用返回*ECONNRESET: Connection reset by peer*，这些不会被记录。任何其他错误消息（例如*EPIPE: Broken pipe*）都会被记录到*cache.log*。请参阅您 Unix 手册第 2 部分的“intro”以获取所有错误代码的列表。
🔗 icpDetectClientClose：FD 135, 255 意外字节
这些是由行为不端的 Web 客户端尝试使用持久连接引起的。
🔗 Squid 是否支持 NTLM 身份验证？
是的，Squid 支持 Microsoft NTLM 身份验证，以验证访问代理服务器的用户（无论是正向代理还是反向代理）。有关详细信息，请参阅 ProxyAuthentication。
Squid 2.6+ 和 3.1+ 还支持正确允许用户针对启用了 NTLM 的 Web 服务器进行身份验证所需的基础架构。
作为 NTLM 身份验证后端，实际工作通常由*Samba*代表 Squid 完成。因此，Squid 支持 Samba 支持的任何身份验证后端，包括 Samba 本身以及 MS Windows 3.51 及更高版本的域控制器。
然而，HTTP 的 NTLM 是一种糟糕的身份验证协议示例，我们建议避免使用它，而选择更合理且符合标准的替代方案，如 Digest。
🔗 我的 Squid 在运行一段时间后变得非常慢。
这很可能是因为 Squid 使用的内存超出了您系统的需要。当 Squid 进程变得很大时，它会经历大量的页面交换。这将迅速降低 Squid 的性能。内存使用是一个复杂的问题。有许多因素需要考虑。
🔗 警告：启动“dnsserver”失败
这可能是权限问题。Squid 用户 ID 是否有权执行 dnsserver*程序？*
🔗 向 Squid 团队发送错误报告
🔗 致命错误：ipcache_init：DNS 名称查找测试失败
Squid 在开始服务器请求之前通常会测试您系统的 DNS 配置。Squid 尝试解析一些常见的 DNS 名称，这些名称在 dns_testnames*配置指令中定义。如果 Squid 无法解析这些名称，可能意味着：
- 您的 DNS 名称服务器无法访问或未运行。
- 您的系统正在启动过程中。
- 您的 /etc/resolv.conf 文件可能包含不正确的信息。
- 您的 /etc/resolv.conf 文件可能具有不正确的权限，并且 Squid 可能无法读取它。
要禁用此功能，请使用* -D*命令行选项。由于此问题在启动时显示，强烈建议 Squid 早于 3.1 的 OS 启动脚本使用此选项禁用测试。
🔗 致命错误：无法创建交换目录 /var/spool/cache：(13) 权限被拒绝
从 1.1.15 版开始，我们要求您首先运行
squid -z
以在您的文件系统上创建交换目录。
Squid 的默认用户是*nobody*。这可以通过在构建时使用*–with-default-user*选项的包来覆盖，或在 squid.conf 中使用*cache_effective_user*选项来覆盖。
Squid 进程在创建目录之前会采用指定的用户 ID。如果
cache_dir
目录（例如 /var/spool/cache）不存在，并且 Squid 用户 ID 没有创建它的权限，那么您将收到“permission denied”错误。这可以通过手动创建缓存目录来轻松修复。
或者，如果目录已存在，那么您的操作系统可能会在 mkdir() 系统调用时返回“Permission Denied”而不是“File Exists”。
🔗 致命错误：无法打开 HTTP 端口
要么
- Squid 用户 ID 没有绑定端口的权限，或者
- 另一个进程已绑定到该端口。 请记住，打开小于 1024 的端口号需要 root 权限。如果您在使用高端口号时看到此消息，或者即使以 root 身份启动 Squid 时看到，那么该端口已经被另一个进程打开。
🔗 致命错误：所有重定向器都已退出！
这在 Redirectors 中有解释。
🔗 致命错误：无法打开 /usr/local/squid/logs/access.log：(13) 权限被拒绝
在 Unix 中，进程和文件等都有所有者。对于 Squid，进程所有者和文件所有者应该是相同的。如果它们不相同，您可能会收到“permission denied”之类的消息。
要找出文件的所有者，请使用命令
ls -l
进程通常由启动它的用户拥有。然而，Unix 有时允许进程更改其所有者。如果您在 squid.conf 中指定了*cache_effective_user*选项的值，那么它将是进程所有者。文件必须由同一个用户 ID 拥有。
如果这一切都很令人困惑，那么您可能在没有更多了解 Unix 的情况下就不应该运行 Squid。作为参考，我推荐 Learning the UNIX Operating System, 4thEdition。
🔗 pingerOpen: icmp_sock: (13) 权限被拒绝
这意味着您的 pinger 辅助程序没有 root 权限。您应该在构建 Squid 时执行此操作：
make install pinger
或者
# chown root /usr/local/squid/bin/pinger
# chmod 4755 /usr/local/squid/bin/pinger
🔗 什么是转发循环？
转发循环是指一个请求通过一个代理超过一次。如果您遇到以下情况，可能会出现转发循环：
- 一个缓存将请求转发给自己。这可能发生在拦截缓存（或服务器加速）配置中。
- 一对或一组缓存相互转发请求。当 Squid 使用 ICP、Cache Digests 或 ICMP RTT 数据库来选择下一跳缓存时，可能会发生这种情况。
转发循环是通过检查*Via*请求头来检测的。每个“触碰”请求的缓存都必须将其主机名添加到*Via*头。如果一个缓存注意到传入请求的此头中有自己的主机名，它就知道某个地方存在转发循环。
当 Squid 检测到转发循环时，它会被记录到*cache.log*文件中，并附带收到的*Via*头。从这个头文件中，您可以确定是哪个缓存（列表中的最后一个）将请求转发给了您。
减少转发循环的一种方法是将*parent*关系更改为*sibling*关系。
🔗 accept 失败：(71) 协议错误
此错误消息主要在 Solaris 系统上看到。 Mark Kennedy 提供了一个很好的解释。
Error 71 [EPROTO] is an obscure way of reporting that clients made it onto your
server's TCP incoming connection queue but the client tore down the
connection before the server could accept it. I.e. your server ignored
its clients for too long. We've seen this happen when we ran out of
file descriptors. I guess it could also happen if something made squid
block for a long time.
##为什么我收到“fwdDispatch：无法检索‘https://www.buy.com/corp/ordertracking.asp’”
这些消息是由有缺陷的客户端引起的，主要是 Netscape Navigator。发生的情况是，Netscape 在持久 HTTP 连接上发送 HTTPS/SSL 请求。通常，当 Squid 收到 SSL 请求时，它看起来像这样：
CONNECT www.buy.com:443 HTTP/1.0
然后 Squid 打开到目标主机和端口的 TCP 连接，*实际*的请求会加密地通过此连接发送。这就是 SSL 的要点，所有信息都必须加密发送。
然而，有了这个客户端错误，Squid 收到的请求如下：
CONNECT https://www.buy.com/corp/ordertracking.asp HTTP/1.0
现在，所有头和消息体都*未加密*地发送给了 Squid。Squid 无法以某种方式将其转换为 SSL 请求。我们唯一能做的就是返回错误消息。
##Squid 无法访问 http://3626046468/ab2/cybercards/moreinfo.html 等 URL
作者：Dave J Woolley (DJW at bts dot co dot uk)
它们的目的是
- 混淆代理上的内容过滤规则，以及可能混淆某些浏览器关于它们是否是本地内网受信任站点的想法；
- 混淆 whois（？）；
- 让人们认为它们不是 IP 地址和未知的域名，以阻止他们尝试定位和向 ISP 投诉。
任何与之工作的浏览器或代理都应被视为安全风险。
RFC 1738 关于 URL 的主机名部分是这样说的：
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
🔗 我的缓存日志中有很多“URI 包含空格”错误消息，我该怎么办？
不幸的是，许多 Web 服务会生成带空格的 URL。当然，您喜欢的浏览器会自动处理这些错误的 URL。生成这些 URL 的服务器（或人）违反了互联网标准。空格字符应该被编码。
如果您希望 Squid 接受带空格的 URL，您必须决定如何处理它们。您可以在*squid.conf*中使用*uri_whitespace*选项进行设置，有四种选择：
-
- STRIP
- 这是正确的处理方式。这是 Squid 3.x 的默认设置。
-
- DENY
- 请求被拒绝，并显示“Invalid Request”消息。这是 Squid 2.x 的默认设置。
-
- ALLOW
- 请求被允许，URL 保持不变。
-
- ENCODE
- 空格字符根据 RFC 1738 进行编码。
-
- CHOP
- URL 在第一个空格字符处被截断，然后正常处理。
只有*STRIP*和*DENY*是处理这些 URI 的唯一批准方式。其他技术上是违规的，不应执行。有缺陷的 Web 服务应予以修复。它破坏的互联网比您的代理要多得多。
🔗 commBind：无法将套接字 FD 5 绑定到 127.0.0.1:0：(49) 无法分配请求的地址
这可能意味着您的系统没有环回网络设备，或者该设备未正确配置。所有 Unix 系统都应具有名为*lo0*的网络设备，并且应将其配置为地址 127.0.0.1。否则，您可能会收到上述错误消息。要检查您的系统，请运行：
ifconfig
结果应包含：
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
🔗 “sslReadClient：FD 14：读取失败：(104) Connection reset by peer”是什么意思？
“Connection reset by peer”是 Unix 操作系统有时为 read、write、connect 和其他系统调用返回的错误代码。
Connection reset 意味着对端（peer）在 TCP 连接上发送了 RESET 数据包。当一个主机收到一个不属于任何连接的数据包时，它会发送一个 RESET。例如，如果一方在另一方关闭连接的同时发送数据，那么当另一方收到数据时，它可能会发送一个重置返回。
这些消息出现在 Squid 的日志中可能表明存在问题，例如损坏的源服务器或父缓存。另一方面，它们可能是“正常的”，尤其是因为某些应用程序已知会强制连接重置而不是正常关闭。
除非您收到大量与 SSL 网站相关的用户投诉，否则您可能无需担心它们。
Rick Jones 指出，如果服务器运行 Microsoft TCP 堆栈，当监听队列溢出时，客户端会收到 RST 段。换句话说，如果服务器非常繁忙，新连接就会收到重置消息。这与理性行为相悖，但不太可能改变。
🔗 “连接被拒绝”是什么意思？
这是您的操作系统在响应 connect() 系统调用时生成的错误消息。当我们在尝试连接的端口号上没有服务器在监听时，就会发生这种情况。
您自己很容易生成此错误。只需 telnet 到一个随机的高位端口：
telnet 12345
发生这种情况是因为端口 12345 上没有服务器在监听连接。
当您在 URL 请求中看到此消息时，可能意味着源服务器网站暂时关闭。如果您有父缓存，它也可能意味着您的父缓存已关闭。
🔗 squid: 错误：没有运行副本
运行*squid -k rotate*等命令时，您可能会收到此消息。
此错误消息通常意味着 squid.pid 文件丢失。由于 PID 文件通常在 squid 运行时存在，因此 PID 文件丢失通常意味着 Squid 未运行。如果您不小心删除了 PID 文件，Squid 仍会继续运行，但您将无法向其发送任何信号。
首先，通过运行 ps 命令并查找 Squid 来定位进程 ID。您可能会看到两个进程，如下所示：
% ps ax | grep squid
PID TTY STAT TIME COMMAND
2267 ? Ss 0:00 /usr/sbin/squid-ipv6 -D -sYC
2735 pts/0 S+ 0:00 grep squid
8893 ? Rl 2:57 (squid) -D -sYC
8894 ? Ss 0:17 /bin/bash /etc/squid3/helper/redirector.sh
您需要的是 (squid) 进程 ID，在本例中是 8893。
第一个解决方案是手动创建 PID 文件并将进程 ID 号填入其中。例如：
echo 8893 > /usr/local/squid/logs/squid.pid
第二个方法是使用上述技术查找 Squid 进程 ID。然后向该进程发送一个 HUP 信号，这相当于运行 squid -k reconfigure。
kill -SIGHUP 8893
重新配置过程会自动创建一个新的 PID 文件。
🔗 FATAL: getgrnam failed to find groupid for effective group ‘nogroup’
您可能正在以 root 用户身份启动 Squid。Squid 正在尝试查找一个没有特殊权限的组 ID 来运行。默认是 nogroup，但您的系统上可能未定义此组。
最佳的解决方法是为 squid 分配一个低权限的用户 ID，并将该用户 ID 分配给一个组 ID。很有可能 nobody 用户以及 nogroup 组对您来说是可用的。
或者，在较旧版本的 Squid 中，可以在 squid.conf 中将 cache_effective_group 更改为 /etc/group 中一个非特权组的名称。很有可能 nobody 用户对您来说是可用的。
🔗 Squid 占用 100% CPU
这可能有很多原因。
Andrew Doroshenko 报告说，删除 /dev/null 或使用 nodev 选项挂载文件系统都可能导致 Squid 占用 100% CPU。他建议的解决方案是“touch /dev/null”。
🔗 urlParse: Illegal character in hostname ‘proxy.mydomain.com:8080proxy.mydomain.com’
由 Yomler of fnac.net 提供。
Internet Explorer 配置错误与任何使用 cydoor DLL 的应用程序结合使用，都会在日志中产生此条目。有关完整列表，请参阅 cydoor.com。
IE 的错误配置是使用了活动配置脚本 (proxy.pac) 以及活动或非活动但已填写的代理设置。IE 只会使用 proxy.pac。Cydoor 应用程序会同时使用两者，并生成错误。
禁用 IE 中的旧代理设置是不够的，您应该完全删除它们，例如只使用 proxy.pac。
🔗 国际化域名请求不起作用
作者：HenrikNordström。
有些人问为什么请求使用某些域名注册商“支持”的国家符号的域名在 Squid 中不起作用。这是因为目前在 HTTP 或 DNS 等当前互联网协议中还没有关于如何管理国家字符的标准。当前的互联网标准对可接受的主机名非常严格，只接受 A-Z、a-z、0-9 和 - 作为互联网主机名标签。超出这些范围的字符不符合当前的互联网标准，并将导致互操作性问题，例如与此类名称和 Squid 遇到的问题。
当 DNS 和 HTTP 标准化组就如何处理国际化域名达成共识时，如果需要对 Squid 进行任何更改，Squid 将会进行相应更改以支持此功能。
如果您对国际化域名标准化进程的进展感兴趣，请参阅 IETF IDN 工作组的 专用页面。
🔗 为什么有时会收到“Zero Sized Reply”？
当 Squid 向源服务器建立 TCP 连接，但由于某种原因，在 Squid 读取任何数据之前连接就关闭时，就会发生这种情况。根据各种因素，Squid 可能会重试请求。如果您看到“Zero Sized Reply”错误消息，则表示 Squid 无法重试，或者所有重试尝试都失败了。
是什么导致连接过早关闭？这可能是多种原因，包括：
- 过载的源服务器。
- TCP 实现/互操作性错误。有关详细信息，请参阅 SystemWeirdnesses。
- HTTP 持久连接的竞态条件。
- 有问题的或配置错误的 NAT 设备、防火墙和负载均衡器。
- 拒绝服务攻击。
- 在 FreeBSD 上使用 TCP 黑洞 (请参阅 SystemWeirdnesses)。
您可以使用 tcpdump 来跟踪和观察问题。
以下是一些您可以尝试减少“Zero Sized Reply”错误发生次数的方法：
- 删除或重命名您的 cookie 文件，并配置您的浏览器在接受任何新 cookie 之前提示您。
- 使用 server_persistent_connections 和 client_persistent_connections 指令禁用 HTTP 持久连接。
- 禁用 Squid 系统上的任何高级 TCP 功能。在 Linux 上禁用 ECN (echo 0 > /proc/sys/net/ipv4/tcp_ecn/)。
如果此错误给您带来了严重问题且上述方法无效，Squid 开发人员将很乐意帮助您找出问题所在。但是，我们需要您提供高质量的调试信息，例如 tcpdump 输出、服务器 IP 地址、操作系统版本以及包含完整 HTTP 头的 access.log 条目。
如果您想让 Squid 按需产生 Zero Sized 错误，您可以使用 一个简短的 C 程序。只需在一个端口 80 上没有运行服务器的系统上编译并启动该程序。然后尝试通过 Squid 连接到这个假的服务器。
🔗 为什么会收到“The request or reply is too large”错误？
作者：Grzegorz Janoszka
当您尝试使用 GET 下载大文件或使用 POST/PUT 上传大文件时，会出现此错误消息。有几个参数需要注意：
这两个参数默认设置为 0，这意味着没有限制。除非您真正了解它们如何影响您的 squid 行为，否则不应该限制它们。或者在标准代理中根本不限制。
从 Squid-3.1 开始，这两个参数默认设置为 64kB。早期版本的 Squid 默认值低至 2 kB。在某些非常罕见的情况下，即使是 64kB 也太低了，因此您可以增加此值。
🔗 Store Directory Statistics 中的负数或非常大的数字，或关于缓存超过限制的持续抱怨
在某些 swap.state 损坏的情况下，Squid 可能会对其缓存中的数据量感到非常困惑。这种损坏可能发生在断电或类似致命事件之后。要恢复，请先停止 Squid，然后删除每个缓存目录中的 swap.state 文件，然后重新启动 Squid。Squid 将会相对较好地从缓存文件中自动重建 swap.state 索引。
如果这不起作用或由于重新索引缓存而导致服务器负载过高，请删除缓存内容，如 OperatingSquid 中所述。
🔗 Windows 更新问题
回到 FAQ 索引
导航： 网站搜索、网站页面、分类、🔼 向上