我已经尝试解决这个问题将近 6 个月了。无论 Nginx 或 Ubuntu 版本如何，这个问题都会随机出现。nginx-extras 包来自 Ubuntu 存储库。这是一组具有不同硬件的 10 台服务器，它们都存在同样的问题。
简而言之：Nginx 会随机地无法重新加载。错误日志将显示它无法绑定到地址（目前发生在端口 443 上，但也会随机发生在端口 80 上）。有时发出service nginx upgrade会重新加载服务器。如果这也失败了，service nginx restart有时会成功，有时则不行。即使这失败了，重新加载配置的唯一方法是发出service nginx stop，等待几秒钟然后执行service nginx start。这些命令都不会返回错误，相反，[OK]即使命令失败，它们也会返回。
停止和启动 Nginx 是一个问题，因为这些机器正在发送大文件，传输会中断。此外，如果从后端拉取大文件进行缓存，则在重新启动期间，缓存版本最终将被损坏。
nginx version: nginx/1.4.6 (Ubuntu)
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
TLS SNI support enabled
configure arguments:
--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
--prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log
--lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--with-debug
--with-pcre-jit
--with-ipv6
--with-http_ssl_module
--with-http_stub_status_module
--with-http_realip_module
--with-http_addition_module
--with-http_dav_module
--with-http_flv_module
--with-http_geoip_module
--with-http_gzip_static_module
--with-http_image_filter_module
--with-http_mp4_module
--with-http_perl_module
--with-http_random_index_module
--with-http_secure_link_module
--with-http_spdy_module
--with-http_sub_module
--with-http_xslt_module
--with-mail
--with-mail_ssl_module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/headers-more-nginx-module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-auth-pam
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-cache-purge
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-dav-ext-module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-development-kit
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-echo
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/ngx-fancyindex
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-http-push
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-lua
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-upload-progress
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-upstream-fair
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/ngx_http_substitutions_filter_module
当前正在运行的进程：
# ps ax | grep nginx
25771 pts/1 S+ 0:00 grep --color=auto nginx
29145 ? S 0:00 nginx: master process /usr/sbin/nginx
29664 ? RN 516:47 nginx: worker process
29665 ? SN 513:46 nginx: worker process
29666 ? SN 514:17 nginx: worker process
29667 ? SN 517:24 nginx: worker process
29668 ? SN 512:29 nginx: worker process
29669 ? SN 515:28 nginx: worker process
29670 ? SN 517:52 nginx: worker process
29671 ? SN 507:52 nginx: worker process
29672 ? S 0:13 nginx: cache manager process
尝试重新加载：
# service nginx reload
* Reloading nginx configuration nginx [ OK ]
再次查看 ps 输出，什么也没有发生：
# ps ax | grep nginx
29145 ? S 0:00 nginx: master process /usr/sbin/nginx
29664 ? SN 516:54 nginx: worker process
29665 ? SN 513:49 nginx: worker process
29666 ? SN 514:20 nginx: worker process
29667 ? SN 517:27 nginx: worker process
29668 ? SN 512:34 nginx: worker process
29669 ? SN 515:31 nginx: worker process
29670 ? SN 518:08 nginx: worker process
29671 ? SN 507:55 nginx: worker process
29672 ? S 0:13 nginx: cache manager process
31121 pts/1 S+ 0:00 grep --color=auto nginx
检查错误日志（IP地址已删除）：
2018/03/10 00:22:29 [info] 32481#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:95
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: still could not bind()
唯一使用 443 的进程是 nginx 本身：
# sudo netstat -tulpn | grep :443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 29145/nginx
在这些服务器上，每个客户都有两个服务器块 - 一个公共服务器块，监听标准端口，另一个内部服务器块负责缓存。后者监听本地主机 IP 和唯一端口，并通过来自公共块的 proxy_pass 进行访问。这些内部服务器块会自行将所有 proxy_pass 阻止到另一个位置。此设置的原因太复杂，无法在此介绍。
到目前为止我已经检查了什么：
所有内部块都可以解析其上游
所有内部端口都是唯一的且未被其他服务使用
未使用 SPDY（在 Nginx 的邮件列表中发现一个报告的错误）
问题似乎是随机的，但 Nginx 实例运行的时间越长，发生的可能性就越大
该行为存在于 Ubuntu 14.04.X 和 16.04、Nginx 版本 1.4.6 至最新版本中。
与 CPU、磁盘或网络负载没有明显关系
示例服务器块，由使用这些服务器的平台自动生成（一些信息被删除）：
公有区块：
server {
keepalive_timeout 10;
listen 195.xx.xx.xx:80;
#listen 195.xx.xx.xx:80 ssl;
root /home/nginx;
server_name xxxxxx.xxxxxx.com ;
index index.php index.html index.htm index.nginx-debian.html
error_page 403 /403.html; location = /403.html {
return https://www.xxxxxx.com/403.php;
}
error_page 404 /404.html; location = /404.html {
return https://www.xxxxxx.com/404.php;
}
error_page 500 /500.html; location = /500.html {
root /home/nginx;
}
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
return 301 http://xxxxx.xxxxxxx.com$request_uri;
}
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_intercept_errors on;
proxy_buffering off;
proxy_pass http://127.0.1.3:8213;
set $sent_http_accept_ranges bytes;
}
location ~ /playlist.m3u8 {
secure_link $arg_st,$arg_e;
secure_link_md5 xxxxxxxxxxxxxxxxxxxx$uri$remote_addr$arg_e;
if ($secure_link = "") { return 403; }
if ($secure_link = "0") { return 410; }
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header geo_xxxxxx $geoip_country_code;
proxy_intercept_errors on;
proxy_buffering off;
proxy_pass http://127.0.1.3:8213;
}
#ssl_certificate /etc/letsencrypt/live//fullchain.pem; # managed by Certbot
#ssl_certificate_key /etc/letsencrypt/live//privkey.pem; # managed by Certbot
#include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
limit_rate 10000k;
}
关联的私有块：
proxy_cache_path /home/nginx/282-281-cache levels=1:2
keys_zone=282-281:5m inactive=48h max_size=500g;
limit_conn_zone $http_x_forwarded_for zone=addr282-281:10m;
map $http_user_agent $blockedUA {
default 0;
"~thisisadummyua" 1;
"~thisisanotherdummyua" 1;
}
map $http_referer $blockedREF {
default 0;
"~thisisadummyref.com" 1;
"~thisisanotherdummyref.com" 1;
}
server {
limit_conn addr282-281 100;
limit_conn_status 429;
keepalive_timeout 10;
listen 127.0.1.3:8213;
root /home/nginx;
server_name 127.0.1.3;
location ~* \.(m3u8)$ {
real_ip_header X-Forwarded-For;
set_real_ip_from xxx.xx.xx.xx/xx;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_set_header Host $proxy_host;
real_ip_recursive on;
# CORS setup
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Expose-Headers' 'Content-Length';
proxy_ignore_headers Cache-Control;
add_header Cache-Control public;
# allow CORS preflight requests
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
add_header Edge-Cache $upstream_cache_status;
proxy_cache 282-281;
proxy_cache_valid 200 206 5s;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 10s;
proxy_cache_key $uri;
proxy_pass http://xxx.xx.xx.xx:41000;
}
location / {
deny 10.10.10.1;
deny 10.10.10.2;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Expose-Headers' 'Content-Length';
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control public;
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
real_ip_header X-Forwarded-For;
set_real_ip_from xxx.xx.xx.xx/xx;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_set_header Host $proxy_host;
proxy_http_version 1.1;
real_ip_recursive on;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_no_cache $http_range $http_if_range;
proxy_cache_bypass $http_range $http_if_range;
proxy_temp_path /home/nginx/282-281-temp;
proxy_buffering on;
proxy_max_temp_file_size 25m;
proxy_intercept_errors on;
proxy_cache_purge PURGE from all;
add_header Edge-Cache $upstream_cache_status;
proxy_cache 282-281;
proxy_cache_valid 200 206 5m;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 120s;
proxy_cache_key $uri;
proxy_pass http://xxx.xx.xx.xx:41000/;
}
if ($blockedUA = 1){
return https://www.xxxxxxx.com/403.php;
}
#if ($http_user_agent = "") {
# return https://www.xxxxxxx.com/403.php;
#}
if ($blockedREF = 1){
return https://www.xxxxxxx.com/403.php;
}
access_log /var/log/nginx/xxxx/xxx-xxx-proxy-access.log xxxx;
error_log /var/log/nginx/xxxx/xxx-xxx-proxy-error.log;
}`
我现在正在考虑尝试 nginx-common 包，但这是生产系统。我不确定这个问题是否会在测试机器上出现。
编辑： 在问了这个问题之后，我决定添加一个 cron 作业，每 3 小时重新加载一次，因为我的观察是，Nginx 运行的时间越长，不重新加载，问题就越有可能出现。今天是 cron 运行的第三天，所有服务器都正确响应重新加载，但尚未发现任何服务器存在问题。充其量，这只不过是一个创可贴，并不能解决真正的问题。然而，这是我能想到的最好的办法，而且几乎是唯一似乎有效的方法。
编辑2： 添加 cron 并不能解决问题，但我不得不尝试。然后，我用最少的模块从源代码编译了 Nginx，并将其安装在其中一台服务器上。这是 7 天前的事了，从那时起这台服务器就再也没有出现过问题。由于时间紧迫，3 天前我决定不再等待，开始逐台关闭生产服务器，用新编译的版本替换它们的 Nginx。到目前为止一切顺利，它们都不再出现问题的迹象。希望我不会再回来进行第三次编辑。
答案1
这种情况时有发生。所以没什么特别的。
如果我们想重新启动或重新加载我们的服务，我们建立了以下方法：
1.检查配置是否按预期工作：
nginx -t
2. 重新启动 Nginx 并检查响应：
service nginx restart
3. 如果由于端口冲突而无法重新启动...
检查哪个服务阻塞了端口：
netstat -nltp | grep -E ':80\W|:443\W'
杀死相应服务：
killall nginx
在某些情况下，一个进程可能会被冻结。您必须使用更强大的功能来终止挂起的进程：
kill -9 {process_id}