课件及代码下载链接：

老师您好昨天这个问题我没有表述清楚： 之前的upstream并未使用zone模块，为什么也能正常运行呢？比如权重为2的话，会记录下已经访问了1次或者2次？ 我想问您的是，您是不是在您的nginx中只开启了一个work进程？不然的话，您若不使用zone模块，访问次数无法记录在共享内存，多个work无法判断上次访的客户端访问是分配到了哪个上游服务

老师，您好，upstream的名称为什么不区分大小写。如果配置了upstream backend 还有一个是upstream Backend。语法检查会报duplicated upstream

老师有个问题 location /api { proxy_next_upstream http_504 error timeout; proxy_pass http://api; } upstream api { server 1.1.1.1 max_fails=2 fail_timeout=30s; server 1.1.1.2 max_fails=2 fail_timeout=30s; } 这种如果访问 http://domain/api/xxx 这个一直有问题的话504会导致 api这个loacation有问题然后 http://domain/api/yyy http://domain:api/zzz 这些都访问不了 请问有什么第三方模块可以解决或者有其他处理方式吗

老师咨询一个问题 系统压测过程 nginx有错误显示110connected upstream timeout 和no live upstreams while connecting to upstream 后端tomcat没有错误 ，老师能提供一个分析思路吗

老师，您好： 我用upstream模块进行https反向代理实验，配置两个不一样的IP以及不同服务，发现upstream其中一个无法正常访问。 172.25.128.50:443 输入后换跳转至https://172.25.128.50/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f172.25.128.50%2fowa%2f 该URL是exchange邮箱的服务界面 172.25.128.52:443 输入后换跳转至https://172.25.128.52/，该URL是nginx的安装后默认展示界面 ------------------------------ 现象：反向代理跳转172.25.128.52:443的时候会出现以下报错，而跳转exchange时候则正常。 nginx error! The page you are looking for is not found. Website Administrator Something has triggered missing webpage on your website. This is the default 404 error page for nginx that is distributed with Fedora. It is located /usr/share/nginx/html/404.html You should customize this error page for your own site or edit the error_page directive in the nginx configuration file /etc/nginx/nginx.conf. ------------------------------ 提问： [1] 是否必须要求两个IP提供服务要求一致？ [2] 是否有解决方案可以轮询跳转不同服务？ ------------------------------ 核心配置文件部分如下 ……省略…… upstream apps { server 172.25.128.50:443; server 172.25.128.52:443; } ……省略…… server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name _; ssl_certificate "/etc/ssl/private/nginx_private.crt"; ssl_certificate_key "/etc/ssl/certs/nginx_public.key"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; include /etc/nginx/default.d/*.conf; location / { proxy_pass https://apps; proxy_redirect default; } } ……省略……

接上一条留言，我困惑的是 nginx upstream 时间相关的这几个参数 我在实际(内网)环境中遇到过，就是 nginx request_time 时间长，upstream_response_time 时间长，upstream_header_time 时间不长，upstream_header_time 时间长，不过上游服务器(tomcat)处理完记录处理时间很短，处理结束打日志的时间和nginx 记录处理日志的时间接近 我的nginx日志格式: '$remote_addr - $remote_user [$time_iso8601] ' ' "$request" $status $body_bytes_sent $bytes_sent ' ' $request_trace_id ' ' ["$upstream_addr" "$upstream_status" "$upstream_bytes_received" "$upstream_response_length" "$upstream_cache_status" ' ' "$upstream_response_time" "$upstream_connect_time" "$upstream_header_time"] ' ' "$request_time" "$http_referer" "$http_user_agent" "$http_x_forwarded_for" "$ssl_protocol"'; request_trace_id 变量的自定义: #trace.setting set $request_trace_id $http_x_request_id; if ( $request_trace_id = '' ) { set $request_trace_id $pid-$connection-$bytes_sent-$msec; } 我的tomcat日志格式: "[%{Y-M-d H:m:s.S+z}t] real_ip:%{X-Real-IP}i remote:%h requestid:%{X-Request-ID}i first_line:"%r" status:%s bytes:%b cost:%Dms commit_time:%Fms Agent:"%{User-Agent}i" %{Connection}i %{Connection}o %{Keep-Alive}i %{Keep-Alive}o" nginx日志: 192.168.26.73 [2021-09-09T09:58:23+08:00] POST /cgp2-oauth/oauth/check_token HTTP/1.1 200 12983 13364 6462-1025729-0-1631152697.976 [ 127.0.0.1:8801 200 12991 - 5.026 0.000 5.026 ] 5.026 2021-09-09 09:58:17.976 对应tomcat日志(根据自定义的 $request_trace_id 匹配的): [2021-9-9 9:58:17.993+CST] real_ip:192.168.26.73 remote:127.0.0.1 requestid:6462-1025729-0-1631152697.976 first_line:" POST /cgp2-oauth/oauth/check_token HTTP/1.1" status:200 bytes:12991 cost:17ms commit_time:16ms Agent:"Java/1.8.0_144" - - - - 也想听听老师的意见，我目前是换 SSD 替换 HDD 解决了问题，不过内部测试的压力并不大。比较困惑，谢谢！

陶辉老师好： 关于 nginx upstream 的这几个时间相关的变量，想确认一下具体哪一个对或者还是自己理解错了 参考之前nginx的blog发的一篇文章，以及nginx.org官网的 ngx_http_upstream_module 的文档 https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables 官网说的是这样: $upstream_response_time keeps time spent on receiving the response from the upstream server; $upstream_header_time keeps time spent on receiving the response header from the upstream server (1.7.10); $upstream_connect_time keeps time spent on establishing a connection with the upstream server (1.9.1); nginx blog 有篇文档说的是这样： $request_time Full request time, starting when NGINX reads the first byte from the client and ending when NGINX sends the last byte of the response body $upstream_connect_time Time spent establishing a connection with an upstream server $upstream_header_time Time between establishing a connection to an upstream server and receiving the first byte of the response header $upstream_response_time Time between establishing a connection to an upstream server and receiving the last byte of the response body 官方的这个文档解释让我误解，之前学习过老师这部分的视频，后来结合我自己遇到的问题加上看了一些网上的文章， 我理解 $upstream_response_time 是nginx与上游整个处理的流程耗时时长(从nginx向upstream server发连接开始到nginx 收到上游响应报文的最后一个字节的数据) 它是包括 $upstream_header_time 和 $upstream_connect_time 的 我主要迷惑的是 $upstream_header_time， 它有包含 $upstream_connect_time 的连接时长，我理解的是这个时间是 nginx 与 upstream server 连接开始到 upstream server 处理，然后到返回，nginx 收到 upstream server 的http 内容的第一个字节截至， 之间的时间(我理解就是这个变量不包含nginx读取upstream server的完整的 响应报文的http header 数据) 由于篇幅问题，我另一个留言附上我的实际日志。

老师您好: 我这里遇到一个问题nginx 版本1.12.2 并使用了upstream_check模块用来作主动热检测，偶尔有接口返回502，而ngx日志中出现no live upstreams 请问老师这问题怎么查？

Nginx出现no live upstream但是后端服务正常的情况基本是nginx的failmaxs 和failtimeout默认配置造成的，默认失败一次，就禁用failtimeout的时间，默认是10秒，当多个服务都出现超时时就502了，简单的话把failmax设置为0即可

NGINX内置变量很丰富