訂閱以接收新文章的通知:

2023 年第二季度網際網路中斷摘要

2023-07-27

閱讀時間:14 分鐘
本貼文還提供以下語言版本:EnglishFrançaisDeutsch日本語한국어简体中文

Cloudflare 在 100 多個國家/地區的 300 多座城市開展業務,並與 12,000 多個網路提供者互連,從而為數百萬個客戶提供多種各樣的服務。我們的網路和客戶群覆蓋範圍非常廣泛,為我們提供了一個有關網際網路復原能力的獨特視角,讓我們能夠觀察網際網路中斷所產生的影響。

Q2 2023 Internet disruption summary

2023 年第二季度是網際網路中斷特別頻繁的一個季度,尤其是政府指示的網際網路關停。在本季度,我們觀察到許多短暫的中斷,但也有不少長期的中斷。除了政府指示的網際網路關停外,我們還觀察到由於惡劣天氣電纜損壞停電、一般或未詳細說明的技術問題網路攻擊軍事行動以及基礎結構維護而導致的部分或完全中斷。

正如我們過去所指出的那樣,本文旨在對觀察到的中斷進行概括總結,而不是羅列該季度內所發生問題的詳盡或完整的清單。

政府指示

Government directed

在一些中東和非洲國家,春末通常標誌著所謂「考試季」的開始,學生們要參加一系列中學考試。為了防止考試作弊,各國政府已開始在考試前和考試期間實施大規模的網際網路關停。我們過去曾報導過這些關停,包括 2021 年的蘇丹敘利亞以及 2022 年的敘利亞、蘇丹和阿爾及利亞。今年,我們看到伊拉克、阿爾及利亞和敘利亞政府採取了此類行動。

伊拉克

報導,在今年的網路關停開始前幾週,伊拉克通訊部宣布拒絕教育部提出的在考試期間關閉網際網路以防止作弊的請求。不幸的是,這種拒絕很短暫,最終在兩週後開始關停。

在伊拉克,觀察到兩次關停:一次影響了除庫爾德斯坦地區之外的全國范圍內的網路,而另一次則影響了庫爾德斯坦地區內的網路。前一次關停與 9 年級和 12 年級考試有關,計劃於當地時間 6 月 1 日至 7 月 15 日 04:00 至 08:00(世界標準時間 01:00 - 05:00)之間進行。下圖顯示,6 月份期間,6 月 1 日、4 日、6 日、8 日、11 日、13 日、15 日、17 日、21 日、22 日、24 日、25 日和 26 日發生了關停,導致網際網路連線嚴重中斷。多家網路提供者均實施了關停,包括 AS203214 (HulumTele)、 AS59588 (Zain)AS199739 (Earthlink)AS203735 (Net Tech)AS51684 (Asiacell)AS58322 (Halasat)。下圖中橙色突出顯示的區域顯示,每個網路提供者的流量在關停期間降至零。

如上所述,伊拉克庫爾德斯坦地區也實施了與考試相關的網際網路關停。一份報導援引庫爾德斯坦地區政府教育部長的話說,「考試期間將根據需要關閉網際網路,但就像往年一樣,網際網路關停的時間不會很長,而是比較短暫的。」為此,觀察到的關停通常持續約兩個小時,發生在當地時間 6 月 3 日、6 日、10 日、13 日、17 日和 24 日 06:30 至 08:30(世界標準時間 03:30 - 05:30)之間。下圖顯示了該地區三家網路提供者的影響:AS21277 (Newroz Telecom)AS48492 (IQ Online)AS59625 (KorekTel)

有關伊拉克兩次網際網路關停的更多詳細資料,請參閱我們 6 月 13 日的部落格文章:伊拉克和阿爾及利亞與考試相關的網際網路關停使連通性受到考驗

阿爾及利亞

