如何在 Zimbra 代理伺服器中啟用 HTTPS 重新導向

使用 Zimbra 代理程式屬性zimbraReverseProxyMailMode將 Web 請求從 HTTP 重新導向到 HTTPS。在每個 Zimbra 代理節點上啟用此屬性redirect，然後重新啟動代理服務並驗證 HTTP 回應是否包含 HTTPSLocation: https://...標頭。在此之前，請確保公用 HTTPS 主機名稱已解析到您的代理程式或負載平衡器，並且具有有效的憑證。

此設定用於透過 Zimbra 代理進行 Web 存取。它本身不會配置郵件儲存的 HTTPS、安裝證書，也不會保證每個郵件應用程式都遵循重定向。如果您需要完全拒絕 HTTP 請求，請考慮使用僅限 HTTPS 的代理模式，而不是重新導向。

圖示顯示 mail.example.com 指向兩個 Zimbra 代理節點，然後這兩個節點連接到郵件伺服器。 — 拓樸結構範例：公用郵件主機名稱先到達代理層，然後請求才會傳遞到郵件伺服器。

選擇適合您部署情況的行為

代理郵件模式	HTTP會發生什麼變化？	何時使用
`redirect`	代理伺服器傳回 HTTP 302 回應，將客戶端定向到 HTTPS。	當使用者仍然輸入 HTTP URL 而應該跳到安全網址時，此功能非常有用。
`https`	代理伺服器透過 HTTPS 為 Web 用戶端提供服務；它不提供相同的 HTTP 到 HTTPS 重定向流程。	如果客戶端永遠不應該透過 HTTP 發起會話，則應優先選擇這種方式。
`both`或者`mixed`	這些是不同的代理模式，具有不同的HTTP/HTTPS行為。	僅當部署需要特定行為時才使用；不要假設它們會強制執行 HTTP 重定向。

Zimbra 的安全指南警告說，某些用戶端（包括 ActiveSync 用戶端）可能不會回應 HTTP 重定向，並可能在初始未加密請求中傳送憑證。因此，重定向有助於提升瀏覽器的便利性，但當所有用戶端都必須避免使用 HTTP 時，重定向並不能取代僅使用 HTTPS 的存取方式。如果您選擇重新導向模式，請根據需要保護網路邊緣的 HTTP 監聽器，並將 HTTPS URL 告知使用者。

瀏覽器視窗顯示 Zimbra Web Client 登入頁面（網址為 https://mail.example.com），並附有一個鎖形圖示。 — 在變更代理行為之前，請確認公用 Webmail 主機名稱透過 HTTPS 開啟並顯示受信任的鎖定指示器。

更改代理之前

確認範圍。此操作會變更 Zimbra Proxy 處理的 Web 流量。您的部署必須已啟用並正常執行代理服務。
檢查公共端點。使用者存取的主機名稱（例如mail.example.com`example.com`）必須解析到公共代理程式或負載平衡器。 HTTPS 必須在預期的主機名稱和連接埠上正常運作。
檢查證書。在重新導向使用者之前，請為公用主機名稱安裝並驗證憑證鏈。如果重定向到 HTTPS 時憑證損壞或不匹配，只會將故障轉移到下一個請求。
識別每個代理節點。在負載平衡環境中，請記錄每個代理伺服器的 Zimbra 伺服器名稱。對一個代理伺服器所做的變更不會自動配置其他代理伺服器。
如有需要，請安排維護窗口。重啟代理服務可能會短暫中斷通過該節點的連線。在冗餘部署中，請一次在一個節點上套用變更並監控服務運作狀況。

請使用 Zimbra 帳戶執行以下管理指令。請將 ` proxy1.example.com<server_name>` 替換為您的代理節點的 Zimbra 伺服器名稱，並將 `<hostname>` 替換mail.example.com為公共 Webmail 主機名稱。請勿將範例名稱直接貼到生產系統中。

啟用 HTTP 到 HTTPS 重定向

1. 記錄當前代理模式

在安裝了命令列工具的 Zimbra 主機上，查詢代理程式的目前設定：

zmprov gs proxy1.example.com zimbraReverseProxyMailMode

記錄輸出結果，以便在變更後進行比較，或在必要時恢復到先前的模式。該gs命令讀取伺服器屬性；ms下面使用的命令則修改這些屬性。

範例終端機視窗查詢 zimbraReverseProxyMailMode 以取得 proxy1.example.com 的配置，並顯示目前值為 https。 — 範例命令讀取一個代理節點上的目前郵件模式；您的伺服器可能會顯示不同的值。

2. 將代理模式設定為重新導向

設定代理伺服器物件的屬性：

zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirect

Zimbra Proxy 設定文件將此模式指定redirect為將 HTTP 請求重新導向到 HTTPS 的模式。對每個接受公共 Web 流量的代理節點套用相同的命令。如果負載平衡器可以將 HTTP 請求傳送到多個代理，則每個符合條件的代理程式都需要保持一致的行為。

