我们有一个应用程序托管在一个Azure aks kubernetes集群上。它基本上是一个web应用，使用java后端和一个nginx容器作为反向代理来引导http流量。大部分流量被路由到后端服务，但我们将几个端点引导回我们的应用的预置实例（使用一个公共域）。
这种设置在相当稳定的流量负载下，大约一周内运行得非常好，然后突然停止了对我们的内部资源的流量代理。我们起初以为是有人改变了防火墙设置，但进一步测试发现，问题出在托管nginx代理的单个节点上。
我可以ssh进入该节点，并尝试使用公共http地址访问我们的on-prem服务器，但失败了。然而，我可以访问互联网上的任何其他网站，包括我们在其他IP地址上托管的网站。如果我通过ssh连接到另一个节点，我可以顺利访问我们的on-pre托管网站。似乎我们的节点被阻止或被阻止访问我们的网站，但我们找不到负责的机制。据了解，没有进行过防火墙或配置更改。Azure aks文档说，http流量出口没有默认限制。有人遇到过这个问题吗？
这是我们nginx配置中的一个块，它将请求代理到我们的本地实例。
location /civix/content/oic {
proxy_pass $on_prem_site;
proxy_set_header Host $server_name;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_intercept_errors on;
}
由于您能够从行为不正常的节点连接到其他站点，我将假设这不是解析DNS名称的问题，您只是在DNS查找成功后无法连接到on-prem应用程序。任何关于无法连接到on-prem应用的额外细节都会有所帮助。
为获得即时反馈，请尝试关闭 proxy_intercept_errors 的设置，看看是否能提供更多有用的信息。
检查on-prem应用程序是否限制了与故障节点出口相关的IP地址的速率。如果你无法访问on-prem应用程序，尝试将nginx代理服务移动到一个新的节点上（使用节点亲和力来锁定一个 "好 "节点--"好 "节点）。https:/docs.microsoft.comen-usazureaksoperator-best-practices-advanced-scheduler#control-pod-scheduling-using-node-selectors-and-affinity。).
流量很可能会重新开始流动，这将验证这个理论，同时你要排除你的on-prem应用那边的阻塞。