HTTP 自動轉 HTTPS 怎麼做？掌握 301 轉址與 HSTS 設定

HTTP 自動轉 HTTPS 的正確做法

HTTP 自動轉 HTTPS 的核心做法，是讓網站同時保留 80 Port 與 443 Port：80 Port 接收使用者原有的 HTTP 請求，再以伺服器端 301 永久重新導向至相同網址的 HTTPS 版本；443 Port 則負責提供已安裝有效 SSL/TLS 憑證的加密內容。轉址完成且確認網站運作正常後，再啟用 HSTS，要求瀏覽器後續直接使用 HTTPS。一般不建議直接關閉 80 Port，否則輸入舊網址、點擊歷史連結或使用尚未更新書籤的訪客，可能只會看到連線失敗，而不是自動前往安全網站。

正確順序應為：先安裝有效憑證、建立 HTTPS 繫結、修正網站內部資源、設定 HTTP 轉 HTTPS、測試各類網址，最後才啟用 HSTS。如此不但能降低資料遭攔截或竄改的風險，也能統一搜尋引擎收錄網址，避免 HTTP 與 HTTPS 版本分散 SEO 訊號。

80 Port、443 Port 與 HTTPS 的關係

80 Port 與 443 Port 的服務定義

80 Port 通常提供 HTTP 服務，傳輸內容本身沒有經過 TLS 加密。帳號、密碼、Cookie、查詢內容及表單資料若透過 HTTP 傳送，可能在不安全網路環境中遭到監看或修改。

443 Port 通常提供 HTTPS 服務。HTTPS 是在 HTTP 外層加入 TLS 加密，可提供傳輸加密、資料完整性及伺服器身分驗證。使用者看到 HTTPS 並不代表網站程式本身沒有漏洞，但至少可防止資料在一般傳輸過程中直接以明文暴露。

HTTP 與 HTTPS 配置比較表

使用者偶爾會把網址輸入成 http:/，但正確格式應是 http://，也就是通訊協定後方有兩個斜線。即使使用者輸入正確的 HTTP 網址，伺服器仍應負責將其重新導向 HTTPS，而不是要求使用者自行修改網址。

為什麼不建議關閉 80 Port

即使網站已全面支援 HTTPS，80 Port 通常仍有保留價值。使用者可能手動輸入不含通訊協定的網域名稱，瀏覽器也可能先嘗試 HTTP；搜尋結果之外的舊文章、電子郵件、文件、QR Code 及第三方網站，也可能仍然保留 HTTP 連結。

若保留 80 Port 並設定 HTTP 強制轉 HTTPS，這些請求可以立即收到 301 回應並前往 HTTPS。若直接關閉 80 Port，瀏覽器可能出現逾時、拒絕連線或網站無法開啟，伺服器也失去告知搜尋引擎「網址已永久移轉」的機會。

對擁有數百個網站的管理者而言，較好的做法不是逐一關閉 80 Port，而是利用 IIS 共用設定、反向代理、負載平衡器、CDN、Apache 虛擬主機範本或自動化部署，集中處理轉址規則。仍須注意每個網域的 443 Port 都要具備相符且有效的憑證。

301、302 與 308 重新導向怎麼選

轉址狀態碼比較表

一般內容網站可使用 301，明確告知瀏覽器與搜尋引擎 HTTP 網址已永久移至 HTTPS。302 比較適合測試、維護或短期切換，不應長期作為正式的 HTTPS 強制轉址方式。

如果轉址可能接收到 POST、PUT 等非 GET 請求，應謹慎評估 301 對請求方法的處理差異。308 能保留原始方法及請求內容，但客戶端相容性、應用程式流程與 API 設計仍須先測試。最佳原則是不要讓敏感表單先提交到 HTTP，再期待透過轉址保護資料。

IIS 設定 HTTP 自動轉向 HTTPS

設定前的必要條件

