nginx - 是什么导致 nginx 出现 'The underlying connection was closed'？

Question

我们有一个支付网关集成，可以将数据发布到第三方 URL。然后，用户完成他们的支付流程，当交易完成时，网关回传到我们服务器上的一个 URL。

该帖子失败，网关报告以下错误:

ERROR 13326: Couldn't speak to ServerResultURL [https://foo.com/bar].

Full Error Details: The underlying connection was closed: An unexpected error occurred on a send.

Response object is null

当我直接发布到 https://foo.com/bar 时，我收到了 200 的响应，正如我所期望的，所以我不确定这是哪里出了问题。

这是在运行 nginx 的 Ubuntu 机器上。

可能导致该问题的原因是什么？我如何才能找到有关该问题的更多详细信息以及解决该问题的方法？

编辑:

为简洁起见，上面的示例是在 /bar 的 URL 上，但实际情况是我已经进行了重写(见下文)。实际发布到的 URL 是 /themes/third_party/cartthrob/lib/extload.php/cardsave_server/result 所以我不确定下面的重写是否是导致问题的原因。

我仍然认为不会，因为我在通过 POSTMAN 发帖时确实收到了 200 响应。

# http://expressionengine.stackexchange.com/questions/19296/404-when-sagepay-attempts-to-contact-cartthrob-notification-url-in-nginx
location /themes/third_party/cartthrob/lib/extload.php { 
    rewrite ^(.*) /themes/third_party/cartthrob/lib/extload.php?$1 last;
}

Answer 1

此类错误的典型原因

我敢打赌，您的服务器正在使用网关(PaymentSense，对吗？)不期望的内容来响应发送到/bar 的 POST。这可能是因为:

1. 网关无法通过网络到达您的 Ubuntu 机器，因为两者之间的防火墙或网络硬件阻止了它。
2. 您的 https 证书错误/过期/自签名，网关拒绝连接。
3. NGINX 或您的 Web 应用程序软件(我想是 PHP？或任何 nginx 正在提供服务)的错误配置导致/bar 响应一些奇怪的响应，例如 30x 或 50x 错误页面，或者可能只是错误的响应，例如 HTML 页面。
4. 对 POST 的响应还有其他问题。
5. 在/bar 上运行的脚本/ Controller 可能会在 POST 请求中收到意外输入，因此您可能需要查看传入的请求。
6. 您遇到网络连接问题。

我会将前两项留给您进行故障排除，因为我认为这不是您在这个问题中要问的。

NGINX 响应故障排除

我建议使用 body_filter_by_lua 将其配置为将其响应转储到 nginx 变量中，这样您就可以看到输出的响应。 here 提供了一个很好的设置示例.我认为这会让您理解为什么/bar 不正常。

NGINX 请求故障排除

如果这不能揭示问题的原因，请尝试记录请求数据。你可以用类似的东西来做到这一点:

location = /bar {
  log_format postdata $request_body;
  access_log  /var/log/nginx/postdata.log  postdata;
  fastcgi_pass php_cgi;
}

查看此 POST 的请求 header 和正文，如果错误没有立即显现，请尝试重播完全相同的请求(使用可让您完全控制的 HTTP 客户端，例如 curl) 并调试/bar 发生的情况。当您对/bar 进行相同的 POST 时，nginx 是否正在运行您认为它应该运行的脚本/ Controller ？将日志记录添加到/bar 脚本/ Controller 进程。

必要时使用交互式调试。 (如果您使用 PHP，这可能需要远程 Xdebug，但无论您在服务器上使用什么，大多数 Web 应用程序工具都提供某种形式的交互式调试。)

网络故障排除

如果这些都不起作用，则可能是网关无法访问您运行它的主机和端口，或者您有其他类型的网络连接问题。我会在你的 Ubuntu 机器上运行 tcpdump 来捕获网络流量。如果您可以在安静的(网络)系统上重新创建它，那将对您有利。尽管如此，它仍然是 TLS (https)，​​所以除了连接打开和数据包到达之外，别指望看到太多。如果您发现需要查看 TLS 流量内部以便进行故障排除，您可以考虑使用 mitmproxy 来执行此操作。