不，您不应该担心，尤其是HEAD您引用的 HTTP 请求的速率。平均每半小时一个这样的请求真的不多。基本上，HEAD请求会按照盒子上的说明进行操作，也就是说，您的 Web 服务器只会返回响应标头，而不会附加完整的响应正文。这对于降低简单任务的带宽要求很有用，例如为请求的位置建立响应代码、客户端缓存验证等。然后可以使用它来确定您的 Web 服务器正在响应，或者如果请求的位置仍然可用，则不重新发送同时未更改且已由客户端本地缓存的内容，...取决于您的服务器的响应HTTP 状态码和标头内容。

现在，这些请求可能相当频繁，有时在数量上有点烦人，但从技术上讲，它们在消耗资源方面更适合您的服务器，因为编写良好的网络主机可以更快地处理此类请求并消耗更少的上传带宽来发送回一个响应，而不是它必须处理并在其响应中包含一个完整的文档。对于较大的媒体文件，这一点变得更加明显。因此，我不建议在您的 Web 服务器配置中阻止此类请求，如果它们使您的服务器日志文件的可读性降低，我建议您将此类请求通过管道传输到单独的日志文件中。

就这些标头中返回的内容而言，它们与普通 请求没有什么不同，只是GET内容长度会明显更小。并且没有理由认为HEADHTTP 请求的增加是对服务器的某种形式的 DOS 攻击，因为攻击者发送GET请求需要同样的努力，同时更快地耗尽服务器的资源。唯一的情况是，如果您HEAD不GET通过其他方式（例如请求 IP）限制或阻止前者，但您限制或过滤后者以及其他一些常见的 HTTP 请求类型，例如POST，这将是配置错误的情况，并且并不常见。请确保您不会无意中在配置中为不太常见的请求方法禁用任何此类过滤，以确保这一点。

因此，是否应该阻止HEAD请求取决于您，但我不会打扰。还有其他一些更令人担忧的 HTTP 请求类型，特别是如果您甚至在主机上都没有使用它们，例如TRACE, SEARCH, OPTIONS,... 而且禁用对所有 HTTP 的响应始终是一个好习惯您的服务器软件没有任何用途的请求方法。例如，这是来自我的 Apache 配置：

RewriteCond %{REQUEST_METHOD} ^(TRACE|SEARCH|TRACK|OPTIONS|PUT|QUIT|CONNECT|DELETE|PATCH|DEBUG|PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK) 
RewriteRule .* - [F]

这确保没有提供任何列出的方法（请求从 Web 服务器软件转发到处理这些请求并处理它们的应用程序），并且 Web 服务器立即通过403 Forbidden向客户端返回状态代码来拒绝它们。请注意，尽管您的 Web 应用程序可能被编写为需要我在配置中阻止的一些 HTTP 方法，但此示例并不打算直接复制，如果不谨慎使用，可能会破坏您的 Web 主机的功能！