IIS 站台必須具備 80 Port 的 HTTP 繫結及 443 Port 的 HTTPS 繫結，也就是常見的 IIS HTTP HTTPS 共存。若同一個 IP 上有多個 HTTPS 網站，應正確設定主機名稱、SNI 及各網域對應憑證。

此外，伺服器需安裝 IIS URL Rewrite 模組。正式上線前應確認憑證網域名稱相符、尚未過期、憑證鏈完整，且網站能直接透過 HTTPS 正常開啟。

IIS URL Rewrite 設定範例

可在網站根目錄的 web.config 加入以下規則，將 HTTP 請求永久轉向相同主機名稱及路徑的 HTTPS 網址：

XML

url=”https://{HTTP_HOST}/{R:1}”

redirectType=”Permanent” />

這項 IIS HTTP 重新導向規則會保留原始主機名稱、路徑與查詢字串。例如：

http://example.com/products?id=10

會重新導向至：

https://example.com/products?id=10

若網站只允許單一正式網域，不宜完全信任任意的 {HTTP_HOST}。更穩健的做法是將目的網址固定為已驗證的正式網域，例如 https://www.example.com/{R:1}，同時完成 HTTPS 與主機名稱標準化，避免 Host Header 被濫用。

IIS 位於反向代理後方的注意事項

如果 IIS 位於 CDN、Web Application Firewall、負載平衡器或反向代理後方，外部連線可能已是 HTTPS，但代理到 IIS 時使用 HTTP。此時僅判斷 {HTTPS} 是否為 off，可能形成無限重新導向。

管理者必須依代理服務的實際配置，正確判斷 X-Forwarded-Proto、Forwarded Header 或平台提供的原始通訊協定資訊。只有在可信任的代理伺服器覆寫這些標頭時，才能據此判斷，不能直接信任用戶端自行傳入的標頭。

IIS HTTPS 自簽憑證適合正式網站嗎

IIS HTTPS 自簽憑證適合內部開發、功能測試或隔離環境，但不適合直接提供一般公開網站使用。自簽憑證並非由瀏覽器信任的公開憑證機構簽發，因此訪客通常會看到憑證警告。

自簽憑證仍可加密傳輸，但如果用戶端沒有預先信任該憑證，就無法可靠驗證伺服器身分。公開網站應使用受主流瀏覽器信任的憑證，並建立自動續期及到期監控機制。內部網站若使用自簽憑證，也應透過組織管理的信任根憑證與裝置政策進行部署，而不是要求使用者忽略安全警告。

Apache 使用 .htaccess 強制 HTTPS

Apache 轉址規則

Apache 伺服器已啟用 mod_rewrite，且允許 .htaccess 覆寫設定時，可在網站根目錄加入：

apache

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%{HTTPHOST}%{REQUESTURI} [R=301,L]

這段設定會將 HTTP 路徑及查詢參數導向 HTTPS。若正式網站只使用固定網域，建議把 %{HTTP_HOST} 改成明確網域：

apache

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

若可直接管理 Apache 主設定或虛擬主機，將規則寫入 HTTP VirtualHost 通常比 .htaccess 更有效率，也更容易集中維護：

apache

ServerName example.com

ServerAlias www.example.com

Redirect permanent / https://www.example.com/

使用 CDN 或反向代理時，同樣要避免代理端已使用 HTTPS、來源伺服器卻重複判斷為 HTTP 所造成的轉址迴圈。

cPanel 設定 HTTP 轉 HTTPS

使用網域功能強制 HTTPS

多數 cPanel 環境可在「網域」功能中啟用 Force HTTPS Redirect。啟用前應先確認該網域已有有效憑證，且 HTTPS 網站可以正常顯示。

這種方式適合無法直接管理主機設定的使用者，優點是操作簡單，亦可減少手動編輯 .htaccess 發生語法錯誤的風險。實際功能名稱及支援程度仍依主機商採用的 cPanel 版本與環境而定。

