如何判斷你的伺服器是在遭受 CC 攻擊，還是業務繁忙

當你的網站變得異常緩慢，甚至直接離線時，你往往很難分辨：這究竟是遭到了攻擊，還是因為流量太好。這裡先給出最直接的判斷方法：如果是真實流量激增，頻寬和 QPS 往往會同步上升；如果是 CC 攻擊，QPS 會明顯飆升，而頻寬通常相對平穩，因為這類應用層流量主要由大量短小、重複的第 7 層請求構成。你可以按照下面這套四步診斷與回應指南，判斷伺服器是否正在遭受 CC 攻擊。你將學會如何區分真實流量暴漲、網路層洪泛攻擊，以及 CC 洪泛攻擊，並據此採取正確措施。

先在監控中查看頻寬與 QPS

大多數情況下，這個問題只需在一個地方就能初步判斷：把頻寬和 QPS 放在同一時間軸上並排查看。規則很簡單。若是真實使用者流量激增，頻寬和 QPS 會同步上漲；若是 CC 攻擊，QPS 會飆升，而頻寬則相對平穩。原因很直接：CC 攻擊本質上是應用層洪泛，由大量短小、重複的 HTTP 請求組成。單個請求傳輸的資料量很小，因此佔用頻寬有限，但請求數量會迅速攀升。

當兩個指標同時上升時

打開你的監控面板，把兩張圖對齊來看。真正的流量高峰會表現為兩條曲線同步上揚。頁面瀏覽、檔案下載和 API 呼叫都會攜帶一定的資料負載，因此使用者越多，傳輸的位元組數也越多。你還可以在存取日誌中找到佐證：真實頁面請求和下載記錄會符合正常使用者存取路徑。不過這裡有一個需要注意的例外。國際鏈路波動有時會觸發 TCP 重傳，從而造成「頻寬看起來很滿」的假象。此時頻寬圖會突然升高，但其中相當一部分流量其實是重複資料，而不是真實存取。在下結論之前，應先將來源地區與平時的使用者分布做對比。

正常業務高峰和攻擊在一開始看起來可能非常相似。行銷活動、訊息推播或內容病毒式傳播，都可能同時拉高 QPS 和 CPU。此時要和你的常態基線對比。檢查來源地區是否符合你的使用者分布，存取路徑是否像真實使用者那樣——先打開頁面，再請求靜態資源和 API——而不是反覆只命中同一個介面。

當只有 QPS 單獨飆升時

你最需要捕捉的，就是這種「指標背離」。下表展示了結合圖表一起分析時，兩類攻擊是如何區分的。

對於 CC 攻擊，總頻寬通常相對平穩，但第 7 層 QPS、並發連線數和每秒新 HTTP 請求數會異常升高。對於網路層洪泛，頻寬和每秒封包數會急遽上升，而第 7 層 QPS 則可能保持平穩，甚至因為握手失敗而下降。這種對比，是你最快速的第一步判斷。先問自己：究竟是頻寬和封包量一起飆升了，還是只有請求速率單獨上去了？

以下三個輔助訊號，可以進一步確認第二種情況：

• CPU 長時間打滿，而頻寬並不突出

• 請求集中在少數幾個高消耗 URL 上

• 存取日誌中，同一批 IP 以高度規律的時間間隔反覆請求

當這些現象與 QPS 飆升、頻寬平穩同時出現時，就應先將其視為惡意流量，除非後續證據能夠證明並非如此。這也是判斷伺服器是否遭受 CC 攻擊、避免拍腦袋猜測的關鍵方法。

你的網站遭受的是 DDoS 還是 CC 攻擊？

到這裡，你已經知道第一個分界點：頻寬和 QPS 同時上升，多半是真實流量高峰；只有 QPS 單獨暴漲，則往往意味著麻煩。接下來的問題是：這究竟是哪一種麻煩？網路層洪泛和應用層洪泛會留下完全不同的痕跡，也需要採取不同的應對方式。判斷你的網站遭遇的是 DDoS 還是 CC 攻擊，關鍵就在於先確認攻擊發生在哪一層。

網路層與應用層的典型特徵

網路層 DDoS 最明顯的訊號，是頻寬突然飆升。流量型洪泛會將海量原始封包灌向你的鏈路，因此最關鍵的指標是每秒封包數（pps）。而應用層 CC 攻擊則恰恰相反。它會透過高頻發送 HTTP/HTTPS 請求，去模擬看似正常的使用者行為，目標通常是登入頁、搜尋頁、提交表單等動態頁面。每個請求本身都看起來合法，但目的在於耗盡伺服器 CPU、資料庫連線和其他計算資源，最終讓服務停止回應。在這種情況下，最重要的指標就是每秒請求數。

