API 速率限制繞過

中級3 分鐘閱讀更新於 2026-03-15

繞過 LLM 服務 API 速率限制的技術，包括標頭操控、分散式請求、認證輪換和端點探測。

infrastructure api rate-limiting bypass red-teaming

LLM API 服務實作速率限制以防止濫用、控制成本並確保公平存取。然而，速率限制實作的精細程度各不相同，許多常見配置都存在可利用的弱點。理解這些弱點對紅隊（測試防禦）和藍隊（建立健全限制）都至關重要。本詳解涵蓋速率限制指紋識別、繞過技術和防禦建議。

步驟 1：識別速率限制實作

在嘗試繞過前，透過分析回應標頭和行為來識別速率限制的實作方式。

fingerprint_rate_limiter 函式發送 20 個請求並提取速率限制相關標頭：

# 要提取的速率限制標頭清單
rl_headers = [
    "X-RateLimit-Limit",
    "X-RateLimit-Remaining",
    "X-RateLimit-Reset",
    "Retry-After",
    "RateLimit-Limit",
    "RateLimit-Remaining",
    "RateLimit-Reset",
    "X-Rate-Limit-Limit",
    "X-Rate-Limit-Remaining",
]

analyze_fingerprint 函式處理結果，輸出：

偵測到的標頭清單
限制值（從標頭解析）
第幾個請求觸發限制
是否使用 Retry-After 標頭

這些資訊揭示了目標使用哪種速率限制算法（固定視窗、滑動視窗、令牌桶）以及追蹤維度（IP、API 金鑰、使用者 ID、組合）。

步驟 2：基於標頭的繞過技術

許多速率限制器透過 IP 位址追蹤客戶端，當應用程式信任代理標頭時，此方式可透過 HTTP 標頭欺騙。

header_bypass_techniques 函式生成七種標頭變體：

技術	標頭	描述
`x_forwarded_for`	`X-Forwarded-For`	最常見的代理標頭，被許多負載均衡器信任
`x_real_ip`	`X-Real-IP`	Nginx 專用客戶端 IP 標頭
`x_originating_ip`	`X-Originating-IP`	Microsoft/Exchange 客戶端 IP 標頭
`x_client_ip`	`X-Client-IP`	部分代理使用的通用客戶端 IP 標頭
`cf_connecting_ip`	`CF-Connecting-IP`	Cloudflare 專用標頭（在 CF 後面時有效）
`true_client_ip`	`True-Client-IP`	Akamai CDN 客戶端 IP 標頭
`x_forwarded_for_chain`	多跳鏈	多跳代理鏈（部分解析器取第一個 IP）

每次請求輪換隨機 IP 以最大化有效性。test_header_bypass 函式對每種技術執行 5 次請求並報告成功率。

步驟 3：分散式速率限制繞過

endpoint_rotation_bypass 非同步函式在多個 API 端點間輪換，利用以下邏輯：如果速率限制是每個端點而非每個使用者，則在端點間分散請求會使有效限制成倍增加。

concurrent_burst_bypass 非同步函式同時發送 20 個並發請求，利用非原子速率限制實作中的競爭條件——這些請求在速率限制器更新計數器前同時到達。

兩個函式都回傳 DistributedBypassResult，包含成功/被限制請求數和有效每秒請求數（effective_rps）。

步驟 4：認證輪換

APIKeyRotator 類別實作 API 金鑰輪換以突破每金鑰速率限制。關鍵方法：

get_next_key：返回下一個可用（未被限速）的 API 金鑰
mark_limited：將金鑰標記為已限速
send_request：使用下一個可用金鑰發送請求，若回應 429 則自動標記金鑰

run_rotation_test 方法執行 100 次請求，計算有效倍增係數（effective_multiplier），顯示金鑰輪換相較於單一金鑰的吞吐量提升。

步驟 5：視窗邊界利用

exploit_fixed_window 函式利用固定視窗速率限制器的邊界效應：

從 X-RateLimit-Reset 標頭讀取視窗重置時間
等待至視窗重置前 1 秒
在視窗重置前發送最大允許請求數（pre_window）
等待 1.5 秒使視窗重置
在新視窗剛開始時再次發送最大允許請求數（post_window）

