nginx经过多层代理后获取真实来源ip

nginx取 $remote_addr 当做真实ip,而事实上,$http_X_Forwarded_For 才是用户真实ip,$remote_addr只是代理上一层的地址

解决方案:

在 http 模块 加

set_real_ip_from 172.17.10.125;   #上一层代理IP地址

real_ip_header X-Forwarded-For;
real_ip_recursive on;

添加之后启动nginx报错:

nginx: [emerg] unknown directive “set_real_ip_from” in /home/lnidmp/nginx/conf/nginx.conf:26

需要添加realip模块,重新编译nginx

1、cd /usr/local/nginx-1.15.12
2、./configure –prefix=/usr/cmcc/nginx –with-http_stub_status_module –with-http_ssl_module –with-http_realip_module
3、make && make install

温馨提示:
1、set_real_ip_from 是指接受从哪个信任前代理处获得真实用户ip

2、real_ip_header 是指从接收到报文的哪个http首部去获取前代理传送的用户ip

3、real_ip_recursive 是否递归地排除直至得到用户ip(默认为off)

首先,real_ip_header 指定一个http首部名称,默认是X-Real-Ip,假设用默认值的话,nginx在接收到报文后,会查看http首部X-Real-Ip。

(1)如果有1个IP,它会去核对,发送方的ip是否在set_real_ip_from指定的信任ip列表中。如果是被信任的,它会去认为这个X-Real-Ip中的IP值是前代理告诉自己的,用户的真实IP值,于是,它会将该值赋值给自身的$remote_addr变量;如果不被信任,那么将不作处理,那么$remote_addr还是发送方的ip地址。

(2)如果X-Real-Ip有多个IP值,比如前一方代理是这么设置的:proxy_set_header X-Real-Ip $proxy_add_x_forwarded_for;

得到的是一串IP,那么此时real_ip_recursive 的值就至关重要了。nginx将会从ip列表的右到左,去比较set_real_ip_from 的信任列表中的ip。如果real_ip_recursive为off,那么,当最右边一个IP,发现是信任IP,即认为下一个IP(右边第二个)就是用户的真正IP;如果real_ip_recursive为on,那么将从右到左依次比较,知道找到一个不是信任IP为止。然后同样把IP值复制给$remote_addr。

 

生产nginx配置文件如下:

复制代码
user  www;
worker_processes  10;
worker_rlimit_nofile 51200;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
error_log   /data/logs/nginx_error.log  crit;

#pid        logs/nginx.pid;