2023 年是阿爾及利亞中斷網際網路連線以防止全國考試作弊的第六年。2022 年,我們注意到「阿爾及利亞政府似乎已轉向基於內容封鎖的方法,而不是大規模關停網際網路。」今年似乎採取了同樣的方法,因為我們再次觀察到每個考試日期間流量有兩次輕微的下降,而不是完全沒有流量。這些流量變化是在行動網路提供者 AS33779 (Ooredoo/Wataniya)AS327931 (Djezzy/Optimum)AS327712 (Mobilis/Telecom Algeria)上觀察到的。第一次中斷發生在當地時間 08:00 - 12:00(世界標準時間 07:00 - 11:00)之間,第二次中斷發生在當地時間 14:00 - 17:00(世界標準時間 13:00 - 16:00)之間。

敘利亞

繼 2022 年實施了四次與考試相關的網際網路關停之後,今年僅關停了兩次。當地時間 6 月 25 日至 26 日 05:00 - 08:30(世界標準時間 02:00 - 05:30)發生了網際網路關停。政府附屬電信公司 Syrian Telecom (AS29256)Facebook 帖文中通知用戶,應教育部的要求,網際網路將被切斷。

塞內加爾

在塞內加爾,反對派領導人 Ousmane Sonko 被判入獄引發的暴力抗議導致政府限制使用 WhatsApp、Facebook、Twitter、Instagram、TikTok、Telegram、Signal 和 YouTube 等平台。6 月 4 日,塞內加爾通訊部發布聲明,暫時停止行動網際網路存取,並於 6 月 6 日發布後續聲明,表示結束暫停。在該國的兩家網路提供者中可明確看到這些行動網路存取中斷:AS37196 (Sudatel Senegal)AS37649 (Tigo/Free)

如下圖所示,Sudatel Senegal 的關停時間為當地時間 6 月 3 日 15:00 至 6 月 5 日 01:00,然後在當地時間 6 月 5 日 13:00 到 6 月 6 日 01:00 又一次關停。Tigo/Free 出現了三次關停,分別為當地時間 6 月 3 日 15:30 至 19:00、當地時間 6 月 4 日 13:45 至 6 月 5 日 02:05,以及當地時間 6 月 5 日 13:05 至 6 月 6 日 01:00。(塞內加爾是 UTC+0,因此當地時間與世界標準時間相同。)

茅利塔尼亞

在毛里塔尼亞, 一名年輕人在警方拘留期間死亡引發抗議後,當局切斷了行動網際網路服務。關停從當地時間 5 月 30 日 23:00 開始,持續了六天,於當地時間 6 月 6 日 23:00 恢復連線。(毛里塔尼亞為 UTC+0,因此當地時間與世界標準時間相同。)下圖顯示,該國境內兩家行動網路提供者 AS37541 (Chinguitel)AS37508 (Mattel) 在此期間幾乎完全沒有網際網路流量。

巴基斯坦

5 月 9 日,巴基斯坦前總理 Imran Khan 因腐敗指控被捕。逮捕後,多個城市爆發暴力抗議活動,導致巴基斯坦政府下令關閉行動網際網路服務,並封鎖多個社交媒體平台。下圖顯示了命令關停對國內四家行動網路提供者流量的影響:AS24499 (Telenor Pakistan)AS59257 (China Mobile Pak)AS45669 (Mobilink/Jazz)AS56167 (Ufone/PTML)。這一命令關停導致這些網路的網際網路流量完全丟失,Telenor 和 China Mobile Pakistan 的關停從當地時間 5 月 9 日 22:00(世界標準時間 17:00)開始,Mobilink/Jazz 的關停從當地時間 18:00(世界標準時間 13:00)開始,以及 Ufone/PTML 的關停從當地時間 5 月 10 日 01:00(世界標準時間 5 月 9 日 20:00)開始。當地時間 5 月 12 日 22:00(世界標準時間 17:00)恢復流量。

