DDoS 是什麼？DoS 與 DDoS 差別、常見症狀與防護方式

DDoS（Distributed Denial of Service，分散式阻斷服務）是大量分散來源同時消耗網站、主機或網路資源，讓正常使用者無法順利連線。網站變慢不一定就是 DDoS；設備故障、程式錯誤、資料庫塞車、DNS 異常或正常活動帶來的流量尖峰，也可能出現相似症狀。

這篇只從防禦角度介紹判斷、準備與事件應變，不包含攻擊指令、流量產生方式或規避防護的方法。所有安全測試都必須限定在自己擁有或取得明確授權的系統。

DoS 與 DDoS 有什麼差別？

DoS 和 DDoS 的目的都在影響服務可用性，主要差別是流量或請求的來源結構。

項目	DoS	DDoS
中文名稱	阻斷服務	分散式阻斷服務
常見來源	單一或較集中的來源	許多分散的裝置、網路或來源
阻擋難度	有時可從單一來源著手處理	來源分散，單靠封鎖 IP 通常不足
可能影響	主機、應用程式或一段連線	網站、DNS、網路頻寬、主機與上游設備
防護重點	服務限制、資源保護與來源控管	CDN/WAF、流量清洗、上游協調與分層防護

「分散」不代表每個來源都會產生很大的流量。大量來源各自只送出少量請求，加總後仍可能超過連線、頻寬或應用程式的承受能力。

L3/L4 容量型與 L7 應用層 DDoS 差在哪裡？

實務上可以先把常見情況分成兩個觀察方向，但事件可能同時包含多種類型。

L3/L4：先壓滿網路或連線資源

L3/L4 指網路層與傳輸層。這類事件常讓頻寬、每秒封包數、連線追蹤表或防火牆資源先到上限。即使網站主機本身還有 CPU 和記憶體，使用者也可能因為上游線路已經壅塞而連不上。

這類容量問題通常不是只在主機上加一條防火牆規則就能解決。當流量已經塞滿網站前方的線路，往往需要 ISP、機房、主機商或流量清洗服務在更上游處理。

L7：用看似正常的網站請求消耗應用程式

L7 是應用層，例如 HTTP 或 HTTPS。請求表面上可能像一般使用者瀏覽，但集中在搜尋、登入、結帳、API 或其他較耗資料庫與運算資源的功能。

這時候頻寬不一定明顯升高，卻可能看到：

Web 或 API 回應時間突然拉長。
CPU、記憶體、PHP worker、Node.js 程序或資料庫連線耗盡。
特定 URL 的請求數異常集中。
大量 429、502、503、504 或逾時紀錄。
首頁正常，但登入、搜尋或 API 無法使用。

因此，判斷時要同時看網路、主機、應用程式與服務商告警，不能只看總流量。

網站變慢就是 DDoS 嗎？

不是。下面這些現象可以列為警訊，但不能單獨證明是 DDoS：

網站或 API 突然無法使用。
頻寬、封包數或連線數持續異常升高。
CPU、記憶體或資料庫連線突然用滿。
某些頁面收到遠高於平常的請求。
防火牆、DNS、CDN 或主機商發出異常通知。
同一時間有多個服務變慢或斷線。

也要排除正常活動、程式部署失敗、DNS 設定錯誤、憑證問題、資料庫鎖定、磁碟空間不足、網路設備故障與上游維護。你可以先用 Ping 與 Traceroute 基礎檢查比較不同地點的連線，再對照監控、應用程式日誌與供應商狀態頁。

DDoS 會不會代表網站已經被入侵？

DDoS 主要影響「可用性」，不等於攻擊者已取得主機權限或竊取資料。不過，DDoS 也可能和其他安全事件同時發生，或被用來分散維運人員注意力。

事件處理時仍應檢查：

管理員與系統帳號是否有陌生登入。
程式、網站檔案、排程或設定是否被修改。
API key、密碼與金鑰是否有異常使用。
日誌是否中斷、被清除或出現不合理時間差。
對外連線與 DNS 紀錄是否被變更。

不要因為看到大流量就忽略其他入侵跡象，也不要在沒有證據時直接宣稱資料外洩。

網站應該怎麼做分層防護？

沒有任何單一設備或服務能保證完全擋住所有 DDoS。較實際的做法是讓不同層各自處理適合的問題。

1. CDN 與 Anycast 網路

對公開網站來說，CDN 可以讓靜態內容由分散節點提供，並在流量抵達原始主機前先吸收或分類部分請求。設定前要確認 DNS、HTTPS、快取規則與真實使用者來源判斷方式，不能只把網域切換過去就視為完成防護。

可先參考 Cloudflare DNS 與 CDN 設定教學。不同方案的防護範圍、流量限制與事件支援方式不一樣，正式上線前要閱讀服務條款。

2. WAF 與 rate limiting

WAF（Web Application Firewall）適合依照 URL、請求特徵或已知風險攔截應用層異常；rate limiting 則可以限制特定功能在一定時間內的請求量。

