好的，这是场景。我们将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 Forbidden机会接近0％的解决方案。
完全不知所措。任何想法将不胜感激。
答案 0 :(得分：0)
所以事实证明，这一直是 mod_security 的错误。我不知道我怎么会错过告诉我的关键细节，即后端服务器中实际安装了mod_security的地方，而这正是请求被拦截的地方。
我们最终将有关mod_security的一些规则列入白名单，以便它不会主动破坏从外部源进行的某些API调用。