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

Question

我在服务前面配置了 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'

，我会从代理服务获得预期的响应。如果我在容器内使用容器应用程序的公共 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

版本做一些事情，但我还没有找到任何配置或日志来确认这一点。

既然反向代理在容器内部起作用，我是否可以假设问题与容器应用程序配置有关？可能是什么问题？

额外信息

入口已启用，可以接受来自任何地方的流量、入口类型

HTTP

和传输

auto

。 我使用的是 Cloudflare 的证书，用于保护 Cloudflare 和容器应用程序之间的流量。有一次，我认为 Cloudflare 在代理请求时可能正在执行某些操作，但如果我直接访问容器应用程序 URL（跳过 Cloudflare），我仍然会遇到相同的错误。

Answer 1

我终于解决了这个问题，所以我将把我的解决方案留在这里，以防其他人遇到类似的情况。

我的容器应用程序已配置为不接受不安全的连接，因此在我的 Nginx 配置中，我只监听

443

端口：

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

由于某种原因，添加

listen 80;

修复了错误，现在反向代理正在容器应用程序中工作。

我在内部使用

http

连接到我的代理服务（而不是

https

），所以也许这是需要考虑的事情。