通过 EC2 负载均衡器的请求挂起答案

【问题标题】：Requests going through EC2 load balancer hangs通过 EC2 负载均衡器的请求挂起
【发布时间】：2014-04-30 12:10:02
【问题描述】：

我已经使用 Tinyproxy 在 EC2 实例上设置了一个简单的代理（默认配置监听/允许所有传入连接）。这很好用。如果我为了调试，在浏览器中填写 IP 地址和代理设置的端口，我可以毫无问题地浏览代理。一切正常。但是，如果我在实例前面创建一个 EC2 负载均衡器（确保正确转发 http 端口），它只会在我浏览负载均衡器 IP 时挂起。这对我来说似乎是一个谜。该实例正在运行，负载均衡器报告“服务中”，并且绕过负载均衡器工作，但通过它只是挂起。我错过了什么，我应该在哪里查找错误？

更新

我现在查看了 Tinyproxy 的日志：尝试通过实例代理直接访问 google.com 时，我看到如下日志：

CONNECT   Apr 30 20:41:33 [1862]: Request (file descriptor 6): GET http://google.com/ HTTP/1.1
INFO      Apr 30 20:41:33 [1862]: No upstream proxy for google.com
CONNECT   Apr 30 20:41:33 [1862]: Established connection to host "google.com" using file descriptor 7.
INFO      Apr 30 20:41:33 [1862]: Closed connection between local client (fd:6) and remote client (fd:7)
CONNECT   Apr 30 20:41:33 [1901]: Connect (file descriptor 6): x1-6-84-1b-ADDJF-20-07-92.fsdfe [430.12327.65117.615]
CONNECT   Apr 30 20:41:33 [1901]: Request (file descriptor 6): GET http://www.google.ie/?gws_rd=cr&ei=_V9hU8DeFMTpPJjygIgC HTTP/1.1
INFO      Apr 30 20:41:33 [1901]: No upstream proxy for www.google.ie
CONNECT   Apr 30 20:41:33 [1901]: Established connection to host "www.google.ie" using file descriptor 7.

但是，如果我尝试通过负载均衡器访问 google，然后转发到实例，那么我会看到如下日志：

CONNECT   Apr 30 20:42:54 [1860]: Request (file descriptor 6): GET / HTTP/1.1
CONNECT   Apr 30 20:42:54 [1869]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [10.238.155.237]
CONNECT   Apr 30 20:42:54 [2037]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [10.238.155.237]
INFO      Apr 30 20:42:54 [1860]: process_request: trans Host GET http://google.com:8888/ for 6
INFO      Apr 30 20:42:54 [1860]: No upstream proxy for google.com
CONNECT   Apr 30 20:43:12 [1861]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [1230.23845.515.2537]
CONNECT   Apr 30 20:43:12 [2035]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [143.238.12345.117]
ERROR     Apr 30 20:43:12 [2035]: read_request_line: Client (file descriptor: 6) closed socket before read.
ERROR     Apr 30 20:43:12 [1861]: read_request_line: Client (file descriptor: 6) closed socket before read.
ERROR     Apr 30 20:43:12 [2035]: Error reading readble client_fd 6
ERROR     Apr 30 20:43:12 [1861]: Error reading readble client_fd 6
WARNING   Apr 30 20:43:12 [2035]: Could not retrieve request entity
WARNING   Apr 30 20:43:12 [1861]: Could not retrieve request entity

据我所知，ELB 正在尝试通过端口 8888 发送请求

【问题讨论】：

我对代理一无所知，但它有日志，它是否接收到请求？
问得好，我想是的，我看看再回来
我现在查看了来自微型代理的日志。它确实收到了请求。但是负载均衡器似乎将代理的列表/转发端口附加到 url/http 请求（请参阅问题更新）

标签： amazon-ec2 proxy load-balancing

【解决方案1】：

您可以获得ELB访问日志。这些访问日志可以帮助您确定不同时间间隔的请求所花费的时间。例如：

request_processing_time：从负载均衡器收到请求并将请求发送到注册实例的总时间（以秒为单位）。
backend_processing_time： 从负载均衡器向已注册实例发送请求到实例开始发送响应标头所经过的总时间（以秒为单位）。
response_processing_time：从负载均衡器接收到来自注册实例的响应标头并开始向客户端发送响应所经过的总时间（以秒为单位）。该处理时间包括负载均衡器的排队时间和从负载均衡器到后端的连接获取时间。

...以及更多信息。您需要先配置访问日志。请关注以下文章，以了解有关使用 ELB 访问日志的更多信息：

这些日志可能/可能无法解决您的问题，但肯定是一个很好的起点。此外，您可以随时咨询 AWS 技术支持以进行更深入的分析。

【讨论】：

【解决方案2】：

听起来您正在尝试在 HTTP 模式下使用 ELB，本质上，它类似于 forward 代理，或者至少是您在其后面运行的转发代理的网关。这不是 ELB 的预期应用程序，因此它在该配置中不起作用也就不足为奇了。

HTTP 侦听器模式下的 ELB 旨在用作 Web 端点/源服务器前的 reverse 代理。

将您的 ELB 侦听器配置为使用 TCP 模式而不是 HTTP 模式应该允许您的预期配置工作，但这有点超出 ELB 的最佳应用程序。

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html

【讨论】：

是的，我认为你是对的。我查看了代理的日志，请参阅问题更新中的以下信息。