烏克蘭連襲 Yandex 資料中心，Cloudflare 顯示 Bot 流量幾乎歸零：俄羅斯資訊戰機器人真的癱瘓了嗎？

一、俄羅斯的 Google 遭到攻擊，機器人流量突然消失？

2026 年 10 月 11 日，一張來自 Cloudflare Radar 的網路流量圖表在社群平台上引起關注。

圖表顯示，俄羅斯科技巨頭 Yandex 所屬的 AS13238 自治系統，在一段原本相當穩定的自動化 HTTP 流量之後，突然出現接近垂直的下降曲線。

藍色流量線在短時間內跌至接近零，並且在截圖涵蓋的剩餘時段維持低位。

更引人注意的是，這個時間點與 Yandex 位於俄羅斯 Vladimir 地區的資料中心遭到無人機攻擊相近。

於是，一種說法迅速出現：烏克蘭是否透過攻擊 Yandex 資料中心，意外或刻意癱瘓了俄羅斯的大規模網路機器人系統？

這個推論具有吸引力，因為 Yandex 不只是搜尋引擎，也經營雲端平台、企業服務、AI 模型與其他數位基礎設施。

如果大型資料中心遭到實體破壞，部署在其中的自動化程式確實可能停止運作。

但問題在於，圖表究竟證明了什麼？

首先需要確認的是，這張圖顯示的是 Yandex 特定網路的 HTTP 請求變化，而不是整個俄羅斯網際網路的活動。

其次，Cloudflare 對 Bot Traffic 的分類包含正常搜尋爬蟲、監控程式與其他自動化客戶端，並不直接判斷它們是否參與政治宣傳。

因此，這起事件真正值得研究的，不只是流量有沒有下降，而是如何從公開網路觀測資料，判斷一次實體攻擊對數位基礎設施造成的影響。

二、四天三座機房：Yandex 遭襲事件時間線

根據 Reuters、Financial Times 與 Yandex 官方公告，2026 年 10 月上旬，Yandex 多座重要資料中心接連遭到攻擊。

10 月 8 日：Sasovo 資料中心完全關閉

第一起重大事件發生於 10 月 7 日深夜至 8 日凌晨。

Yandex 位於俄羅斯梁贊州 Sasovo 的資料中心遭到無人機攻擊，設施嚴重受損並完全停止運作。

Yandex 在 10 月 9 日的官方聲明中確認，Sasovo 資料中心已完全關閉，工程團隊仍在評估設備狀況。

這座設施的重要性不只在於一般網路服務。

根據 Reuters 報導，Sasovo 還部署了 Yandex 三套主要 AI 超級電腦中的兩套。

這意味著事故可能同時影響雲端服務與人工智慧研發能力。

不過，資料中心停止運作不代表其中的超級電腦已經全部遭到摧毀。設備損壞程度仍需要更多公開證據確認。

10 月 9 日：Kaluga 資料中心部分設施失效

10 月 9 日，Yandex 又確認位於 Kaluga 的另一座資料中心遭到攻擊。

官方聲明指出，部分基礎設施已經停止運作，現場工程團隊正在進行評估。

這座資料中心是 Yandex 重要的運算與雲端設施之一。

根據 Tom's Hardware 報導，其設計電力容量約為 63 MW，配置超過 3,800 個伺服器機櫃。

需要注意的是，63 MW 是設施規模指標，並不代表攻擊當時正在使用的實際電力，也不能直接換算成損壞的 GPU 數量。

10 月 11 日：Vladimir 資料中心關閉

10 月 11 日，Reuters 再次報導，Yandex 位於 Vladimir 地區的資料中心因無人機攻擊而關閉。

Yandex 表示，該事件沒有造成員工受傷，但部分服務無法正常使用。

這是短短數日內第三座傳出重大中斷的 Yandex 資料中心。

值得注意的是，社群流傳的 Cloudflare Radar 截圖，也是在 10 月 11 日凌晨前後顯示 AS13238 的 Bot 流量急遽下降。

兩件事情的時間接近，但目前尚缺乏足夠的公開資料，可以確認 Vladimir 機房遭襲就是流量崩跌的唯一或直接原因。

三、Cloudflare 圖表究竟顯示了什麼？

這次流傳的截圖來自 Cloudflare Radar，查詢對象為：

AS13238 YANDEX — Yandex LLC

圖表包含兩個主要區域。