請勿將此設定與zimbraMailModeZimbra 文件中單獨列出的郵件伺服器連線屬性混淆。更改郵件儲存模式並非在代理程式上啟用瀏覽器導向的 HTTP 重定向的步驟。

範例終端命令將 zimbraReverseProxyMailMode 設定為重定向到 proxy1.example.com。 — 將代理程式的郵件模式設定為`redirect`；在多節點部署中，對每個代理伺服器名稱重複此操作。

3. 將變更套用到每個代理程式。

在更改設定的節點上重啟代理服務：

zmproxyctl restart

然後檢查其服務狀態：

zmproxyctl status

在每個代理節點上執行重啟命令，如果存在冗餘層，則一次重新啟動一個節點。如果您的環境有預設的設定快取刷新或服務編排流程，請遵循已安裝的 Zimbra 版本的操作指南。避免直接編輯產生的 Nginx 檔案：Zimbra 透過其伺服器設定管理代理配置，手動編輯的內容可能會被覆蓋。

這些範例使用了 Zimbra Daffodil v10 管理指南和 Zimbra 發布的代理/安全文件。較舊的 ZCS 版本在打包方式或支援的步驟上可能有所不同，因此在進行任何變更之前，請務必查閱管理指南，確認您環境中安裝的版本與指南中的版本完全一致。

示例性終端序列，顯示 Zimbra 配置快取刷新，然後執行 zmproxyctl restart。 — 範例操作序列會重新整理設定資料並重新啟動代理程式；請依照您已安裝版本支援的步驟進行操作。

驗證重定向和 HTTPS 回應

4. 檢查 HTTP 回應頭

從能夠存取公共端點的系統中，請求HTTP URL，而不跟隨重定向：

curl -sS -D - -o /dev/null http://mail.example.com/

在重定向模式下，請尋找 302 個回應以及Location以 `.` 開頭的標頭https://mail.example.com/。具體的標頭和狀態處理可能會因 Zimbra 版本、路徑以及代理伺服器前的負載平衡器或 Web 閘道而異。以下螢幕截圖僅為預期標頭模式的範例，並非從實際伺服器擷取的測試資料。

HTTP 請求的終端輸出範例，顯示 302 Found 和指向 https://mail.example.com/ 的 Location 標頭。 — 預期重新導向模式：HTTP 傳回 302 回應，並將瀏覽器指向 HTTPS 主機名稱。實際回應頭和日期會有所不同。

5. 驗證 HTTPS 和憑證

請單獨向安全URL發出請求：

curl -sS -D - -o /dev/null https://mail.example.com/

確認 TLS 憑證對主機名稱有效，且回應是預期的 Web 郵件頁面或應用程式重新導向。請勿使用curl -k繞過憑證驗證的方法：這會掩蓋使用者會看到的憑證問題。登入頁面可能會傳回重新導向或 200 以外的狀態碼，具體取決於產品版本和驗證流程，因此請結合瀏覽器檢查結果來判斷回應。

以下是 HTTPS 請求的終端輸出範例，顯示了 mail.example.com 的成功 HTTP 回應和憑證驗證。 — 此範例顯示了使用主機名稱匹配憑證透過 HTTPS 連接到服務；請驗證您的端點上的實際憑證鏈。

6. 在瀏覽器中測試

在新瀏覽器會話中開啟此http://mail.example.com視窗。輸入憑證之前，地址應更改為 HTTPS URL。然後直接開啟 HTTPS URL，並確認登入頁面載入正常，沒有憑證警告。如果公用 DNS、防火牆規則或負載平衡器可能導致不同的結果，請在內部網路外部重複上述步驟。

請勿在網址列仍顯示 HTTP 時輸入真實密碼進行測試。如果重定向失敗，請先停止並修正代理程式、邊緣或憑證配置。

Zimbra Web Client 登入頁面顯示在瀏覽器中，網址列中顯示 https://mail.example.com 和一個鎖形圖示。 — 瀏覽器最終檢查：重定向後，登入頁面在 HTTPS 主機名稱下提供服務。

故障排除快速參考

症狀	需要檢查什麼
HTTP 協定保持在同一個 URL 上。	查詢`zimbraReverseProxyMailMode`處理請求的代理程式；驗證每個負載平衡節點是否具有預期值並已重新啟動。
Location 標頭使用了錯誤的主機名稱或端口	檢查用於產生公共連結的公共 URL、反向代理或負載平衡器規則以及 Zimbra 公共服務主機名稱/協定/連接埠設定。
瀏覽器報告憑證警告	檢查憑證是否已安裝在 TLS 終止點上，是否會覆寫公用主機名，以及是否包含必要的憑證鏈。
用戶會看到重定向循環	檢查前端負載平衡器是否終止了 TLS 連線但將 HTTP 請求轉送至 Zimbra，並確認代理伺服器能夠正確識別外部請求協定。在網路邊緣調整 TLS 和轉送配置。
郵件用戶端仍然發送HTTP	不要假設客戶端會遵循 302 重定向。對於絕對不能透過 HTTP 發送憑證的客戶端，應優先使用 HTTPS 訪問，並為每個客戶端配置 HTTPS 伺服器 URL。