設定時要先了解正常使用量，並特別測試登入、API、付款、搜尋、Webhook 與搜尋引擎爬蟲。門檻過低會把正常使用者擋掉，門檻過高則可能沒有實際效果。

3. 主機與應用程式保護

停用不需要公開的服務與連接埠。
為 Web、API、資料庫與背景工作設定合理的逾時和資源上限。
對高成本功能做快取、佇列或降級設計。
將管理介面限制在必要來源並啟用多因素驗證。
保持作業系統、Web 伺服器、框架與套件更新。
把日誌送到獨立或集中式儲存，避免主機故障後一起遺失。

4. ISP、機房與主機商

如果攻擊量超過你的對外線路，處理位置必須往上游移。事前就要向 ISP 或主機商確認：

是否提供 DDoS 偵測、流量清洗或臨時緩解服務。
哪些服務是自動啟用，哪些需要通報後人工處理。
緊急聯絡窗口、服務時間與需要提供的資訊。
流量超量、封鎖或黑洞路由的觸發條件。
事件期間能提供哪些流量圖、日誌與報告。

黑洞路由可能同時丟棄正常和異常流量，目的是保護其他網路或服務，並不等於網站仍能正常使用。對需要固定 IP、雲端白名單或多據點連線的企業，可先整理需求後參考企業網路與固定 IP 服務。

平常應該準備哪些監控資料？

沒有平時基準，就很難判斷事件發生時什麼叫「異常」。至少保留：

每分鐘或每五分鐘的頻寬、封包與連線數。
Web/API 的每秒請求、回應時間與錯誤率。
CPU、記憶體、磁碟 I/O、程序與資料庫連線。
CDN、WAF、DNS、防火牆、負載平衡器與應用程式日誌。
正常熱門 URL、使用地區、尖峰時段與活動排程。
ISP、主機商、CDN、DNS 與維運人員的緊急聯絡方式。

監控最好能從外部地點檢查服務，並讓告警走不同管道。若網站和告警系統使用同一台主機，主機故障時可能連告警也收不到。

懷疑正在發生 DDoS 時怎麼處理？

可以依照下面的順序處理，實際步驟仍要配合自己的服務架構與供應商流程。

第一步：確認影響範圍

記錄事件開始時間、受影響的網域、IP、服務與地區。
從不同網路檢查 DNS、網站、API 與其他服務。
比較頻寬、封包、連線、錯誤率、CPU 與應用程式日誌。
確認是否剛好有部署、活動、設備故障或上游維護。

第二步：聯絡正確的供應商

容量型或線路已塞滿：先聯絡 ISP、機房或主機商。
網站請求異常：同步檢查 CDN、WAF、rate limiting 與應用程式。
DNS 無法解析：聯絡 DNS 代管商並檢查網域與名稱伺服器狀態。

通報時提供開始時間、目的 IP 或網域、影響服務、監控圖表與已做的變更，可以減少來回確認時間。

第三步：保留日誌與時間線

匯出 CDN、WAF、防火牆、Web、應用程式與系統日誌。
記錄規則、DNS、路由與服務設定的每一次變更。
保留告警、工單、供應商回覆與流量報告。
確認各系統時區與時間同步，避免事後對不上時間線。

不要為了讓服務「看起來乾淨」就先刪除日誌。若必須重啟或切換服務，先記錄當時狀態與原因。

第四步：恢復後做檢討

確認真正的瓶頸是在頻寬、設備、主機還是應用程式。
檢查防護規則是否誤擋正常客戶與搜尋引擎。
補上監控、聯絡窗口、容量與切換流程的缺口。
保存事件摘要，並安排下一次演練或規則複查。

中小企業需要買 DDoS 防護嗎？

先從風險與中斷成本判斷，不必只看網站規模：

網站停機會不會讓客戶無法下單、付款或聯絡？
API、DNS、Email 或雲端白名單是否依賴同一條線路？
團隊是否能在非上班時間聯絡 ISP、主機商與 CDN？
現有方案是否包含防護，還是事件發生後才另外計費？
可以接受多久的服務中斷？

一般形象網站可先建立 CDN、WAF 基本規則、外部監控、日誌與供應商聯絡流程。交易網站、關鍵 API、自建機房或對外固定 IP 服務，則要更早確認上游容量、清洗方式與服務等級。防護目標應該是降低中斷機率與縮短恢復時間，而不是承諾「永遠不會被打掛」。

重點整理

DoS 常指單一或集中來源；DDoS 由大量分散來源共同造成影響。
L3/L4 常先消耗頻寬、封包或連線資源；L7 可能直接拖慢 Web、API 與資料庫。
流量升高、網站變慢或 CPU 滿載都只是線索，必須和 DNS、網路、主機、程式與日誌一起判斷。
CDN、WAF、rate limiting、主機調校與上游 ISP 各自處理不同層面的問題。
事件發生前準備基準值、日誌、聯絡窗口與處理流程，比臨時找工具更重要。
沒有絕對防護；正確目標是分層降低風險、保留證據並縮短中斷時間。