因上努力，果上随缘。但行好事，莫问前程。

至此全部完成，使用浏览器访问http://nginx.test.com和https://nginx.test.com。

问题背景：app上传图片提示413Request Entity Too Large。原因：前端采用的是nginx反向代理，默认client_max_body_size大小是1M，如果图片大于1M就报错了解决方案 ：在http或者server或者location标签添加client_max_body_size 20m;官方说明：Sets the maximum allowed size of the client request body, specified in th.

关闭tcp_tw_reccycle 后，又大面积出现的time-wait，仔细观察连接发现全是nginx和Tomcat之间的连接time-wait，搜索了N多资料发现可以通过修改反向代理长连接超时时间控制，具体使用方法upstream http_backend { server 127.0.0.1:8080; keepalive 16; #设置长连接超时时间}server { ... location /http/ { proxy_pass h

nginx反向代理将自定义headers发送到后端应用服务器范例用户前端请求带有headers app_key注意：默认header不允许_变量名，如果需要在http段或者server段加underscores_in_headers on;发送后端方式为在server段或者location段定义，前面有http_proxy_set_header app_key ${http_app_key};详细：http { underscores_in_headers on;

1，问题近来，有测试同学反馈测试环境的前端项目，在代码发布之后，再次访问会出现404的情况，希望我们能介入排查定位一下原因。于是，我约好会议室，拉上前端同学一起，她来发代码，我们来访问验证，而后的确复现了如上问题：在发布完成之后有一段时间会获取到上一次发布的入口文件的hash。我们进行了逐层的排除法验证，在排除了各层NGINX对html的缓存问题，排除了代码发布到主机与通过nfs挂载到pod的代码是否同时更新的问题，排除了浏览器缓存的问题，由于每次验证都需要前端重新发布，编译过程略长，因此不知

HTTP 状态码（HTTP Status Code）是用以表示网页服务器 HTTP 响应状态的 3 位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范扩展。当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含 HTTP 状态码的信息头（server header）用以响应浏览器的请求。HTTP 状态码的英文为 HTTP Stat

有时候我们会给一些没有集成权限认证系统的页面加一层认证，以提高安全性，但是针对一些涉及到线上生产的一些界面，如果使用 NGINX 统一认证的账号，那么如果某个时刻被改坏了，想要确认是谁都很难。NGINX 在打印日志的时候，事实上是有$remote_user这一参数的，只不过常规使用的时候，无法获取到值，需要在基于认证规则的时候，才能够生效，大多时候我们使用htpasswd来做的认证，这样会比较麻烦，所以优雅的方案应该是结合 ldap 认证的模块，来实现认证系统，然后在日志格式化中添加用户字段：...

在日常工作中，会有这样的场景，为了便于测试，可能希望线上的请求能够同步到测试一部分，以便于验证某些功能，或者是在多套测试环境的情况下，希望能够将某些请求在几个环境同步，比如在 1 环境测试的时候生成了某个图片或者视频，这个生成依赖于一个请求的回调，而如果没有特别配置，则这个请求就只在当前环境中生效，这对测试工作有相当大的不便。于是，我们需要引入流量复制这一概念，流量复制有不少工具可以实现，有 Gor、tcpreplay、tcpcopy 等，而今天将要使用的，是配置简单，使用方便的 NGINX 的一个模块

有时候 NGINX 面对一些特殊的场景时，需要进行一定的限速限流的配置，比如一个官网，可能前端静态文件是非常小的，但是同时配置的还有一些 apk 包，这些包如果不做任何限制，可能会形成比较大的负载或者带宽的压力，我这边碰到了，今天就来针对这个问题处理一下。没有限制之前，对应的包下载速度如下：添加如下配置，进行一定的限制：http { ...#省略 limit_conn_zone $binary_remote_addr zone=addr:10m; ...#省略}serve

1，说明。很多时候，测试环境可能会有好多套环境，这个时候，如果每套都配置一个对应的域名，会非常麻烦，但是很多时候针对这个问题似乎又没有特别好的方案，新公司新气象，学到新的思路是在 NGINX 层面基于 cookie 来进行不同环境的分流转发，今天就来做一下这个实验。2，环境准备。因为在新环境，还没有个人自用的测试服务器，Mac 当中做实验又不习惯，于是只能通过 docker 来进行了。所以需要先安装 docker 环境，这个就不在这里赘述了。那么，docker 环境准备完毕之后，就可以开始实验了，

公司原有的测试数据库在主机192.168.10.5上边，现在数据库转移到了192.168.10.4上，为了不让各个地方都需要更改地址，现在需要一个四层代理工具，将原来请求到192.168.10.5的3306端口转发到192.168.10.4的3306端口。这个工具，用到了 nginx 的四层代理。官方文档：http://nginx.org/en/docs/stream/ngx_stream_core_module.html四层代理依赖模块ngx_stream_core_module，该模块自 1.9.

通过脚本按天切割nginx的日志nginx的日志默认是不会进行切割的，如果我们不对其进行一些处理，那么就会一天一天变大，等大到几个G的时候，一旦出现问题，想通过日志进行一些问题的排查都很困难了。我的博客中nginx日志也是这么个情况，于是打算做一下日志切割。脚本如下：#!/bin/bashDate=`date -d '-1 day' '+%Y-%m-%d'`cd /var/log/nginx && mkdir logs/$Datefor i in access.

1，nginx 是什么？Nginx 是一个基于 c 语言开发的高性能 http 服务器及反向代理服务器。由俄罗斯的程序设计师 Igor Sysoev 所开发，官方测试 nginx 能够支支撑 5 万并发链接，并且 cpu、内存等资源消耗却非常低，运行非常稳定。2，为什么要用 nginx？理由一：传统的小型网站并发量小，用户使用的少，所以在低并发的情况下，用户可以直接访问 tomcat 服务器，然后 tomcat 服务器返回消息给用户。为了解决并发，可以使用负载均衡，也就是多增加几个 tomcat 服

1，前言风平浪静的下午，一个前端开发同事找到我，说感觉好像nginx那边有一些转发并没有到达后端。我问，怎么了？她说的也非常具体，第一是常规访问服务，然后返回的状态是401，提示令牌失效（Token Invalid ）。接着直接访问后端所代理的服务，然后就是正常的。哦，听上去很明显啦，事儿就是到nginx这里卡住了呗。我问她详细的情况是怎样的？她说获取验证码以及登陆都是没有问题的，但是就是这里的token没有传过去，token是放在请求头里边的，这个头的名称是“old_token”。听上去一切好

今天第一篇，就 nginx 先来啦nginx 的配置文件，如果你是源码安装的，那么默认在 nginx/conf 下，而且同目录下默认有一个备份配置，可以放心折腾，坏了还能有默认的来还原。Nginx 与 Apache 都是用于 web 服务器, 相比较之下，Nginx 的优势在于：反向代理，rewrite 规则，稳定性，静态文件处理，内存消耗，节省带宽，稳定性高，支持热部署，可以高并发连接等优点，过多的两者之间的对比这里就不展开了。要想真正的对 Nginx 熟练运用掌握, 熟悉其中配置文件的内容必不可少