好的，这是场景。我们将API请求发送到NGINX服务器，然后将其重定向到AWS Elastic Load Balancer，AWS Elastic Load Balancer的目标指向我们的后端服务器。后端服务器处理请求，返回响应。没有什么不寻常的，对吧？
好吧，无论出于何种原因，有时来自特定API资源的POST请求都以403结尾。我们在Proxy Server日志（/var/log/nginx/access.log）中看到它返回了403，然后Load Balancer日志（访问日志，写入S3）也显示403。但是，后端服务器（catalina.out）中根本没有日志表明请求甚至已经到达。 [这使我相信负载均衡器会以某种方式丢弃某些请求，并且永远不会将其发送到后端。当然，这只是表面层的假设。我真的不确定请求在哪里被卡住/丢弃。
需要注意的是，在403情况下，返回请求403所花费的时间少于<60ms。如果返回200，通常花费约250ms。因此，看来Load Balancer甚至根本没有尝试将其带到后端服务器，而只是假设403在某处。
断断续续只会使问题变得更糟，因为查明问题更加困难。
我们实际上已经尝试了迁移到现代的应用程序负载平衡器，并且有一段时间这种问题已经消失了。但是现在，即使使用更新的负载均衡器，我们也会再次获得更多间歇性的403。
该问题已经存在了将近一年，但仍未找到能够使403禁止机会接近0％的解决方案。
这里完全不知所措。任何想法将不胜感激。
因此事实证明，这一直是mod_security的错误。我不知道我怎么会错过告诉我的关键细节，即后端服务器中实际安装了mod_security的地方，而这正是请求被拦截的地方。
我们最终将有关mod_security的一些规则列入白名单，以便它不会主动破坏来自外部资源的某些API调用。