nginx问题合集

nginx遇到的问题

Warning: nginx.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Warning: nginx.service changed on disk. Run 'systemctl daemon-reload' to reload units.

$ systemctl daemon-reload

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

# kull掉80端口
$ sudo fuser -k 80/tcp

如果提示找不到fuser命令

# 查看端口号占用情况:(6426就是进程号)
# tcp 0 0 10.65.42.27:80 172.22.142.20:62771 ESTABLISHED6426/lighttpd
$ netstat -apn|grep 80
# 查看进程号情况
$ ps -aux|grep <进程号>
# bae 6426  0.0  0.2 133724 22848 ? Sl Feb27 0:22 bin/lighttpd
# kill掉
$ kill -9 6426 

nginx: [error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)

# 加载一下配置(-c后面是配置的路径)
$ /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
# 如果配置了环境变量
$ nginx -c /usr/local/nginx/conf/nginx.conf

4.nginx: [error] invalid PID number "" in "/usr/local/webserver/nginx/logs/nginx.pid"

$ nginx -c /usr/local/nginx/conf/nginx.conf
$ nginx -s reload

nginx -s reload的时候 nginx could not build the server_names_hash you should......

在配置文件的http{}段增加一行配置
server_names_hash_bucket_size 64; 
如果64还不够,那么就按32的倍数往上加。

nginx: [emerg] getpwnam("www") failed in /usr/local/nginx/conf/nginx.conf:2

# 增加用户&用户组
$ groupadd www
$ useradd -g www www

nginx: [emerg] open() "/var/log/nginx/error.log" failed (2: No such file or directory)

$ mkdir /var/log/nginx
$ cp /usr/local/nginx/logs/error.log /var/log/nginx

413 Request Entity Too Large

在api上传图片的时候,nginx报错413请求太大

<html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.10.2</center>
</body>
</html>

解决办法,设置nginx.confclient_max_body_size参数

client_max_body_size 8m;
nginx -s reload

nginx 访问站点 File not found.

事情起因是我新增了一个用户junjia,同时在/home/junjia/www下部署了一个wanpi-back项目(laravel框架)

很奇怪一个问题,解析了一个站点 nginx 报错File not found.

nginx 配置


server {
    listen  xxxx;
    server_name localhost;
    root     /home/junjia/www/wanpi-back/public;
    index   index.php   index.html  index.htm;
    location / {
        if (!-e $request_filename) { 
            rewrite ^/(.*) /index.php last;
        }

    } 
    location ~ \.(js|css|png|jpg|jpeg|gif)$ {
        expires off;
        if (!-e $request_filename) {
            break;
        }
    }
    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

}

分析可能性

  • nginx root 目录不存在
  • nginx fastcgi_param参数不正确
  • linux 文件权限问题

linux文件权限问题

修改/home/junjia/www/wanpi-back权限

因为之前我是用root用户克隆的,所以都是root用户的

drwxr-xr-x 15 root root 4.0K 3月   7 01:03 wanpi-back
chown junjia:junjia wanpi-back -R
drwxr-xr-x 15 junjia junjia 4.0K 3月   7 01:03 wanpi-back

然后重载nginx之后还是不行

查看nginx用户组和php-fpm用户组
ps -aux | grep nginx
➜  wanpi-back git:(dev-junjia) ✗ ps -aux | grep nginx
root     14222  0.0  0.1 106404  3932 ?        Ss   3月06   0:00 nginx: master process nginx -c /etc/nginx/nginx.conf
www      17373  0.0  0.1 108132  6016 ?        S    01:02   0:00 nginx: worker process
www      17374  0.0  0.1 107612  4344 ?        S    01:02   0:00 nginx: worker process
root     24526  0.0  0.0 112676   996 pts/2    R+   01:07   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nginx
ps -aux | grep php-fpm
www       4525  0.0  1.4 761336 56340 ?        S    3月06   0:05 php-fpm: pool www
www      22298  0.0  0.6 673560 24360 ?        S    00:45   0:00 php-fpm: pool www
www      28984  0.0  1.3 673924 52332 ?        S    3月06   0:04 php-fpm: pool www
root     31671  0.0  1.9 670336 75680 ?        Ss   3月06   0:02 php-fpm: master process (/etc/php-fpm.conf)
www      31697  0.0  1.3 762916 53248 ?        S    3月06   0:05 php-fpm: pool www
www      31698  0.0  1.4 758816 56812 ?        S    3月06   0:06 php-fpm: pool www
www      31699  0.0  1.4 761148 57840 ?        S    3月06   0:05 php-fpm: pool www
www      31700  0.0  1.3 759012 54184 ?        S    3月06   0:05 php-fpm: pool www
www      31701  0.0  1.3 759096 53912 ?        S    3月06   0:05 php-fpm: pool www