結果是在短時間內發送了兩倍於預期限制的請求數（effective_limit）。滑動視窗算法對此免疫，因為它們追蹤個別請求的時間戳。

步驟 6：LLM 專用速率限制繞過

針對 LLM API 特有的速率限制架構，五種特定技術：

技術	描述	有效性
`model_parameter_variation`	不同模型參數可能被分開追蹤	低——大多數 API 按金鑰追蹤
`streaming_vs_blocking`	串流回應可能以不同方式計算	中等——部分實作對串流回應的符元計數不同
`batch_api_abuse`	批次 API 可能有獨立或更高的速率限制	中等——批次可以成倍提升有效吞吐量
`model_version_switching`	切換模型版本以利用每模型限制	中等——許多 API 有每模型限制
`organization_rotation`	建立多個具獨立計費的組織/專案	高——但需要多個帳戶

步驟 7：自動化速率限制測試

RateLimitTester 類別提供全面的速率限制測試框架：

_test_baseline：建立基準速率限制行為（每 50ms 發送一個請求，記錄哪個請求觸發 429）
_test_headers：測試 X-Forwarded-For 標頭輪換有效性（每次請求隨機 IP）

generate_report 方法輸出包含所有測試結果和五項建議的 JSON 報告：

使用實際 TCP 連接 IP，而非 X-Forwarded-For 進行速率限制
實作滑動視窗或令牌桶，而非固定視窗
對分散式速率限制使用原子操作
同時按 IP 和 API 金鑰進行速率限制以實現縱深防禦
為突發模式添加異常偵測

步驟 8：防禦建議

SlidingWindowRateLimiter 類別實作健全的速率限制算法，核心邏輯是：

為每個客戶端維護精確到秒的請求時間戳列表
每次請求時過濾掉超過視窗時間的時間戳
計算當前視窗內的請求數，超過限制則拒絕
此方法不受視窗邊界利用的影響

MultiDimensionalRateLimiter 類別同時在四個維度進行限速：按 IP（每分鐘 100 次）、按 API 金鑰（每分鐘 60 次）、按使用者（每分鐘 30 次），以及全局限制（每分鐘 10,000 次）。check 方法回傳允許/拒絕決定、每個維度的剩餘配額，以及如果被拒絕則指出是哪個維度觸發了限制。

API 速率限制繞過

中級3 分鐘閱讀更新於 2026-03-15

繞過 LLM 服務 API 速率限制的技術，包括標頭操控、分散式請求、認證輪換和端點探測。

infrastructure api rate-limiting bypass red-teaming

步驟 1：識別速率限制實作

在嘗試繞過前，透過分析回應標頭和行為來識別速率限制的實作方式。

fingerprint_rate_limiter 函式發送 20 個請求並提取速率限制相關標頭：

# 要提取的速率限制標頭清單
rl_headers = [
    "X-RateLimit-Limit",
    "X-RateLimit-Remaining",
    "X-RateLimit-Reset",
    "Retry-After",
    "RateLimit-Limit",
    "RateLimit-Remaining",
    "RateLimit-Reset",
    "X-Rate-Limit-Limit",
    "X-Rate-Limit-Remaining",
]

analyze_fingerprint 函式處理結果，輸出：

偵測到的標頭清單
限制值（從標頭解析）
第幾個請求觸發限制
是否使用 Retry-After 標頭

這些資訊揭示了目標使用哪種速率限制算法（固定視窗、滑動視窗、令牌桶）以及追蹤維度（IP、API 金鑰、使用者 ID、組合）。

步驟 2：基於標頭的繞過技術

許多速率限制器透過 IP 位址追蹤客戶端，當應用程式信任代理標頭時，此方式可透過 HTTP 標頭欺騙。

header_bypass_techniques 函式生成七種標頭變體：

技術	標頭	描述
`x_forwarded_for`	`X-Forwarded-For`	最常見的代理標頭，被許多負載均衡器信任
`x_real_ip`	`X-Real-IP`	Nginx 專用客戶端 IP 標頭
`x_originating_ip`	`X-Originating-IP`	Microsoft/Exchange 客戶端 IP 標頭
`x_client_ip`	`X-Client-IP`	部分代理使用的通用客戶端 IP 標頭
`cf_connecting_ip`	`CF-Connecting-IP`	Cloudflare 專用標頭（在 CF 後面時有效）
`true_client_ip`	`True-Client-IP`	Akamai CDN 客戶端 IP 標頭
`x_forwarded_for_chain`	多跳鏈	多跳代理鏈（部分解析器取第一個 IP）

