禁用NGINX中的TLS 1.0

我有一个NGINX作为我们网站的反向代理,并且运作良好.对于需要ssl的网站,我遵循 raymii.org以确保尽可能强大的SSLLabs分数.其中一个站点需要符合PCI DSS,但基于最新的TrustWave扫描现在因为启用了TLS 1.0而失败.在nginx.conf中的http级别我有:

  对于我有的特定服务器:

  我已经更改了密码,将事情从http级别移到了每个ssl站点服务器,但不管我运行的是什么:

  我获得了TLS 1.0的有效连接. SSLLabs将网站的nginx设置为A但是使用TLS 1.0,所以我相信其余的设置是正确的,它不会关闭TLS 1.0. 关于我可能缺少什么的想法?

  这里的问题是TLS协商的服务器名称指示部分是在协商连接本身之后完成的.并且在连接协商期间协商协议.如果将该虚拟主机配置为没有与其关联的其他虚拟主机的服务器上的IP地址,则可能无法为该虚拟主机强制执行TLS v1.0.因此,nginx将根据IP地址知道不允许TLS v 1.0.   from:http://www.voidcn.com/article/p-vufkevsw-btw.html

nginx 跨域踩坑及解决--OPTIONS请求处理

一、问题出现 新项目采用新的前端ajax请求方式,对应的后端接口也进行了参数层面的修改。 原先在谷歌F12查看的接口请求参数打印为Query String Parameters   后续对参数进行了封装,接口请求参数打印为 。   本地测试都通过的情况下,决定上线。上线完之后对于post请求出现了请求服务器失败的情况,开始对nginx的配置进行整理和排查。   二、问题排查 原先的nginx配置如下图所示 通过对nginx日志的分析,发现了一个OPTIONS类型的请求。经过查证在请求时,OPTIONS请求是客户端的浏览器对服务端发送的一个请求,属于浏览器级行为 OPTIONS请求方法的主要用途有两个: 1、获取服务器支持的HTTP请求方法; 2、用来检查服务器的性能。例如:AJAX进行跨域请求时的预检,需要向另外一个域名的资源发送一个HTTP OPTIONS请求头,用以判断实际发送的请求是否安全。 再来看下这个“某些情况下”都是什么情况? 1、跨域请求,非跨域请求不会出现options请求 2、自定义请求头 3、请求头中的content-type是application/x-www-form-urlencoded,multipart/form-data,text/plain之外的格式 当满足条件12或者13的时候,简单的ajax请求就会出现options请求,有没有感觉到一点同源策略的意思,个人理解这个就是浏览器底层对于同源策略的一个具体实现。首先得到服务器端的确认,才能继续下一步的操作,这也是为什么options请求也被叫做“预检”请求的原因吧。 通过上面的描述,大致理解了什么是opyions请求以及options请求发送的时机,以此说明需要先处理options请求再对自己的请求做处理   三、处理方式 直接上代码了

  from:https://blog.csdn.net/ATadpole/article/details/109185390

微信小程序webview的缓存问题

前言 小程序webview的页面缓存会影响开发中的调试和生产中的使用 解决 1.页面缓存由浏览器缓存引起,那么可以通过设置来修改浏览器缓存。 可以通过nginx设置cache-control 来关闭浏览器缓存 2.由于是单页面应用,所以只需要对index.html设置即可。 对index.html中的资源地址,也会存在缓存,可以通过webpack构建时加入hash值解决。 作者:依然还是或者其他 链接:https://www.jianshu.com/p/e0363ff16b34 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Nginx配置禁止缓存

