来自 AWS 经典负载均衡器的虚假 504答案

【问题标题】：Spurious 504s from AWS classic load balancer来自 AWS 经典负载均衡器的虚假 504
【发布时间】：2018-08-13 09:41:30
【问题描述】：

我有一个在 AWS Elastic Beanstalk 上运行的 REST API，大部分时间都运行良好。但是，每隔几个小时，它就会通过在单个请求中返回 504 来打嗝。这是 AWS Elastic Load Balancer（经典）日志：

2018-03-04T21:07:00.151327Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.216:57324 - -1 -1 -1 504 0 2497 0 "POST https://my.api.com:443/v1/data/add HTTP/1.1" " -" ECDHE-RSA-AES128-SHA TLSv1

这是上下文中的日志：

2018-03-04T21:07:54.884768Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.216:57339 xxx.xxx.xxx.85:80 0.000041 0.134478 0.000084 200 200 2672 93 "POST @987654 HTTP/1.1" "-" ECDHE-RSA-AES128-SHA TLSv1 2018-03-04T21:07:55.935722Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.216:57342 xxx.xxx.xxx.85:80 0.000067 0.107369 0.000075 200 200 5538 93“HTTP/98765432.32 " "-" ECDHE-RSA-AES128-SHA TLSv1 2018-03-04T21:07:56.633812Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.226:33815 xxx.xxx.xxx.85:80 0.000041 0.149562 0.000079 200 200 332 93 "HTTP/11@98765432.4 " "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 2018-03-04T21:07:00.151327Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.216:57324 - -1 -1 -1 504 0 2497 0 "POST https://my.api.com:443/v1/data/add HTTP/1.1" "-" ECDHE -RSA-AES128-SHA TLSv1 2018-03-04T21:08:00.521384Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.226:45505 xxx.xxx.xxx.85:80 0.000037 0.172259 0.000072 200 200 334 93“HTTP/1.1.1.1” " "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 2018-03-04T21:08:02.896099Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.226:55647 xxx.xxx.xxx.112:80 0.000041 0.166058 0.000064 200 200 334 93 "HTTP/98765432.72 " "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 2018-03-04T21:08:08.914958Z awseb-ex-AWSEBLoa-abc123 xxx.xxx.xxx.226:10771 xxx.xxx.xxx.85:80 0.000046 0.173661 0.000091 200 200 341 93“HTTP/11@98765432@8 " "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ```

在实际 ec2 实例的日志中没有报告相关的健康损失。

重建底层 ec2 实例后，它似乎消失了几天。

【问题讨论】：

是Beanstalk应用通过ELB返回504，还是ELB本身返回（网关超时）。
@jarmod - 它是 ELB 本身。请求甚至没有到达 beanstalk 节点。
你有没有调查过docs.aws.amazon.com/elasticloadbalancing/latest/classic/…的任何建议
您的日志条目有些奇怪。对于成功的 HTTP 请求，时间通常会增加。对于失败的请求，时间是 2018-03-04T21:07:00.151327Z，比上一个条目 2018-03-04T21:07:56.633812Z 早了将近一分钟。在你的日志中及时返回，看看当时是否还有其他 504 错误。
@Michael-sqlbot。同意。如果同时出现其他错误，则表明运行状况检查失败。如果在那之前和之后都有成功，那么其他事情正在发生。我敢打赌，要么是健康检查太严格/设置不正确，要么是用户有一个小 T2 实例被限制。提问者的配置和设置数据不足。

标签： amazon-web-services amazon-elastic-beanstalk elastic-load-balancer

【解决方案1】：

罪魁祸首是我的 .ebextensions 目录中的错误代理配置，特别是 proxy_connect_timeout、proxy_send_timeout 和 proxy_read_timeout 的值过高：

files: "/etc/nginx/conf.d/proxy.conf" : mode: "000644" owner: root group: root content: | client_max_body_size 500m; proxy_buffers 8 16k; proxy_buffer_size 32k; proxy_connect_timeout 1800s; proxy_send_timeout 1800s; proxy_read_timeout 1800s; gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 4; gzip_static on; gzip_http_version 1.1; gzip_min_length 256; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;

我最初设置这些是为了允许大容量上传，但这是错误的。删除设置并重新部署就像一个魅力。

【讨论】：