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

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

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

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

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

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

現(xiàn)場(chǎng)通常會(huì)看到活躍連接（尤其 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ǎng)問(wèn)日志還能發(fā)現(xiàn)同一 IP 維持大量長(zhǎng)期未完成的請(qǐng)求或異常長(zhǎng)的響應(yīng)時(shí)間。

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

如何防護(hù)

核心目標(biāo)就是盡快關(guān)閉拖延發(fā)送請(qǐng)求頭/請(qǐng)求體或極慢讀取響應(yīng)的連接，限制單 IP 的并發(fā)與速率，避免慢連接占滿(mǎn) 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。
• 反向代理場(chǎng)景：proxy_request_buffering on; 先把請(qǐng)求緩沖到 Nginx，避免慢上傳占住上游。
• 分路徑/分人群：對(duì)登錄、搜索等接口更嚴(yán)；對(duì)可信源/健康檢查放寬或白名單。
• 邊緣清洗：結(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;  # 等請(qǐng)求體每個(gè)讀周期的時(shí)間
    send_timeout           10s;  # 發(fā)送響應(yīng)給客戶(hù)端每個(gè)寫(xiě)周期的時(shí)間
    keepalive_timeout      10s;  # keep-alive 連接空閑時(shí)間
    keepalive_requests     100;  # 單連接最大請(qǐng)求數(shù)，防長(zhǎng)時(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 專(zhuān)項(xiàng)（若開(kāi)啟了 http2）
    http2_max_concurrent_streams 64; # 降并發(fā)流數(shù)
    http2_recv_timeout           5s; # 接收客戶(hù)端幀超時(shí)
    http2_idle_timeout          10s; # HTTP/2 空閑超時(shí)

    # 6) 合理的頭部緩沖（避免過(guò)大內(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;

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

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

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

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

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

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

• 高頻 API 可將 rate 調(diào)小、burst 適度放大；頁(yè)面類(lèi)流量可相反。
• 對(duì)上傳較多的業(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)。

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

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

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

總結(jié)

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

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

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

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

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

最新評(píng)論