我花了將近六個月的時間試圖解決這個問題。無論 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 天前的事，此後這台伺服器就再也沒有出現過問題。三天前，由於時間緊迫，我決定不再等待，開始一次一台關閉生產伺服器，用新編譯的版本取代 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}