網站轉用 HTTPS 後，如何找出並修復混合內容？

先認清瀏覽器保護的邊界

網頁本身透過 HTTPS 傳送，仍可能要求瀏覽器用 HTTP 載入圖片、程式碼、樣式、字體、內嵌頁面或下載檔案。這會產生混合內容風險：主頁傳輸受到保護，附屬資源卻可能在途中被窺看或修改。不同資源的處理並不一樣。現時瀏覽器指引指出，部分圖片、音訊及影片請求可自動升級至 HTTPS；不安全的程式碼、樣式、框架及資料請求通常會被阻擋。因此某張圖在一個瀏覽器看似正常，不能證明遷移已完成；付款流程中的程式碼被阻擋，更可能直接令顧客無法完成操作。

業務上要先決定遷移後哪些顧客旅程必須正常，以及每項外部依賴由誰修復。列出首頁、貨品頁、帳戶登入、結帳、確認頁和安全下載等重要頁面。除了程式模板，亦要查看內容管理系統產生的頁面；舊圖片網址可能藏在編輯內容內，而不是原始碼內。第三方小工具及嵌入服務也要納入清單，但不能假設 HTTP 網址改成 HTTPS 就一定可用。應實際測試目標、轉址、憑證及所需資源。主頁的安全鎖標誌只說明主頁連線情況，並非瀏覽器所有請求的完整清單。

把每項不安全請求追至來源

先用瀏覽器開發者工具的主控台及網絡面板，完整走過顧客流程，包括點選貨品規格、送出表格、開啟帳戶頁或下載收據等後載入操作。MDN 指出主控台會顯示已升級或被阻擋的混合內容。逐項記下觸發頁面、請求網址、資源類型、觸發動作及瀏覽器結果，再回到模板、樣式、設定、已儲存內容、網站相關電郵和第三方嵌入設定找出來源。文字搜尋能找出許多寫死的 HTTP 網址，但動態組成的網址可能漏掉，因此仍需實際觀察瀏覽器請求。

按顧客影響和修復能力排序。被阻擋的付款依賴、帳戶程式或必要樣式，通常比裝飾圖片更急。可是已自動升級的圖片仍屬未完成的遷移工作；若 HTTPS 主機沒有相同路徑，圖片仍會失敗。MDN 亦指出，以 IP 位址為主機的請求是一般自動升級的例外；透過 srcset 或 picture 指定的圖片也不能與普通 src 圖片一概而論。測試紀錄應寫明瀏覽器及日期，因為相容性細節可能改變。沒有顧客投訴，也不能推斷整個頁面安全可靠。

修正來源網址及傳送路徑

優先使用自己控制、已確認可經 HTTPS 提供的資源，或供應商已核實的 HTTPS 端點。在內容原本編寫的位置修正網址，再查看瀏覽器最後實際發出的請求。自己網站的資源若能在同一站點經 HTTPS 提供，相對路徑可減少寫死 HTTP 的情況；但仍須檢查正式主機名稱及轉址。第三方服務則要確認 HTTPS 版本提供相同內容，亦容許所需嵌入或跨來源請求。全站字串取代可能把不安全網址變成失效網址，所以每類資源及每個關鍵頁面都要核對。若供應商無法安全提供必要資源，便要考慮停用或更換該依賴。

不要把修正資源與推出 HSTS 混為一談。HSTS 處理瀏覽器日後如何以 HTTPS 連回主機，不能憑空建立缺失的安全資源，也不能修復第三方端點。MDN 記錄的 Content Security Policy 升級不安全請求指令，可以在遷移舊網址時要求瀏覽器嘗試 HTTPS，但無法令不存在的 HTTPS 服務突然可用。它需要測試，不能取代修正來源網址。混合下載亦要另行檢查：安全頁面若以 HTTP 交付檔案，即使頁面正常顯示，檔案仍可能在途中被讀取或更改。要核實檔案回應及顧客整段下載流程均使用 HTTPS。

用商店遷移作演練

