我在 Google Cloud Platform 实例上运行 WordPress（版本 4.5.2）博客（由 Apache 提供服务），该实例使用 GCP 的网络设置完全与互联网隔离。只有来自同一 GCP 网络中的另一台计算机（面向互联网的代理，nginx 版本 1.10.0）的连接才允许在单个端口 80 上进行。前段时间，我发现 WordPress 计算机负载过重，这是由于对 /xmlrpc.php 的频繁 POST 请求造成的，我认为这是一种常见的攻击，因此我使用 .htaccess 阻止了对它的访问以争取一些时间。现在，apache 的日志中充斥着
<same external ip> - - [timestamp] "POST /xmlrpc.php HTTP/1.0" 403 <same answer length>
正如预期的那样。奇怪的是，nginx 日志中没有一条记录提到 xmlrpc.php，无论是在阻止它之前还是之后，尽管对博客页面和其余页面的有效请求都正常记录。我可以想到两种解释，但这两种解释都很难令人信服：
- 攻击者（我很确定这是一次故意攻击）利用 nginx 中的一些漏洞使请求避免被记录。
- 攻击者成功绕过了 GCP 防火墙，这更令人难以置信。
也许有某种方法可以追踪 TCP 数据包的来源（是我的负载均衡器还是外部地址）？或者也许我太偏执了，对这种情况有更简单的解释。
更新 我通过完全禁用 nginx 上的代理排除了选项 (1)，因此最不可能的解释仍然是唯一的解释。如果有人能证明我错了，那就太好了。
更新 2
几个小时后，攻击停止了，因为它不再发挥作用了（apache 只是响应了 403）。我想如果这种情况再次发生，可能的解决方案是tcpdump转储通信，然后使用 Wireshark 进行分析，以找出至少最后一跳的来源。不过，如果有更有经验的人分享一些如何做到这一点的知识或为我指明正确的方向，那就太好了。