使用Nginx反向代理的Azure容器应用程序返回连接失败

r1zk6ea1  于 2023-11-17  发布在  Nginx
关注(0)|答案(1)|浏览(182)

我在一个服务前面配置了一个Nginx反向代理。它们都是Docker镜像,我将它们作为Azure容器应用上传。
我有以下配置的反向代理:

location /api/my-service/ {
    access_log /var/log/nginx/my-service_api.log main;
    proxy_http_version 1.1;
    proxy_set_header "Connection" "";
    proxy_pass http://my-service/;    
}

字符串
如果我从Nginx容器控制台内部运行curl -ik -X GET 'https://localhost/api/my-service/some-endpoint',我会从我的代理服务获得预期的响应。如果我在容器内部使用Contaier App的公共URL(而不是localhost),我会获得相同的预期结果。问题是,如果我试图从我的计算机执行请求,我会得到一个503错误,响应为upstream connect error or disconnect/reset before headers. retried and the latest reset reason: connection failure, transport failure reason: delayed connect error: 111
我之前在Nginx容器内部执行请求时也遇到了同样的错误,但是在我为我的服务添加proxy_http_version 1.1;到Nginx location配置后,它得到了修复。这让我觉得我的外部请求和Nginx容器应用程序之间的某些东西可能会对HTTP版本做一些事情,但我没有找到任何配置或日志来确认这一点。
既然反向代理是在容器内部工作的,那么我是否可以假设问题与容器应用程序的配置有关?问题可能是什么?

额外信息

Ingress已启用,可以接受来自任何地方的流量,入口类型为HTTP,传输类型为auto。我使用的是来自Cloudflare的证书,用于保护Cloudflare和容器应用程序之间的流量。在某个时候,我认为Cloudflare可能在拒绝请求时做了一些事情,但如果我直接访问容器应用程序URL(跳过Cloudflare),我仍然会得到同样的错误。

x759pob2

x759pob21#

我终于解决了这个问题,所以我将在这里留下我的解决方案,以防其他人也发生类似的事情。
我的容器应用程序被配置为不接受不安全的连接,所以在我的Nginx配置中,我只监听443端口:

server {
    ...
    listen 443 ssl;
    ...
}

字符串
出于某种原因,添加listen 80;修复了错误,现在反向代理在容器应用程序中工作。
我在内部使用http连接到我的代理服务(而不是https),所以也许这是需要考虑的。

相关问题