最近在出一個前端的體系課程，里面的內(nèi)容非常詳細，如果你感興趣，可以加我 v 進行聯(lián)系 yunmz777:

浪費你幾秒鐘時間，內(nèi)容正式開始

慢速攻擊是一類用很少帶寬就能長期占用服務器連接/資源的攻擊方式。攻擊者通過非常慢地發(fā)送請求頭或請求體，或極慢地讀取服務器響應，讓每個連接都“掛著不結束”，從而耗盡 Web 服務器（或上游應用、數(shù)據(jù)庫、代理）的并發(fā)與緩沖資源。

典型類型主要有以下幾個方面：

• Slowloris（慢請求頭）：客戶端以極低速率分片發(fā)送 HTTP 頭部，始終不把頭部發(fā)完，服務器就一直等待。
• Slow POST / RUDY（慢請求體）：先宣稱要上傳較大的 Content-Length，然后以極慢速率發(fā)送請求體，服務器為其保留緩沖與上游連接。
• Slow Read（慢讀取響應）：客戶端窗口/讀取速率極低，迫使服務器緩沖并保持連接很久（尤其響應較大時）。
• HTTP/2 變種：濫用單連接多流（streams）和窗口控制：開很多流但每流都很慢，放大資源占用。

傳統(tǒng) DDoS 依靠高帶寬與高包速直接壓垮網(wǎng)絡/設備，而慢速攻擊用極低帶寬長期占用連接，更隱蔽，常被誤認為是網(wǎng)絡狀況差的正常用戶。

現(xiàn)場通常會看到活躍連接（尤其 reading）持續(xù)攀升，但總體帶寬并不高。

error_log 中頻繁出現(xiàn) client timed out、client sent invalid header while reading client request headers 等信息。

上游服務看似空閑卻體驗發(fā)卡，Nginx 的 429/502/504 增多，訪問日志還能發(fā)現(xiàn)同一 IP 維持大量長期未完成的請求或異常長的響應時間。

• 429 表示“請求過多被限流”，通常稍后或按 Retry-After 重試即可。
• 502 表示“網(wǎng)關收到上游無效響應或連不上上游”，多見于上游掛掉、拒連或協(xié)議不匹配。
• 504 表示“等待上游超時”，通常是上游處理太慢一直沒回。

如何防護

核心目標就是盡快關閉拖延發(fā)送請求頭/請求體或極慢讀取響應的連接，限制單 IP 的并發(fā)與速率，避免慢連接占滿 worker 的 worker_connections 與上游資源。

• 收緊超時：client_header_timeout、client_body_timeout、send_timeout、keepalive_timeout。
• 超時立刻復位：reset_timedout_connection on; 減少 TIME_WAIT/ 資源滯留。
• 限并發(fā)/限速：limit_conn、limit_req（必要時返回 429 并帶 Retry-After）。
• HTTP/2 參數(shù)：降低 http2_max_concurrent_streams，設置 http2_recv_timeout/http2_idle_timeout。
• 反向代理場景：proxy_request_buffering on; 先把請求緩沖到 Nginx，避免慢上傳占住上游。
• 分路徑/分人群：對登錄、搜索等接口更嚴；對可信源/健康檢查放寬或白名單。
• 邊緣清洗：結合 CDN/WAF 的連接層/應用層限速更穩(wěn)。

一些相關的配置可以參考下面的 Nginx 配置：

worker_processes auto;

events {
    worker_connections  4096;
    multi_accept        on;
}