location / { #如果expires 和 add_header 同时开启的情况下,则add_header优于expires生效 #Cache-Control比Expires可以控制的多一些, 而且Cache-Control会重写Expires的规则 #设置禁止浏览器缓存,每次都从服务器请求 add_header Cache-Control no-cache; add_header Cache-Control private; #设置缓存上面定义的后缀文件缓存到浏览器的生存时间 expires -1s; proxy_pass  http://…; } ———————————————— 版权声明:本文为CSDN博主「风暴幽居」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/shuiyuetianwy/article/details/98938530   光子补充:

 

centos7 把终端显示改为英文/中文

把终端显示改为英文: 1、先备份语言配置文件 cp /etc/locale.conf /home/locale.conf.backup 2、打开配置文件 vim /etc/locale.conf 3、把“zh_CN.UTF-8”修改为“en_US.UTF-8” 4、esc :wq 保存并退出 5、shutdown -r now 重启   from:https://www.cnblogs.com/nnniki/p/10359229.html

Nginx出现403 forbidden

nginx访问时报403, 于是查看nginx日志,路径为/var/log/nginx/error.log。打开日志发现报错Permission denied,详细报错如下: 1.    open() "/data/www/1.txt" failed (13: Permission denied), client: 192.168.1.194, server: www.web1.com, request: "GET /1.txt HTTP/1.1", host: "www.web1.com" 没有权限?于是找了不少资料,可以通过下面四步排查解决此问题。你可能只是其中之前配置有问题,不一定四个步骤都用上。   一、由于启动用户和nginx工作用户不一致所致 1.1查看nginx的启动用户,发现是nobody,而为是用root启动的   命令:ps aux | grep "nginx: worker process" | awk'{print $1}'   1.2将nginx.config的user改为和启动用户一致, 命令:vi conf/nginx.conf 二、缺少index.html或者index.php文件,就是配置文件中index index.html index.htm这行中的指定的文件。 1.    server { 2.      listen       80; 3.      server_name  localhost; 4.      index  index.php index.html; 5.      root  /data/www/; 6.    } 如果在/data/www/下面没有index.php,index.html的时候,直接文件,会报403 forbidden。     三、权限问题,如果nginx没有web目录的操作权限,也会出现403错误。 解决办法:修改web目录的读写权限,或者是把nginx的启动用户改成目录的所属用户,重启Nginx即可解决 1.    chmod -R 777 /data 2.    chmod -R 777 /data/www/     四、SELinux设置为开启状态(enabled)的原因。 4.1、查看当前selinux的状态。 1.    /usr/sbin/sestatus 4.2、将SELINUX=enforcing 修改为 SELINUX=disabled 状态。 1.    vi /etc/selinux/config 2. 3.    #SELINUX=enforcing 4.    SELINUX=disabled 4.3、重启生效。reboot。 1.    reboot   from:https://blog.csdn.net/qq_35843543/article/details/81561240

解决nginx报错:nginx: [emerg] bind() to 0.0.0.0:8088 failed (13: Permission denied)

报错描述: nginx: [emerg] bind() to 0.0.0.0:8088 failed (13: Permission denied) 通过ansible远程给主机更换端口并重新启动nginx服务,出现以上报错信息(权限被拒绝)。 解决方式:经检查发现是selinux导致报错。 [root@localhost nginx]# getenforce    #查询selinux状态 [root@localhost nginx]# setenforce 0        #临时将selinux关闭 如果需要永久关闭selinux,请编辑/etc/selinux/config文件,将SELINUX=disabled。之后将系统重启一下即可。 之后重启nginx服务,发现报错已经解除。   from:https://www.cnblogs.com/python-wen/p/11358978.html

上传文件报413 Request Entity Too Large错误解决办法

产生这种原因是因为服务器限制了上传大小 1、nginx服务器的解决办法 修改nginx.conf的值就可以解决了 将以下代码粘贴到nginx.conf内

  可以选择在http{ }中设置:client_max_body_size 20m; 也可以选择在server{ }中设置:client_max_body_size 20m; 还可以选择在location{ }中设置:client_max_body_size 20m; 三者有区别 设置到http{}内,控制全局nginx所有请求报文大小 设置到server{}内,控制该server的所有请求报文大小 设置到location{}内,控制满足该路由规则的请求报文大小 同时记得修改php.ini内的上传限制 upload_max_filesize = 20M 注意:如果以上修改完毕后还会出现413错误的话 , 可能是域名问题 , 本人遇到过此类情况 , 记录 2、apache服务器修改 在apache环境中上传较大软件的时候,有时候会出现413错误,出现这个错误的原因,是因为apache的配置不当造成的,找到apache的配置文件目录也就是conf目录,和这个目录平行的一个目录叫conf.d打开这个conf.d,里面有一个php.conf

  误就发生在这个LimitRequestBody配置上,将这个的值改大到超过你的软件大小就可以了 如果没有这个配置文件请将

  写到apache的配置文件里面即可。 3、IIS服务器(Windows Server 2003系统IIS6) 先停止IIS Admin Service服务,然后 找到windows\system32\inesrv\下的metabase.xml,打开,找到ASPMaxRequestEntityAllowed 修改为需要的值,然后重启IIS Admin Service服务 1、在web服务扩展 允许active server pages和在服务器端的包含文档 2、修改各站点的属性 主目录-配置-选项-启用父路径 3、使之可以上传大文档(修改成您想要的大小就可以了,以字节为单位) c:\WINDOWS\system32\inetsrv\MetaBase.xml !企业版的windows2003在第592行 默认的预设置值 AspMaxRequestEntityAllowed="204800" 即200K 将其加两个0,即改为,现在最大就可以上传20M了。 AspMaxRequestEntityAllowed="20480000" 作者:烂孩子 链接:https://www.jianshu.com/p/3851c3d6eaf1 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Nginx配置Https反向代理

ZERO 持续更新 请关注:https://zorkelvll.cn/blogs/zorkelvll/articles/2018/12/09/1544347717025 背景 本文主要是记录配置nginx反向代理https过程中的一些记录! 一、Nginx添加SSL模块 nginx默认缺少SSL模块支持,需要手动编译安装!由于本文之前已经编译安装过nginx,因此本文将是在原有基础之上编译安装添加SSL模块

  二、免费获取SSL证书

  imagepng

  三、配置nginx

  作者:zorkelvll 链接:https://www.jianshu.com/p/e46ec3fc121e 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

域名、https、nginx反向代理小结

1、域名备案:指域名与公网ip的绑定,绑定后即可使用80/443等端口。 2、域名添加A记录子域名后指定对应的公网ip地址,无法指定端口。 3、只要使用https就必须使用证书,证书可以自己购买也可使用openssl生成,但是自己生成的证书安全性较差,仍然容易被串改,而且网页显示与购买的有区别。 4、nginx反向代理配置       可以不使用upstream,直接在prox_pass后添加真正的服务器地址,但是使用upstream好处更多,如实现负载均衡、设置权重等功能。 nginx部分内容详解如下: proxy_redirect off; 重写后端服务器的location和refresh头。 proxy_set_header Host $host; 重写发送给后端服务器的请求头内容。 proxy_connect_timeout 300; 代理服务器接收请求到连接后端服务器的最长等待时间。 proxy_buffer_size 4k; 后端响应的缓冲区数量和大小。 proxy_buffers 4 32k; 请求后端的缓冲区数量和大小。 proxy_busy_buffers_size 64k; 当代理服务器忙时,缓冲区的最大值。 proxy_send_timeout 300 将超时与请求传输到代理服务器分配。 proxy_read_timeout 300 NGINX等待获取请求响应的时间。 upstream ip_hash:指令通过ip地址生成hash值将客户端均匀地连接到所有服务器。 keepalive:指令指定每个worker进程缓存后端服务器的长连接数。 least_conn:指令激活负载均衡算法,使用最少连接数。 server: —- weight:设置服务器的优先级。 —- fail-timeout、max-fails:在fail-timeout时间内出现了max-fails次数的连接失败,nginx则认为该后端服务器已经挂掉了。 —- backup:指定服务器的备用机器,只有非backup机器挂掉,才会接收请求。 —- down:指定当前的服务器不再接收请求。 对upstream仍不了解,可参考此网站实例:https://www.cnblogs.com/wzjhoutai/p/6932007.html   from:https://www.cnblogs.com/wdp-home/p/12092480.html

nginx上传大文件,413错误解决

在nginx里增加了配置。

我觉得,应该只用修改client_max_body_size就可以解决问题。 其它几个,设置了并未起作用。其参数意义如下: client_max_body_size 限制请求体的大小,若超过所设定的大小,返回413错误。 client_header_timeout 读取请求头的超时时间,若超过所设定的大小,返回408错误。 client_body_timeout 读取请求实体的超时时间,若超过所设定的大小,返回413错误。 proxy_connect_timeout http请求无法立即被容器(tomcat, netty等)处理,被放在nginx的待处理池中等待被处理。此参数为等待的最长时间,默认为60秒,官方推荐最长不要超过75秒。 proxy_read_timeout http请求被容器(tomcat, netty等)处理后,nginx会等待处理结果,也就是容器返回的response。此参数即为服务器响应时间,默认60秒。 proxy_send_timeout http请求被服务器处理完后,把数据传返回给Nginx的用时,默认60秒。   from:https://www.cnblogs.com/aguncn/p/11189159.html