webserver nginx / https / upstream / nginx.conf

s

/usr/local/nginc/conf/nginx.conf 

user  nobody;
worker_processes  auto;
worker_cpu_affinity     auto;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    use epoll;
    accept_mutex             off;  
    multi_accept             on;
    worker_connections  10240;
}


http {
   # resolver 10.19.251.34 valid=30s;
   # resolver_timeout 5s;

    include       mime.types;
    default_type  application/octet-stream;

#    log_format  main  '$remote_addr ,- , $remote_user [$time_local] ,"$request" ,'
#                      '$status $body_bytes_sent ,"$http_referer" ,'
#                      '"$http_user_agent" ,"$http_x_forwarded_for"';
#    log_format  main  '$remote_addr\t$http_x_forwarded_for\t$remote_user\t$time_iso8601\t$request_method\t"$document_uri"\t"$query_string"\t$server_protocol\t$status\t$body_bytes_sent\t$request_time\t"$http_referer"\t"$http_user_agent"\t$http_Cdn-Src-Ip\t$host\t$hostname\t$server_addr\t+\tV4';
#     log_format  main  '$remote_addr\t$http_x_forwarded_for\t-\t$remote_user\t$time_iso8601\t$request_method\t"$document_uri"\t"$query_string"\t$server_protocol\t$status\t$body_bytes_sent\t$request_time\t"$http_referer"\t"$http_user_agent"\t$http_Cdn-Src-Ip\t$host\t$hostname\t$server_addr\t-\t-\t-\t-\t-\tV5';
     log_format  main '$remote_addr\t$http_x_forwarded_for\t-\t$remote_user\t'
                     '$time_iso8601\t$request_method\t"$document_uri"\t'
                     '"$query_string"\t$server_protocol\t$status\t$body_bytes_sent\t'
                     '$request_time\t"$http_referer"\t"$http_user_agent"\t'
                     'traceId:$http_sntraceid,spanId:$http_snspanid\t$host\t$hostname\t$server_addr\t'
                     '$remote_port\t$server_port\t'
                     '"$upstream_addr"\t"$upstream_status"\t"$upstream_response_time"\tV5';

    access_log  logs/access.log  main;
    server_tokens       off;
    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  15;
    concat on;

    #gzip  on;
    gzip  on;
    gzip_vary on;
    gzip_min_length  1k;
    gzip_buffers     4  8k;
    gzip_comp_level 1;
    gzip_types       text/plain application/x-javascript text/css text/htm application/xml application/javascript text/javascript;
    gzip_http_version 1.1;
    proxy_buffering off;

    upstream list1 {
         server 10.237.0.90:8080;
     #check interval=3000 rise=1 fall=5 timeout=1000 type=tcp;
         sticky;
     }


    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        access_log  /opt/rsync_log/access_http.log  main;

        location / {
            #root   html;
            #index  index.html index.htm;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://list1;
        }
    
    location /NginxStatus {
          stub_status on; 
          allow 127.0.0.1;
          allow 192.168.138.0/24;
          allow 192.168.241.0/24;
          allow 192.168.242.0/24;
          allow 192.168.119.0/24;
          allow 192.168.207.0/24;
          allow 192.168.90.0/24;
          allow 192.168.224.34;
          deny all;
    }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
#    server {
#        listen       443;
#        server_name  localhost;
#        access_log  /opt/rsync_log/access_https.log  main;
#        server_tokens off;

#        ssl                  on;
#        ssl_certificate      cns*****.pem;
#        ssl_certificate_key  cns*****.key;

#        ssl_session_timeout  5m;

#        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
#        ssl_prefer_server_ciphers   on;

#        location / {
#            root   html;
#            index  index.html index.htm;
#        }
#    }

}

#TCP/UDP proxy
#
#stream {
#    log_format proxy '$remote_addr\t$remote_port\t$realip_remote_addr\t$realip_remote_port\t'
#                     '"$proxy_protocol_addr"\t"$proxy_protocol_port"\t$time_iso8601\t'
#                     '$server_addr\t$server_port\t$protocol\t$status\t$bytes_sent\t$bytes_received\t'
#                     '$session_time\t$hostname\t$pid\t'
#                     '"$upstream_addr"\t"$upstream_bytes_sent"\t"$upstream_bytes_received"\t'
#                     '"$upstream_connect_time"\t"$upstream_first_byte_time"\t"$upstream_session_time"';
#
#    proxy_next_upstream on;
#    proxy_next_upstream_tries 4;
#
#    upstream list1 {
#        server 192.168.0.1:12345;
#        server 192.168.0.2:12345;
#        server 192.168.0.3:12345;
#        server 192.168.0.4:12345;
#        server 192.168.0.5:12345;
#    }
#
#    server {
#        access_log logs/access_stream.log proxy buffer=1k flush=1s;
#
#        listen 12345;
#        proxy_pass list1;
#    }
#}

 

