HSTS使用首次使用信任模型。如果您與該站點的第一次連接已受到威脅，則可能不會在後續請求中收到HSTS錯誤。

HTTPS Everywhere會堵塞此漏洞，方法是讓您的瀏覽器知道該站點是HTTPS唯一的站點，

另外，即使某些網站支持HTTPS，也不會發布HSTS標頭。或者他們的HTTPS可能位於其他域/路徑中（例如， http://www.example.com 但 https://secure.example.com ）， HTTPS Everywhere嘗試通過重寫站點的URL來解決這些情況。

HTTPS Everywhere在客戶端，HSTS在服務器端。

因此答案是，在服務器未設置HSTS標頭的情況下，HTTPS Everywhere可以為您提供保護。

即使我們瀏覽到一個說www.facebook.com的網站，來自Facebook服務器的響應標頭也會提到HSTS

我做了一個 curl 請求到 http://www.facebook.com ，這就是我得到的：

  < HTTP / 1.1 302 Found<位置：https：/ /www.facebook.com/<內容類型：文本/ html< X-FB-調試：zgK / A + 8XSlghi / vWvAivsZ04gawpdr + 3BuO7yuQaKDdrP / + B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A == <日期：星期六，2017年4月29日19時23分25秒GMT<連接：keep-alive<內容長度：0  

您可以看到這裡沒有HSTS標頭，因為根據其規範（RFC6797）：

HSTS主機不得在通過非安全傳輸傳遞的HTTP響應中包括STS頭字段。

Web瀏覽器也將忽略HSTS頭在HTTP響應中：

注意：使用HTTP訪問您的網站時，瀏覽器會忽略ict-Transport-Security標頭；這是因為攻擊者可能攔截HTTP連接並註入標頭或將其刪除。通過HTTPS訪問您的網站且沒有證書錯誤時，瀏覽器會知道您的網站具有HTTPS功能，並且會遵守Strict-Transport-Security標頭。

HSTS的目的是告訴客戶端通過HTTPS訪問網站後就不要切換到HTTP，反之亦然。來自 Wikipedia：

HTTP嚴格傳輸安全性（HSTS）是一種網絡安全策略機制，有助於保護網站免受協議降級攻擊和cookie劫持。

協議降級攻擊：

降級攻擊是對計算機系統或通信協議的一種攻擊形式，它使其放棄高質量的操作模式（例如，加密連接），而轉而使用較舊的較低質量的操作模式（例如，清除）文本），以便與舊系統向後兼容。

因此，HSTS標頭不用於將新的HTTP連接重定向到HTTPS，而是用於防止瀏覽器發出HTTP請求

另一方面， HTTPS Everywhere插件可確保網絡瀏覽器與支持HTTPS的網站建立HTTPS連接，但也可以通過HTTP進行訪問。

p>

Web上的許多站點對基於HTTPS的加密提供了一些有限的支持，但使它難以使用。例如，它們可能默認為未加密的HTTP，或使用返回到未加密站點的鏈接來填充加密頁面。 HTTPS Everywhere擴展通過使用巧妙的技術將對這些站點的請求重寫為HTTPS來解決這些問題。

HSTS由網站運營商酌情決定。他們必須確定強制HTTPS的安全性優勢是否值得額外的服務器負載，阻止無法使用HTTPS的用戶以及使緩存代理無效。強制HTTPS是HSTS的先決條件。

許多站點可選地提供HTTPS，但是通常由最終用戶而不是提供鏈接或URL的人來選擇是否使用HTTPS。 HTTPS Everywhere允許用戶在此類站點上使用HTTPS，即使鏈接或鍵入的URL使用HTTP。用於“ HTTPS無處不在”，但直到/除非所有提供HTTPS的站點都這樣做，否則它將仍然是一個有用的插件。

問題在於錯誤的前提。

...如果我們瀏覽到說www.facebook.com的網站，則來自Facebook服務器的響應標頭將提及HSTS，而我們的瀏覽器會將我們從 http：// 定向到 https：// ...

不是真的*。儘管 Strict-Transport-Security 標頭是HTTP標頭，但是HSTS規範要求服務器僅將其包括在通過加密通道發送的響應中，並且要求客戶端在通過非加密通道發送的響應中忽略它-加密的頻道。摘自 RFC 6797：

HTTP嚴格傳輸安全性主機：是符合標準的主機，用於實現HSTS策略的HTTP服務器方面。這意味著HSTS主機在通過安全傳輸發送的HTTP響應消息中返回“ Strict-Transport-Security” HTTP響應標頭字段。

...

HTTP主機聲明通過向UA發出HSTS策略來使自身成為HSTS主機，該策略由Strict-Transport-Security HTTP響應頭字段表示並通過安全傳輸（例如TLS）進行傳輸。

...

HSTS主機不得在通過非安全傳輸傳送的HTTP響應中包括STS頭字段。

...

如果通過非安全接收到HTTP響應傳輸，UA必須忽略任何當前的STS標頭字段。

*好，我排除了Facebook服務器和您的瀏覽器都違反HSTS規範的可能性。確實，配置良好且帶有HSTS的服務器通常也將配置為不偵聽端口80或將永久重定向發送到HTTPS URL。但是請參閱RFC的7.2節中的限制。

許多域沒有正確配置HSTS。例如，Google在www.google.com及其子域上擁有HSTS，但在google.com及其子域上卻沒有。因此，訪問 https://google.com或 https://www.google.com

Google進行此類設置的原因很複雜。要進入Chrome HSTS預加載列表，必須具有域及其子域的HSTS。我認為Google有一些內部服務，也許是面向公眾的服務，無法通過HTTPS運作。因此，針對Google.com所有子域的HSTS都會中斷這些服務。所有www.google.com域的HSTS實際上僅覆蓋www.google.com，因為它在* .www.google.com上沒有任何子域。

但是，HTTPS Everywhere的規則要比允許此類複雜用例的HSTS複雜得多。

我發現HSTS預加載還沒有任何答案。總結一下：現有答案中提到的警告，例如@ Lie Ryan的：

HSTS使用首次使用信任模型。如果您與該站點的第一次連接已受到威脅，則後續請求可能不會收到HSTS錯誤。

（…）

此外，某些網站沒有廣告HSTS標頭即使它們支持HTTPS。

不適用於預加載的網站；也就是說，它們位於網絡瀏覽器內置的列表中。就像使用HTTPS Everywhere一樣，此列表中的網站即使在第一次訪問時也始終會重寫為HTTPS。

因此，HTTPS Everywhere的維護者已經決定預加載列表不會添加到HTTPS Everywhere的URI數據庫中（也可能會從HTTPS Everywhere的數據庫中刪除）。

我專門為Stack Exchange本身使用HTTPS Everywhere。上次我檢查（幾個月前）時，它沒有使用HSTS，甚至沒有從HTTP重定向到HTTPS。但是，它確實提供了HTTPS，因此該附件使我免於潛在的竊聽。

對於Stack Exchange，情況現在可能已經改變。