查看 Cloudflare Radar 最近在關停期間推出巴基斯坦網際網路品質頁面,我們發現行動網路關停後,巴基斯坦境內的延遲中間值略有下降,如下圖所示。在關停之前,延遲中間值(根據 Cloudflare 和其他一些提供者的觀察)在 90-100 毫秒範圍內,而之後,平均延遲接近 75 毫秒。這可能是由於使用者轉向低延遲固定寬頻連線的結果——該國的幾家固定寬頻提供者在行動網路不可用時出現了流量增加的情況。

如需詳細瞭解行動網路關停、內容封鎖以及對行政單位和城市級別的影響,請參閱我們 5 月 12 日的部落格文章 Cloudflare 對巴基斯坦網際網路中斷的看法

印度

不幸的是,印度的網際網路關停十分頻繁,數位版權組織 Access Now 報告稱,2022 年該國至少有 84 起網際網路關停事件。這些關停通常是在地方層面實施的,而且通常會持續很長一段時間。印度東北部曼尼普爾邦在種族衝突升級後於 5 月 3 日開始實施此類封鎖,據報導,其目的是_「透過阻止虛假資訊和虛假謠言的傳播,挫敗反民族和反社會分子的設計和活動……」以及「嚴重擾亂社群整體和平共處和公共秩序維護」_的可能性。行動數據服務最初被暫停五天,隨後每五天追加發布一個範本化命令,不斷延長暫停時間。

下圖顯示了命令關停對曼尼普爾邦兩家主要網路提供者流量的影響。當地時間 5 月 4 日 18:00(世界標準時間 12:30)左右,來自 AS45609 (Airtel)AS9829 (BSNL) 的流量顯著下降。Airtel 的流量持續保持在低位,並在 6 月底進一步下降。從 6 月初開始,BSNL 的流量出現輕微復甦跡象,但仍然極低。

截至撰寫本文時(7 月下旬),關停命令仍然存在。

Severe weather

惡劣天氣

關島

5 月 24 日,「超強颱風」Mawar 對美國領土關島造成嚴重破壞,登陸後造成大面積實體破壞,全島樹木、建築物、電線和通訊基礎結構被摧毀。這種損害的結果之一是網際網路連線嚴重中斷,如下方國家級圖表所示。人們立即開展了恢復工作,關島電力局Docomo PacificGTA Teleguam 都在其網站和/或社交媒體帳戶上定期發布狀態更新。

Cable damage

兩家網際網路提供者中,GTA Teleguam (AS9246) 在 6 月份基本能夠完成服務恢復,流量在 6 月 17 日左右恢復到風暴前的水平,如下圖所示。事實上,他們在 6 月 20 日的 Facebook 帖子中指出,_「截至今天,我們的大多數無線網路蜂窩基站都已投入運作。」_然而,Docomo Pacific (AS3605) 的復原需要更長的時間。下圖顯示,截至 6 月底,流量仍顯著低於風暴前的水平。

電纜損壞

玻利維亞

6 月 19 日,玻利維亞電信公司 COTAS 在其 Facebook 頁面上發布更新,提醒使用者龐戈鎮的一根光纜被切斷。如下圖所示,由於這一切斷,在當地時間 13:00 - 18:00(世界標準時間 17:00 - 22:00)期間,COTAS 和該國其他兩個網路提供者的網際網路連線遭遇嚴重中斷:AS25620 (COTAS)AS27839 (Comteco)AS52495 (Cotel)

甘比亞

甘比亞國有電信公司 Gamtel 於 6 月 7 日透過 Twitter 帖子通知用戶發生了局部光纖切斷,並於 6 月 8 日發生了另一起光纖切斷事件。這些光纖切斷事件導致當地時間 6 月 7 日 14:00 至 6 月 9 日 0:00 期間,AS25250 (Gamtel) 出現了網際網路連線中斷,流量較前期下降高達 80%。(甘比亞為UTC+0,因此當地時間與世界標準時間相同。)

Power outages

菲律賓