nginx server_name 配置

https://segmentfault.com/q/1010000008426747?_ea=1647456

问题：我的host还没有域名,server_name应该填什么.  

解决：填写IP地址即可。

 

问题1，测试要访问https://192.168.1.100/action.do

解决1：访问带有IP访问https，则需要修改nginx.conf  

server {
listen 80;
server_name 192.168.1.100;
、、、

 

问题2：

nginx集群报错“upstream”directive is not allow here 错误

https://www.iyunv.com/thread-406-1-1.html

原因2：nginx upstream配置内容，位置摆放错误。

解决2：

nginx集群报错“upstream”directive is not allow here 错误
搭建了一个服务器, 采用的是nginx + apache(多个) + php + mysql(两个) 多个apache负载均衡及后端mysql读写分离的服务器. 
当设定好 upstream 如下:
upstream backend { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3;}
执行命令:/usr/local/nginx/sbin/nginx -s reload 时 报错如下:
[emerg]: "upstream" directive is not allowed here in /usr/local/nginx/conf/nginx.conf:52
后来检查了一下原来是upstream backend 位置放错了, upstream位置应该放在http模块里面 但必须是在server模块的外面. 应该是下面这样的结构:
http{upstream backend { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3;} server { location / { proxy_pass http://backend; }}}
如果你配置的服务器也如类似的错误 不妨检查你的upstream位置是否正

 

问题3：centos7 ./configure --prefix error checking for C compiler

解决3：

[root@d916e56d345b nginx-1.19.2]# ls
CHANGES CHANGES.ru LICENSE README auto conf configure contrib html man src
[root@d916e56d345b nginx-1.19.2]# ./configure
checking for OS
+ Linux 3.10.0-957.27.2.el7.x86_64 x86_64
checking for C compiler ... not found

./configure: error: C compiler cc is not found

[root@d916e56d345b nginx-1.19.2]# yum -y install gcc gcc-c++ autoconf automake make

 

问题4：[root@d916e56d345b nginx-1.19.2]# /opt/nginx-1.19.2/configure 

checking for PCRE library ... not found
checking for PCRE library in /usr/local/ ... not found
checking for PCRE library in /usr/include/pcre/ ... not found
checking for PCRE library in /usr/pkg/ ... not found
checking for PCRE library in /opt/local/ ... not found

./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.

解决4：

 

 

nginx 短链接高并发掉坑现象分析

nginx upstream里面配置keepalive 数目，并且在server域配置
proxy_http_version 1.1;
proxy_set_header Connection "";

掉坑原因有可能是并发高，并使用了短连接，在socket的创建和释放影响了

 1 upstream xxx.cns*****.com|80{
 2     server ip:80 max_fails=2 fail_timeout=10s;
 3 }
 4 
 5 server {
 6  proxy_set_header Proxy-Connection ""; 
 7  proxy_set_header Host $host;
 8  proxy_http_version 1.1;
 9  proxy_connect_timeout 5;
10  proxy_send_timeout 30;
11  proxy_read_timeout 30;
12  proxy_buffer_size 128k;
13  proxy_buffers 64 64k;
14  root html
15  index index.html index.htm;
16  default_type text/html;
17 
18  gzip off;
19 }

 

Nginx HTTP负载均衡/反向代理的相关参数测试 

https://www.cnblogs.com/xiaochaohuashengmi/archive/2011/03/15/1984976.html 

测试目的

（1）弄清楚HTTP Upstream 模块中Server指令的max_fails与fail_timeout参 数的关系、它们对后端服务器健康情况的检查起到了什么作用、它们的取值对Http proxy模块中的其它指令是否有直接或间接的影响等……

（2）测试HTTP Proxy模块中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、 proxy_send_timeout指令的作用、对nginx性能的影响、对后端服务器响应的处理等……

测试方法

本文测试不会使用压力测试，所有的测试都是通过浏览器手动刷新来实现的。后端服务器使用简单的php程序来实现。

测试环境

Nginx负载均衡/反向代理服务器
系统：CentOS 5.4 64bit
Nginx：0.7.65
IP:192.168.108.10

后端web服务器
系统：CentOS 5.4 64bit
Web环境：apache+php
Web-1 IP:192.168.108.163
Web-2 IP:192.168.108.164

webserver nginx / https / upstream / nginx.conf

本次测试主要针对HTTP Upstream和HTTP Proxy模块进行，下面测试环境中http upstream 和http proxy模块参数的初始化设置，后文会针对测试的参数进行相应的修改：

…
upstream test  {
server 192.168.108.163 ;
server 192.168.108.164:80;
}

server {
listen          80;
server_name     .test.com;
index           index.php index.html index.htm;

location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;

proxy_connect_timeout       10s;
proxy_read_timeout          2s;
#proxy_send_timeout          10s;
proxy_pass http://test;
}
}
…

提出server指令后面的参数部分，以下摘抄nginx wiki 内容

语法：server name [parameters]

parameters包 含：

·weight = NUMBER - 设置服务器权重，默认为1。

·max_fails = NUMBER - 在一定时间内（这个时间在fail_timeout参数中设置）检查这个服务器是否可用时产生的最多失败请求数，默认为1，将其设置为0可以关闭检查，这 些错误在proxy_next_upstream或fastcgi_next_upstream（404错误不会使max_fails增加）中定义。

·fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用，同样它指定了服务器不可用的时间（在下一次尝试连接请求发起 之前），默认为10秒，fail_timeout与前端响应时间没有直接关系，不过可以使用proxy_connect_timeout和 proxy_read_timeout来控制。

·down - 标记服务器处于离线状态，通常和ip_hash一起使用。

·backup - (0.6.7或更高)只用于本服务器，如果所有的非备份服务器都宕机或繁忙。

关于max_fails 参数的理解：根 据上面的解释，max_fails默认为1，fail_timeout默 认为10秒，也就是说，默认情况下后端服务器在10秒钟之内可以容许有一次的失 败，如果超过1次则视为该服务器有问题，将该服务器标记为不可用。等待10秒后再 将请求发给该服务器，以此类推进行后端服务器的健康检查。但如果我将max_fails设置为0， 则代表不对后端服务器进行健康检查，这样一来fail_timeout参数也就没什么意义了。那若后端服务器真的出现 问题怎么办呢？上文也说了，可以借助proxy_connect_timeout和proxy_read_timeout进 行控制。

下面介绍http proxy模块中的相关指令：

proxy_next_upstream
语法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
确定在何种情况下请求将转发到下一个服务器。转发请求只发生在没有数据传递到客户端的过程中。

proxy_connect_timeout
后端服务器连接的超时时间_发起握手等候响应超时时间

proxy_read_timeout
连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）

proxy_send_timeout
后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

proxy_pass
这个指令设置被代理服务器的地址和被映射的URI

开始测试

情况1：后端程序执行时间超过或等于proxy_read_timeout设 置值，max_fails=0 关闭后端服务器健康检查。

Nginx配置修改内容 server 192.168.108.163 max_fails = 0;
server 192.168.108.164 max_fails = 0;
proxy_next_upstream error timeout
proxy_read_timeout 2s
 
后端web服务器
Web1 test.php Web2 test.php
<?php
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-1<br>";
?>		 <?php
header('RS:Web2');
$t = 5;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-2<br>";
?>
备注：

我这里的两台后端web服务器，他们的主页文件均为一个test.php程序，该程序分别sleep了2秒和5秒，等于和超过了 proxy_read_timeout的时间，[max_fails=0] 即关闭后端服务器健康检查。[proxy_next_upstream error timeout] 说明碰到错误或超时的情况切到下一个后端服务器。如此设置后利用curl命令对nginx发起连接请求，看nginx会作何反应。
测试开始：

（1）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 02:43:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

4.008:0.002:4.007

说明：

连续请求3次后得到的http返回结果是一样的，均为504 Gateway Time-out 错误。这种情况只有在后端服务器都有问题的时才会出现这个错误，很显然我这里的proxy_read_timeout设置的时间太短，后端程序还没来得及 把程序执行完，nginx就迫不及待的将请求甩给upstream定义的另一台服务器上了，当发现另外一台服务器同样2秒没有返回后，nginx这回没有 服务器可用，只有返回504 Gateway Time-out 。这也是为什么最后的time_total时间是4秒。（经查看两台web服务器的访问日志得知，均有一条访问记录，且返回代码为200，说明nginx 确实来过，但没有等到执行完成就匆匆的离去了）如果我有3台服务器，在保证任何不变的情况下，time_total时间一定会是6秒，因为nginx会一 个接一个的将3台服务器都走一遍。

-----------------------------------------------------------------------------------------------------------------------

好了，确认是我proxy_read_timeout设置时间太短后，我将它的值设置为3秒，再通过curl命令访问：

（2）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:07:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

5.042:0.005:5.042

说明：通过3次连续请求，得到的结果是一样的，RS:Web1 也就是说我这三次的请求都甩到了web1上。但我web1中的程序只需要2秒后就可以返回结果，但为什么我通过nginx代理后时间总是我的 程序执行时间+proxy_read_timeout时间呢？

-----------------------------------------------------------------------------------------------------------------------

继续将proxy_read_timeout设置为4s

（3）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:15:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

6.004:0.000:6.004

三次请求后结果也是一样，这次花的时间更长了，但确实是程序执行时 间+proxy_read_timeout 时间。但为什么每次都需要6秒呢？按照upstream中定义的权重应该是平分请求的，最起码 应该有2秒的时候。经过分析得知：最终返回给用户请求的是web1，那么当再次请求的时候一定会分给web2，由于web2是sleep 5秒的，因此经过proxy_read_timeout的时间（4s）后会跳到web1，结果还是web1返回的请求，所花时间就是nginx在web2 等待的时间+web1执行的时间，以此类推下一次nginx自然的还会分给web2……。如果有更多的后端web，则判断下一个请求服务器可以看当前返回 给最终用户的是那台服务器，然后根据upstream中定义的顺序向下查询（权重一样的情况）
结论：

（1）上面的三次测试分别将proxy_read_timeout的值设置为2s、3s、4s的情况进行的。最终的测试结果也都在后面做了解释与说 明。由于我关闭了后端服务器的健康检查（max_fails=0）因此判断后端服务器情况的唯一依据便是proxy_read_timeout参数，如果 这个参数设置得过小，但后端程序的执行或多或少会超过这个时间的话，这种情况nginx的效率是非常低的。

（2）上面的测试都是后端服务器正常但执行超时的情况下nginx根据proxy_read_timeout和 proxy_next_upstream的值来选择下一个服务器，那如果我后端服务器直接报错的情况呢？可以想到如果报错信息在 proxy_next_upstream 中有定义的话nginx还会跳到下一台服务器。否则直接将保存信息返回给nginx从而最终呈献给用户

情况2：打开后端服务器健康检查，测试程序执行时间超过或等于proxy_read_timeout值或后端服务器直接报错的情况

 

Nginx配置修改内容 server 192.168.108.163 max_fails = 1;
server 192.168.108.164 max_fails = 1;
proxy_next_upstream error timeout http_500 http_502 http_504
proxy_read_timeout 2s
 
后端web服务器
Web1 test.php Web2 test.php
<?php
header('RS:Web1');
$t = 2;
sleep($t);
echo "sleep {$t}s<br>";
echo "web-1<br>";
?>		 <?php
header('RS:Web2');
header('http/1.1 500 Internal Server Error ');
#$t = 5;
#sleep($t);
echo "sleep {$t}s<br>";
echo "web-2<br>";
?>
备注：

开启了后端服务器健康检查
proxy_read_timeout 2s （下面会随着测试变更）
Web1程序仍然sleep 2s
修改了Web2程序，让他直接返回500错误
测试开始：

（1）连续测试三次结果如下：

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:48 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 502 Bad Gateway
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:50 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 173
Connection: keep-alive

0.001:0.001:0.001

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:57 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

说明：

第1次请求所用时间是2秒，web1执行超时，web2返回了500错误，upstream没有更多的后端，因此nginx直接把504扔出来了， 同时标记web2，web1不可用。查看后端2台web服务器的访问日志，均有nginx代理的访问记录。
第2次请求时间很短，报502错误，说明没有可用的后端服务器接受请求。查看后端两台web服务器访问日志，没有任何变化，说明这两台服务器被nginx 标记为不可用，没有把请求转向后端，直接返回用户502错误
第3次请求同第1次

（2）修改 proxy_read_timeout 3s 连续访问6次后结果以及2台web服务器的日志情况
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:30:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

2.003:0.001:2.002

访问日志

Web1
[18/May/2010:15:30:00
[18/May/2010:15:30:03
[18/May/2010:15:30:05
[18/May/2010:15:30:08
[18/May/2010:15:30:11
[18/May/2010:15:30:13

Web2

[18/May/2010:15:30:00
[18/May/2010:15:30:11

说明：

由访问日志可知：
第1次请求是被分到web2上的，由于它返回了500错误，因此请求被转到web1，并标记web2不可用。
第2次至第4次均将请求给了web1，第四次请求完毕后距第一请求已经过去了8秒。
第5次请求时已经是fail_timeout参数默认的10s也就是标记web2不可用的时间已经过去了，因此在第5 次访问实际上和第一次情况是一样的。
结论：

（1）proxy_next_upstream参数很有用，他可以避免很多 错误
（2）max_fails 参数在繁忙的大型系统中建议设置为3，如果没有几个后端服务器的话保持默认即可。
（3）proxy_read_timeout要根据自身程序而定，不要过大，也不 要太小。如果是php程序，请参照php.ini中的max_execution_time选项值。

 

end

相关文章：

  • 2021-11-18
  • 2022-02-05
  • 2021-11-10
  • 2021-11-20
  • 2022-12-23
  • 2022-12-23
  • 2021-07-29
猜你喜欢
  • 2022-12-23
  • 2022-12-23
  • 2021-07-28
  • 2022-12-23
  • 2022-12-23
  • 2021-05-28
  • 2022-01-22
相关资源
相似解决方案
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode