# <center>『雲端貓居 NyankoHost』<br>11月12日服務故障事件報告</center>
> 發佈單位：Ryan • [@rqtl._.](https://github.com/itsrqtl)
> 發布日期：2025 年 11 月 15 日

2025 年 11 月 12 日，『雲端貓居 NyankoHost』因遭受分散式阻斷服務 (Distributed Denial-of-Service, DDoS) 攻擊，導致控制面板於香港標準時間 (UTC+8) 14:09 至 15:20 期間間歇性無法訪問；及後由於針對攻擊之修復過程中出現配置錯誤，US2 節點在 15:50 至 17:14 及 20:10 至 20:32 期間部分功能暫時不可使用。是次事件中所有使用者的資料機密性和完整性並未受到影響。

我們了解伺服器服務穩定性對使用者至關重要，對於服務故障造成的不便我們深表歉意。以下我們將詳細說明是次事件經過、所採取的應對措施，以及未來我們將如何改善並處理同類事件。

## 事件經過

### 第一波攻擊
Cloudflare 的記錄顯示，在香港標準時間 (UTC+8, 下同) 14:03 開始出現異常的 HTTP 流量導向控制面板 (server.nyanko.host)、峰值約為每分鐘12萬次請求。短時間内這些請求尚未完全過載控制面板的主機、僅導致面板的回應變得不穩定。在 14:09 至 14:11 期間，監控系統 Uptime Kuma 先後兩次發出控制面板無法存在的通知，並在短暫中斷後回復正常。Cloudflare 也在 14:11 記錄到第一波攻擊流量告一段落。我們團隊於 14:12 確認了這兩次共計約兩分鐘的停機時間，當下判斷僅為短時間的問題，沒有對整體服務造成實質影響，因此並未立即啟動更進一步的調查與防禦措施。

### 第二波攻擊
在 14:25 時，Cloudflare 再次記錄到異常流量上升，第二波攻擊開始。從 14:26 起，控制面板在數分鐘間多次反覆出現短暫的 502 錯誤與連線逾時，監控系統 Uptime Kuma 亦一直記錄到在離線狀態與恢復之間切換。與此同時，使用者也開始回報無法連線至控制面板。14：27，我們團隊正式注意到控制面板的異常狀態，並開始針對可能的故障原因展開排查。

隨著狀態的多次切換，我們在 14:49 確認這並非偶發的故障，而是一場由大量 HTTP 請求引起、針對『雲端貓居 NyankoHost』的分散式阻斷服務攻擊。在確認攻擊性質後，我們在 14:58 開啟了 Cloudflare 的 Under Attack Mode，讓所有進入控制面板的請求都需要通過嚴格的機器人挑戰和風險評估。根據 Cloudflare 的記錄，攻擊流量在打開 Under Attack Mode 後絕大多數被 Cloudflare 擋下，隨後在 15:00 明顯減緩並停止。

由於 Under Attack Mode 的嚴格檢查會導致節點與控制面板的通訊部分受阻、同時觀測到流量已經顯著下降，我們於 15:10 將其關閉。而幾乎在同一時間，Cloudflare 在 15:11 再次記錄到攻擊流量的出現。所幸這一波流量規模較小且持續時間短，在 15:18 再次減弱並停止，監控系統 Uptime Kuma 亦在短暫後的 15:19 回報控制面板恢復正常。

在第二波攻擊期間，Cloudflare 總共記錄到 502 萬次請求、峰值約為每分鐘24萬次。

### 緩解攻擊後的處理
為了在短時間内增加一層額外保護以應對可能再次出現的攻擊，我們在 15:40 於 Cloudflare 設定了一組全域速率限制，將單一來源IP在短時間内可發出的請求數限制在每10秒300次。這項設定在短期內提供了額外一道防線，但同時也不是非常有效。在進一步評估之後，我們在 15:50 將策略調整為地理限制，只允許來自香港與台灣的使用者直接存取控制面板，而來自其他地區的流量則暫時被拒絕。

根據 Cloudflare 的記錄，在 15:55 至 15:56 期間再次記錄到異常流量短暫出現、共約12萬次請求，但全部均被先前所設置的地區限制擋下。

### 修復處理的配置錯誤
在調整 Cloudflare 限制不久後的 16:06 有使用者回報 US2 節點的部分功能無法正常使用。我們立刻展開調查並在 16:30 確認 US2 節點的問題與節點主機本身無關，而是節點無法與控制面板 API 正常通訊所造成。16:42 時，為更全面檢查問題根源，我們公告進入了維護狀態、重啟了 TEST1 節點、US2 節點，以及控制面板，造成了大約5分鐘的全面停機。

排查過程在 16:55 得到明確結果。我們發現前一階段為了限制可連線地區而建立的主機白名單設定有誤 (缺少 US2 節點的 IPv6 地址)，導致節點與控制面板之間的合法通訊也被阻擋。確認原因後，我們在 17：02 修正相關設定，節點重新與控制面板建立穩定連線，服務逐步恢復。17:12，所有相關服務自維護模式中解除，恢復正常對外提供服務。

在服務恢復之後，我們繼續對地區限制進行微調。17:23，基於實際使用需求，我們將馬來西亞加入可連線地區。接著在 17:58，我們進一步關閉原先基於地理位置的限制，改為要求所有不屬於主機間通訊白名單的連線通過 Cloudflare 的 Managed Challenge，以風險評估與行為分析為主要判斷依據。

### 内部開發的配置錯誤
晚間 20:10，為了支援內部開發需求，我們在 internal DNS 中新增了兩項紀錄，以便在某些情境下繞過部分 Cloudflare 限制進行測試。隨後在 20:20，有使用者回報 US2 節點再度出現部分功能無法運作的情況。團隊在 20:22 確認問題確實存在，並立即檢視近期的設定變更。排查顯示，這次的異常與新加入的 internal DNS 記錄有關，該記錄讓節點無法正確解析控制面板的 IP，導致節點無法與控制面板正常通訊。在 20:31 我們刪除了相關記錄並重新啟動受影響的節點服務，US2 節點與其他服務隨即恢復正常

為確保不再出現潛在影響，我們在晚間持續監控所有服務的狀態與 Cloudflare 記錄，直到 21:42 確認各項服務穩定、未再出現異常後，正式宣告本次事件結束。

## 攻擊分析
綜合 Cloudflare、Uptime Kuma 與 Zabbix 的記錄，是次事件是一場針對控制面板的 Layer 7 HTTP Flood 攻擊。攻擊者透過對特定 URL 大量發送 HTTP 請求消耗伺服器資源，從而使合法使用者無法在同一時間正常連線。此次攻擊總共產生約 572 萬次 HTTP 請求、總流量約為 37 GB。

從來源分布來看，流量集中於多個國家與地區，其中以印尼為主，其次為美國、孟加拉、哥倫比亞、菲律賓等。與此同時，我們觀察到大部分請求型態一致、頻率集中，與典型的殭屍網路行為高度吻合，因此我們判斷是次事件並非單一攻擊者或少數 IP 所為，而是利用受控設備大規模同時發動的自動化攻擊。

## 影響評估
就整體影響而言，這次攻擊主要影響的是控制面板服務的可用性。至 14:09 起，控制面板在攻擊期間多次出現短暫中斷及高延遲，其後又因為防禦策略與配置調整衍生節點通訊問題，造成 US2 節點與部分相關服務在 16:06 至 17:12 以及 20:10 至 20:31 之間出現無法正常運作的情形。

即便如此，大多數運行中的伺服器實例本身在大部分時間保持正常，且未觀察到任何資料遺失、異常，或未經授權的操作。所有使用者帳號、伺服器檔案與資料庫內容，無論在本次攻擊期間或事後檢查中，皆未發現遭到入侵或外洩的跡象。

## 後續改善計畫
這次事件讓我們重新檢視在有限人力與資源下，小型團隊該如何有效地面對 DDoS 攻擊。『雲端貓居 NyankoHost』目前僅為二人團隊，沒有大型企業的資訊安全部門、也沒有全天候待命的網路營運中心，但我們仍會在力所能及的範圍内持續改善系統的可靠性。

在防禦策略方面，我們會持續調整 Cloudflare 的規則與驗證邏輯，讓挑戰機制及速率限制等更加合理。我們也會逐步改良控制面板與節點之間的通訊方式，使其在面臨攻擊或需要臨時調整設定時，避免因單一設定錯誤導致多個服務同時受影響。

在營運流程方面，我們會完善内部系統的變更管理與事件回應程序，尤其是白名單、防火墻、DNS 等較容易影響整體服務的設定，確保每一項變更都能有更清楚的預先檢查與回滾方案，降低因臨時調整造成錯誤的風險及縮短故障排查時間。

在日常運作中，我們也會更密切觀察 Cloudflare、Uptime Kuma 與 Zabbix 提供的資料，讓這些監控工具成為提升反應能力與架構穩定性的基礎。對於我們而言，經驗與紀錄本身便是非常重要的資源，能讓我們在下一次遇到故障或攻擊時更快掌握修復方向。

最後，隨著服務持續成長，我們也會視情況考慮擴充團隊人手。我們深知穩定的服務來自穩定的團隊，而在未來適當的時候我們將邀請更多的成員以分擔監控、營運與事件應對的工作量，讓『雲端貓居 NyankoHost』整體具備更好的彈性與回應速度。

## 結語

這次攻擊與後續的問題暴露了在快速應對網路攻擊時，如何在安全與可用性之間取得平衡的挑戰。雖然最終所有服務在當日恢復正常，且使用者資料從未遭受任何損害，但我們十分重視這次事件對使用者造成的困擾與不便。

『雲端貓居 NyankoHost』將持續以透明、負責的態度面對所有重大事件，並把每一次挑戰視為改進的機會。我們感謝所有使用者在本次事件期間的耐心與理解，也承諾會持續強化基礎架構與防禦機制，讓未來的『雲端貓居 NyankoHost』更安全穩定。