菲律賓電信提供者 PLDT 於當地時間 6 月 5 日 18:43(世界標準時間 10:43)在 Twitter 上發佈公告稱,「我們的一個海底電纜合作夥伴確認其部分網際網路頻寬容量丟失,從而導致網際網瀏覽速度變慢。我們正在與合作夥伴共同努力,提供備用容量,以在接下來的幾個小時內恢復瀏覽體驗。」下方的流量圖表顯示,AS9299 (PLDT) 的網際網路流量從當地時間 14:00 左右(世界標準時間 06:00)開始出現輕微中斷,PLDT 指出的「網際網路瀏覽速度較慢」這一情況在下方的網際網路品質圖表中清晰可見,同一時段延遲增加和頻寬下降的情況也十分明顯。PLDT 在隨後的推文中表示 ,截至當地時間 6 月 6 日 06:22(世界標準時間 6 月 5 日 22:22),「我們的海底電纜合作夥伴確認補充額外容量,恢復了瀏覽器體驗。

停電

古拉索

Aqualectra 是古拉索的主要公用事業公司,提供水和電力服務。6 月 8 日,他們在 Facebook 頁面上就影響「所有街區」的停電事件發布了一系列警示(1234),原因是連接到帕雷拉變電站的一條主電力電纜出現故障。這次斷電影響了島上的網際網路連線,如下圖所示,在國家層面以及多個網際網路服務提供者中觀察到流量顯著下降,包括 AS11081 (UTS)AS52233 (Columbus Communications)AS27660 (Curaçao Telecom)。當地時間 6 月 9 日 01:25(世界標準時間 05:25),發佈的 Facebook 後續帖文確認所有街區已恢復供電。

葡萄牙

據已發佈的報告稱,6 月 6 日下午,Prior Velho(里斯本附近)的 Equinix 資料中心發生停電,影響了當地公用事業、銀行服務和法院網路(12)。葡萄牙網際網路服務提供者 MEO 也受到停電影響,導致 AS3243 (MEO-RESIDENCIAL)AS15525 (MEO-EMPRESAS) 的流量下降,如下圖所示。停電造成的中斷也影響了葡萄牙境內的連線品質,正如下面的 Radar 網際網路品質圖表所突出顯示的那樣,頻寬同時下降,延遲增加,這表明終端使用者在那段時間可能擁有糟糕的效能體驗。

波札那

Technical problems

5 月 19 日,波札那全國范圍內停電,在當地時間 10:45 至 12:15(世界標準時間 08:45 - 10:15)期間造成了網際網路中斷,持續約 90 分鐘,如下圖所示。波札那電力公司的一條推文公開了該事件,但沒有說明根本原因。

巴貝多

4 月 4 日, 巴貝多照明電力公司在 Twitter 上發布了「停電通知」,稱「_我們發現全島的客戶目前斷電」。_該通知於當地時間 11:46(世界標準時間 15:46)發布,比在全國范圍內觀察到流量大幅下降的時間略晚一些,這表明停電也影響了全國范圍內的網際網路連線。在當天追加發佈幾次更新後,當地時間 18:00(世界標準時間 22:00)發布的最終更新表明,受影響客戶的電力已 100% 恢復。下圖顯示,又過了幾個小時的時間,流量才恢復到正常水平。(請注意,圖表中的橙色突出顯示表示中斷的持續時間,紅色陰影與內部資料收集問題相關。)

技術問題

納米比亞

6 月 15 日至 16 日,納米比亞發生了長達 7 小時的網際網路中斷,原因是納米比亞電信遭遇「技術挑戰」,但並未對此進行具體說明。根據該提供者的推文 ,「納米比亞電信週四在其固定和行動數據服務上遇到了技術挑戰,導致網際網路連線時斷時續。」從下方的國家層面和網路層面流量圖表中,都可以看出這些挑戰帶來的影響。

所羅門群島

