在 Nginx 前置 Apache 時如何配置 HTTPS 重新導向

若要獲得最可靠的 HTTPS 重新導向效果，最佳實務是讓 Nginx 統一處理 HTTPS 以及所有 HTTP 到 HTTPS 的重新導向，特別是在為 美國伺服器租用 環境提供前端代理時。Apache 只需信任代理標頭，就能正確辨識協定類型，從而避免重新導向循環。常見的重新導向循環原因包括：

1. 在多層環境中錯誤配置 SSL 或 HTTPS

2. 反向代理或 CDN 配置錯誤

3. 平台或框架特定的錯誤

4. www 與非 www 網域版本規則衝突

5. 過期或異常的 Cookie 或瀏覽器快取

6. HSTS（HTTP 嚴格傳輸安全）策略問題

業界通行作法是：將所有網域統一重新導向到 HTTPS，為不同網域使用獨立的 server 區塊，並檢查諸如 X-Forwarded-Proto 之類的請求標頭，以確保流量在安全通道中傳輸。

要點速覽

• 使用 Nginx 統一處理 HTTPS 以及 HTTP 到 HTTPS 的重新導向，以獲得更佳的安全性與效能。

• 務必從 Nginx 向 Apache 轉送正確的代理標頭，避免重新導向循環並確保紀錄檔（log）記錄精準。

• 透過 Certbot 安裝 SSL 憑證並啟用自動續期，確保連線始終安全。

• 在 Nginx 中配置 301 重新導向，強制所有流量使用 HTTPS，有助於 SEO 與使用者信任。

• 定期測試配置並監控問題，例如重新導向循環以及混合內容（Mixed Content）警示。

Nginx + Apache 反向代理架構

反向代理情境下的 HTTPS 運作方式

當你使用 Nginx 作為 Apache 前端的反向代理時，就建立了一套強大而彈性的 Web 服務堆疊。在這種架構中，Nginx 會接收所有來自使用者的請求：它會直接提供靜態檔案（如圖片、CSS），而動態內容請求則轉送給 Apache。Apache 處理完請求後，將結果回傳給 Nginx，再由 Nginx 回應給使用者。如此可以顯著減輕 Apache 的負載，並讓你更輕鬆地水平擴充後端伺服器。

將 HTTPS 交由 Nginx 處理，你可以獲得多方面的好處：

• Nginx 充當前端「防護盾」，隔離使用者與後端伺服器，增強整體安全性。

• 只需在 Nginx 一處管理 SSL 憑證，更新與續期都更簡單。

• 後端 Apache 僅需使用一般 HTTP，減少加解密負擔，進而提升效能。

• 許多產業專家都建議在代理層終止 HTTPS，以兼顧安全與速度。

流量路徑與代理請求標頭

為了確保站點安全並避免重新導向循環，你必須從 Nginx 向 Apache 轉送正確的請求標頭。這些標頭資訊協助 Apache 瞭解原始請求的細節，例如使用的協定以及用戶端 IP 位址。若缺少這些資訊，Apache 可能無法判斷請求是否來自 HTTPS，進而導致重新導向或紀錄檔異常。

以下是你應當轉送的重要代理請求標頭列表：

提示：務必檢查你的 Nginx 配置，確認上述這些請求標頭已正確設定。這能協助 Apache 辨識 HTTPS 請求，讓重新導向邏輯穩定可靠。

配置 HTTPS 重新導向前的準備工作

所需軟體與存取權限

開始之前，請確保你擁有正確的工具和足夠的權限。伺服器上需要同時安裝並執行 Nginx 和 Apache。你還需要透過 SSH 登入伺服器終端機，並具備 root 或 sudo 權限，才能修改配置檔與重新啟動服務。否則，將無法完成整套部署。

以下是一份簡要檢查清單，協助你確認環境就緒：

• Nginx 已安裝並作為反向代理執行

• Apache 已安裝並作為後端伺服器執行