这里看到我是用的www用户在跑nginx和php-fpm

重新修改权限

因为这里都是以www用户和www用户组运行的服务,所以要重新修改权限

这里我修改为junjia用户和www用户组都有操作文件的权限

chown junjia:www wanpi-back -R
drwxr-xr-x 15 junjia www 4.0K 3月   7 01:03 wanpi-back

然后还是不行...

查看文件访问权限

Emmm.....没有权限

sudo -u www stat /home/junjia/www/wanpi-back
stat: 无法获取"/home/junjia/www/wanpi-back" 的文件状态(stat): 权限不够
改变思路利用软连接

/mnt/jinjua/下克隆一个wanpi-back项目,并看www用户是否有权限,如果有,就软连到/homt/junjia/www下面

sudo -u www stat /mnt/junjia/wanpi-back
  文件:"/mnt/junjia/wanpi-back"
  大小:4096       块:8          IO 块:4096   目录
设备:fd01h/64769d Inode:929253      硬链接:15
权限:(0755/drwxr-xr-x)  Uid:( 1001/  junjia)   Gid:( 1000/     www)
最近访问:2018-03-06 17:18:50.445897175 +0800
最近更改:2018-03-06 17:16:30.072216588 +0800
最近改动:2018-03-06 17:16:30.072216588 +0800
创建时间:-
ln -s /mnt/junjia/wanpi-back /home/junjia/www
chown junjia:www wanpi-back -R

# 以后junjia用户创建的文件或文件夹都继承了www用户组,而不是junjia
sudo chmod g+s /var/www -R
修改nginx root目录

我发现用虽然设置了软连接,但是nginx root用/home/junjia/www/wanpi-back/public还是不行的

root     /mnt/junjia/wanpi-back/public;
nginx -s reload

终于能访问了~~ Haaaaaaa

nginx解析react项目,刷新页面404

如果你使用了React-Router的browserHistory 模式,请在Nginx配置中加入如下配置

location / {
    //....
    try_files $uri $uri/ /index.html;
}

原理,因为我们的项目只有一个根入口,当输入类似/home的url时,找不到这个页面,这是,nginx会尝试加载index.html,加载index.html之后,react-router就能起作用并匹配我们输入的/home路由,从而显示正确的home页面,,如果browserHistory模式的项目没有配置上述内容,会出现404的情况。

nginx gzip压缩

file

nginx里面也开启了gzip

gzip on;

文件实际大小

总用量 1.6M
-rw-r--r-- 1 nobody nobody 910K 1月  13 00:05 app.js
-rw-r--r-- 1 nobody nobody 1.1K 12月 17 13:42 article.js
-rw-r--r-- 1 nobody nobody 686K 1月  22 10:15 echarts.min.js

大家这里看到了,实际上资源并没有走压缩,为什么呢,其实这里还缺一个很重要的参数,那就是gzip_types,因为,你开启了gzip,最后你并没有指定那些文件要走压缩,自然并不会走压缩

nginx中关键配置

gzip on;
gzip_types text/plain. application/javascript application/x-javascript text/css application/xml text/javascript application/json application/x-httpd-php   text/xml  application/xml+rss image/jpg image/gif image/png;

这里列很多类型

压缩类型,默认就已经包含text/html,所以下面就不用再写了,写上去也不会有问题,但是会有一个warn。

重载nginx

nginx -s reload

file

nginx: [emerg] bind() to 0.0.0.0:80 failed (13: permission denied)

所有用户都可以运行(因为是755权限,文件所有者:root,组所有者:root)

chown root:root nginx
chmod 755 nginx
chmod u+s nginx

参考文章

Laravel框架路由403

url

http://xxx.com/app_web/feedback

改动前 public 资源目录结构

├── app_web
│   ├── css
│   │   └── common.css
│   ├── images
│   │   ├── arrow.png
│   │   ├── close.png
│   │   ├── download.png
│   │   ├── download2.png
│   │   ├── enjoy.png
│   │   ├── haolihai.png
│   │   ├── timeroff.png
│   │   ├── upload.png
│   │   └── wallpaper.png
│   └── js
│       └── index.js