左側是 Bot vs. Human，顯示所選期間內的 HTTP 請求分類比例。

右側是 Bot Traffic，顯示自動化 HTTP 請求量隨時間變化的趨勢。

截圖左側顯示：

這個數字很容易造成誤解。

99.6% 是所選期間內被分類為 Bot 的 HTTP 請求占比，不是 Bot 流量下降了 99.6%。

換句話說，它說明觀測到的請求中，自動化流量占據絕大多數，但不能直接拿來計算事故造成的跌幅。

真正顯示流量急跌的，是右側時間序列。

從截圖可以觀察到，在 10 月 10 日的大部分時間，Bot 流量保持相對穩定。

到了 10 月 11 日凌晨前後，藍色曲線突然向下，短時間內接近零值。

圖中代表上一週的灰色虛線則維持在相對穩定的高位。

這表示所選時間內的變化，與圖表提供的歷史比較基準存在明顯差異。

然而，截圖沒有提供可讀取的絕對 HTTP 請求數量，也沒有完整標示時區與資料匯出設定。

因此，雖然可以描述為流量斷崖式下降，卻不宜直接宣稱已經精確證實下降 99.6%、99.9% 或其他特定百分比。

四、AS13238 是什麼？為什麼不能代表整個俄羅斯？

要理解這張圖，首先必須認識 Autonomous System，簡稱 AS，也就是自治系統。

網際網路不是由單一中央網路構成，而是由大量獨立營運的網路互相連接。

電信業者、雲端服務供應商、大型企業與內容平台，都可能擁有自己的自治系統。

每個自治系統使用一組 Autonomous System Number，也就是 ASN 進行識別。

AS13238 是與 Yandex 相關的自治系統之一。

Cloudflare Radar 可以按照 ASN 分析 HTTP 請求來源，讓研究人員觀察特定網路的流量變化。

但一個 ASN 並不等於一家企業的所有網路資產。

大型科技公司可能使用多個自治系統、不同網路服務供應商、海外資料中心與第三方雲端平台。

同樣地，俄羅斯境內的自動化服務，也不可能全部集中在 Yandex 的單一 ASN 中。

因此，即使 AS13238 的 Bot 流量完全停止，也只能說明 Cloudflare 所觀察到的該網路來源請求出現重大變化。

不能因此推論整個俄羅斯的搜尋爬蟲、社群自動化系統或政治宣傳網路全部停止運作。

AS13238 的流量異常，是特定網路事件，不是全國網路活動的完整統計。

五、Cloudflare 如何判斷一個請求是 Bot？

Cloudflare 使用多種方法分析 HTTP 請求是否來自自動化程式。

其中一項核心技術是 Bot Score。

Bot Score 的數值範圍通常為 1 至 99。

分數越低，代表系統越傾向判斷該請求來自自動化工具；分數越高，則越傾向判斷來自一般人類使用者。

根據 Cloudflare 官方文件，Radar 將 Bot Score 介於 1 至 29 的請求歸類為 Likely Automated，而 30 以上則歸類為 Likely Human。

這種分類可能參考請求特徵、瀏覽器訊號、機器學習模型與其他偵測方法。

但 Bot Score 判斷的是自動化可能性，不是使用者的政治立場，也不是內容的真實性。

例如，以下活動都可能產生 Bot Traffic：

搜尋引擎爬蟲定期索引網站內容。

企業監控程式檢查服務是否正常運作。

自動化工具大量呼叫網站 API。

資料分析服務定期收集公開資訊。

惡意程式掃描網站漏洞或嘗試登入。

政治宣傳系統透過自動化帳號發布或轉傳內容。

這些活動在網路行為上都可能具有自動化特徵，但目的完全不同。

此外，Cloudflare Radar 官方文件指出，其 Bot vs. Human 分析預設可能聚焦 HTML 內容，藉此排除部分 API 與靜態資源請求。因此，分析不同圖表時，也必須確認內容類型與篩選條件是否一致。

Bot 不等於惡意程式，更不等於政治水軍。

六、為什麼 Yandex 本來就可能產生大量 Bot 流量？

Yandex 是俄羅斯重要的搜尋引擎業者。

搜尋引擎必須透過自動化爬蟲持續存取網站，才能建立與更新搜尋索引。

例如，當某個網站新增文章，搜尋引擎可能派出爬蟲讀取網頁、解析連結、取得文字內容，並將資訊加入搜尋系統。