不過，並不是所有應用層攻擊都會表現為「請求風暴」。像 Slowloris 這樣的慢速攻擊同樣屬於這一層，但它並不會帶來高 QPS。它的特點是請求長時間保持未完成狀態，因此日誌量甚至可能並不會明顯增加。遇到這種情況，更應關注以下訊號：

• ESTABLISHED 連線長時間處於飽和狀態

• Web 服務工作程序耗盡，而 CPU 卻並不高

• 日誌量看起來正常，但網站已明顯變慢

向資料中心索取流量圖

網路層或傳輸層 DDoS 往往比較容易確認。你可以直接向資料中心索取對應 IP 的流量圖。如果圖上出現明顯的入站流量尖峰，再與你自身監控資料進行比對，通常就能很快確認。相比之下，應用層 CC 攻擊更難憑這類圖表直接判斷。因為其封包看起來非常普通，所以流量圖可能幾乎沒有明顯變化。此時你需要更深入地分析請求、連線和日誌，才能做出準確判斷。

很多管理員容易被一個陷阱誤導：攻擊持續時間。CC 攻擊者常常用短時間的攻擊流量去耗盡資源，所以一次短暫事件並不代表伺服器很快就會恢復正常。哪怕只是短短一波流量，也可能讓資料庫連線在攻擊結束後仍被耗空。因此，持續時間只能作為較弱的參考訊號，更應重視攻擊強度和請求模式。當你判斷伺服器是否正在遭受 CC 攻擊時，請求的形態遠比持續了多久更重要。如果你懷疑伺服器正在遭受攻擊，但流量圖卻沒有明顯波動，就繼續檢查連線狀態和存取日誌，後面的章節會說明如何操作。這也是在懷疑遭遇 DDoS 或 CC 式攻擊時，避免在錯誤層面浪費時間的正確排查思路。

檢查 TCP 連線狀態

監控圖告訴你應該往哪裡看，連線狀態則會告訴你系統內部究竟發生了什麼。你可以在主機上執行 netstat -an 或 ss -s，按狀態統計 socket 數量。一個健康的 Web 伺服器，會呈現與正常使用者負載相匹配、相對穩定的狀態分布。

識別異常的 SYN_RECV 與 TIME_WAIT

有兩個狀態尤其值得重點關注。第一，若有大量半開連線長期停留在 SYN_RECV，說明很多用戶端發起了握手，卻沒有完成後續過程。網際網路中存在少量此類雜訊是正常的，但如果這一數量持續攀升到數百甚至更高，並長時間不下降，就值得警惕。第二，TIME_WAIT 的含義不同。每個關閉的連線都會在短時間內留下一個 TIME_WAIT，所以繁忙網站本來就會有一些。但如果它們成千上萬地堆積，並且增長速度遠高於清理速度，就說明有大量短生命週期連線正在以機器速度不斷建立和關閉。這種模式更像是 CC 洪泛，而不是一大群真實使用者在存取。

將連線情況與真實使用者行為對比

數字本身只有放在基線中才有意義。建議你連續一週記錄伺服器在離峰期和尖峰期的連線數，這樣你就知道一個「正常的週二尖峰」應該長什麼樣。當前連線數應與這套基線做比較，而不是和零相比。真實使用者的行為也具有可識別性：他們會先載入頁面，再取得頁面資源，然後停下來閱讀。而攻擊來源則會不停地敲打某些介面，幾乎沒有停頓。

除了 socket 數量，還要留意其他輔助訊號。Ping 延遲升高、用戶端在工作階段中途頻繁斷線、伺服器從伺服器列表中消失，這些通常都說明是資源耗盡，而不是單純「太受歡迎」。網路層洪泛往往也會連 SSH 一起拖垮，而 CC 攻擊則常常不影響你正常登入。把這些線索視為輔助確認，而不是單獨證據。接下來繼續看日誌。

透過 Web 存取日誌識別 CC 模式

如果僅靠圖表和 socket 狀態仍難以判斷，就去查看 Web 存取日誌。日誌會記錄每一次請求，因此它往往比流量圖更能準確幫助你判斷伺服器是否正在遭受 CC 攻擊。CC 攻擊會留下清晰可讀的痕跡。大量請求會在短時間內集中湧入，而這些流量背後的模式，正是你判斷問題性質的關鍵。

重複路徑與單一來源連線

真實訪客的請求通常會分散在多個頁面上。他們會先存取首頁，再打開文章，同時請求圖片和腳本等靜態資源。攻擊流量則往往更集中。你會看到同一個 URL 被高頻刷新，且常常伴隨著來自單一來源位址的大量並發連線。最明顯的特徵是：某個用戶端反覆只請求同一個介面，比如登入表單或搜尋介面，而完全忽略靜態資源。此時你要問自己：存取日誌中是否在極短時間視窗裡，對同一路徑出現了大量請求？如果某些動態介面被帶著相同參數反覆衝擊，這更像是 HTTP/HTTPS 洪泛，而不是正常讀者存取。