4 月 26 日至 27 日,Our Telekom 所羅門群島的客戶也因未具體說明的「技術原因」遭遇了行動網際網路連線中斷。Our Telekom 在 4 月 26 日的 Facebook 帖子中簡單地指出「由於技術原因,我們的行動數據網路目前已關閉」。下圖顯示,在當地時間 4 月 27 日 06:30(世界標準時間 4 月 26 日 19:30)和當地時間 4 月 27 日 17:00(世界標準時間 06:00)期間,AS45891 (Our Telekom/SBT) 的流量顯著下降。Our Telekom 行動流量的丟失也影響了國家層面的流量,如圖所示,所羅門群島也出現了類似的中斷。

隨著服務足跡日益全球化,SpaceX Starlink 上觀察到的中斷可能會影響全球多個國家的使用者。就在世界標準時間 4 月 7 日午夜之前,AS14593 (SpaceX-Starlink) 的網際網路流量開始大幅下降。這一中斷十分短暫,流量在兩小時內恢復到預期水平。根據 SpaceX 首席執行官 Elon Musk 在 Twitter 上發布的帖子,該問題是「由過期的地面站憑證引起的」(與一個或多個 Starlink 地面站關聯的數位憑證過期,可能會阻止衛星星座與地面站之間的通訊 )。

馬達加斯加

據 Telma Madagascar 報導,在馬達加斯加當地時間 4 月 7 日 09:15 - 14:00(世界標準時間 06:15 - 11:00)期間,「骨幹網問題」導致多達三分之二的網際網路流量丟失。下圖顯示骨幹網問題中斷了國家層面及 AS37054 (Telma Madagascar) 的流量。

英國

4 月 4 日,英國網際網路提供者 Virgin Media 遭遇多次服務中斷,影響了寬頻客戶的網際網路連線。第一次中斷於當地時間 01:00(世界標準時間 00:00)之前開始,一直持續到當地時間 09:00(世界標準時間 08:00)左右。第二次中斷於當地時間 16:00(世界標準時間 15:00)左右開始,接下來的幾個小時內流量反復上升和下降,然後在當地時間 21:30(世界標準時間 20:30)左右穩定下來。

Cyberattacks

Virgin Media 的 Twitter 帳戶在凌晨發生中斷幾個小時後就承認了這一情況,並發布訊息稱:「我們意識到一個問題正在影響 Virgin Media 客戶以及我們聯絡中心的寬頻服務。我們的團隊目前正在努力盡快發現並解決問題,在此向受影響的客戶深表歉意。」服務恢復後的後續帖子指出:「我們已經為客戶恢復了寬頻服務,但我們的工程師正在繼續調查,並密切關注情況。很抱歉給您造成不便。

然而,Virgin Media 的 Twitter 帳戶更快地承認了第二次中斷,並在世界標準時間 16:25 發布了一篇帖文,表示「不幸的是,我們看到之前的問題再次出現,導致一些 Virgin Media 客戶出現間歇性寬頻連線問題。我們再次向受影響的人致歉,我們的團隊正在繼續全力以赴尋找問題的根本原因並解決它。

儘管 Virgin Media 沒有透過社交媒體分享有關中斷或其解決方案的更多詳細資料,但一位知曉內情的客戶透過 Twitter 分享了一些額外資訊,該客戶發布了帖文:「Virgin Media 工程師重新安裝了光纖卡並重設了中樞設備以恢復服務。延伸了 TTL 以作為一種變通方法,以在實施永久修復的過程中維持穩定性。

有關 Virgin Media 服務中斷的更多詳細資料,請參閱我們 4 月 4 日的部落格文章: Cloudflare 對英國 Virgin Media 服務中斷的看法

網路攻擊

Military action

烏克蘭

正如我們在過去的部落格文章中所介紹的,俄羅斯和烏克蘭之間的實體戰爭也帶來了活躍的線上活動。自 2022 年 2 月衝突開始以來,我們觀察到了流量轉移、網路攻擊和流量重新路由。2022 年 5 月上旬,我們觀察到來自多家烏克蘭網路提供者的流量正在透過 AS201776 (Miranda Media)(一家總部位於克里米亞、由俄羅斯控制的網路營運商)重新路由。(兩篇部落格文章更詳細地討論了這種重新路由:《追蹤烏克蘭赫爾鬆的網際網路連線變化》《烏克蘭戰爭一年:網際網路趨勢、攻擊和復原能力》。)

