1、妙用nginx的重试机制 nginx的上有服务器为A和B，当请求经过nginx转发到达A时，A突然宕机后，该怎么让请求继续得以执行成功返回响应呢？这就需要利用nginx的重试机制。 重试就是再次尝试，容错的一种策略。当nginx收到A服务器的响应或者压根就没有响应时，nginx会根据默认
目录1.防止DDOS2.处理防盗链 1.防止DDOS限制请求速度设置Nginx、Nginx Plus的连接请求在一个真实用户请求的合理范围内。比如，如果你觉得一个正常用户每两秒可以请求一次登录页面，你就可以设置Nginx每两秒钟接收一个客户端IP的请求（大约等同于每分钟30个请求）。在nginx的nginx.conf文件中去修改说明：区域名称为one（自定义），占用空间大小为
一. 限制每秒请求数 ngx_http_limit_req_module模块通过漏桶原理来限制单位时间内的请求数，一旦单位时间内请求数超过限制，就会返回503错误。配置需要在两个地方设置：nginx.conf的http段内定义触发条件，可以有多个条件 在location内定义达到触发条件时nginx所要执行的动作 例如：http {
limit_req_zone $binary_remot
目前在我的VPS上主要通过两种方式来限制ip的访问次数。通过Nginx的limit_req配置来限制同一ip在一分钟内的访问次数通过Nginx deny封禁一天内超过指定次数的ip(需要一个监控脚本)一、limit_req配置Nginx 提供了两个模块：ngx_http_limit_req_module 和 ngx_http_limit_conn_module，前者是限制同一ip在一段时间内的访问
场景目前开发的是一个4S店的小程序模板，其中有预约模块，即用户可以预约洗车、保养等项
目，若用户在预约的时候由于网络问题导致请求时间过长，可能会重复点击请求按钮，造成
同样的预约预约了两次，因此考虑到重复请求的问题。
Tip：其实写数据的操作感觉都需要处理重复请求，要不然总会操作一次DB。思考方案前端控制逻辑
请求前，参数判断后，禁用按钮
请求回调的最后一步再启用按钮
问题
可以避免一部分
最近实际开发过程中，发现部分服务资源访问503 Service Temporarily Unavailable，查找后证实是在对nginx做了限速以后，限速做的太低了超过访问次数直接拒绝访问返回503错误。nginx 可以使用ngx_http_limit_req对服务器资源请求进行限制。该模块使用漏斗算法（Leaky Bucket），该算法有两种处理方式Traffic Shaping和Traffi
一、一处“鸡肋”的反射XSS 上月，遇到一处有趣的XML接口，使用POST方式发送如下请求时： POST /query HTTP/1.1
Host: api.demo.com
Content-Type: application/xml
<xml><vulnerable>2019<ScRiPt>alert(1)</ScRiPt></vuln
前言我们在上传大文件的时候通常会把请求体大小限制设置的很大，但平常没有这种业务需求的时候一般就会做出限制，避免异常请求的进入，我们该怎么去设置这个限制呢？一般来说，Linux服务器没有直接限制请求参数包大小的限制。但是，通常会设置一些配置来限制请求大小，这些配置通常在Web服务器或应用服务器上进行设置，比如Nginx和Tomcat如何限制请求体大小1.Nginx1.1 Nginx 1.12及以下版
nginx服务器给客户端发送响应时，包括http响应头部、http响应包体内容。可以调用http框架提供的两个函数ngx_http_send_header，ngx_http_output_filter，分别用于给客户端发送http响应头部、http响应包体。这两个函数会调用各个过滤器模块，对将要发送给客户端的响应头部、响应包体进行过滤处理。例
Nginx通过反向代理做负载均衡时，如果被代理的其中一个服务发生错误或者超时的时候，通常希望Nginx自动重试其他的服务，从而实现服务的高可用性。实际上Nginx本身默认会有错误重试机制，并且可以通过proxy_next_upstream来自定义配置。如果不了解HTTP协议以及Nginx的机制，就可能在使用过程中遇到各种各样的坑。例如服务出现了错误或超时却未重试，或者一些例如创建订单或发送短信这类
nginx通过proxy模块对上游服务使用http/https协议进行反向代理，下图是反向代理处理过程在读取客户端发送的请求时，如果proxy_request_bufferring=on,那么读取完整的包体后再发送给后端服务，如果 proxy_request_bufferring=off，则是边读取包体，边发送。在服务端返回请求响应的包体时，通过proxy_bufferring=on/o
[color=red][b]nginx加上proxy_read_timeout 3000配置可以解决，其中keepalive_timeout也是不能少的
http {
client_max_body_size 500m;
keepalive_timeout 3000;
proxy_read_timeout 3000; //后台服务器执行时间[/b][/color]
Rewrite 介绍Rewrite是Nginx服务器提供的一个重要基本功能，是Web服务器产品中几乎必备的功能。 主要的作用是用来实现URL的重写。 注意：Nginx服务器的Rewrite功能的实现依赖于PCRE的支持，因此在编译安装Nginx服务之前，需要安装PCRE库（正则表达式库）。Nginx使用的是ngx_http_rewrite_module模块来解析和处理Rewrite功能的相关配置（
该模块可实现如下的功能，在浏览器输入http://你的IP/lcw.text，能够读出你在根目录下创建的lcw.txt里面的内容，并在前面加上一句字符串where there is a will,there is a way! 代码如下：//start from the very beginning,and to create greatness
//@author: Chuangwei Lin
关于nginx负载均衡策略配置，可参考nginx 负载均衡策略从nginx 1.9.13开始，默认情况下不重试非幂等请求（PUT、POST等），当在配置中增加失败重试配置时，如果后端服务器响应超时，Get请求会重新选择一台上游服务器进行重试，而POST请求则会返回504 Gateway Time-out，不会进行重试。可使用以下两种方式处理POST请求失败重试问题方式1想在1.9.13或更高版本上
前言前几天正在升级发版项目的时候，发现一个很奇葩的问题，就是用户再浏览器里执行了一次http请求，结果后端服务器执行了两遍，如果这次请求是Insert操作，可想而知，数据库会多出一条一模一样的记录来。场景还原网关用Nginx做了反向代理和负载均衡，Nginx下挂着两台阿里云ECS服务器，每台机器上都装着Tomcat，用户打开浏览器，点击页面，访问后端接口，查看Nginx的access.log,结果
所有跨域的js在提交post请求的时候，如果服务端设置了可跨域访问都会默认发送两次请求，第一次是预检请求，查询是否支持跨域，第二次才是真正的post提交第一条为options请求，第二条请求才是我们预想中的请求。为什么先发起了一条options请求：options请求 options请求的官方定义：OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的
查看安装了哪些模块命令： nginx -V
nginx version: nginx/1.2.3
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/opt/xcache/nginx --wit
介绍大家经常会遇到这样需求，一个活动页面的URL地址很长，推广起来产品运营和用户反馈不容易记住不美观，但是暂时没办法修改代码，这个时候就可以用到rewrite。或者你现在网站升级到https现在有些用户还在访问http你想统一用https，这些都可以用rewrite规则来实现。rewrite会重写用户的请求地址，但是不会修改问号后面参数，返回给用户的httpcode为302。 语法：rewri
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test ，ABTestingGateway就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度发布常见一般有三种方式:Nginx+LUA方式根据Cookie实现