http {
    # 1) 關鍵超時（防慢頭/慢體/慢讀）
    client_header_timeout  5s;   # 等頭部時間
    client_body_timeout    10s;  # 等請求體每個讀周期的時間
    send_timeout           10s;  # 發(fā)送響應給客戶端每個寫周期的時間
    keepalive_timeout      10s;  # keep-alive 連接空閑時間
    keepalive_requests     100;  # 單連接最大請求數(shù)，防長時間占用

    # 2) 連接超時直接復位（釋放資源更快）
    reset_timedout_connection on;

    # 3) 并發(fā)限制（每 IP）
    #    10m 可容納 ~160k 鍵（基于 $binary_remote_addr）
    limit_conn_zone $binary_remote_addr zone=perip:10m;

    # 4) 速率限制（每 IP），按需調大/調小 rate
    limit_req_zone  $binary_remote_addr zone=req_perip:10m rate=10r/s;

    # 5) HTTP/2 專項（若開啟了 http2）
    http2_max_concurrent_streams 64; # 降并發(fā)流數(shù)
    http2_recv_timeout           5s; # 接收客戶端幀超時
    http2_idle_timeout          10s; # HTTP/2 空閑超時

    # 6) 合理的頭部緩沖（避免過大內(nèi)存占用；默認已夠用，按需微調）
    large_client_header_buffers 4 8k;

    server {
        listen 443 ssl http2;
        server_name example.com;

        # 并發(fā)/速率在 server 層生效
        limit_conn       perip 20;        # 每 IP 并發(fā)連接上限
        limit_conn_status 429;

        limit_req        zone=req_perip burst=20 nodelay;  # 短突發(fā)
        limit_req_status 429;

        # 限制請求體大?。ㄅ浜?body_timeout 可更快淘汰異常大/慢上傳）
        client_max_body_size 10m;

        # 【反向代理站點強烈推薦】先把完整請求緩沖到 Nginx
        # 避免上游被慢上傳拖住連接
        location / {
            proxy_pass http://app_backend;
            proxy_request_buffering on;

            proxy_connect_timeout  3s;
            proxy_send_timeout    10s;  # 向上游發(fā)送（寫）超時
            proxy_read_timeout    30s;  # 自上游讀取（讀）超時
        }

        # 對靜態(tài)資源可放寬速率限制以提升體驗（示例）
        location ~* \.(?:css|js|png|jpg|jpeg|gif|webp|ico|svg)$ {
            root /var/www/html;
            access_log off;
            expires 30d;
        }

        # 自定義 429 頁面（可選）
        error_page 429 /429.html;
        location = /429.html { internal; return 429 "Too Many Requests\n"; }
    }
}

除此之外，還有一些數(shù)值上的建議：

• 高頻 API 可將 rate 調小、burst 適度放大；頁面類流量可相反。
• 對上傳較多的業(yè)務，將 client_body_timeout 與 proxy_request_buffering on; 組合尤為關鍵。
• 如果公網(wǎng)復雜、遭遇中等強度慢攻：client_header_timeout 2-3s、client_body_timeout 5-8s、send_timeout 8-10s 往往更穩(wěn)。

考慮到移動網(wǎng)絡或跨境訪問確實可能很慢，限流需要在防護與容錯間取平衡?？梢赃m度調大 burst，并返回合理的 Retry-After，讓偶發(fā)擁塞得以通過。把嚴格策略僅應用在登錄、搜索等敏感接口，對靜態(tài)資源和頁面流量適當放寬。對可信來源（如辦公網(wǎng)、監(jiān)控、合作方）設置白名單或更高配額，盡量減少誤殺。

之于上面的理解，我們可以針對不同慢速攻擊的做不同的優(yōu)化了：

• Slowloris（慢頭部）：用 client_header_timeout 嚴控請求頭收齊時間，配合較短的 keepalive_timeout 降低長連駐留，并用 limit_conn 限制每 IP 并發(fā)；一旦超時，借助 reset_timedout_connection on; 立即復位斷開。
• RUDY / Slow POST（慢體）：設置較短的 client_body_timeout，并開啟 proxy_request_buffering on; 先在 Nginx 緩沖請求體，慢上傳直接在邊緣被淘汰且不上游；必要時配合 client_max_body_size 約束體積。
• Slow Read（客戶端讀超慢）：通過 send_timeout 限制客戶端讀取過慢的連接，觸發(fā)即復位釋放緩沖；若是 SSE/長輪詢等合法長連，為對應路徑單獨放寬 send_timeout，避免誤傷。

總結

慢速攻擊是用極低帶寬長期占用服務器連接/緩沖的攻擊：攻擊者故意慢發(fā)請求頭/請求體或慢讀響應，讓連接一直不結束，耗盡并發(fā)與內(nèi)存。

常見形態(tài)有 Slowloris（慢頭部）、RUDY/Slow POST（慢請求體）與 Slow Read（慢讀響應），在 HTTP/2 下還能通過多流+窗口控制放大影響。

典型癥狀是活躍連接（尤其 reading）持續(xù)升高但總體帶寬不高，日志頻繁出現(xiàn)超時/異常頭部，且 429/502/504 增多、同一 IP 大量長時間未完成請求。

防護要點是收緊超時（client_header/body/send/keepalive）、開啟 reset_timedout_connection、用 limit_conn/limit_req 控制每 IP 并發(fā)與速率，反向代理時啟用 proxy_request_buffering on; 并調優(yōu) HTTP/2；同時對敏感路徑更嚴、對可信來源適度放寬或白名單以減少誤殺。

到此這篇關于nginx配置防止慢速攻擊的的文章就介紹到這了,更多相關nginx 防止慢速攻擊內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論