一年多後,5 月 26 日,我們觀察到 Miranda Media 出現網際網路服務中斷的情況。流量於當地時間 16:30(世界標準時間 13:30)左右開始下降,並於當地時間 18:15(世界標準時間 15:15)左右降至零。此次事件中斷了克里米亞半島和被佔領的烏克蘭部分地區的連線,並持續到當地時間 5 月 27 日 06:00(世界標準時間 03:00)左右。已發佈的報告(12)表明,此次中斷是由於針對 Miranda Media 的網路攻擊造成的,據報導,該攻擊由烏克蘭駭客團夥發起。

俄羅斯

俄羅斯衛星提供者 Dozor Teleport 的客戶包括俄羅斯國防部、北方艦隊艦艇、俄羅斯能源公司 Gazprom、偏遠油田、比利比諾核電站、聯邦安全局 (FSB)、Rosatom 和其他組織,該公司於 6 月 29 日發生了長達數小時的服務中斷。此次服務中斷發生在世界標準時間 01:30 至 17:30 之間,報道稱由網路攻擊造成,有至少兩個組織聲稱對此次攻擊負責

軍事行動

Maintenance

查德

4 月 23 日至 24 日,查德發生多起網際網路中斷,影響了多家網際網路提供者,並最終影響了國家層面的流量。如下圖所示,中斷發生時間為當地時間 4 月 23 日 04:30 - 06:00(世界標準時間 03:30 - 05:00)和當地時間 15:00 - 20:00(世界標準時間14:00 - 19:00),以及當地時間 4 月 24 日 04:00 - 08:30(世界標準時間 03:00 - 07:30)。查德受影響的網路提供者包括 AS327802 (Millicom Chad)AS327756 (Airtel Chad)AS328594 (Sudat Chad)AS327975 (ILNET-TELECOM)。據報導,此次中斷是由於連結查德與鄰國喀麥隆和蘇丹的光纖基礎結構受損造成的,後者因蘇丹武裝部隊 (SAF) 和快速支援部隊 (RSF) 之間的衝突,也遭遇了網際網路服務中斷。

蘇丹

如上所述,4 月份蘇丹的軍事行動中斷了查德的網際網路連線。從四月中旬開始,蘇丹主要網際網路提供者出現多起網際網路服務中斷事件,其中三起如下圖所示。該國的戰鬥導致燃料短缺和斷電,最終影響了網際網路連線。

AS15706 (Sudatel) 於當地時間 4 月 23 日 03:00 至 4 月 24 日 17:00(世界標準時間 4 月 23 日 01:00 至 4 月 24 日 15:00)經歷了完全網際網路服務中斷,並於當地時間 4 月 25 日 03:00 至 4 月 28 日01:00(世界標準時間 4 月 25 日 01:00 至 4 月 27 日 23:00)再一次經歷了網際網路服務中斷。AS36972 (MTN) 的網際網路連線在當地時間 4 月 16 日 03:00 至 12:00(世界標準時間 01:00 - 10:00)期間中斷,並在 4 月 27 日 20:00 至 4 月 29 日 02:00 (世界標準時間 4 月 27 日 18:00 至 4 月 29 日 00:00)期間再次中斷。在略微恢復幾天後,5 月 5 日開始出現接近完全的長期服務中斷,持續數週。與 MTN 類似,AS33788 (Kanar Telecommunication) 也觀察到多次長時間中斷。繼 4 月 19 日中午流量大幅下降後,4 月 21 日 12:00 至 4 月 29 日 01:00(世界標準時間 4 月 21 日 10:00 至 4 月 28 日 23:00)之間出現近乎完全中斷的情況 ,在 4 月 24 日晚些時候出現了非常短暫的小幅恢復。當地時間 5 月 11 日 00:00 左右(世界標準時間 5 月 10 日 22:00)開始,遭遇了一次持續時間較長的服務中斷,也持續了數週時間。

