身為網站管理員或 DevOps/SRE 人員，Nginx 無疑是我們最得力的助手之一，然而在日常維護或修改 Nginx 設定檔 (config) 時，我們有時會遇到一些警告 (warn) 訊息。
雖然警告不至於讓 Nginx 停止運作，但它們往往暗示著設定檔存在潛在問題或不一致性。
最近，你可能在重啟 Nginx 服務 ( nginx -s reload 或 systemctl restart nginx ) 時，在日誌或終端機上看到了類似以下的警告訊息：
nginx: [warn] protocol options redefined for 0.0.0.0:443 in /etc/nginx/sites-enabled/test:5
nginx: [warn] protocol options redefined for [::]:443 in /etc/nginx/sites-enabled/default:28
nginx: [warn] protocol options redefined for [::]:443 in /etc/nginx/sites-enabled/web:5這則 [warn] protocol options redefined 警告是什麼意思？它會造成什麼影響？又該如何一勞永逸地解決它呢？本篇文章將帶你深入探討這個問題的根本原因，並提供清晰的解決步驟。
警告的核心原因：重複定義
Nginx 跳出此警告訊息，核心問題非常明確：「同一個監聽埠 (Port) 上的協定選項 (protocol options) 被重新定義了。」
簡單來說，Nginx 發現在多個設定檔（或同一個設定檔的多個地方）中，你都監聽了相同的 IP 位址和埠組合（例如 0.0.0.0:443 或 [::]:443），但是卻為它們提供了不同的協定參數。
最常見的例子就是 ssl 或 http2 參數。
在 Nginx 中，listen 指令用於指定伺服器監聽的 IP 和埠。當我們設定 HTTPS 服務時，通常會這樣寫：
listen 443 ssl http2;
listen [::]:443 ssl http2;這裡的 ssl 和 http2 都是協定選項，它告訴 Nginx 在這個埠上要啟用 SSL/TLS 協定並支援 HTTP/2。
問題情境模擬
假設你有兩個網站設定檔：site-a.conf 和 site-b.conf，它們都需要在 443 埠上提供 HTTPS 服務。
情境一：參數不一致（例如：http2 參數不一致）
- 在
site-a.conf中，你寫了：server { listen 443 ssl http2; # 啟用了 SSL 和 HTTP/2 server_name a.example.com; # ... 其他設定 } - 在
site-b.conf中，你雖然也啟用了 SSL，但忘了加上http2：server { listen 443 ssl; # 只啟用了 SSL server_name b.example.com; # ... 其他設定 }
當 Nginx 加載設定時，它首先看到 443 埠需要 ssl 和 http2。接著，它又看到同一個 443 埠（在沒有指定 IP 的情況下，443 等同於 0.0.0.0:443）只需要 ssl。Nginx 對此感到困惑——同一個埠，協定到底要不要啟用 HTTP/2？因此，它會發出 protocol options redefined 警告，並通常會採用它讀取到的第一個設定（在這個例子中是 ssl http2）。
情境二：IPv4 和 IPv6 設定不一致
這也是一個常見的陷阱。你可能在一個檔案中同時監聽了 IPv4 和 IPv6：
- 在
default.conf中：server { listen 443 ssl; # 監聽 IPv4 listen [::]:443 ssl; # 監聽 IPv6 server_name default.example.com; # ... } - 在
another-site.conf中，你可能只設定了 IPv4：server { listen 443 ssl; # 同樣監聽 IPv4 server_name another.example.com; # ... }
在這種情況下，listen 443 ssl; 在兩個檔案中被重複定義了。雖然它們的設定 ( ssl ) 是一致的，但 Nginx 仍然會警告你，因為它在不同的地方看到了對同一個監聽對象的定義。
更糟的是，如果你在 another-site.conf 中這樣寫：
listen [::]:443; # 忘了加 ssl那麼 Nginx 就會明確地警告你 [::]:443 的協定選項被重新定義了（從 ssl 變成了「沒有 ssl」）。
解決方案：保持設定一致性
要排除此問題，我們的目標是確保所有監聽同一個 IP 和埠組合的 listen 指令，都具有完全一致的協定選項。
步驟一：全局搜索監聽埠
首先，你需要找出所有正在監聽 443 埠（或其他出現警告的埠）的設定檔。在 Nginx 的設定目錄中（通常是 /etc/nginx/）執行：
grep -r "listen 443" /etc/nginx/這會列出所有 sites-enabled、sites-available、conf.d 或主設定檔 nginx.conf 中提到 listen 443 的地方。
步驟二：檢查 IPv4 (0.0.0.0:443 或 443)
檢查所有 listen 443 或 listen 0.0.0.0:443 的地方。
- 錯誤範例：
- 檔案 A:
listen 443 ssl http2; - 檔案 B:
listen 443 ssl;
- 檔案 A:
- 修正方式： 確保它們 全部 都是
listen 443 ssl http2;（或者全部都是listen 443 ssl;，取決於你的需求）。
步驟三：檢查 IPv6 ([::]:443)
同樣地，檢查所有 listen [::]:443 的地方。
- 錯誤範例：
- 檔案 A:
listen [::]:443 ssl; - 檔案 B:
listen [::]:443;
- 檔案 A:
- 修正方式： 確保它們 全部 都是
listen [::]:443 ssl;。
步驟四：(推薦) 使用 default_server 整合
一個更乾淨的做法是，只在一個「預設」的 server 區塊中定義一次監聽選項，特別是當你使用 ssl、http2 或 quic 等參數時。
你可以建立一個專門處理 SSL 參數的設定檔，例如 /etc/nginx/conf.d/ssl_params.conf，或者在你的預設網站設定檔 (default.conf) 中這樣定義：
server {
# 這是 IPv4 的預設 SSL 伺服器
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server; # 這是 IPv6 的預設 SSL 伺服器
# 綁定一個預設的 server_name
server_name _;
# 包含通用的 SSL/TLS 設定
include /etc/nginx/snippets/ssl-params.conf;
# 可以返回一個錯誤或拒絕連線
return 444;
# 或者，如果你想讓它作為一個備用網站
# root /var/www/html;
}
然後，在你其他的網站設定檔中 (site-a.conf, site-b.conf…)：
# site-a.conf
server {
# 這裡不再需要 'ssl', 'http2' 等參數
# 因為 Nginx 知道 443 埠已經在處理 SSL 了
listen 443;
listen [::]:443;
server_name a.example.com;
# ... 針對 a.example.com 的特定設定
}
# site-b.conf
server {
listen 443;
listen [::]:443;
server_name b.example.com;
# ... 針對 b.example.com 的特定設定
}透過使用 default_server，你等於告訴 Nginx：「嘿，所有到 443 埠的 ssl 流量都先由這個 server 區塊處理協定。」接著 Nginx 會根據請求的 Host 標頭（即 server_name）來決定要將請求路由到哪一個具體的 server 區塊。
這樣做，ssl 參數只被定義了一次，[warn] protocol options redefined 警告自然就消失了。
結論
Nginx 的 [warn] protocol options redefined 警告雖然不會導致服務中斷，卻是設定檔不夠嚴謹的訊號。提醒我們對於同一個監聽 IP 和埠，Nginx 希望提供一致的協定定義。
透過仔細排查所有 listen 指令，確保 ssl、http2 等參數在所有相關的定義中保持一致，或者採用 default_server 的方式來集中管理這些協定選項，我們就能輕鬆消除這個警告，讓 Nginx 設定檔保持乾淨、高效且易於維護。
