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

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

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

典型類型主要有以下幾個(gè)方面：

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

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

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

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

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

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

如何防護(hù)

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

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

一些相關(guān)的配置可以參考下面的 Nginx 配置：

worker_processes auto;

events {
    worker_connections  4096;
    multi_accept        on;
}

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

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

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

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

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

    # 6) 合理的頭部緩沖（避免過大內(nèi)存占用；默認(rèn)已夠用，按需微調(diào)）
    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;

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

            proxy_connect_timeout  3s;
            proxy_send_timeout    10s;  # 向上游發(fā)送（寫）超時(shí)
            proxy_read_timeout    30s;  # 自上游讀?。ㄗx）超時(shí)
        }

        # 對靜態(tài)資源可放寬速率限制以提升體驗(yàn)（示例）
        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 調(diào)小、burst 適度放大；頁面類流量可相反。
• 對上傳較多的業(yè)務(wù)，將 client_body_timeout 與 proxy_request_buffering on; 組合尤為關(guān)鍵。
• 如果公網(wǎng)復(fù)雜、遭遇中等強(qiáng)度慢攻：client_header_timeout 2-3s、client_body_timeout 5-8s、send_timeout 8-10s 往往更穩(wěn)。

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

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

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

總結(jié)

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

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

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

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

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

最新評論