我在一个服务前面配置了一个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),我仍然会得到同样的错误。
1条答案
按热度按时间x759pob21#
我终于解决了这个问题,所以我将在这里留下我的解决方案,以防其他人也发生类似的事情。
我的容器应用程序被配置为不接受不安全的连接,所以在我的Nginx配置中,我只监听
443
端口:字符串
出于某种原因,添加
listen 80;
修复了错误,现在反向代理在容器应用程序中工作。我在内部使用
http
连接到我的代理服务(而不是https
),所以也许这是需要考虑的。