只改寫已知能走 HTTPS 的網址，盲目升級會把頁面弄壞
作者是 John Graham-Cumming。JSON-LD 的刊登時間是 2016 年 9 月 22 日，修改時間寫 2026 年 7 月 15 日。正文沒有說功能預設或規則表在 2026 年重測過。頁面另有德文、西班牙文、法文、日文和簡體中文。佇列裡的三則是德文、法文和簡體中文。
他要結束未加密的網頁，但把網站改成 HTTPS 有先後問題。Universal SSL 讓換成 HTTPS、拿到免費憑證變成按一下。網站也能用 HTTP/2。他說網站會因此更快。這句沒有速度測試的數字。
目錄（7）
編譯自 Cloudflare · John Graham-Cumming · 2016-09-22 原文
完整來源聲明
來源聲明：本文根據 John Graham-Cumming（Cloudflare，2016-09-22）〈Fixing the mixed content problem with Automatic HTTPS Rewrites〉編譯為繁體中文，不是逐句翻譯。頁面沒有寫文章採用 CC BY。德文、法文和簡體中文是同一篇的譯本，不另成篇。功能上線當天預設關閉；只改寫已知能用 HTTPS 載入的網址。原文：https://blog.cloudflare.com/fixing-the-mixed-content-problem-with-automatic-https-rewrites/。文中「編輯解讀」為本站觀點，不屬於原文。檢索日期：2026-10-17。
鎖頭要每一個子資源都走 HTTPS
HTTPS 頁面只要載入任何 HTTP 資源，包括自己網站上的，就不會顯示綠色鎖頭。圖片、JavaScript、音訊、影片走 HTTP，等於在加密頁面上開一個洞。瀏覽器很早知道這件事。1997 年 Internet Explorer 3.0.2 會跳出警告。選是，就忽略風險、用明文載入子資源。選否，就不載入，頁面可能破掉，但維持加密。
文中當時的 Chrome 在有不安全內容的 HTTPS 頁上顯示一個帶圈的 i。Firefox 的鎖頭帶警告符號。要拿到綠色鎖頭，頁面載入的每一個子資源都必須走 HTTPS。這是 2016 年文章裡的圖示，不是對現在瀏覽器介面的描述。
他把「全部改成 HTTPS」說成聽起來容易、其實做不到。第一方和第三方塞進頁面的東西太多。Wired 從 4 月開始，主站先準備了數月，正式切換又花 5 個月。這 5 個月是他的轉述。Wired 2016 年 5 月的文章確實把混合內容寫成改用 HTTPS 的大困難：頁面走 HTTPS 時，圖片和 JavaScript 也必須走 HTTPS。1
2014 年《紐約時報》把混合內容當成改用加密的主要障礙：頁面上的資源，包括 JavaScript 和廣告素材，都得從加密通道載入。W3C 把手動改舊網址說成管理員的沉重工作，並舉 BBC 的大量典藏為例。W3C 那頁這次是 403，沒有放進連結，說法依這篇文章。內容管理系統的連結可能在設定、程式或資料庫裡。使用者也會貼上 HTTP 網址。
主動內容會被擋，被動內容只警告
混合內容分兩種。主動內容能改頁面本身，包括 script、link、iframe、object，CSS 裡用 url 的值，以及 XMLHTTPRequest。這些可以改頁面、讀 cookie、碰到使用者憑證。被動內容是寫進頁面、但不能自己碰頁面的圖片、音訊和影片。
文中寫，當時的瀏覽器會自動、完整擋下主動混合內容；被動內容仍載入，但顯示警告。主動內容的風險是有人攔截 HTTP 請求並換成自己的內容。他說這不是想像：2015 年 GitHub 遭到被稱為 Great Cannon 的系統攻擊，對方攔截透過 HTTP 索取常見 JavaScript 的請求，換成攻擊腳本，借用使用者的電腦。Citizen Lab 2015 年 4 月 10 日的報告寫，這次攔截的是通往特定位址的流量，並與惡意 JavaScript 有關。2 JavaScript 被替換的細節，以這篇 Cloudflare 文章的轉述為準。
被動內容的風險不同。請求是明文，旁聽者可以看請求、取出資料。他舉的例子是 cookie、看過的頁面，以及可能的登入資料。Firesheep 這個 Firefox 附加元件可以在區域網路，例如咖啡店，監看 HTTP 請求並偷 cookie，一下就冒用身分。附加元件頁這次沒有另核。
他的結論是：當時瀏覽器擋主動、放行被動，但只有全部改成 HTTPS 才處理得了混合內容的全部問題。
三種全改的做法被拿掉
他們要的是按一下就能修。考慮過四種做法，前三種沒有採用。
第一種是自動加上這段內容安全政策：
Content-Security-Policy: upgrade-insecure-requests瀏覽器會把 HTTP 請求改成 HTTPS。站方若確定每個子資源都有 HTTPS，就不用自己改頁面裡的網址。缺點是瀏覽器不管改完打不打得開，一律升級，頁面會壞。W3C 文件這次打不開，壞頁的說法依這篇文章。
第二種是頁面經過 Cloudflare 時，把所有 HTTP 網址改成 HTTPS。這樣不依賴瀏覽器支不支援那條政策。問題一樣：改完如果資源其實不能用 HTTPS 載入，連結就斷。
第三種只改指向其他 Cloudflare 網站的網址。他寫當時有 400 萬客戶有免費 Universal SSL，所以那些網址改了打得開。這只解決一部分，不是一般網站從 HTTP 改到 HTTPS 的做法。400 萬是文中的數字，不是 2026 年的客戶數。
只改已知打得開的網址
採用的是第四種：只有知道資源能用 HTTPS 提供時，才把 http:// 改成 https://。判斷來自三處：EFF 的 HTTPS Everywhere 規則、Google Chrome 的 HSTS 預載清單，以及他們自己知道已開 SSL 的 Cloudflare 網站。他感謝 EFF 參加這個專案。HTTPS Everywhere 的產品頁在，規則表這次沒有逐條核對。3
規則不是把整個網域一併升級。他舉 gstatic.com 的一條：正則只對上 csi、encrypted-tbn、fonts 等特定子網域，再把那些請求改成 HTTPS。規則集裡也有排除。完整規則在 EFF 的目錄，本文不把這條正則寫成你要貼上的設定。
他估計頁面裡要改的網址大約每秒 500 萬筆。現有的 HTML 解析器，包括他們自己的，速度不夠，所以為這種改寫新寫了一個。設計、測試和效能留到以後的文章。這篇沒有那些數字。
Automatic HTTPS Rewrites 當天起在所有客戶的儀表板裡。預設關閉，按一下開啟。他們會看效能和效果，並計畫在那年稍晚為免費和專業方案預設開啟。也計畫用內容安全政策的報告，讓客戶看到還有哪些網址沒改。預設開啟和報告都是計畫，這篇沒有上線結果。本文沒有核對 2026 年儀表板的預設值。
常見問題
- 是不是把頁面上所有 HTTP 都改成 HTTPS？不是他們採用的做法。一律升級，包括內容安全政策那條，會在 HTTPS 其實打不開時把頁面弄壞。上線的功能只改已知能用 HTTPS 載入的網址。
- 怎麼知道某個網址改了還打得開？文中寫三個來源：HTTPS Everywhere 的規則、Chrome 的 HSTS 預載清單，以及已開 SSL 的 Cloudflare 網站。規則可以只含特定子網域，也可以排除。gstatic.com 那條正則是例子，不是要你貼上的設定。
- 上線時預設是開的嗎？2016 年 9 月 22 日，所有客戶的儀表板都有，預設關閉，按一下開啟。為免費和專業方案改成預設開啟，是那年稍晚的計畫，這篇沒有結果。本文沒有核對現在的預設。
- 圖片走 HTTP，瀏覽器會擋嗎？文中寫當時不會。圖片、音訊、影片是被動內容，會載入並顯示警告。script、iframe 這類能改頁面的主動內容才會被自動擋下。鎖頭仍要每一個子資源都走 HTTPS。
- 每秒 500 萬筆是測出來的流量嗎？是他的估計，用來說明為什麼要新寫解析器。解析器的效能數字不在這篇。400 萬客戶也是文中當時的數字。
編輯解讀
一句話重點：這次上線的不是把所有 HTTP 改成 HTTPS。只改已知打得開的，而且當天預設關閉。
這對你的網站意味著什麼：
- 不要用「全部升級」代替這篇的規則。打不開的 HTTPS 會把頁面弄壞，是他們否決前三種做法的理由。
- 鎖頭看的是每一個子資源。圖片仍走 HTTP 時，文中寫只會警告，不會被擋下。
- 主動內容走 HTTP 可以被攔截替換。Great Cannon 是他們引的 2015 年事件，不是這次功能的客戶數據。
- 預設要不要開，以你現在的儀表板為準。這篇只寫 2016 年 9 月 22 日預設關閉，以及稍後要改預設的計畫。
適用與不適用的情境：適用於理解這項改寫為什麼不碰未知的網址。不適用於把每秒 500 萬筆、400 萬客戶或 5 個月當成你的遷移時程，也不適用於假設今天的免費方案已經預設開啟。
需要注意的限制：這是 Cloudflare 的產品發布，他們銷售 SSL。速度變快沒有測試數字。瀏覽器圖示和擋不擋被動內容，是 2016 年的描述。W3C 頁面是 403。解析器效能不在這篇。JSON-LD 的 2026 年修改時間沒有新的預設或成效。
可複用規則3 條
從本文提煉，可供人工對照或 AI 分析站點時作為依據。全部規則
Cloudflare 2016-09-22 這篇否決了兩種一律升級：瀏覽器的 upgrade-insecure-requests，以及經過他們時把每個 HTTP 網址改成 HTTPS。兩者都不管改完打不打得開，頁面會壞。只改其他 Cloudflare 客戶的網址也只解決一部分。
- 寫明打不開就會弄壞頁面
- 一律升級不是採用的做法
同一篇採用的規則：只有知道資源能用 HTTPS 提供時才改寫。來源是 EFF 的 HTTPS Everywhere 規則、Chrome 的 HSTS 預載清單，以及已開 SSL 的 Cloudflare 網站。規則可以只含特定子網域，gstatic.com 那條是例子，也可以排除。不是把整個網域一併升級。
- 三個判斷來源都在
- 子網域和排除寫明
同一篇：2016-09-22 起所有客戶的儀表板都有這個功能，預設關閉，按一下開啟。為免費和專業方案改成預設開啟，是那年稍晚的計畫，文中沒有結果。每秒約 500 萬筆網址是估計。新解析器的效能不在這篇。主動混合內容當時會被瀏覽器擋下，圖片等被動內容只警告。
- 預設關閉和計畫分開
- 主動與被動分開
名詞與資料來源
- WIRED：〈WIRED’s First Big HTTPS Snag〉 https://www.wired.com/2016/05/wired-first-big-https-rollout-snag/（檢索：2026-10-17）。頁面寫混合內容是改用 HTTPS 的主要困難。花 5 個月是 Cloudflare 文章的轉述。
- Citizen Lab：〈China’s Great Cannon〉 https://citizenlab.org/2015/04/chinas-great-cannon/（刊登：2015-04-10；檢索：2026-10-17）。寫攔截通往特定位址的流量，並與惡意 JavaScript 有關。
- Electronic Frontier Foundation：〈HTTPS Everywhere〉 https://www.eff.org/https-everywhere（檢索：2026-10-17）。這次只確認產品頁在，沒有逐條核對規則。
- John Graham-Cumming／Cloudflare：〈Fixing the mixed content problem with Automatic HTTPS Rewrites〉 https://blog.cloudflare.com/fixing-the-mixed-content-problem-with-automatic-https-rewrites/（刊登：2016-09-22；JSON-LD 修改時間：2026-07-15；檢索：2026-10-17）