使用日誌工具進行偵測與調查

日誌分析工具可以在日誌寫入的同時即時掃描，並自動標記上述模式。它們還能幫助你保留證據，這對於事後調查同樣重要。攻擊突增偵測又多加了一層防護：它會監測安全引擎的告警速率，一旦活動偏離正常範圍，就發出預警。藉助這些工具，你可以更有效地區分應用層攻擊與網路層攻擊。第 7 層洪泛會推高請求數，但封包量仍相對平穩，表現為第 7 層 QPS 上升卻沒有相應的頻寬增長；而較低層的 DDoS 則正好相反。這個對比能夠幫助你確認攻擊層級，並指導後續回應。

避免誤判，並採取正確回應

先排除常見誤報情況

促銷活動、電子報群發或某篇內容突然爆紅，都可能製造出看似「惡意」的流量高峰。在封鎖任何來源之前，務必先排除這些情況。先檢查你的行銷活動日曆和社群平台傳播情況，再對比來源地區是否符合平時的受眾分布。真實使用者通常來自你原本服務的區域，而且他們會先打開頁面，再請求其中的資源。爬蟲大規模抓取或監控機器人也可能抬高請求數。此時可以查看它們是否宣告了 User-Agent，以及請求頻率是否足夠克制。最後，還要確認這次流量峰值不是由不穩定的國際鏈路導致的重傳雜訊。重複資料封包會抬高流量圖，但並不會帶來真實使用者。

針對不同場景分別應對

如果是真實流量激增，應優先擴容並強化快取。橫向增加 Web worker，提升資料庫連線上限，並透過 CDN 分發靜態資源。如果業務允許，還可以快取已渲染頁面。這些措施能夠在不影響真實使用者的前提下有效吸收流量。

如果是 CC 攻擊，則需要分層處理。先按來源和介面實施速率限制；再對可疑用戶端加入 JavaScript 驗證或驗證碼挑戰。隨後檢查伺服器日誌中是否存在惡意腳本或已知漏洞利用，因為一台被攻陷的主機也可能正在參與洪泛。如果你懷疑遭受的是網路層攻擊，則應立即聯絡服務提供商進行上游清洗。這個層面的 DDoS，通常不是靠主機本地調校就能解決的。要學會根據各自的證據來調查不同類型事件：應用層洪泛會體現在請求日誌中，而第 7 層請求風暴往往不會顯著推高封包量。確認攻擊發生在哪一層，就用對應那一層的方法去處理。

透過「頻寬與 QPS 是否背離」來判斷，依然是識別伺服器是否遭受 CC 攻擊的最快第一步。只要先做這一項對比，就能避免一開始就在錯誤層面上猜測。隨後再逐層確認：系統回應情況、TCP 狀態以及存取日誌，都會進一步印證請求模式所揭示的問題。保持冷靜，按證據排查。在封鎖任何來源之前先驗證事實，在懷疑惡意之前也先考慮是否只是需要擴容。CC 洪泛和網路層 DDoS 都會留下各自鮮明的特徵，因此必須將解決方案和你確認的攻擊層級一一對應。最後，建議你現在就建立正常流量基線。連續一週記錄離峰與尖峰時段的資料，下一次再發生類似事件時，你會更容易做出準確判斷。

常見問題

我多快能判斷這是攻擊還是正常繁忙？

先把頻寬和 QPS 放到同一張圖上查看。若兩者同步上升，多半是真實需求增加；若 QPS 飆升而頻寬基本平穩，則更像是 CC 洪泛。通常幾分鐘內就能得到初步答案，而不是耗上幾個小時。

如果只是短暫當機，是否就能排除攻擊？

不能。攻擊者經常透過短時間的 CC 流量突襲，迅速耗盡資料庫連線和 worker 池。即便流量很快停止，服務也可能在之後長時間處於異常狀態。判斷依據應是請求模式，而不是持續時長。

CC 攻擊會不會「躲過」我的頻寬圖？

會。因為單個請求攜帶的資料量很小，所以頻寬圖可能幾乎不動。此時更應該關注請求速率、並發連線和 CPU 使用情況。相反，網路層 DDoS 通常會立刻在頻寬圖上表現出來。

在封鎖任何來源之前，我應該先檢查什麼？

先確認來源地區是否符合你的目標使用者分布；檢查你的行銷日曆中是否有促銷活動或內容爆紅；查看 User-Agent 判斷是否可能是爬蟲。真實流量和惡意流量在路徑多樣性上差異明顯，因此在採取措施前，一定要先閱讀日誌。

什麼時候應該聯絡服務提供商，而不是繼續調校伺服器？

當你看到封包量和頻寬同時飆升時，就應該聯絡服務提供商。這個特徵通常意味著遭遇的是網路層 DDoS，而上游清洗通常比主機本地調校更有效。至於應用層 CC 洪泛，則仍應主要在伺服器側進行處理。