![来自 AWS ALB 的持久 502](https://linux22.com/image/749271/%E6%9D%A5%E8%87%AA%20AWS%20ALB%20%E7%9A%84%E6%8C%81%E4%B9%85%20502.png)
这是我们的架构:Cloudflare -> ALB 1 -> Nginx API 网关 -> ALB 2 -> (Nginx Sidecar -> 应用程序)
应用程序和 sidecar 位于同一个盒子上并通过 unix 域套接字进行通信。
我们看到来自 ALB 2 的 HTTP 502 错误流稳定但数量不多。据我们所知,这些请求没有到达应用程序。通过分析数据包捕获数据,我们的团队发现 Sidecar 正在向 ALB 2 返回连接重置响应,导致 ALB 出现 502 错误。
我们已经确保 sidecar nginx 配置上的 keepalive_timeout 大于 ALB 的空闲超时(90 秒)。
ALB 2 的监听规则是在 HTTPS 443 处监听并转发到目标组。
Nginx API 网关的相关配置:
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
more_clear_headers Server;
underscores_in_headers on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
large_client_header_buffers 4 512k;
client_max_body_size 50M;
keepalive_timeout 120s;
client_header_timeout 120s;
来自 sidecar 的相关配置:
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
underscores_in_headers on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
large_client_header_buffers 4 512k;
client_max_body_size 50M;
keepalive_timeout 650s;
client_header_timeout 650s;
keepalive_requests 10000;
lingering_timeout 650s;
upstream app {
server unix:/var/tmp/puma.sock fail_timeout=0;
}
server {
listen 8000;
location / {
proxy_pass http://app;
proxy_buffering off;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Request-Start "t=${msec}";
proxy_set_header Host $http_host;
}
}
该应用程序是在 Puma 上运行的 Rails 应用程序。相关的 Puma 配置:
bind("unix:///var/tmp/puma.sock?backlog=3")
我们对 502 的来源非常困惑。;(