改动后 public 资源目录结构

├── app_web
│   └── feedback
│       ├── css
│       │   └── common.css
│       ├── images
│       │   ├── arrow.png
│       │   ├── close.png
│       │   ├── download.png
│       │   ├── download2.png
│       │   ├── enjoy.png
│       │   ├── haolihai.png
│       │   ├── timeroff.png
│       │   ├── upload.png
│       │   └── wallpaper.png
│       └── js
│           └── index.js

然后访问就出现403

问题是nginx的目录映射.. 刚好我在public下面有一个 app_web/feedback目录

然后路由也是这个..所以.. nginx发现有这个文件夹..就不会去走动态php了..然后我又没有指定访问文件..自然就403了

所有只需要把静态资源放在asset目录下即可

Nginx could not build the server_names_hash

could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

在给nginx 配置了一个超长的域名后导致的

# 该数值是32的倍数为宜
server_names_hash_bucket_size 64;

一次proxy_pass的错误

我们的文件在云存储上.. 然后CDN的回源地址.. 我们不能直接写云存储的地址(虽然云是开放的).. 写自己的地址..方便控制一点

所以这里我用了nginx反向代理

file

最后出现问题是nginx 404

反代代码

location ~ \.(mp4|mp3|json|png)$ {
        proxy_pass http://lq-test.pek3a.qingstor.com;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_buffer_size          4k;
        proxy_buffers              4 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;
}

解决第一步 开启debug日志

注意这里debug 只能用于error_log. 并且nginx编译参数需要开启 --with-debug

server{
    //.....
    error_log /var/log/nginx/leqv_file_server.error.log debug;
    access_log /var/log/nginx/leqv_file_server.access.log;
    //....
}
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "Cache-Control: max-age=0"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "Upgrade-Insecure-Requests: 1"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "Accept-Encoding: gzip, deflate"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header: "Accept-Language: zh-CN,zh;q=0.9"
2018/10/24 00:27:11 [debug] 22362#22362: *71900 http proxy header:
"GET /uploads/music.mp3 HTTP/1.0
Host: leqv_file_server.develop.bestdjb.com
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

大家注意这一行 这里他居然访问了 leqv_file_server.develop.bestdjb.com 域名,也就是说他访问的是 leqv_file_server.develop.bestdjb.com/uploads/music.mp3

"GET /uploads/music.mp3 HTTP/1.0
Host: leqv_file_server.develop.bestdjb.com

修改host

所以这里修改反代host,不能是$host(代表当前域名),而要写 要转向的地址

proxy_set_header   Host             lq-test.pek3a.qingstor.com;

[error] PHP message: PHP Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

2019/01/22 22:48:57 [error] 2493#2493: *100058 FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: failed to open stream: Permission denied in Unknown on line 0
Unable to open primary script: /data/www-data/lumen/public/index.php (Permission denied)" while reading response header from upstream, client: 192.168.56.100, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.56.100"
2019/01/22 22:48:57 [info] 2493#2493: *100058 client 192.168.56.100 closed keepalive connection
Connection to 192.168.56.100 closed by remote host.
Connection to 192.168.56.100 closed.

一般是有以下四点造成的

  • 9000端口被占用或被禁止(No)
  • 缺少索引文件(No)
  • 权限问题(No)
  • SELinux状态(Yes)

冷门的SELinux状态

其他的都很好排查,唯独这个很难遇到,,因为太冷门了

查看当前selinux的状态
/usr/sbin/sestatus
发现 SELinux status: enabled
将SELINUX=enforcing 修改为 SELINUX=disabled 状态
vi /etc/selinux/config
#SELINUX=enforcing
SELINUX=disabled
reboot

connect() to 127.0.0.1:5051 failed (13: Permission denied)

2019/04/03 03:39:28 [crit] 31415#0: *12 connect() to 127.0.0.1:5051 failed (13: Permission denied) while connecting to upstream, client: 61.48.58.165, server: xx.xx.com, request: "GET /poweredby.png HTTP/1.1", upstream: "http://127.0.0.1:5051/poweredby.png", host: "xx.xx.com", referrer: "http://xxx.xxx.com/"
[root@cs1551675380142 ~]# getenforce
Enforcing
[root@cs1551675380142 ~]# setenforce 0
[root@cs1551675380142 ~]# getenforce
Permissive

网上还有一种说法,在此记录下。执行下面的命令

setsebool -P httpd_can_network_connect 1