這些請求不是人類使用者手動點擊產生的，而是由自動化程式執行。

對 Cloudflare 來說，它們可能被分類為 Bot Traffic。

因此，一個大型搜尋引擎所屬網路出現極高比例的自動化 HTTP 請求，本身並不令人意外。

尤其當分析對象是資料中心或服務供應商網段，而不是一般家庭寬頻網路時，自動化請求的占比可能非常高。

這也是為什麼圖表中 99.6% 的 Bot 比例，不能直接視為異常活動的證據。

真正值得關注的是時間序列的突變。

如果某個網路原本持續產生大量爬蟲請求，卻突然停止，那麼可能意味著搜尋索引工作、排程系統、網路出口或其他基礎設施出現問題。

但若沒有進一步區分 Verified Bots、搜尋引擎爬蟲、未知自動化程式與其他請求類型，就無法知道究竟是哪一類流量消失。

七、資料中心遭到攻擊，為什麼可能讓 Bot 流量瞬間歸零？

從技術角度來看，資料中心停擺確實可能造成自動化 HTTP 請求突然減少。

第一種可能，是執行自動化程式的伺服器直接停止運作。

假設搜尋爬蟲部署在特定機房，機房因電力、冷卻或網路設備故障而關閉，這些爬蟲就可能無法繼續發送請求。

第二種可能，是共用的網路出口失效。

即使伺服器本身仍然正常，如果資料中心的核心路由器、交換器或對外連線中斷，外部網站仍然可能看不到它們的流量。

第三種可能，是控制與排程系統停止運作。

大型自動化服務通常不只包含執行工作的 Worker，也可能依賴中央排程、任務佇列、資料庫與設定管理服務。

如果控制系統發生故障，即使部分 Worker 仍然在線，也可能無法取得新的工作。

第四種可能，是企業主動暫停非必要工作。

當多座資料中心接連受損時，營運團隊可能優先恢復搜尋、郵件、支付與其他核心服務，暫時停止部分背景排程與資料收集工作。

第五種可能，是流量來源網段改變。

如果 Yandex 將部分工作遷移到其他機房或第三方雲端，原本來自 AS13238 的請求可能減少，但相同服務可能從其他 ASN 繼續運作。

因此，某個 ASN 的流量消失，不一定代表服務完全停止，也可能代表服務已經改變網路出口。

八、BGP 與路由變化：看起來像伺服器消失，實際上可能是網路搬家

現代網際網路主要依靠 Border Gateway Protocol，簡稱 BGP，讓不同自治系統交換路由資訊。

大型企業可以透過 BGP 宣告自己的 IP 網段，讓其他網路知道應該如何傳送封包。

當資料中心遭到攻擊，企業可能調整路由、撤銷部分網段宣告，或將服務轉移到其他出口。

這些變化可能影響 Cloudflare Radar 觀察到的來源網路分布。

例如，一個原本由 AS13238 發出的自動化請求，如果改由另一個網路出口送出，Cloudflare 可能將其歸入不同 ASN。

從 AS13238 的圖表來看，流量可能大幅下降。

但從整體服務角度來看，部分工作仍可能持續執行。

要區分這些情況，可以比對攻擊前後的 BGP 路由宣告、相關 IP Prefix 的可達性，以及其他 Yandex 相關 ASN 的流量變化。

如果路由宣告仍然穩定，但 HTTP 請求突然消失，可能更需要調查應用程式或工作排程層面的故障。

如果路由本身出現大規模撤銷或轉移，則需要考慮網路基礎設施故障與流量遷移。

不過，目前公開報導尚未提供足以完整重建這次事件的 BGP 與應用層資料，因此不能指定某一種機制作為已確認的原因。

九、俄羅斯資訊戰機器人真的被摧毀了嗎？

這是整起事件最吸引人、但也是證據最不足的部分。

俄羅斯長期受到有關網路影響力操作與假訊息活動的調查與討論。

自動化帳號、內容農場、社群協同操作與政治宣傳，是資訊戰研究的重要主題。

但這些活動不一定由同一家公司執行，也不一定使用同一種技術架構。

更重要的是，Cloudflare Radar 的 Bot Traffic 不會直接標記某個請求是否用於政治宣傳。

即使研究人員確認 AS13238 的自動化流量下降，也仍然需要回答幾個問題。