• 可以存取伺服器終端機（SSH）

• 擁有編輯配置檔與重啟服務的 root 或 sudo 權限

• 有一個已解析到伺服器 IP 的網域名稱

提示：在修改任何配置檔之前，務必先做好備份。一旦出現問題，備份可以協助你快速恢復網站服務。

SSL 憑證與自簽憑證選項

要保護站點安全，你需要一張 SSL 憑證。可以選擇由權威 CA（憑證頒發機構）簽發的商業憑證，也可以使用自簽憑證。兩者各有適用情境與優缺點。

• 自簽憑證適合個人專案或內部測試環境。它們在加密層面是安全的，但瀏覽器不會信任，若用於公開網站，將顯示警告。

• 由 CA 簽發的憑證既能加密傳輸，又能驗證伺服器身分，這種信任對面向大眾的站點至關重要。

• 自簽憑證會觸發瀏覽器安全警告，使用者必須主動「接受風險」才能繼續瀏覽，這對電商或企業網站極為不利。

• 商業憑證可以消除瀏覽器警告，讓使用者更容易信任你的網站。

在 Nginx + Apache 架構下管理憑證時，你應確保憑證在到期前完成續期。最佳實務是：產生新的 CSR（憑證簽署要求），提交給 CA，安裝更新後的憑證並重新啟動服務。將此流程自動化可以節省時間並持續保障安全。

注意：在 Nginx 中使用獨立的 server 區塊來處理 HTTP 到 HTTPS 的重新導向。此作法高效、清晰且可靠。

Nginx 中的 HTTPS 重新導向配置

在 Nginx 中配置 HTTPS 並管理重新導向，是建構安全、穩定 Web 服務的關鍵步驟。你可以透過 Nginx 虛擬主機配置（server 區塊）控制伺服器如何處理請求以及如何轉送到 Apache。本節將引導你完成啟用 HTTPS、設定 HTTP 到 HTTPS 重新導向以及轉送代理請求標頭。

在 Nginx 中啟用 HTTPS

你需要在 Nginx 中啟用 HTTPS 來保護網站流量。此過程透過 SSL 憑證加密伺服器與訪客之間的資料傳輸。請依照以下步驟設定：

1. 安裝 Certbot 並取得免費 SSL 憑證
   Certbot 可以協助你從 Let’s Encrypt 取得並安裝 SSL 憑證。執行以下指令：

   sudo apt install certbot python3-certbot-nginx
   sudo certbot --nginx -d example.com -d www.example.com
   

2. 為 HTTPS 配置 server 區塊
   編輯 Nginx 配置檔，為 HTTPS 新增一個 server 區塊：

   server {
       listen 443 ssl http2;
       listen [::]:443 ssl http2;
       server_name example.com www.example.com;
       root /var/www/example.com/html;
       index index.html;
       ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
       # Additional settings...
   }
   

3. 重新啟動 Nginx
   儲存修改後，重新啟動 Nginx 讓配置生效：

   sudo systemctl restart nginx
   

提示：務必檢查 SSL 憑證路徑與檔案權限。若路徑或權限錯誤，Nginx 可能無法順利啟動。

從 HTTP 重新導向到 HTTPS

為確保所有存取都使用加密連線，你必須將 HTTP 請求重新導向到 HTTPS。這一步可以防止使用者透過不安全的連線存取站點。建議使用 301 重新導向，向瀏覽器宣告此變更為永久性。

在 Nginx 中設定重新導向的方法如下：

• 新增一個監聽 80 連接埠（HTTP）的 server 區塊，並回傳 301 重新導向到 HTTPS：

  server {
      listen 80;
      server_name example.com www.example.com;
      location / {
          return 301 https://$server_name$request_uri;
      }
  }
  

• 你也可以使用一個預設的 server 區塊來攔截所有 HTTP 流量並統一重新導向：

  server {
      listen 80 default_server;
      server_name _;
      return 301 https://$host$request_uri;
  }
  