每次請求輪換隨機 IP 以最大化有效性。test_header_bypass 函式對每種技術執行 5 次請求並報告成功率。

步驟 3：分散式速率限制繞過

concurrent_burst_bypass 非同步函式同時發送 20 個並發請求，利用非原子速率限制實作中的競爭條件——這些請求在速率限制器更新計數器前同時到達。

兩個函式都回傳 DistributedBypassResult，包含成功/被限制請求數和有效每秒請求數（effective_rps）。

步驟 4：認證輪換

APIKeyRotator 類別實作 API 金鑰輪換以突破每金鑰速率限制。關鍵方法：

get_next_key：返回下一個可用（未被限速）的 API 金鑰
mark_limited：將金鑰標記為已限速
send_request：使用下一個可用金鑰發送請求，若回應 429 則自動標記金鑰

run_rotation_test 方法執行 100 次請求，計算有效倍增係數（effective_multiplier），顯示金鑰輪換相較於單一金鑰的吞吐量提升。

步驟 5：視窗邊界利用

exploit_fixed_window 函式利用固定視窗速率限制器的邊界效應：

從 X-RateLimit-Reset 標頭讀取視窗重置時間
等待至視窗重置前 1 秒
在視窗重置前發送最大允許請求數（pre_window）
等待 1.5 秒使視窗重置
在新視窗剛開始時再次發送最大允許請求數（post_window）

結果是在短時間內發送了兩倍於預期限制的請求數（effective_limit）。滑動視窗算法對此免疫，因為它們追蹤個別請求的時間戳。

步驟 6：LLM 專用速率限制繞過

針對 LLM API 特有的速率限制架構，五種特定技術：

技術	描述	有效性
`model_parameter_variation`	不同模型參數可能被分開追蹤	低——大多數 API 按金鑰追蹤
`streaming_vs_blocking`	串流回應可能以不同方式計算	中等——部分實作對串流回應的符元計數不同
`batch_api_abuse`	批次 API 可能有獨立或更高的速率限制	中等——批次可以成倍提升有效吞吐量
`model_version_switching`	切換模型版本以利用每模型限制	中等——許多 API 有每模型限制
`organization_rotation`	建立多個具獨立計費的組織/專案	高——但需要多個帳戶

步驟 7：自動化速率限制測試

RateLimitTester 類別提供全面的速率限制測試框架：

_test_baseline：建立基準速率限制行為（每 50ms 發送一個請求，記錄哪個請求觸發 429）
_test_headers：測試 X-Forwarded-For 標頭輪換有效性（每次請求隨機 IP）

generate_report 方法輸出包含所有測試結果和五項建議的 JSON 報告：

使用實際 TCP 連接 IP，而非 X-Forwarded-For 進行速率限制
實作滑動視窗或令牌桶，而非固定視窗
對分散式速率限制使用原子操作
同時按 IP 和 API 金鑰進行速率限制以實現縱深防禦
為突發模式添加異常偵測

步驟 8：防禦建議

SlidingWindowRateLimiter 類別實作健全的速率限制算法，核心邏輯是：

為每個客戶端維護精確到秒的請求時間戳列表
每次請求時過濾掉超過視窗時間的時間戳
計算當前視窗內的請求數，超過限制則拒絕
此方法不受視窗邊界利用的影響

API 速率限制繞過

步驟 1：識別速率限制實作

步驟 2：基於標頭的繞過技術

步驟 3：分散式速率限制繞過

步驟 4：認證輪換

步驟 5：視窗邊界利用

步驟 6：LLM 專用速率限制繞過

步驟 7：自動化速率限制測試

步驟 8：防禦建議

相關主題

API 速率限制繞過

步驟 1：識別速率限制實作

步驟 2：基於標頭的繞過技術

步驟 3：分散式速率限制繞過

步驟 4：認證輪換

步驟 5：視窗邊界利用

步驟 6：LLM 專用速率限制繞過

步驟 7：自動化速率限制測試

步驟 8：防禦建議

相關主題

API 速率限制繞過

相關文章

API 速率限制繞過

相關文章