在过去的一天左右，其中一个实例消耗了大量的带宽。 这意味着我们已经接近我们的津贴（大致相同的入境和出境）。
看看日志，我能看到的唯一的事情是在nginx access.log中有相同的文本string，有很多400 172错误。
我已经改变了nginx到不同的端口，实现了fail2ban，但由于stream量来自不同的IP，这是行不通的。 我也有我们的VPS提供商来改变我们的VPS的IP。
Fail2ban目前正在断开所有连接到80端口，这是不理想的，因为我们想要使用这个端口。
我们能做些什么来改善这种状况吗？ 如果我们正在降低可疑交通量，这还会计入我们的补贴吗？
更多信息
我设法通过更改nginx错误日志级别获得更多的细节。
似乎正在发生的唯一错误是cleint在读取客户端请求行时发送无效请求。
该域是新的，并没有被使用过（它是一个长期存在的领域之一，一个全新的子域）。
我将检查它是否使用相同的path。
还有什么原因，为什么只是因为入站的数据包被阻止，它的stream量越来越大？
一般来说，到达或到达网关的任何stream量（从主机出站时）都会占用您的带宽容量。 即使该活动不实质，或仅由您的主机防火墙阻止的stream量组成，情况也是如此。
尽快删除恶意stream量是理想的。 然而，听起来你可能有一个问题，涉及一个带宽很大但传输配额小的托pipe计划 – 如果是这样的话，你正在经历一个这样的计划的根本问题。
你从这里做什么取决于stream量是什么样子。 如果只有less数主机，则可以考虑使用VPS提供商的防火墙阻止这些主机，如果他们使这个选项可用的话。 如果它是一个search引擎机器人，添加一个robots.txt禁止他们抓取任何path产生的错误。
您的日志中的172不是错误代码的一部分 – 这些行仅意味着您的服务器返回了错误代码400 Bad Request ，它发回的错误页面长度为172字节。
由于它是错误400，它很可能不是一个search引擎（除非你正在运行一个奇怪的CGI应用程序），但不知道查询string（包括方法）是什么，很难说发生了什么事情。 但是，试着根据“攻击者”试图做的事情来处理它。
阻止nginx中的请求不太可能改变。
相反，您可以考虑通过放弃攻击stream量来阻止networking层的这些请求。 这意味着stream量的发起者将以一堆开放的连接结束。 如果速度没有变化，赔率相当好，这是恶意的。 您可能会考虑向原始ISP发送滥用投诉，如果这些投诉都来自同一个networking，并且看起来像洪水，而不是尝试做某事的自动过程。 这可能与其他人在您之前拥有您的域名一样简单。
不知道你的托pipe服务提供商，我不能给出一个明确的答案，拒绝的请求是否计入你的津贴，但一般来说，如果它到达你的服务器实例，它通常被计算在内。
在这种情况下绝对推荐使用fail2ban。 确保丢弃入站数据包而不拒绝它们将意味着您不应该以“连接被拒绝”ICMP数据包的forms看到任何出站通信量的增加。
传入请求中是否有任何模式？ 他们全部来自特定的CIDR块还是请求特定的URL？ 这是一个url合法的网站或一个随机的string？
如果每当我build议在Nginx中阻止这些请求时，如果它是相同的URL，如果你还没有。
如果这是一个特定的源CIDR块是相当小的，你可以从这些地址删除所有的连接。
这听起来像你是DDoS'd。 这个服务器故障文章提供了很好的build议： 我在DDoS下。 我能做什么？