上述配置能確保到你站點的每一個請求最終都透過 HTTPS 存取。301 永久重新導向對搜尋引擎最佳化（SEO）友善，也能提升使用者信任感。

注意：修改後務必測試 HTTP 到 HTTPS 的重新導向。可透過瀏覽器或 curl 工具驗證 HTTP 請求是否收到 301 並跳轉到正確的 HTTPS 位址。

將代理請求標頭轉送給 Apache

當 Nginx 作為反向代理時，必須向 Apache 轉送關鍵請求標頭。這些標頭資訊協助 Apache 偵測原始協定、用戶端 IP 等細節。若缺失，Apache 可能無法判斷請求是否源自 HTTPS，進而導致重新導向循環或紀錄檔錯誤。

在 Nginx HTTPS 的 server 區塊中新增如下配置：

location / {
    proxy_pass http://127.0.0.1:8080;
    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 X-Forwarded-Proto $scheme;
}

• proxy_set_header X-Real-IP $remote_addr; 將真實用戶端 IP 傳遞給 Apache。

• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 保留代理鏈上的所有用戶端 IP。

• proxy_set_header X-Forwarded-Proto $scheme; 告訴 Apache 原始請求使用的是 HTTP 還是 HTTPS。

⚠️ 安全警示：
務必仔細檢查反向代理請求標頭配置。若 proxy_pass 設定錯誤或缺少關鍵請求標頭，可能會洩露敏感資訊，甚至讓攻擊者存取本應受限的後端服務。無效的 HTTP 請求可能繞過安全策略並暴露後端回應（包含機密標頭資訊）。請妥善保護配置檔，切勿直接對外提供存取。

透過轉送這些請求標頭，你可以協助 Apache 做出正確的重新導向與紀錄檔判斷。這一步對實現穩定的 HTTP 到 HTTPS 重新導向以及整體安全性至關重要。

彙總表：Nginx 配置 HTTPS 重新導向的關鍵步驟

完成以上配置後，你就建立了一套安全、高效且可靠的 Web 服務架構，也能避免諸如重新導向循環和混合內容等常見問題。在正式上線前，請務必反覆檢查配置並進行充分測試。

Apache 配置：避免重新導向循環

當 Apache 位於 Nginx 之後執行時，你必須配置 Apache 以識別原始用戶端資訊並正確處理重新導向。這有助於防止重新導向循環，並確保任何形式的重新導向（包含 301 永久重新導向）都能如預期運作。同時也能提升安全性並維持紀錄檔的準確性。

在 Apache 中信任代理請求標頭

Apache 預設不會自動信任來自 Nginx 的代理請求標頭。你需要啟用並配置 mod_remoteip 模組。此模組協助 Apache 從代理標頭中讀取真實用戶端 IP 與協定。若不執行這一步，Apache 會認為所有請求都來自代理伺服器本身，從而破壞重新導向邏輯，並影響安全策略。

你可以透過在 Apache 配置中加入如下內容來啟用並設定 mod_remoteip：

# Enable mod_remoteip
LoadModule remoteip_module modules/mod_remoteip.so

# Trust proxy headers from Nginx
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1

# Trust the protocol header
RemoteIPProtocolHeader X-Forwarded-Proto

• mod_remoteip 模組會從 HTTP 請求標頭中擷取真實 IP 位址，這對透過代理存取的請求尤為重要。

• 此模組內建一定的檢查邏輯，以降低 IP 偽造風險，協助 Apache 以真實用戶端 IP 進行存取控制。

• 啟用後，mod_remoteip 會將遠端位址替換為真實用戶端 IP，使 Apache 能夠正確處理請求與重新導向。

提示：修改配置後務必重新啟動 Apache，確保新設定生效。

使用 ProxyPassReverse 處理重新導向

