nginx平滑升级 0x1 nginx官方其实已经带了升级的办法，会根据 ./configure 在 Makefile 文件中显示出来，如下： default: build clean: rm -rf Makefile objs .PHONY: default clean build: $(MAKE) -f objs/Makefile install: $(MAKE) -f objs/Makefile install modules: $(MAKE) -f objs/Makefile modules upgrade: /usr/local/tengine/sbin/nginx -t kill -USR2 `cat /usr/local/tengine/logs/nginx.pid` sleep 1 test -f /usr/local/tengine/logs/nginx.pid.oldbin kill -QUIT `cat /usr/local/tengine/logs/nginx.pid.oldbin` .PHONY: build install modules upgrade 我们在 make 出二进制文件后，备份原有的二进制文件、替换，再使用 make upgrade 即可升级，或者根据上面的步骤手动操作也是可以的

nginx之403错误-写权限不足 0x0 前段报错后，通过浏览器F12查看是403错误，于是登录 tengine 查看日志，确发现 access 一度没有看到相关的请求，怀疑是没有经过此 tengine、甚至是客户端错误，但从浏览器内 403 返回内容否定了这点，因为 403 的内容是 tengine 返回的。 那么这是怎么回事呢？ 通过在浏览器内请求指定的 url，发现 access 日志能匹配到，那么日志是没问题的，由于响应的是 tengine 返回，所以应该也没有 waf 拦截。 在尝试了多次方案之后，仍然没有找到请求，于是尝试查看 error 日志，发现此请求会要求写缓存，但是缓存无权限写入报错。 猜测是 nginx 无权限写文件，于是为了标识是权限问题，所以返回了 403 ，所以这个问题教会我们的是，我们总以为服务正常情况下能记录所有日志，因为基本上 4xx、5xx日志都会记录下来，而现在可以知道，就算是 nginx、web都没问题，日志不一定能记录所有请求，可能会因为 nginx 内部错误、甚至可能是操作系统级别的错误导致异常，而无法记录下日志。

nginx proxy_pass域名解析到ipv6 0x1 问题 某环境nginx在配置好proxy_pass反向代理外网地址后出现502的情况。但是telnet和curl测试都无问题。在查看error日志可以看到域名地址解析到了ipv6，直接导致502的出现。 0x2 解决 根据nginx的资料和检索的相似案例，尝试设置了参数 resolvoer ipv6=off，但是仍然无效果。进一步搜索之后得知需要在系统级别禁用ipv6，修改sysctl.conf文件，如下： net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 设置后再次重载nginx，测试反代地址正常。同时发现设置此参数后nginx的reload速度也加快，正常不到1秒，之前大概需要5秒左右。猜测是之前解析ipv6地址过慢导致。

nginx信号 0x1 The master Nginx process can handle the following signals on Linux and Unix like systems: TERM, INT : Quick shutdown QUIT : Graceful shutdown KILL : Halts a stubborn process HUP : Configuration reload. Start the new worker processes with a new configuration. Gracefully shutdown the old worker processes USR1 : Reopen the log files USR2 : Upgrade Executable on the fly WINCH : Gracefully shutdown the worker processes 如上的话，如果是切割日志，那么推荐使用USR1

nginx更换默认内存分配器为jemalloc 0x1 虽然nginx的性能很高，但是在互联网高并发的场景下长期运行，仍然需要尽可能提升其性能/保持稳定，那么修改默认内存分配器glibc为jemalloc是一个不错的选择 0x2 nginx的默认内存分配器，通过以下命令做了简单的判断： lsof | grep nginx # 无malloc相关的内容 strings ./nginx # 有malloc关键字，但是无明显jemalloc或者tcmalloc ldd ./nginx # 无malloc相关的内容 通过以上内容，我们无法判断nginx显示使用了jemalloc或者tcmalloc，那么应该是使用了linux默认的glibc的内存分配器 0x3 nginx使用jemalloc的前提是安装了jemalloc，这里不再重复说明。要想更换为jemalloc，仅增加编译参数： --with-ld-opt="-ljemalloc" 0x4 确定已经使用jemalloc。启动nginx，执行如下命令，保证回显有jemalloc关键字 lsof | grep nginx