這些請求原本是搜尋引擎爬蟲，還是其他類型的自動化工具？

是否存在證據顯示它們正在操作社群平台帳號？

這些請求是否涉及政治內容發布、轉傳或互動？

受影響的自動化工作是否真的部署在遭襲資料中心？

相關活動是否轉移到其他雲端或海外網路？

如果缺少這些證據，就不能從單一 ASN 的流量曲線，直接推導出俄羅斯資訊戰系統遭到全面摧毀。

另外，社群平台上的自動化活動可能經由住宅代理、第三方雲端、不同國家的主機或平台內部 API 執行。

這些活動未必會在 Yandex 的網路流量中留下明顯痕跡。

因此，最合理的描述是：Yandex 所屬網路的自動化 HTTP 流量出現重大異常，但其與俄羅斯政治宣傳系統之間的關係尚未證實。

十、為什麼三座資料中心接連受損，比單一機房故障更值得關注？

大型雲端服務通常會設計冗餘機制，避免單一設備故障造成整體服務中斷。

例如，企業可能使用多台伺服器提供相同服務，或將資料複製到不同機房。

當其中一台主機失效時，其他主機可以接手工作。

這種機制稱為 Failover，也就是故障切換。

但 Failover 的有效性取決於備援系統是否具有足夠容量，以及資料是否已經同步。

如果只是單一機房停擺，其他機房可能仍有能力接管工作。

但當多座資料中心在短時間內接連受損，企業就可能面臨更複雜的問題。

例如，原本預留給災難復原的運算容量可能已經被第一波故障使用。

當第二座或第三座資料中心也停止運作，剩餘系統就可能無法繼續承擔全部負載。

這種情況稱為 Capacity Exhaustion，也就是備援容量耗盡。

此外，大型平台的不同服務可能共用資料庫、儲存、身分驗證與排程系統。

即使某個服務的前端部署在其他地區，只要它依賴的後端系統失效，仍可能出現連鎖故障。

這次 Yandex 事件的特殊之處，正是在短時間內接連出現多個實體設施中斷。

它提醒雲端產業：擁有多座資料中心，不代表已經具備承受多座資料中心同時或連續失效的能力。

十一、AI 超級電腦也受到威脅：從搜尋爬蟲到大型語言模型

Yandex 不只經營搜尋引擎，也投入人工智慧模型與相關技術研發。

根據 Reuters 報導，Sasovo 資料中心部署了 Yandex 三套主要 AI 超級電腦中的兩套。

這些設備的重要性，與一般 Web 伺服器有所不同。

大型 AI 訓練叢集通常需要大量 GPU、專用高速網路、大容量儲存與穩定的電力系統。

如果資料中心停擺，受影響的可能不只是網站回應速度，也包括模型訓練、實驗排程與研發效率。

例如，正在執行的模型訓練工作可能需要依靠 Checkpoint，也就是訓練檢查點，才能從中斷前的狀態恢復。

即使模型資料與 Checkpoint 已經備份，企業仍然需要足夠的 GPU 資源才能重新啟動訓練。

對受到先進半導體出口限制影響的俄羅斯而言，高階 AI 加速器與相關設備的替換可能更加困難。

不過，現有公開資料尚不足以確認 Yandex 在此次攻擊中實際損失多少 GPU、多少訓練算力，或特定 AI 模型開發計畫受到多少延誤。

因此，AI 算力風險值得關注，但不能將其寫成已經確認的永久性算力損失。

十二、如果要真正證明資訊戰受到重創，還需要哪些資料？

要把目前的網路流量異常提升為可靠的資訊戰研究，需要進行跨資料來源分析。

首先，需要取得 AS13238 攻擊前後的完整 HTTP 請求時間序列，包含絕對請求數量、時間戳記與內容類型。

其次，需要區分不同 Bot 類別，確認下降的主要是搜尋引擎爬蟲、一般自動化程式，還是其他未知流量。

第三，需要比較其他 Yandex 相關自治系統的流量，檢查是否發生網路出口轉移。

第四，需要觀察 BGP 路由宣告與 IP Prefix 可達性，判斷是否存在網路層面的重大變化。

第五，需要分析外部社群平台的公開活動資料，例如可疑帳號的發文頻率、互動網路與內容同步模式。

但這類分析必須遵守平台資料存取規則與個人隱私要求，不能將一般使用者的自動化活動任意標記為政治宣傳。