當 Apache 作為後端伺服器使用時，經常會配置一些伺服端重新導向邏輯。ProxyPassReverse 指令可以協助 Apache 重寫 HTTP 回應標頭中的 URL。這對避免重新導向循環並確保所有重新導向指向正確位址至關重要。

下面的表格簡要說明了 ProxyPassReverse 指令：

ProxyPassReverse 會重寫回應標頭中的 Location、Content-Location 和 URI 等欄位裡的 URL。唯有如此，Apache 作為反向代理時，才能避免重新導向循環，同時確保後端返回的重新導向位址對用戶端來說是正確的。

要在 Apache 中配置一個能正常工作的伺服端重新導向情境，可依照以下步驟操作：

1. 透過 ProxyPass "/app/" "http://127.0.0.1:8080/" 設定代理。

2. 新增 ProxyPassReverse "/app/" "http://127.0.0.1:8080/" 來處理重新導向。

3. 如此一來即可確保後端 Apache 產生的任何重新導向，都被正確重寫成用戶端可見的 URL。

注意：在使用 ProxyPass 時，務必搭配 ProxyPassReverse 一起使用。這樣才能確保重新導向位址精準，避免讓使用者感到困惑。

Apache HTTPS 虛擬主機配置範例

在 Nginx 前置的情境中，你仍然需要合適的 Apache VirtualHost 配置，來處理 Nginx 轉送過來的請求。這可以協助 Apache 安全地處理請求，並在內部正確處理各種重新導向。

下面是一個範例表格，展示多網域配置時可能涉及的參數：

下方則是在 Nginx 之後執行的 Apache 虛擬主機範例配置：

<VirtualHost *:80>
    ServerName example.com
    # Redirect all HTTP to HTTPS
    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:8080>
    ServerName example.com
    DocumentRoot /var/www/example.com/html

    # Trust proxy headers
    RemoteIPHeader X-Forwarded-For
    RemoteIPTrustedProxy 127.0.0.1
    RemoteIPProtocolHeader X-Forwarded-Proto

    # Proxy settings
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

    # Logging
    LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    CustomLog /var/log/apache2/access.log combined
</VirtualHost>

此配置確保 Apache 信任來自 Nginx 的代理標頭，正確處理伺服端重新導向並重寫 URL。同時也在 80 連接埠上配置了一個從 HTTP 到 HTTPS 的 301 永久重新導向。如此一來，不僅提升整體安全性，也能有效避免重新導向循環，讓瀏覽體驗更加順暢。

⚡ 修改配置後請務必進行測試。利用 curl 或瀏覽器檢查每一次重新導向是否正常，並確認 Apache 紀錄檔中記錄的用戶端 IP 和協定是否準確。

測試與排查 HTTP 到 HTTPS 重新導向

驗證重新導向與 SSL 狀態

你需要確認 HTTPS 部署和重新導向規則是否依照預期運作。首先，檢查每一個 HTTP 請求是否都能收到 301 跳轉，並最終存取 HTTPS 版本。你可以透過瀏覽器開發者工具或 curl 指令檢視狀態碼，確保跳轉指向正確的目標位址。同時，還要檢查 SSL 憑證是否有效並被主流瀏覽器信任。

下表列出了一些在反向代理環境中測試 SSL 與重新導向行為的最佳實務：

此外你還應：

• 監控憑證到期時間，並在到期前至少 30 天設定警示。

• 在每次更新或修改配置後重新測試。

• 將憑證續期流程自動化，確保持續的安全性。

修復常見問題（循環重新導向、混合內容）

重新導向循環與混合內容錯誤會嚴重影響站點可用性。若遇到持續不斷的重新導向，首先嘗試清除瀏覽器 Cookie 與快取。損壞或過期的登入／工作階段 Cookie 往往會觸發這類問題。同時，伺服器配置錯誤或不當的 HTTPS 重新導向規則也可能造成循環。

你可以依照以下步驟排查：