events {
    use epoll;
    worker_connections  51200;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    server_names_hash_bucket_size 128;
    server_tokens off;
    expires       1h;
    sendfile       off; 
    tcp_nopush     on;
    fastcgi_connect_timeout 1200s;
    fastcgi_send_timeout 1200s;
    fastcgi_read_timeout 1200s;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 8 128k;#8 128
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    keepalive_timeout  65;
    tcp_nodelay on;
    error_page   404  /;    
    gzip on;
    gzip_min_length  2048;
    gzip_buffers     4 16k;
    gzip_http_version 1.1;
    gzip_types  text/plain  css  html  application/xml application/x-javascript ;

    set_real_ip_from 上一层代理IP地址;
    real_ip_recursive on;
    real_ip_header X-Forwarded-For;

    log_format  access  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" $http_x_forwarded_for';
#################### include    ################################################

include conf.d/*.conf;
}
复制代码

nginx做负载均衡,引起写io大的优化

服务器:DELL R710  Xeon E5620 *2/16G/300G SAS*5 raid5
系统:centos5.7 64bit
服务架构:  nginx –> squid —>存储
现在的问题:晚高峰单机流量跑到150Mbit/s 服务器的负载就上到40-50 .
1.负载高的是io引起的,用io软件分析一下,主要是io写操作. 查了一下squid命中率到80% 应该读操作大于写操作才对,百思不解.
用dstat命令分析大部份写操作原来是nginx引起的,nginx只是做转发呀并没有做cache呀,为什么会产生这么大的写io.
网上查了nginx相关资料.如下:
nginx 每次request都要先在proxy本地找一下缓存,没有的时候才去请求真实服务器,其实配置中我并没有设置proxy_stroe之类的参数,因为本身就是要负载I/O ,如果都Cache到proxy上 那就达不到真正的目的了,更何况Cache不太适合大量的不算小的文件。

proxy_buffering

syntax: proxy_buffering on|off
default: proxy_buffering on
context: http, server, location
This directive activate response buffering of the proxied server.
If buffering is activated, then nginx assumes the answer of the proxied server as fast as possible, preserving it in the buffer, assigned by directiveproxy_buffer_size and proxy_buffers.
If the response can not all be placed in memory, then parts of it will be written to disk.
If buffering is switched off, then the response is synchronously transferred to client immediately as it is received.
nginx do not attempt to count entire answer of the proxied server, maximum size of data, which nginx can accept from the server it is assigned by directiveproxy_buffer_size.
For Comet applications based on long-polling it is important to set proxy_buffering to off, otherwise the asynchronous response is buffered and the Comet does not work.
总算发现问题所在了,设置off 后reload一下, 负载从50降到5,这也太夸张了吧,不敢想像。
如果是单纯拿来做负载均衡而不做代理,此项应该是必关的,否则只有无谓的消耗。

Nginx写IO占用高故障处理

问题描述

突然收到一台服务器负载过高告警,网站打开缓慢

问题分析

(1)使用 top 命令看到cpu行的 iowait 达到了70%以上,断定是IO负载过高的原因

(2)使用 iotop -o 命令发现Nginx的写IO特别大,并且在上一步的top命令看到Nginx的进程状态为D,表示Nginx在等待IO已经为僵死状态

这时候可以知道是Nginx产生大量写操作导致的系统负载过高了,但还不能知道具体Nginx在写什么文件

(3)找到其中一个nginx worker进程的pid,使用 lsof -p pid 列出来的文件发现除了一些系统库文件及日志文件,还有相当多的fastcgi_temp/xxx文件,有可能与这些文件有关联

(4)使用 strace -p pid 追踪,发现nginx进程对某个fd进行大量的写操作,与 lsof 命令列出来的文件刚好符合

(5)使用 iostat 1 输出的大量写io的分区与fastcgi_temp所在分区相符合

猜测可能是外部正在上传大量的大文件给php-fpm,于是通过EZHTTP的小工具来查看实时流量,发现入站流量其实不大

解决方案

知道了是 fastcgi_temp io 压力大,目前无法短时间从根本上解决问题,决定先紧急处理一下,把 fastcgi_temp 指向 /dev/shm,也就是映射到了内存,重启nginx之后服务恢复了正常,之后再找开发人员协同查找解决根本问题

线上nginx的一次“no live upstreams while connecting to upstream ”分析

先描述一下环境,前段的负载均衡转发给nginx,nginx再转发给后端的应用服务器。

nginx配置文件如下:

upstream ads {

server ap1:8888 max_fails=1 fail_timeout=60s;

server ap2:8888 max_fails=1 fail_timeout=60s;

}

出现的现象是:

日志里面每隔一两分钟就会记录一条类似 *379803415 no live upstreams while connecting to upstream  的日志,

此外,还有大量的“upstream prematurely closed connection while reading response header from upstream”的日志。

我们先看“no live upstreams”的问题。

看字面意思是nginx发现没有存活的后端了,但是很奇怪的事情是,这段时间一直访问都正常,并且用wireshark看到的也是有进来的,也有返回的。

现在只能从nginx源码的角度来看了。

因为是upstream有关的报错,所以在ngx_http_upstream.c中查找“no live upstreams”的关键字,可以找到如下代码(其实,你会发现,如果在nginx全局代码中找的话,也只有这个文件里面有这个关键字):

在这里可以看出,当rc等于NGX_BUSY的时候,就会记录“no live upstreams”的错误。

往上看1328行,可以发现rc的值又是ngx_event_connect_peer这个函数返回的。

ngx_event_connect_peer是在event/ngx_event_connect.c中实现的。这个函数中,只有这个地方会返回NGX_BUSY,其他地方都是NGX_OK或者NGX_ERROR或者NGX_AGAIN之类的。

rc = pc->get(pc, pc->data);

if (rc != NGX_OK) {

return rc;

}

这里的pc是指向ngx_peer_connection_t结构体的指针, get是个ngx_event_get_peer_pt的函数指针,具体指向哪里,一时无从得知。接着翻看ngx_http_upstream.c

在ngx_http_upstream_init_main_conf中看到了,如下代码:

uscfp = umcf->upstreams.elts;

for (i = 0; i < umcf->upstreams.nelts; i++) {

init = uscfp[i]->peer.init_upstream ? uscfp[i]->peer.init_upstream:

ngx_http_upstream_init_round_robin;

if (init(cf, uscfp[i]) != NGX_OK) {

return NGX_CONF_ERROR;

}

}

这里可以看到,默认的配置为轮询(事实上负载均衡的各个模块组成了一个链表,每次从链表到头开始往后处理,从上面到配置文件可以看出,nginx不会在轮询前调用其他的模块),并且用ngx_http_upstream_init_round_robin初始化每个upstream。

再看ngx_http_upstream_init_round_robin函数,里面有如下行:

r->upstream->peer.get = ngx_http_upstream_get_round_robin_peer;

这里把get指针指向了ngx_http_upstream_get_round_robin_peer

在ngx_http_upstream_get_round_robin_peer中,可以看到:

if (peers->single) {

peer = &peers->peer[0];

if (peer->down) {

goto failed;

}

} else {

/* there are several peers */

peer = ngx_http_upstream_get_peer(rrp);

if (peer == NULL) {

goto failed;

}

再看看failed的部分:

failed:

if (peers->next) {

/* ngx_unlock_mutex(peers->mutex); */

ngx_log_debug0(NGX_LOG_DEBUG_HTTP, pc->log, 0, “backup servers”);

rrp->peers = peers->next;

n = (rrp->peers->number + (8 * sizeof(uintptr_t) – 1))

/ (8 * sizeof(uintptr_t));

for (i = 0; i < n; i++) {

rrp->tried[i] = 0;

}

rc = ngx_http_upstream_get_round_robin_peer(pc, rrp);

if (rc != NGX_BUSY) {

return rc;

}

/* ngx_lock_mutex(peers->mutex); */

}

/* all peers failed, mark them as live for quick recovery */

for (i = 0; i < peers->number; i++) {

peers->peer[i].fails = 0;

}

/* ngx_unlock_mutex(peers->mutex); */

pc->name = peers->name;

return NGX_BUSY;

这里就真相大白了,如果连接失败了,就去尝试连下一个,如果所有的都失败了,就会进行quick recovery  把每个peer的失败次数都重置为0,然后再返回一个NGX_BUSY,然后nginx就会打印一条no live upstreams ,最后又回到原始状态,接着进行转发了。

这就解释了no live upstreams之后还能正常访问。

重新看配置文件,如果其中一台有一次失败,nginx就会认为它已经死掉,然后就会把以后的流量全都打到另一台上面,当另外一台也有一次失败的时候,就认为两个都死掉了,然后quick recovery,然后打印一条日志。

这样带来的另一个问题是,如果几台同时认定一台后端已经死掉的时候,会造成流量的不均衡,看zabbix监控的截图也能看出来:

初步的解决方法:

把max_fails从1改成5,效果很明显,“no live upstreams”出现的概率变少了很多,但却没有完全消失。

另外,日志里面还会有大量的“upstream prematurely closed connection while reading response header from upstream”。

这次从源码上看,在执行ngx_http_upstream_process_header这个函数的时候,会报这个错,但具体是网络原因还是其他原因不是很明显,下面就tcpdump抓一下包。

其中54是nginx前端的负载均衡的地址,171是nginx地址,32是ap1的地址,另外ap2的地址是201

如截图所示:

请求由负载均衡发到nginx上,nginx先是回应ack给负载均衡,然后跟ap1进行三次握手,随后发送了一个长度为614的数据包给ap1.然而却收到了一个ack和fin+ack,从Ack=615可以看出,这两个包都是针对长度为614的数据包的回应,后端app直接就把连接给关闭掉了!

再然后,nginx回应给后端的app一个ack和fin+ack,从Ack=2可以看出这是对fin+ack的回应。

再然后,nginx就向ap2发出了一个syn包,并且也收到了第一台返回的ack。

第二张图:

如图,可以看出,nginx跟ap2三次握手后,也发送了一个请求的数据包,同样被直接关闭连接了。

随后,nginx就把502返回给了负载均衡。

这里的抓包又一次从侧面支持了上面代码的分析。

然后把问题反馈给做后端应用的同事了。

修改 Nginx 进程最大可打开文件数(worker_processes和worker_connections)

worker_processes:操作系统启动多少个工作进程运行Nginx。注意是工作进程,不是有多少个nginx工程。在Nginx运行的时候,会启动两种进程,一种是主进程master process;一种是工作进程worker process。例如我在配置文件中将worker_processes设置为4,启动Nginx后,使用进程查看命令观察名字叫做nginx的进程信息,我会看到如下结果:

[root@localhost nginx]# ps -elf | grep nginx
4 S root 2203 2031 0 80 0 – 46881 wait 22:18 pts/0 00:00:00 su nginx
4 S nginx 2204 2203 0 80 0 – 28877 wait 22:18 pts/0 00:00:00 bash
5 S root 2252 1 0 80 0 – 11390 sigsus 22:20 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
5 S nobody 2291 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2292 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2293 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2294 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
0 R root 2312 2299 0 80 0 – 28166 – 22:24 pts/0 00:00:00 grep –color=auto nginx
1
2
3
4
5
6
7
8
9
图中可以看到1个nginx主进程,master process;还有四个工作进程,worker process。主进程负责监控端口,协调工作进程的工作状态,分配工作任务,工作进程负责进行任务处理。一般这个参数要和操作系统的CPU内核数成倍数。

worker_connections:这个属性是指单个工作进程可以允许同时建立外部连接的数量。无论这个连接是外部主动建立的,还是内部建立的。这里需要注意的是,一个工作进程建立一个连接后,进程将打开一个文件副本。所以这个数量还受操作系统设定的,进程最大可打开的文件数有关。

设置Nginx进程最大可打开文件数
1、更改操作系统级别的“进程最大可打开文件数”的设置
Linux问题—设置“进程最大可打开的文件数”永久有效的方式。

2、更改Nginx软件级别的“进程最大可打开文件数”的设置
刚才更改的只是操作系统级别的“进程最大可打开文件”的限制,作为Nginx来说,我们还要对这个软件进行更改。打开nginx.conf主配置文件。您需要配合worker_rlimit_nofile属性。如下:

user root root;
worker_processes 4;
worker_rlimit_nofile 65535;

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;
events {
use epoll;
worker_connections 65535;
}

这里只粘贴了部分代码,其他的配置代码和主题无关,也就不需要粘贴了。请注意代码行中加粗的两个配置项,请一定两个属性全部配置。配置完成后,请通过nginx -s reload命令重新启动Nginx。

3、验证Nginx的“进程最大可打开文件数”是否起作用
那么我们如何来验证配置是否起作用了呢?在linux系统中,所有的进程都会有一个临时的核心配置文件描述,存放路径在 /pro/进程号/limit。

首先我们来看一下,没有进行参数优化前的进程配置信息:

[root@localhost nginx]# ps -elf | grep nginx
4 S root 2203 2031 0 80 0 – 46881 wait 22:18 pts/0 00:00:00 su nginx
4 S nginx 2204 2203 0 80 0 – 28877 wait 22:18 pts/0 00:00:00 bash
5 S root 2252 1 0 80 0 – 11390 sigsus 22:20 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
5 S nobody 2291 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2292 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2293 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
5 S nobody 2294 2252 0 80 0 – 11498 ep_pol 22:23 ? 00:00:00 nginx: worker process
0 R root 2318 2299 0 80 0 – 28166 – 22:42 pts/0 00:00:00 grep –color=auto nginx
1
2
3
4
5
6
7
8
9
可以看到,nginx工作进程的进程号是:2291 2292 2293 2294。我们选择一个进程,查看其核心配置信息:

[root@localhost nginx]# cat /proc/2291/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 3829 3829 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 3829 3829 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
请注意其中的Max open files ,分别是1024和4096。那么更改配置信息,并重启Nginx后,配置信息就是下图所示了:

[root@localhost conf]# cat /proc/2351/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 3829 3829 processes
Max open files 65535 65535 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 3829 3829 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us

nginx性能调优参数

worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
worker_rlimit_nofile 204800;
error_log /opt/nginx/log/error.log warn;
pid /opt/nginx/nginx.pid;

events {
use epoll;
worker_connections 65535;
}

http {
include /opt/nginx/conf/mime.types;
default_type application/octet-stream;
client_max_body_size 5000M;
log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;
access_log /opt/nginx/log/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
keepalive_timeout 600;
client_header_buffer_size 4k;
large_client_header_buffers 4 8k;
open_file_cache max=204800 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 1;
keepalive_requests 100000;
client_header_timeout 180;
client_body_timeout 180;
reset_timedout_connection on;
client_body_buffer_size 128m;
proxy_connect_timeout 300s;
proxy_send_timeout 900;
proxy_read_timeout 900;
proxy_buffers 4 128k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
include /opt/nginx/conf/conf.d/*.conf;
}

更改nginx软件“进程最大可打开文件数”的设置

https://blog.csdn.net/huangbaokang/article/details/79917023 这篇博客只是操作系统级别的“进程最大可打开文件”的限制。

在nginx.conf文件中加入worker_rlimit_nofile配置

未加这个配置的时候,启动好了nginx服务,我们可以查看到当前nginx进程最大可打开的文件数。如下:

[root@localhost ~]# ps -ef|grep nginx
root 927 1 0 15:32 ? 00:00:00 nginx: master process /root/hbk/nginx2/sbin/nginx
root 928 927 0 15:32 ? 00:00:00 nginx: worker process
root 929 927 0 15:32 ? 00:00:00 nginx: worker process
root 930 927 0 15:32 ? 00:00:00 nginx: worker process
root 931 927 0 15:32 ? 00:00:00 nginx: worker process
root 1065 1049 0 15:34 pts/0 00:00:00 grep –color=auto nginx
1
2
3
4
5
6
7
8
在我这里,有1个master process和4个worker process,随便找一个进程查看:

[root@localhost ~]# cat /proc/928/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 3818 3818 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 3818 3818 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
可以看出,未配置worker_rlimit_nofile,在我的linux下open files 显示的是

Max open files 1024 4096
1
配置改写
user root;
worker_processes 4;
worker_rlimit_nofile 65535;

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;

events {
worker_connections 65535;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
主要是进行了两处改写,加上worker_rlimit_nofile 65535; 和设置worker_connections 65535;

重启nginx服务之后,再次验证。

[root@localhost nginx2]# sbin/nginx -s reload
[root@localhost nginx2]# ps -ef|grep nginx
root 927 1 0 15:32 ? 00:00:00 nginx: master process /root/hbk/nginx2/sbin/nginx
root 1098 927 2 15:52 ? 00:00:00 nginx: worker process
root 1099 927 2 15:52 ? 00:00:00 nginx: worker process
root 1100 927 2 15:52 ? 00:00:00 nginx: worker process
root 1101 927 2 15:52 ? 00:00:00 nginx: worker process
root 1103 1049 0 15:52 pts/0 00:00:00 grep –color=auto nginx
[root@localhost nginx2]# cat /proc/1100/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 3818 3818 processes
Max open files 65535 65535 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 3818 3818 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
可以看到,max open files 变成了65535了。温馨提示,在生产环境下,一定要确保Nginx工作进程的配置信息是经过优化的,否则Nginx对并发请求的处理能力将会大打折扣。
———————
作者:黄宝康
来源:CSDN
原文:https://blog.csdn.net/huangbaokang/article/details/79930189
版权声明:本文为博主原创文章,转载请附上博文链接!

[emerg]: getpwnam(“nginx”) failed

[root@localhost nginx-1.11.2]# /usr/local/nginx/sbin/nginx
nginx: [emerg] getpwnam("nginx") failed

 

没有安装nginx用户导致的无法启动

1
2
[root@localhost nginx-1.11.2]# useradd -s /sbin/nologin -M nginx
[root@localhost nginx-1.11.2]# id nginx

 

 

1
2
3
[root@localhost nginx-1.11.2]# /usr/local/nginx/sbin/nginx
[root@localhost nginx-1.11.2]# netstat -tlunp | grep nginx
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9709/nginx: master