設想一間商店的貨品頁仍載入三項舊資源：自家域名的橫幅圖片、舊主題主機的樣式，以及供應商的庫存查詢。頁面轉用 HTTPS 後，圖片可能因瀏覽器升級而顯示，樣式可能被阻擋，庫存請求則可能失敗。不能據此說圖片已完全修復，另外兩項只是外觀問題。團隊應確認安全圖片路徑存在、替換或安全託管樣式，並查明供應商是否有維持相同授權與回應格式的 HTTPS API。這是假設演練，不是已量度的效能結果。

用全新瀏覽器設定檔及一般回訪顧客狀態各做一次。開啟貨品頁、選擇規格、加入購物籃、走不會向真實顧客收款的測試結帳路徑，並取得樣本收據。每一步都比較網絡請求與頁面實際行為。若請求先走 HTTP 再轉到 HTTPS，應記下最終路徑，並把原始引用改為一開始便安全請求。若資源只在手動例外或瀏覽器覆核後才可用，這條流程並未通過。還要在具代表性的手機及桌面瀏覽器重測，因為版面與延遲載入資源可能不同。

以完整旅程作發佈驗收

驗收紀錄應列明測試過的頁面與動作、所用瀏覽器、是否仍有意外混合內容警告，以及關鍵請求的結果。要分開標示已修正來源引用與瀏覽器自動升級；兩者畫面都可能正常，只有前者真正移除了內容內的舊依賴。若有非關鍵項目暫時不能修復，保留負責人及跟進日期。內容修改、主題更新或第三方小工具變動後要重查，因為它們都可能再次加入 HTTP 網址。爬蟲有助廣泛掃描，實際操作則可發現互動後才出現的請求。

交給業務負責人的應是簡潔決策報告，而不是一整頁主控台訊息。說明哪些顧客旅程通過、哪些資源已修、哪些仍待處理，以及剩餘問題會否影響顧客決定或造成不安全下載。若結帳或帳戶登入仍依賴被阻擋的資源，應暫停該旅程，待修好並重測。若只是可選圖片等候供應商修復，也要明確記錄，不要把瀏覽器默默升級當成已完成工作。下一步是安排每個未解決網址的負責人修正來源，然後重跑同一組任務測試。

團隊也應先定義甚麼證據足以關閉問題。只修改原始碼並不足夠，已發佈模板、快取內容或第三方小工具仍可能輸出舊網址。每修好一項，記錄新的來源引用，重新執行原本觸發不安全請求的瀏覽器動作，確認資源經 HTTPS 到達、版本正確，亦沒有引入新功能錯誤。若選擇移除資源，須核實頁面仍能傳達原有資訊；例如刪去庫存提示，可能隱藏顧客購買時需要知道的限制。這些檢查要緊貼所支援的業務任務，因為安全掃描顯示正常，並不能單獨證明顧客可以結帳或讀取收據。最後應作出具體的旅程驗收決定，清楚列出餘下依賴。

規劃修復時，先分清自家資源與只作嵌入的供應商服務。自家資源通常可修改頁面引用，再確認安全檔案已部署。供應商資源則應向對方確認正式支援的安全端點及所需設定；單把 HTTP 網址改成 HTTPS，未必保留授權或跨來源行為。若沒有安全路線，須決定服務是否必要、是否有受支援的替代方案，以及移除期間如何向顧客交代失去的功能。把決定交由頁面負責人記錄，可避免技術修補掩蓋商業變化，例如顧客選貨時倚賴的送貨估計突然消失。供應商合約或小工具更改後，也要重查這些依賴。

如果預覽及測試頁面共用正式網站的內容模板，也應納入檢查。新加入的 HTTP 引用可能在內容公開前一直無人察覺。把安全資源核對加入內容發佈程序，並讓編輯知道遇到無法自行修正的供應商連結時，應交給哪位技術負責人。相關人員須在正式推出前重試同一頁面及顧客動作，而不是只看連結文字是否已改成 HTTPS。