第六，需要將資料中心遭襲的時間與流量下降時間對齊，並確認兩者使用相同時區。

最後，還需要建立對照組。

例如，同一時段其他俄羅斯大型網路是否也出現異常？其他搜尋引擎爬蟲是否維持正常？Cloudflare 是否發生分類或觀測方法變化？

只有在排除其他合理解釋後，才能對資料中心攻擊與特定資訊活動之間的因果關係提出更強的判斷。

十三、這起事件揭露了數位戰爭的新問題

傳統討論網路戰爭時，常見主題包括 DDoS、勒索軟體、惡意程式與系統入侵。

但 Yandex 事件顯示，現代數位基礎設施也可能受到直接的實體攻擊。

一座資料中心包含的不只是伺服器。

它還依賴供電系統、冷卻設備、網路交換器、光纖連線、儲存設備與消防設施。

只要其中某個關鍵系統失效，即使部分伺服器沒有受到直接破壞，整座機房仍可能無法繼續提供服務。

當搜尋、支付、企業雲端與 AI 訓練集中於大型資料中心，實體設施的可用性就可能影響整個數位經濟。

不過，資料中心同時也承載大量民用服務。

對資料中心的軍事攻擊是否符合國際人道法，需要根據具體設施的用途、是否構成軍事目標、預期軍事利益、平民附帶損害與攻擊預防措施進行判斷。

不能單純因為某座設施具有戰略重要性，就認定對它的任何攻擊都合法。

這也是為什麼 AI、雲端運算與網路基礎設施的韌性，正在從企業 IT 管理問題延伸到國家安全與國際法領域。

十四、結論：流量確實出現異常，但不能把 Bot 直接翻譯成水軍

2026 年 10 月，Yandex 多座資料中心接連遭到無人機攻擊，是已經受到主要媒體與公司官方聲明支持的事件。

使用者提供的 Cloudflare Radar 截圖，也顯示 AS13238 在相近期間出現不尋常的自動化 HTTP 流量崩跌。

這兩項資訊放在一起，確實形成一個值得深入調查的技術問題。

資料中心的實體破壞，是否造成搜尋爬蟲、雲端自動化服務或其他網路工作突然停止？

部分服務是否因為多座機房接連受損而失去備援能力？

相關工作是否已經遷移到其他自治系統？

這些問題都具有實際研究價值。

但目前最需要避免的，是把三個不同層次的結論混在一起。

第一，Yandex 資料中心遭到攻擊，具有明確的新聞與官方資料支持。

第二，AS13238 的 Bot HTTP 流量在截圖期間急遽下降，具有公開觀測圖表佐證，但仍缺少完整原始數據。

第三，俄羅斯假訊息機器人網路因此幾乎全面癱瘓，目前沒有足夠證據可以證實。

對科技產業而言，這起事件真正重要的地方，是它讓人看到實體基礎設施與網路行為之間可能存在的直接連動。

當搜尋引擎、AI 模型、企業雲端與自動化系統都依賴大型資料中心，機房不再只是存放伺服器的建築物，而是數位社會運作的重要節點。

一張突然貼近零值的流量曲線，可能是理解這種依賴關係的起點。

但要從曲線走到真相，仍然需要網路工程、資安鑑識與嚴謹的證據分析。

---

Tech English：本文技術名詞

1. Autonomous System Number, ASN（自治系統編號）：用來識別網際網路中獨立路由網路的編號。AS13238 是與 Yandex 相關的自治系統之一，不代表整個俄羅斯網路。

2. Bot Traffic（機器人流量）：由自動化程式產生的 HTTP 請求，可能包含搜尋爬蟲、監控工具、API 客戶端與惡意自動化活動，不等同於政治宣傳流量。

3. Bot Score（機器人評分）：Cloudflare 用來評估 HTTP 請求是否可能來自自動化程式的指標，數值通常介於 1 至 99。

4. Border Gateway Protocol, BGP（邊界閘道協定）：網際網路自治系統之間交換路由資訊的協定，可協助分析資料中心故障後的網路可達性與流量遷移。

5. Failover（故障切換）：當主要系統停止運作時，將服務或工作負載轉移至備援系統的機制，前提是備援容量與資料同步足以支援接管。

6. Cascading Failure（連鎖故障）：某個系統的失效透過服務依賴關係影響其他系統，造成故障範圍逐漸擴大的現象。