上次更新時間： | 查看所有文件
Let’s Encrypt 提供速率限制，以確保盡可能多的人都能公平使用。我們認為這些速率限制已經足夠高，足以讓大多數人預設情況下正常使用。我們也將其設計為續訂憑證幾乎永遠不會觸及速率限制，並且讓大型組織可以逐步增加它們可以核發的憑證數量，而無需 Let’s Encrypt 的介入。
如果您正在積極開發或測試 Let's Encrypt 客戶端，請使用我們的測試環境，而不是生產 API。如果您正在整合 Let's Encrypt 作為供應商或與大型網站整合，請查看我們的整合指南。
我們的速率限制如何運作
限制是根據每次請求使用洩漏水桶演算法來計算的。這種方法讓您可以彈性地使用您分配的請求。您可以一次爆發性地提出請求（直到達到限制），也可以將請求分散開來，以避免受到限制的風險。
如果您已達到速率限制，我們沒有任何方法可以暫時重置它。別擔心，您的該限制容量會隨著時間逐漸恢復，讓您可以在無需採取任何額外動作的情況下提出更多請求。撤銷憑證並不會重置速率限制，因為核發這些憑證所使用的資源已被消耗。如需更多資訊，請參閱達到速率限制後重試。
帳戶註冊限制
當訂閱者使用 new-account API 端點請求新帳戶時，適用以下限制。超出這些限制非常罕見。我們建議大型整合商偏好為多個客戶使用一個帳戶的設計。
每個 IP 位址的新註冊
每 3 小時可以從單一 IP 位址建立最多 10 個帳戶。建立新帳戶的能力會以每 18 分鐘 1 個帳戶的速度恢復。
覆寫
我們不提供此限制的覆寫。
每個 IPv6 範圍的新註冊
每 3 小時可以從單一 /48 IPv6 子網路建立最多 500 個帳戶。建立新帳戶的能力會以每 22 秒 1 個帳戶的速度恢復。
覆寫
我們不提供此限制的覆寫。
憑證核發限制
當訂閱者使用 new-order API 端點請求新憑證時，適用以下限制。超出這些限制比較常見，特別是對於為許多主機名稱核發憑證的大型託管供應商或組織。
每個帳戶的新訂單
每次您從 Let's Encrypt 請求憑證時，都會建立一個新訂單。單一憑證最多可以包含 100 個主機名稱。為了效能考量，盡可能在每個憑證中使用較少的主機名稱會比較好。
限制
單一帳戶每 3 小時最多可以建立 300 個新訂單。建立新訂單的能力會以每 36 秒 1 個訂單的速度恢復。
覆寫
若要超出此限制，您必須請求特定帳戶的覆寫。
每個已註冊網域的新憑證
一般來說，已註冊網域是您從網域名稱註冊商購買的網域部分。例如，在 www.example.com 中，已註冊網域是 example.com。在 new.blog.example.co.uk 中，已註冊網域是 example.co.uk。我們使用公開後綴列表來識別已註冊網域。
限制
每個已註冊網域每 7 天最多可以核發 50 個憑證。這是全域限制，而且所有新訂單請求，無論是由哪個帳戶提交，都會計入此限制。針對相同已註冊網域核發新憑證的能力會以每 202 分鐘 1 個憑證的速度恢復。
覆寫
若要超出此限制，您必須請求特定已註冊網域或帳戶的覆寫。
每個確切主機名稱組合的新憑證
如果您請求 example.com 和 login.example.com 的憑證，「確切主機名稱組合」是 [example.com, login.example.com]。如果您只請求 1 個主機名稱的憑證，例如 example.co.uk，則確切主機名稱組合將會是 [example.co.uk]。
限制
每 7 天針對每個相同的確切主機名稱組合最多可以核發 5 個憑證。這是全域限制，而且所有新訂單請求，無論是由哪個帳戶提交，都會計入此限制。針對相同的確切主機名稱組合請求新憑證的能力會以每 34 小時 1 個憑證的速度恢復。
常見原因
多次重新安裝您的客戶端以針對未知的錯誤進行疑難排解，或每次部署應用程式時都刪除您的 ACME 客戶端的組態資料，都是達到此限制的常見方式。我們刻意將此限制設定得相對較低，以防止有錯誤的系統或開發中的軟體快速消耗其他速率限制的容量。
在測試或疑難排解您的應用程式時，我們建議您將您的客戶端設定為使用我們的測試環境，該環境的限制明顯較高。
因應措施
如果您已達到此限制，您可以藉由新增 blog.example.com 來變更主機名稱組合，以請求其他憑證。請注意，這些新訂單不會被視為續訂。因此，它們將會受到每個帳戶的新訂單和每個已註冊網域的新憑證速率限制的約束。
覆寫
我們不提供此限制的覆寫。
每個帳戶針對每個主機名稱的授權失敗次數
會針對訂單中包含的每個主機名稱產生授權。在核發憑證之前，必須成功驗證訂單中的所有授權。授權失敗表示，雖然已成功傳送驗證請求，但 Let's Encrypt 驗證對主機名稱的控制權的所有嘗試都已失敗。
限制
每個帳戶每小時可以針對每個主機名稱產生最多 5 次授權失敗。產生授權失敗的能力會以每 12 分鐘每個主機名稱 1 次的速度恢復。一旦超出此限制，便會強制執行此限制，方法是在限制重設之前，禁止相同帳戶針對相同主機名稱提出任何新訂單。
常見原因
在您開始疑難排解之前，我們建議您將您的客戶端設定為使用我們的測試環境。此環境的限制明顯較高，這可以幫助您在不消耗生產限制的情況下識別並解決問題。
-
當使用
HTTP-01和TLS-ALPN-01方法時，驗證失敗通常源自於網路或防火牆組態，導致 Let's Encrypt 驗證伺服器無法連線到您的伺服器。 -
當使用
DNS-01方法時，驗證失敗通常源自於初始設定過程中遺漏的步驟或錯字。一般來說，這種驗證方法需要您在您的主要 DNS 區域中建立 CNAME 記錄，讓您的客戶端能夠在驗證過程中設定必要的 DNS 記錄。
覆寫
我們不提供此限制的覆寫。
續訂的限制豁免
Let's Encrypt 以兩種方式將新的憑證訂單視為「續訂」：首選方法是透過 ACME 續訂資訊 (ARI)，它不受所有速率限制的約束，另一種方法則依賴較舊的續訂偵測邏輯，該邏輯會將具有完全相同主機名稱組合的訂單視為續訂，但仍可能受到某些速率限制的約束。
ARI 續訂
由 ARI 協調的續訂具有獨特的優勢，可以不受所有速率限制的約束。支援 ARI 的客戶端會定期與 Let's Encrypt 伺服器核對，以判斷您的現有憑證是否應續訂。當達到最佳續訂視窗時，客戶端會請求一個新訂單，明確指出它所取代的憑證。如果新訂單至少包含一個符合它打算取代的憑證的主機名稱，且該憑證之前未使用 ARI 取代，則該訂單將不會受到任何速率限制的約束。
非 ARI 續訂
如果您的客戶端或託管供應商尚未新增對 ARI 的支援，如果您的訂單包含完全相同的主機名稱組合，則您的訂單仍然可以被視為較早憑證的續訂，忽略大小寫和主機名稱的順序。例如，如果您請求 [www.example.com, example.com] 主機名稱的憑證，您可以再請求四個 [www.example.com, example.com] 的憑證，然後達到每個確切主機名稱組合的新憑證速率限制。這些新訂單中的每一個都會被視為續訂，並且不會受到每個帳戶的新訂單和每個已註冊網域的新憑證速率限制的約束。然而，與 ARI 續訂不同，這些訂單仍然會受到每個帳戶針對每個主機名稱的授權失敗次數和每個確切主機名稱組合的新憑證的約束。
達到速率限制後重試
我們所有的速率限制錯誤訊息都遵循相同的格式。例如
too many new registrations (10) from this IP address in the last 3h0m0s,
retry after 1970-01-01 00:18:15 UTC.
您應該可以在提供的日期和時間之後成功提出相同的請求。如果您的請求超出了我們多個限制的容量，我們將始終回傳最晚重設的限制錯誤訊息。
Retry-After 標頭
我們在所有速率限制錯誤回應中都包含一個 Retry-After 標頭，指出您的客戶端應在重試之前等待的持續時間。
您可以藉由搜尋 crt.sh 或 Censys 來取得為您的已註冊網域核發的憑證清單，這些清單使用公開的憑證透明度記錄。
請求覆寫
如果您是大型託管供應商或組織，正在進行 Let's Encrypt 整合，我們有一個速率限制表單，可以用來請求更高的速率限制。處理請求需要幾週的時間，因此如果您只是需要比它自行重設的速度更快地重設速率限制，則此表單不適合。