網站在沒有任何設定或程式變動的情況下，有時仍可能突然出現效能異常，例如速度明顯下降、連線開始逾時，甚至回傳 502、503、504 等錯誤訊息。
遇到這類狀況時，除了檢查主機負載、程式效能與資料庫壓力之外，也應將 DDoS 攻擊納入可能原因之一。
DDoS 的主要目的並非入侵系統，而是透過大量請求消耗服務資源，使網站在一段時間內無法穩定提供服務。
什麼是 DDoS 攻擊
DDoS 的基本概念
DDoS 是 Distributed Denial of Service 的縮寫，中文常稱為分散式阻斷服務攻擊。這類攻擊的運作方式，是在短時間內從大量不同來源，同時對同一個服務發送請求，藉此消耗伺服器可用的網路、連線或運算資源。當資源被佔用到一定程度，即使系統本身沒有發生錯誤，正常使用者也可能因為無法即時取得回應，而感覺到服務變慢甚至無法使用。
由於這些請求來自分散的來源，從表面上看往往與正常流量相似，因此在第一時間不容易判斷是否屬於攻擊行為。
DDoS 攻擊的主要目的
與一般對資安事件的直覺想像不同，DDoS 攻擊通常不是為了取得資料，也不一定會嘗試入侵系統或取得權限。它的目的相對單純，主要是透過持續消耗資源，讓服務在一段時間內變得不穩定，甚至暫時無法對外提供功能。
當伺服器需要不斷處理大量請求時，即使每一筆請求本身並不複雜，累積起來仍可能造成回應延遲、連線中斷，或觸發各種錯誤狀態，進而影響整體可用性。
DDoS 與 DoS 攻擊的差異
DoS 攻擊與 DDoS 攻擊在概念上相似，都是以干擾服務正常運作為目的，但兩者在來源結構上有所不同。DoS 攻擊通常來自單一或少數來源，透過持續發送請求造成資源消耗，因此在流量識別與封鎖上相對單純。
DDoS 則是由大量分散來源同時發動，這些來源可能是真實裝置、被控制的設備、雲端節點或代理網路。其中最常見的來源型態稱為「殭屍網路」（botnet）——駭客透過惡意程式感染大量裝置並集中操控，讓這些裝置在同一時間對同一目標發動請求。由於請求來源遍佈各地，單純依賴封鎖特定 IP 或區段，往往難以有效阻擋，也使得整體防護與處理的難度明顯提高。
DDoS 與正常流量成長的行為差異
在正常情況下，網站流量成長通常伴隨較為合理的使用行為，例如使用者會瀏覽不同頁面、請求路徑分布自然，停留時間與操作節奏也具有一定變化。即使在短時間內流量放大，整體行為模式仍然具備可解釋性。
相對地，DDoS 攻擊所產生的流量，常呈現高度重複與集中的特徵。請求會在極短時間內反覆命中特定路徑或功能，行為節奏密集且單一，缺乏一般使用者操作所應有的變化。透過觀察請求行為的分布方式與節奏，通常可以初步區分流量成長是來自正常使用，還是屬於異常干擾。
DDoS 攻擊並非單一形式，而是針對系統瓶頸發動
DDoS 攻擊並不一定需要全面癱瘓整個系統，它的關鍵在於找出服務中最容易被耗盡的環節，並集中施壓。只要某個關鍵資源先達到上限，整體服務品質就會明顯下降，使用者也會率先感受到異常。
因此，實際影響網站穩定性的，往往不是整體硬體效能，而是其中某一個最先被打滿的瓶頸。
頻寬資源被大量佔用的情況
在部分 DDoS 攻擊中，請求量會大到直接佔滿對外網路頻寬。當網路出口被塞住時，即使伺服器本身仍有足夠的運算能力，封包也無法順利送達服務端或回傳給使用者。
這類狀況下，使用者常見的體感是網站整體變得極慢，甚至完全無法連線，而系統層面未必能立即顯示出明顯的 CPU 或記憶體異常。
連線數量達到上限所造成的影響
有些攻擊並不傳送大量資料，而是透過持續建立連線來消耗系統可同時處理的連線數量。當 Web 服務、反向代理或網路設備的連線池被佔滿後，即使新的請求本身並不複雜，也無法取得可用的連線資源。
此時，正常使用者可能會遇到連線逾時、請求失敗，或服務回應明顯延遲的情況，整體看起來就像系統「卡在還沒開始處理」的階段。
運算與應用層資源被消耗殆盡的狀況
另一類常見情形是攻擊集中在應用層，透過大量 HTTP 請求反覆觸發需要運算或存取後端資源的功能。這類攻擊的總流量不一定特別驚人，但會快速消耗 CPU、應用程式執行緒，或後端服務的連線資源。
當運算資源被持續佔用時，系統回應速度會逐漸下降，最終導致請求堆積、錯誤率上升，甚至服務暫時無法回應新的請求。
常見的 DDoS 攻擊類型，可從攻擊層級來理解
從實務角度來看，DDoS 攻擊可以依照它影響系統的層級來區分。
不同層級的攻擊，對網站造成的症狀與防護方式都不相同，因此理解攻擊發生在哪一層，往往是後續處理與防護的關鍵。
網路層攻擊（L3 / L4）
網路層攻擊主要針對網路傳輸與連線建立流程發動，目標是消耗網路設備或作業系統在處理封包與連線時的能力。這類攻擊常見於傳輸層或網路層，並不需要真正進入應用程式。
實際發生時，通常會看到大量 SYN、UDP 或其他異常封包同時湧入，導致連線佇列被佔滿，或網路設備忙於處理無效封包。其結果往往是整體延遲明顯上升，即使應用服務本身仍在運作，使用者也會感覺到連線不穩、回應變慢，甚至連管理用的遠端連線也受到影響。
由於攻擊發生在應用程式之前，這類型 DDoS 通常較難僅靠伺服器端的設定解決，往往需要在網路設備、上游供應商或防護服務層級進行處理。
實務上常見的網路層攻擊手法包括 SYN Flood（大量發送偽造的 TCP 連線請求，佔滿連線佇列卻不完成握手）、UDP Flood（持續發送大量 UDP 封包塞滿頻寬），以及俗稱 Ping Flood 的 ICMP Flood（透過大量 ICMP 封包耗用網路處理資源）。這些手法的共通點，是攻擊直接發生在封包與連線層級，不需要真正命中應用程式邏輯。
應用層攻擊（L7）
應用層攻擊則是直接針對網站或服務本身發動，請求形式看起來與正常使用者行為相似，但在頻率與集中度上遠高於一般情況。攻擊會刻意命中需要後端運算或資料存取的功能，例如動態頁面、搜尋介面、登入流程或 API 端點。
這類攻擊的總流量未必特別驚人，但由於每一筆請求都需要實際執行應用邏輯，會快速消耗 CPU、執行緒或後端服務連線。隨著資源被佔滿，回應時間會逐漸拉長，錯誤率開始上升，最終導致服務無法即時處理新的請求。
應用層攻擊的困難之處在於，它往往混雜在正常流量之中，單純依賴流量大小判斷並不可靠，必須結合行為模式與請求特徵來進行辨識。
常見的應用層攻擊手法包括 HTTP Flood（大量發送偽裝成正常瀏覽行為的 GET／POST 請求）與 Slowloris（刻意以極慢速度傳送請求標頭，讓連線長時間佔用卻遲遲不完成）。這兩種手法都不依賴龐大流量，而是利用請求的數量或拖延方式，讓後端資源提前見底。
反射與放大攻擊
反射與放大攻擊並非直接由攻擊者對目標發送請求，而是利用第三方服務或協定作為中介，將流量反射並放大後再指向目標。攻擊者實際送出的請求量可能不大，但經過放大後，目標端收到的流量卻成倍增加。
在這種情況下，目標伺服器看到的封包來源往往來自世界各地，看起來像是大量不同服務同時發送請求，因此很難從來源 IP 判斷真正的攻擊者位置。對受害端而言，表面上承受的是突如其來的大量封包與頻寬壓力，但實際攻擊源頭隱藏在背後。
這類攻擊的處理通常需要上游網路層級的協助，單靠應用層或主機層的防護手段，往往難以完全抵擋。
常見的反射放大手法包括 DNS 放大攻擊、NTP 放大攻擊與 Memcached 放大攻擊，三者都是利用查詢請求遠小於回應封包大小的協定特性來達成放大效果。根據 TWCERT/CC（台灣電腦網路危機處理暨協調中心）資料，Memcached 放大攻擊的放大係數可達 10,000 至 51,000 倍，是目前已知放大倍率最高的手法；NTP 放大攻擊次之，約為 556.9 倍；DNS 放大攻擊則約在 28 至 54 倍之間。
真實發生過的 DDoS 事件，讓抽象攻擊變得具體
DDoS 攻擊聽起來抽象，但實務上已經發生過多起具規模的真實案例，橫跨全球與國內、攻擊手法與規模也相當不同。透過這些案例，能更清楚理解 DDoS 對服務可用性造成的實際威脅程度。
2016 年 Dyn 事件，DDoS 史上規模最大的案例之一
2016 年 10 月，美國網路效能管理公司 Dyn 遭受大規模 DDoS 攻擊，攻擊流量最高達到 1.2 Tbps，是史上規模最大的 DDoS 事件之一。根據 TWCERT/CC 資料，發動攻擊的殭屍網路由逾 50 萬台網路攝影機組成，攻擊導致 Twitter、Amazon、Spotify、Netflix 等知名服務一度無法正常存取，也讓外界開始重視物聯網設備遭挾持組成殭屍網路的風險。這波攻擊的殭屍網路中，不少受控攝影機的 IP 位址來自國內，顯示物聯網設備一旦防護不足，也可能讓使用者在不知情的狀況下成為攻擊他國服務的一環。
2020 年國內主機代管商事件，元兇是弱密碼設備
2020 年 9 月 19 日至 23 日期間，國內多家主機代管商陸續遭到 DDoS 攻擊。根據 TWCERT/CC 資料，這起事件的特殊之處在於攻擊來源 IP 多數為國內位址，追查後發現元兇是大量使用弱密碼並開啟 Telnet 服務的數位錄影機（DVR）設備，遭駭客集中操控組成殭屍網路發動攻擊。這起案例說明，DDoS 的攻擊來源不一定來自海外，設備管理疏漏同樣可能讓本地裝置被納入攻擊行列。
2017 年券商勒索式攻擊，預告與實際規模有落差
2017 年初，國內逾十間證券公司接獲勒索訊息，要求支付比特幣，否則將發動 TB 等級的大規模攻擊。根據 TWCERT/CC 資料，攻擊者確實在預告時間發動攻擊，但實際攻擊流量多維持在 GB 等級，並未達到預告的 TB 級別，多數受影響公司在半小時內恢復正常運作。這起案例也提醒，勒索訊息中宣稱的攻擊規模，與實際發生的攻擊之間可能存在落差，仍應以實際觀察到的流量與影響為準，而非單憑威脅內容判斷風險程度。
常見症狀與判斷方式，如何辨識是否為 DDoS 影響
在實務上，許多人第一時間注意到的往往是錯誤碼，但錯誤碼本身只是結果，而非真正的原因。要判斷是否可能遭遇 DDoS 攻擊，更重要的是觀察系統行為與流量變化的整體模式。
當以下現象同時或反覆出現時，通常就需要將 DDoS 或其他異常流量納入排查範圍。
5xx 錯誤在短時間內明顯增加
當網站開始頻繁回傳 502、503、504 等錯誤，且錯誤數量集中出現在短時間內，通常代表後端服務無法即時回應請求。
502 常見於代理無法取得上游回應，503 多半與服務暫時不可用或資源不足有關，而 504 則通常表示上游回應超過可接受的等待時間。
如果這類錯誤在沒有部署更新、設定變更或流量活動的情況下突然爆量，往往不是單純的程式問題，而是系統承受了異常的請求壓力。
整體服務呈現不穩定狀態
另一個常見徵象是服務表現出現明顯波動，有時可以正常使用，有時卻幾乎無法連線。
這種「時好時壞」的狀態，常發生於攻擊以波段方式進行，或是系統資源在被塞滿後短暫釋放，又再次被大量請求佔用。
對使用者而言，這種狀況往往比完全無法連線更難判斷，但從系統角度來看，卻是異常流量持續干擾的典型特徵。
監控指標出現不合理的尖峰
在監控系統中，DDoS 常會伴隨突發性的資源使用異常，例如 CPU 使用率瞬間拉高、同時連線數快速增加、請求數暴增，或應用服務的執行緒與工作佇列長時間處於滿載狀態。
這類狀況有時會在重啟服務後短暫改善，但很快又再次發生。
如果資源異常呈現反覆出現的模式，而非隨時間自然回落，通常就不是單一故障事件，而是持續性的外部壓力所造成。
存取日誌呈現高度重複或異常分布
透過存取日誌觀察請求行為，也能提供重要線索。
當特定路徑在極短時間內被大量重複請求，或來源 IP 雖然分散，但請求行為高度一致，通常就不符合一般使用者的操作模式。
此外，User-Agent 分布異常、格式混亂，甚至出現大量空白或相同特徵的請求，也常是自動化流量的跡象。
這些行為單獨出現時未必能立即定論，但若與前述症狀同時發生，則極有可能與 DDoS 或其他惡意流量有關。
實際遭遇 DDoS 時，處理順序比細節更重要
當網站疑似受到 DDoS 影響時，第一時間最重要的，並不是立刻釐清所有攻擊來源或分析完整攻擊手法。從實務經驗來看，更有效的處理方式，是先確保服務能持續運作，再逐步判斷攻擊型態，最後才補齊長期防護措施。
這種由急到緩、由外而內的處理順序，能在壓力最大的時候先控制影響範圍，避免問題在尚未釐清前就全面擴大。
優先確保服務可用，降低即時資源消耗
處理初期的首要目標，是避免服務整體失效。此時應優先採取能立即降低系統負擔的措施，例如提升快取命中率、減少即時計算需求，或暫時停用資源消耗較高但非關鍵的功能。
如果系統本身已有防護平台或 WAF，通常也會建議先切換至較嚴格的防護策略。即使短時間內可能影響部分正常請求，這樣的取捨仍比服務完全中斷來得可控，也能爭取後續分析與調整的時間。
判斷攻擊發生的層級，選擇正確的阻擋位置
在服務暫時穩定之後，下一步便是嘗試判斷攻擊主要集中在哪一個層級。若異常表現集中在頻寬或封包層級，單純在伺服器端新增規則，往往難以產生明顯效果，因為流量本身已經佔滿對外線路。
相對地，若影響主要出現在應用層，則需要針對特定路徑、請求頻率或行為模式進行限制，避免後端資源持續被大量消耗。是否能正確判斷攻擊發生的位置，往往直接決定後續防護措施是否有效。
記錄關鍵資訊，為後續分析保留依據
在事件進行期間，盡可能保留相關紀錄，對後續處理與防護調整非常重要。這些資訊包含異常開始與結束的時間點、流量或請求的峰值區間、主要受影響的路徑、錯誤碼分布，以及來源國家或 ASN 的變化情況。
即使當下無法立即進行深入分析，也應先確保資料被妥善保存，避免事件結束後失去判斷攻擊型態與調整策略的重要依據。
服務恢復後，補齊防護以避免重複發生
在實務上，DDoS 攻擊很少只發生一次，常見情況是短暫測試、暫停觀察，再重新發動。因此，若服務恢復後未針對事件中暴露的弱點進行補強，往往很快就會再次受到影響。
此時應根據事件期間蒐集到的資訊，重新檢視防護規則、限流策略與架構設計，將已被命中的瓶頸納入長期防護範圍，降低未來遭遇相同攻擊時的衝擊程度。
防護 DDoS 的正確思路，在於分層而不是硬撐
面對 DDoS 攻擊時，最常見的誤解之一，是試圖讓單一系統或單一防護措施承受所有流量壓力。然而在實務上，能長期維持穩定的防護策略，幾乎都不是靠某一個工具完成，而是透過分層設計，將不同型態的流量分散到不同層級處理。
這種做法的核心目的，是盡可能讓異常流量在系統外圍就被吸收或削弱，避免所有請求同時落到來源主機，讓核心服務只需要處理真正合理且必要的存取行為。
CDN 與邊緣節點，先吸收大量流量
在多數網站架構中，第一層防護通常發生在靠近使用者的網路邊緣。透過分散於各地的邊緣節點，流量會在進入來源主機之前先被分流與處理，其中大量重複或明顯異常的請求，往往可以在這個階段就被消化掉。
這樣的設計可以有效降低頻寬與連線層級承受的瞬間壓力，也能避免來源主機直接暴露在高強度流量之下，成為第一個被打滿的瓶頸。
WAF 規則要能快速切換
當流量行為處於正常狀態時，防護規則通常會維持在相對寬鬆的設定，以減少對一般使用者造成不必要的影響。然而一旦請求模式開始出現異常，若規則無法隨之快速調整，防護效果便會明顯下降。
具備彈性調整能力的防護機制，能夠在必要時針對特定來源、行為或請求特徵收緊檢查條件，讓防護策略隨著實際狀況變化，而不是固定不變。
Rate Limiting 是最實用的防護手段
在許多應用層攻擊中，真正造成壓力的並不是單一請求的內容，而是請求出現的頻率過於密集。當同一類請求在短時間內被大量重複觸發，即使每一次處理成本不高，累積起來仍可能迅速耗盡系統資源。
透過適當的請求頻率限制，可以讓這類行為逐漸變得不可持續，在不影響多數正常使用者的前提下，有效降低後端服務被長時間佔用的風險。
保護來源主機，避免被繞過防護直打
即使前端已經部署了多層防護，若來源主機仍可被直接存取，整體防護效果仍然有限。攻擊者一旦繞過外層機制，直接對來源主機發送請求，前端的防護便形同失效。
因此，限制來源主機僅接受來自特定節點或信任來源的流量，是實現真正隔離的重要一環。透過這種方式，可以確保所有進入核心系統的請求，都已經通過前層的基本檢查。
快取與效能策略，是降低衝擊的重要基礎
即使在沒有攻擊的情況下，快取與效能設計本身就是網站穩定性的關鍵因素。當系統能夠將大量重複請求轉化為不需要每次重新計算的回應時，整體承載能力自然會提升。
在流量異常的情境下，良好的快取策略更能顯著降低後端負擔，使系統即使面臨短時間的請求暴增，也不容易立即進入資源耗盡的狀態。
常見的 DDoS 防護服務類型，各自適合什麼情境
在落實分層防護的原則之外，實際要選用哪一種服務來處理這件事，也是許多網站管理者會遇到的問題。依照防護發生的位置與運作方式，大致可以分成幾種類型，適合的規模與情境也不盡相同。
| 防護類型 | 代表服務 | 運作方式 | 適合對象 |
|---|---|---|---|
| CDN／邊緣防護 | Cloudflare、Fastly | 將網域 DNS 交由代管，流量在進入來源主機前先經過全球節點過濾與分流 | 中小型網站、部落格、電商，希望不更換主機、能快速啟用防護 |
| 雲端原生防護 | AWS Shield、Azure DDoS Protection、Google Cloud Armor | 與雲端基礎設施深度整合，針對該平台上的資源自動偵測並緩解異常流量 | 服務本身就架設在對應雲端平台上，且已在使用該平台其他資源 |
| 骨幹層級洗流量服務 | Akamai、電信商高防專線 | 由網路骨幹層級大量吸收與清洗流量，通常需另行簽約導入 | 大型企業、金融服務或需承受極大規模攻擊的關鍵系統 |
| 主機／伺服器內建防護 | 多數虛擬主機與 VPS 業者 | 提供基本的封包過濾與連線限制，防護量體有限 | 作為最基礎的第一道防線，不足以單獨抵擋大規模攻擊 |
以第一類 CDN／邊緣防護型服務來說，多數中小型網站已經足以應付常見規模的攻擊，其運作原理與實際啟用方式，可參考「Cloudflare 是什麼？功能、原理與使用情境完整介紹」一文，這裡不重複展開。
DDoS 不是神秘攻擊，它是可管理的穩定性事件。DDoS 本身並不是特殊或罕見的事件，而是任何對外提供服務的網站，都可能遇到的營運風險之一。與其期待完全不發生，更實際的做法，是事先理解它會怎麼影響系統，並為發生時留下調整空間。
當防護架構與處理流程已經建立，即使面對突發的流量衝擊，狀況也不再是不可控的危機，而是一個可以被判斷、被緩解、被修正的過程。
這樣的準備，才是網站長期穩定運作真正倚賴的基礎。