【Nginx系列】关于一次请求超时的思考
【摘要】 一.基础信息 1.问题背景在服务器部署了一个接口,这个接口处理时间较长,超过了 1 分钟,使用如下 curl 请求接口curl -X GET "https://cloud-test/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"稳定在 60s 时返回 504 超时错误 2.nginx 配置use...
一.基础信息
1.问题背景
在服务器部署了一个接口,这个接口处理时间较长,超过了 1 分钟,使用如下 curl 请求接口
curl -X GET "https://cloud-test/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
稳定在 60s 时返回 504 超时错误
2.nginx 配置
user root;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
location /imchat {
proxy_pass http://0.0.0.0:8127$1;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;
}
3.请求链路
我理解的链路
- 客户端 curl 请求 nginx
- nginx 请求代理服务器
- 代理服务器内部处理逻辑
二.逐步排查
1.原因分析
- nginx 超时
- 内部服务器超时
- curl 客户端超时
2.nginx 超时
user root;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
proxy_connect_timeout 300s; #单位秒
proxy_send_timeout 300s; #单位秒
proxy_read_timeout 300s; #单位秒
keepalive_timeout 180s; # 设置为180s
client_header_timeout 180s; # 设置为180s
client_body_timeout 180s; # 设置为180s
send_timeout 180s; #设置为180s
}
nginx 如图所示,配置后还是在在 60s 返回 504,并且查看 nginx 的日志返回 499,关于 nginx 499 单独作为一个章节说明,从这里可以说明超时不是 nginx 的问题
3.另一种排除 nginx 的方法
将 nginx 的超时设置为 10s,同样的方法测试 curl,会看到返回 504 的时候加了 nginx 的字样,说明超时是因为 nginx
user root;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
proxy_connect_timeout 10s; #单位秒
proxy_send_timeout 10s; #单位秒
proxy_read_timeout 10s; #单位秒
keepalive_timeout 10s; # 单位秒
client_header_timeout 10s; # 单位秒
client_body_timeout 10s; # 单位秒
send_timeout 10s; #单位秒
}
4.服务内部超时
不经过 nginx 代理,直接请求服务接口,使用 curl 测试,发现接口超过 2 分钟,还是能返回的,说明接口测没有超时的限制
curl -X GET "http:/127.0.0.1:8888/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
5.curl 超时
curl 超时也是一种猜测,也是一种可能,怎么验证这个说法的错误呢
其实就是使用 curl 直接访问服务接口的时候就已经验证,使用 curl 是没什么问题的,不需要再加什么额外的超时参数
三.解决方案
1.精准定位
排除了以上的可能,发现唯一的可能只能是出在这个域名上,那么如何定位验证是域名的问题呢?
2.自我摸索
通过自我摸索和 gpt 的帮助,发现了 curl -v 的功能
curl -v -X GET "https://cloud-test/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
3.curl -v 分析
-v 是详细打印请求的细节,可以知道请求的整个过程,包括客户端和服务端,非常方便
从图中的截图可以看到,我自己的域名,server 是 nginx
curl -X GET "https://cloud-test/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>
而超时问题的域名,server 是 elb
curl -v -X GET "https://cloud-test/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
curl -v -X GET "https://www.zhanmeng.net/imchat/userInfo/login?password=qyj123&userName=qyj123" -H "accept: */*"
看到这里,大家肯定已经知道了答案,就是大名鼎鼎的老色比(LSB 和 ELB)负载均衡,通过去修改了 ELB 的超时限制,解决了这个超时的问题
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）