有關蘇丹網際網路中斷的更多詳細資料,請參閱我們 5 月 2 日的部落格文章:蘇丹衝突對網際網路模式的影響

維護

多哥、剛果共和國(布拉柴維爾)、布吉納法索

4 月 6 日,西非電纜系統 (WACS) 海底電纜的維修工作中斷了多個國家的網際網路連線,包括多哥、剛果共和國(布拉柴維爾)和布吉納法索。根據 Canalbox Congo 的 Facebook 帖文的 Google 翻譯,修復工作可能會導致「網際網路連線嚴重中斷,並有完全中斷的風險」。(Canalbox (GVA) 是一家非洲電信營運商,在非洲多個國家提供服務。)

針對 AS36924 (GVA-Canalbox) 的以下圖表顯示了三個重疊的服務中斷標註,每個標註都與在受影響國家之一的自發系統(網路)上觀察到的中斷相關。可以看到,在剛果共和國(布拉柴維爾)當地時間 16:15 - 23:15(世界標準時間 15:15 - 22:15)期間出現了嚴重的流量中斷。在布吉納法索,中斷發生的時間較早且沒那麼嚴重,發生在當地時間 09:15 - 18:00(世界標準時間 09:15 - 18:00)之間,多哥受到的影響與此類似,其流量在當地時間 11:00 - 23:15(世界標準時間 11:00 - 23:15)之間受到干擾。

結論

由於網際網路與世界各地的商業、金融服務和日常生活緊密結合,任何網際網路連線的中斷最終都會帶來經濟影響。因意外或不可避免的事件(例如電纜切斷或惡劣天氣)造成中斷而受影響的提供者通常會嘗試盡量減少此類中斷的範圍和持續時間,最終限制經濟影響。然而,對於政府下令關停網際網路的情況,對經濟造成的損害最終是自食其果。網際網路協會的新淨損失計算器現在提供了一種量化這種損害的方法,讓公眾、倡導團體和政府自己能夠從國內生產總值 (GDP)、外國直接投資 (FDI) 和失業的角度瞭解網際網路關停的潛在成本。

造訪 Cloudflare Radar,瞭解有關網際網路中斷的更多深入解析。在社交媒體上關注我們:@CloudflareRadar (Twitter)、cloudflare.social/@radar (Mastodon) 和 radar.cloudflare.com (Bluesky),或透過電子郵件聯絡我們。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Cloudflare RadarInternet TrafficOutageInternet ShutdownInternet Quality

在 X 上進行關注

David Belson|@dbelson
Cloudflare|@cloudflare

相關貼文

2024年9月27日 下午1:00

Network trends and natural language: Cloudflare Radar’s new Data Explorer & AI Assistant

The Cloudflare Radar Data Explorer provides a simple Web-based interface to build more complex API queries, including comparisons and filters, and visualize the results. The accompanying AI Assistant translates a user’s natural language statements or questions into the appropriate Radar API calls....

2024年9月23日 下午1:00

Network performance update: Birthday Week 2024

Since June 2021, we’ve been measuring and ranking our network performance against the top global networks in the world. We use this data to improve our performance, and to share the results of those initiatives. In this post, we’re going to share with you how network performance has changed since our last post in March 2024, and discuss the tools and processes we are using to assess network performance. ...

2024年9月20日 下午2:00

Cloudflare incident on September 17, 2024

On September 17, 2024, during planned routine maintenance, Cloudflare stopped announcing 15 IPv4 prefixes, affecting some Business plan websites for approximately one hour. During this time, IPv4 traffic for these customers would not have reached Cloudflare and users attempting to connect to websites using addresses within those prefixes would have received errors. ...