手動修改 .htaccess

若控制台沒有提供強制 HTTPS 選項，可使用前述 Apache 規則。修改前應備份原始檔案，並檢查 WordPress、CMS 或既有轉址規則，避免產生重複規則、多次跳轉或循環重新導向。

HSTS 如何讓瀏覽器優先使用 HTTPS

HSTS，全名為 HTTP Strict Transport Security，是由 HTTPS 回應傳送的安全標頭。瀏覽器收到並記住政策後，在有效期限內遇到相同網域的 HTTP 網址時，會先在本機將其升級為 HTTPS，再送出請求。

可設定以下回應標頭：

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age=31536000 代表政策保存一年；includeSubDomains 代表子網域也必須使用 HTTPS。只有在所有子網域都能穩定支援 HTTPS 時，才應加入該參數。

HSTS 不應被視為 80 Port 轉址的完全替代品。一般 HSTS 政策必須先透過一次有效的 HTTPS 回應讓瀏覽器取得；首次造訪、換新裝置或政策過期時，使用者仍可能從 HTTP 開始。HSTS Preload 可以降低首次連線風險，但加入預載清單前，必須確定主網域及指定範圍內的子網域都能長期維持 HTTPS，否則可能導致無法連線。

HTTP 網站登入的安全風險

HTTP 網站登入最大的問題，是使用者在 HTTP 頁面輸入帳號、密碼或個人資料時，內容可能在送達伺服器之前就已暴露。即使表單最後提交到 HTTPS，HTTP 登入頁本身仍可能遭竄改，攻擊者可以替換表單目的地或插入惡意程式碼。

因此，登入頁、登入表單目的網址、驗證流程、會員中心與密碼重設頁面都必須全程使用 HTTPS。工作階段 Cookie 應設定 Secure，避免透過 HTTP 傳送；也應依實際需求設定 HttpOnly 與適當的 SameSite 屬性。

不要依賴「使用者按下登入後才轉 HTTPS」的設計。正確方式是 HTTP 請求一進站就先重新導向 HTTPS，並確保任何敏感資料都不曾透過 HTTP 傳送。

HTTPS 轉址對 SEO 的影響

HTTP 與 HTTPS 在技術上是不同網址。若兩個版本都回傳內容，搜尋引擎可能需要判斷應收錄哪一個版本，也可能造成網址訊號分散。使用伺服器端 301 轉址，可以明確表示 HTTPS 是永久的新位置。

網站內部連結、Canonical、XML Sitemap、結構化資料、hreflang、社群分享網址與網站管理工具設定，都應統一使用 HTTPS。不要只設定 Canonical 卻讓 HTTP 持續回傳 200 OK；轉址與 Canonical 應保持一致。

理想轉址應一次完成。例如 HTTP 非 www 網址直接轉向 HTTPS 正式網域，不要先從 HTTP 轉 HTTPS，再從非 www 轉 www，形成兩次以上的轉址鏈。縮短轉址鏈有助於改善爬取效率及使用者等待時間。

HTTPS 本身不是優質內容的替代品，但它是網站安全、可信度與技術 SEO 的重要基礎。搜尋排名仍會綜合內容品質、搜尋意圖、網站效能、行動裝置體驗及其他因素。

上線前的檢查項目

HTTPS 部署檢查清單

1. 確認 SSL/TLS 憑證有效、網域相符且憑證鏈完整。
2. 確認 443 Port 可正常連線，HTTPS 頁面回傳正確內容。
3. 保留 80 Port，並將所有 HTTP 網址以 301 導向 HTTPS。
4. 確認路徑、查詢參數及必要的主機名稱都能正確保留。
5. 檢查 HTTP、HTTPS、www 及非 www 版本，避免多重轉址。
6. 修正圖片、JavaScript、CSS 及字型的混合內容。
7. 將內部連結、Canonical 與 XML Sitemap 更新為 HTTPS。
8. 測試登入、購物車、付款、API 與檔案下載流程。
9. 檢查 CDN 及反向代理設定，避免無限轉址。
10. 確認所有子網域支援 HTTPS 後，再評估 HSTS。
11. 建立憑證到期、轉址異常及 HTTPS 可用性監控。
12. 透過瀏覽器開發者工具及 HTTP 檢測工具確認狀態碼。

