webserver nginx / https / upstream
s
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位置是否正
nginx 短链接高并发掉坑现象分析
nginx upstream里面配置keepalive 数目,并且在server域配置
proxy_http_version 1.1;
proxy_set_header Connection "";
掉坑原因有可能是并发高,并使用了短连接,在socket的创建和释放影响了
upstream xxx.cns*****.com|{
server ip: max_fails= fail_timeout=10s;
} server {
proxy_set_header Proxy-Connection "";
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_connect_timeout ;
proxy_send_timeout ;
proxy_read_timeout ;
proxy_buffer_size 128k;
proxy_buffers 64k;
root html
index index.html index.htm;
default_type text/html; gzip off;
}
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
本次测试主要针对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 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 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 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>"; ?> |
|
备注:
开启了后端服务器健康检查 |
||
测试开始:
(1)连续测试三次结果如下: curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 0.001:0.001:0.001 curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 说明: 第1次请求所用时间是2秒,web1执行超时,web2返回了500错误,upstream没有更多的后端,因此nginx直接把504扔出来了, 同时标记web2,web1不可用。查看后端2台web服务器的访问日志,均有nginx代理的访问记录。 (2)修改 proxy_read_timeout 3s 连续访问6次后结果以及2台web服务器的日志情况 2.003:0.001:2.002 访问日志 Web1 Web2 [18/May/2010:15:30:00 说明: 由访问日志可知: |
||
结论:
(1)proxy_next_upstream参数很有用,他可以避免很多 错误 |
end
webserver nginx / https / upstream的更多相关文章
- linux:Nginx+https双向验证(数字安全证书)
本文由邓亚运提供 Nginx+https双向验证 说明: 要想实现nginx的https,nginx必须启用http_ssl模块:在编译时加上--with-http_ssl_module参数就ok.另 ...
- nginx的upstream目前支持5种方式的分配
Nginx nginx的upstream目前支持5种方式的分配 FROM: 转载 1 轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器, 如果后端服务器down掉, 能自动剔除. 2 w ...
- Nginx Errors: upstream response cache error
Nginx Errors upstream response cache error *2470578 an upstream response is buffered to a temporary ...
- Ubuntu下配置Nginx HTTPS
HTTPS(全称:Hypertext Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版.即HTTP下加入S ...
- centos7 + Nginx+ HTTPS + uwsgi + python3.6 + Docker + Django1.11 + mysql 5.6 + virtualenv 环境搭建
环境搭建: 系统: centos7.2 x64 开发环境: python3.6 Django 1.11 虚拟环境: [Docker](https://www.runoob.com/dock ...
- 17、Nginx HTTPS 实践
1.HTTPS安全证书基本概述 为什么需要使用HTTPS, 因为HTTP不安全.当我们使用http网站时,会遭到劫持和篡改,如果采用https协议,那么数据在传输过程中是加密的,所以黑客无法窃取或者篡 ...
- nginx的upstream目前支持5种方式的分配(转)
nginx的upstream目前支持5种方式的分配 1.轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除. 2.weight 指定轮询几率,weight ...
- 为苹果ATS和微信小程序搭建 Nginx + HTTPS 服务
昨天测试开发微信小程序,才发现微信也要求用HTTPS加密数据,想来是由于之前苹果的ATS审核政策的缘故吧,微信想在苹果上开放小程序必然也只能要求开发者必须使用HTTPS了,于是在服务器上测试安装Ngi ...
- 在阿里云 ECS 搭建 nginx https nodejs 环境(三、nodejs)
在阿里云 ECS 搭建 nginx https nodejs 环境(三.nodejs) 在阿里云 ECS 搭建 nginx https nodejs 环境(三.nodejs) 第一步 指定版本源 执行 ...
随机推荐
- delegate--委托
delegate--委托 (可以把委托看成用来执行方法的一个东西) eg: namespace delegateTest{ delegate double MathsOp(double x); cla ...
- John the Ripper-弱口令检测
简介 John the Ripper免费的开源软件,是一个快速的密码破解工具,用于在已知密文的情况下尝试破解出明文的破解密码软件,支持目前大多数的加密算法,如DES.MD4.MD5等.它支持多种不同类 ...
- linu系统文件授权命令
- 在linux下安装并配置mysql数据库
在linux下安装并配置mysql数据库 工具/原料 MySql5.6 CentOS 方法/步骤 1 查找以前是否安装有mysql,使用下面命令: rpm -qa|grep -i mysql ...
- Matplotlib学习---用matplotlib画雷达图(radar chart)
雷达图常用于对多项指标的全面分析.例如:HR想要比较两个应聘者的综合素质,用雷达图分别画出来,就可以进行直观的比较. 用Matplotlib画雷达图需要使用极坐标体系,可点击此链接,查看对极坐标体系的 ...
- BZOJ 4833: [Lydsy1704月赛]最小公倍佩尔数(数论 + 最值反演)
题面 令 \({(1+\sqrt 2)}^n=e(n)+f(n)*\sqrt2\) ,其中 \(e(n),f(n)\) 都是整数,显然有 \({(1-\sqrt 2)}^n=e(n)-f(n)*\sq ...
- [模板]KMP算法
昨天晚上一直在调KMP(模板传送门),因为先学了hash[关于hash的内容会在随后进行更(gu)新(gu)]于是想从1开始读...结果写出来之后一直死循环,最后我还是改回从0读入字符串了. [预先定 ...
- c# double decimal
两种类型 double范围比decimal大,精度比之低 类型 大致范围 精度 .NET Framework 类型 double ±5.0 × 10−324 到 ±1.7 × 10308 15 到 1 ...
- 数组和list互转
数组转list 方法1: String[] stringArray = { "a", "b", "c", "d", &q ...
- SpaceVim中vimproc的vimproc_linux64.so未找到
vimproc是我使用的SpaceVim中自动安装的插件,在启动时出现了"找不到dll文件"的提示,通过查阅官网( https://github.com/Shougo/vimpro ...