1. 清除瀏覽器資料，移除過期 Cookie。

2. 檢查伺服端重新導向規則是否存在衝突。

3. 使用瀏覽器開發者工具檢視網路請求，分析重新導向鏈路。

4. 檢查伺服器紀錄檔，留意重複出現的重新導向項目。

混合內容（Mixed Content）警示出現在 HTTPS 頁面載入了 HTTP 資源時。要修復此問題，應將所有資源連結更新為 HTTPS。某些外掛或第三方服務也可能引發重新導向或混合內容異常，若問題持續，請一併排查這些元件。

上線前檢查清單

在正式對外提供服務之前，可以使用以下清單確保部署順利：

• 測試所有 HTTP 到 HTTPS 的重新導向，確認 301 永久重新導向正常運作。

• 驗證 SSL 憑證是否有效，並在各主流瀏覽器中無安全警告。

• 檢查所有伺服器及應用層重新導向規則，避免彼此衝突。

• 監控憑證到期時間並啟用自動續期機制。

• 檢查是否存在混合內容，確保所有資源透過 HTTPS 載入。

• 分析伺服器紀錄檔，留意異常的重新導向模式。

• 確認安全回應標頭與代理請求標頭已正確設定。

✅ 透過細緻的測試與持續監控，你可以在確保安全性的同時，為使用者提供順暢、可信賴的瀏覽體驗。

你可以依照以下步驟保護站點安全並避免重新導向循環：

1. 使用 sudo apt install certbot python3-certbot-nginx -y 安裝 Certbot。

2. 使用 Certbot 取得免費的 SSL 憑證。

3. 驗證站點是否可以透過 HTTPS 正常存取，並且 HTTP 會自動重新導向到 HTTPS。

4. 設定憑證自動續期。

將重新導向邏輯集中由 Nginx 管理，可以避免多處規則衝突，從而保障流量安全。搭配上方的檢查清單與疑難排解建議，可以協助你完成一次平穩順暢的上線流程。

常見問題（FAQ）

什麼是 TLS？在 Nginx + Apache 中為什麼需要它？

TLS 透過加密伺服器與訪客之間的資料，保護你的网站安全。使用 TLS 可以防止攻擊者竊聽或竄改傳輸內容。Nginx 和 Apache 都支援 TLS，但在 Nginx 前置 Apache 的架構中，通常建議由 Nginx 統一處理 TLS，以獲得更佳效能與更簡便的憑證管理。

HSTS 如何提升你的 HTTPS 重新導向方案？

HSTS 會告訴瀏覽器在存取你的網站時必須使用 HTTPS。一旦設定了 HSTS 回應標頭，即使使用者手動輸入 http://，瀏覽器也會自動升級為 HTTPS。HSTS 與 TLS 搭配使用，可以防止降級攻擊與中間人攔截，進一步提升整體安全性。

是否需要同時在 Nginx 和 Apache 上開啟 HSTS？

在這種架構下，只需要在 Nginx 中設定 HSTS 回應標頭即可。因為 TLS 終止點在 Nginx，由它將 HSTS 標頭傳送給瀏覽器即可。Apache 不直接處理 TLS 時，無需再單獨設定 HSTS，從而簡化整體配置。

若錯誤配置 TLS 或 HSTS 會出現哪些問題？

如果 TLS 或 HSTS 配置不當，使用者可能會看到安全警告，或陷入重新導向循環。嚴重時還可能暴露敏感資料。每次修改 TLS 或 HSTS 配置後，都要進行充分測試，並借助線上工具檢查 HSTS 標頭與 TLS 配置是否合理。

如何在 Nginx 中啟用 HTTP Strict Transport Security？

你可以在 Nginx 的 server 區塊中新增 HSTS 標頭，如：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

如此便啟用了 HTTP Strict Transport Security。它與 TLS 搭配使用，強制瀏覽器在存取你的主網域和所有子網域時都使用 HTTPS。