結論

HTTP 自動轉 HTTPS 不只是安裝 SSL 憑證，而是由憑證、80 與 443 Port 繫結、伺服器端永久轉址、網站資源修正、SEO 網址統一及 HSTS 共同組成。IIS 可使用 URL Rewrite，Apache 可透過 VirtualHost 或 .htaccess，cPanel 則可使用強制 HTTPS 功能。

正式環境通常應保留 80 Port，只讓它負責將請求轉向 443 Port，而不是直接關閉。完成轉址並全面驗證 HTTPS 後，再逐步啟用 HSTS。這種部署方式能兼顧舊連結、使用者便利性、搜尋引擎移轉、安全性及網站長期維護。

常見問題

1. 安裝 SSL 憑證後，網站會自動從 HTTP 轉成 HTTPS 嗎？

不一定。SSL/TLS 憑證只是讓伺服器具備提供 HTTPS 的能力，通常仍需在 IIS、Apache、Nginx、cPanel、CDN 或負載平衡器上另外建立重新導向規則。

2. HTTP 轉 HTTPS 應使用 301 還是 302？

永久切換通常使用 301；302 適合短期測試或臨時導向。如果需要永久保留 POST 等請求方法，可評估 308，但應先確認客戶端與應用程式相容性。

3. 啟用 HSTS 後可以關閉 80 Port 嗎？

通常仍不建議。首次訪客、未取得 HSTS 政策的瀏覽器及舊 HTTP 連結仍可能使用 80 Port。保留 80 Port 並只提供轉址，能維持較好的相容性與使用體驗。

4. 為什麼 HTTP 轉 HTTPS 後出現無限重新導向？

常見原因是網站位於反向代理或 CDN 後方，來源伺服器看到的連線始終是 HTTP。應依可信任代理提供的原始通訊協定標頭調整判斷條件。

5. IIS 一定要安裝 URL Rewrite 才能轉址嗎？

不一定，但 URL Rewrite 能提供較清楚、可控的規則。也可由反向代理、負載平衡器或其他 IIS 功能處理，但不建議以容易產生 403 錯誤或多次跳轉的方法取代正常轉址。

6. 自簽憑證可以用在公開網站嗎？

技術上可以建立加密連線，但一般瀏覽器不會預設信任，訪客會看到安全警告。公開網站應使用受信任憑證機構簽發的憑證。

7. 為什麼網站已是 HTTPS，瀏覽器仍顯示不安全？

可能原因包括憑證過期、網域不符、憑證鏈不完整、頁面載入 HTTP 混合內容，或瀏覽器無法驗證簽發機構。應檢查憑證資訊與開發者工具的安全性錯誤。

8. HTTP 登入頁最後提交到 HTTPS 是否安全？

仍不安全。HTTP 頁面可能在傳輸途中遭竄改，使表單改送至惡意網站。登入頁與提交目的地都必須從一開始就使用 HTTPS。

9. HTTP 轉 HTTPS 會不會造成 SEO 排名下降？

正確使用 301、更新 Canonical、Sitemap 及內部連結，通常可以協助搜尋引擎完成網址移轉。短期爬取與索引波動可能發生，但不應因此同時保留兩個可收錄版本。

10. 如何確認 HTTP 強制轉 HTTPS 設定成功？

分別測試首頁、內頁、查詢參數、www 與非 www 網址，確認 HTTP 回應為 301 且只經過必要的一次轉址，最終 HTTPS 頁面回傳 200。也要檢查憑證、混合內容、登入流程及行動裝置結果。