從 OONI 公開資料看 8/13 北部行動網路降速的 30 分鐘¶
台灣長期沒有經歷大規模的網路降速或斷網。對日常生活來說是好事，對想理解網路異常的人來說，代表手上缺少對照的樣本。OONI 是國際上長期在做網路封鎖與連線品質觀測的開源專案，任何人都能安裝它的 App 參與量測，結果全部公開。台灣在裡面的紀錄，一直呈現一個正常運作的網路。
8 月 13 日之前的 30 天，台灣三家行動業者在 OONI 上留下 564 筆成功的連線速度測試（測項名稱 ndt），下載中位數 12,425 kbit/s，低於 2,000 kbit/s 的只有 4 筆，其中 2 筆還是量測失敗。kbit/s 是每秒傳輸的千位元數，數字越大越快，1,000 kbit/s 約等於 1 Mbps。
8 月 13 日 14:30 到 15:00，北部七縣市的行動網路降速 30 分鐘。兩天前社群發出號召，請大家在降速時段執行 OONI Probe 的效能測試。當天全台留下 238 筆連線速度測試與 235 筆影音串流測試（測項名稱 dash），其中在行動網路上完成的有 170 筆與 168 筆，來自 47 支裝置。8 月 10 日中部場的同一個時段，全台灣的行動網路效能量測是 0 筆。
號召的起點來自社群夥伴 mashbean（黃豆泥）。演習前他提議趁著難得的時間點找大家一起用 OONI 記錄，兩邊於是分頭準備，一邊整理號召與操作說明，一邊在當天實地觀測。他把自己的紀錄寫成另一篇文章，追到了演習公告結束之後網路仍然受限的情形，正好補上本文資料看不見的時段。兩篇一起讀，涵蓋的時間才完整。
其中一支中華電信行動的手機，在降速時段量到 788 到 1,709 kbit/s。台灣的公開資料裡沒有出現過同一量級的數字。需要先說明的是，數字來自單一裝置留下的 6 筆紀錄，足以作為一個完整的個案，不足以推論全國或任何一家業者的普遍狀況。
本文記錄的是網路狀態。業者是否確實執行指令、官方公布的數字精不精確，都不在討論範圍。台灣過去沒有降速樣態的資料，把 30 分鐘的觀測留下來是主要目的。以下的查詢都免驗證免金鑰，讀者可以自行重新執行一次。
整理資料的過程裡，最實用的收穫與降速本身無關，而是判讀方法。降速與封鎖在 OONI 資料上是兩種完全不同的樣態。封鎖會讓異常率飆升、留下確認封鎖的紀錄，降速則完全不動判定欄位，變化只出現在吞吐量與延遲的數值上。當天全台的網路連線測試異常率是 1.0%，與平常的 0.6% 落在同一個區間，確認封鎖整天維持在 0，下降的只有速度。拿封鎖判定的異常率去描述降速，會得到一個接近平常的數字，然後誤以為什麼都沒發生。
先看當天資料的整體樣態¶
把當天全台的連線速度測試按 15 分鐘分組，社群動員會直接呈現在資料上。
- 8 月 13 日各 15 分鐘區間的連線速度測試筆數，橘色為降速時段
號召文請大家設 14:35 的鬧鐘，行有餘力再加 14:15 與 15:10。三個尖峰都出現了，14:45 到 15:00 的 50 筆是全天最高點。前 30 天全台平均一天約 34 筆連線速度測試，多數來自少數幾台裝置的自動排程，當天單一個 15 分鐘區間就超過平常一整天。
各 15 分鐘區間的完整筆數
| 台灣時間 | 筆數 |
|---|---|
13:00 到 13:15 |
3 |
13:15 到 13:30 |
4 |
13:30 到 13:45 |
11 |
13:45 到 14:00 |
4 |
14:00 到 14:15 |
9 |
14:15 到 14:30 |
27 |
14:30 到 14:45 |
13 |
14:45 到 15:00 |
50 |
15:00 到 15:15 |
31 |
15:15 到 15:30 |
15 |
15:30 到 15:45 |
2 |
15:45 到 16:00 |
2 |
各業者的參與情況如下。AS 開頭的編號是自治網路的全球識別碼，電信商、企業、學校都有各自的號碼，OONI 只記錄到業者層級，不記錄使用者位置。裝置數以 OONI 產生的匿名裝置識別碼（probe_id）去重計算。
| 業者 | 8/13 筆數 | 前 30 天筆數 | 當天裝置數 |
|---|---|---|---|
AS17421 中華電信行動 |
68 |
20 |
22 |
AS9674 遠傳 |
51 |
12 |
15 |
AS24158 台灣大哥大 |
55 |
538 |
9 |
三個數值欄都是連線速度測試的數量，前兩欄的單位是量測筆數，最後一欄是不重複的裝置數。一支手機測三次算 3 筆、1 支裝置。
中華電信行動與遠傳原本是台灣 OONI 資料裡覆蓋最少的兩家。一個下午的量測超過了兩家過去 30 天的累積。台灣大哥大的前 30 天筆數本來就高，來自少數裝置的長期自動執行，當天新增的 9 支裝置是過去沒有的分布。
資料上分不出誰是看到號召才測的。App 裡的效能測試是一張內建卡片（編號 00107），全球使用者點下去執行的都是同一張，當天光是台灣以外就有上千筆帶著同一個編號。號召的效果只能從前後量的對比推估，看不到個別參與者的來源。
放大到一支手機的 30 分鐘¶
裝置識別碼可以把同一支手機的多筆量測串起來。當天有一支中華電信行動的 Android 手機在降速前後都執行了測試，兩個效能測項各留下 6 筆。
- 同一支手機的下載與上傳吞吐量，灰帶為降速時段。縱軸為對數座標，資料跨兩個多數量級。13:33 到 14:36 之間沒有量測，線段在此斷開
下載的兩段落差兩個數量級，上傳的兩段幾乎在同一個高度上。
前兩筆在降速開始前約一小時，後四筆在降速時段內。下載中位數由 132,096 kbit/s 降到 1,223 kbit/s，兩個測項各自算出的比值是 1/108 與 1/88。放回台灣資料的脈絡看，落差更明顯：中華電信行動在前 30 天的 18 筆量測裡，最低值是 42,197 kbit/s，降速中的 788 kbit/s 是該業者在公開資料上前所未見的量級。
同一批量測還記錄了往返延遲與重傳率，六筆的完整數值如下。
| 台灣時間 | 下載 | 上傳 | 串流位元率 | 最小 RTT | 平均 RTT | 重傳率 |
|---|---|---|---|---|---|---|
13:32 |
89,510 |
21,510 |
138,513 |
18.39 |
66.78 |
0.000% |
13:33 |
174,682 |
16,348 |
119,179 |
17.85 |
82.05 |
0.001% |
14:36 |
788 |
26,300 |
1,308 |
16.85 |
168.40 |
0.522% |
14:39 |
881 |
31,789 |
1,608 |
19.97 |
137.24 |
0.202% |
14:51 |
1,565 |
22,370 |
1,624 |
18.72 |
130.05 |
0.000% |
14:52 |
1,709 |
32,695 |
821 |
18.28 |
114.79 |
0.000% |
前三個數值欄的單位是 kbit/s，數字越大越快，其中 1,308 kbit/s 大致相當於標準畫質的串流。兩個 RTT 欄的單位是毫秒（ms），數字越小代表封包來回一趟越快，最小 RTT 取整段測試中最快的一次，接近線路本身的實際距離，平均 RTT 則把途中排隊的時間也算進去。重傳率是需要重送的封包所佔比例。
解讀吞吐量時要記得一件事，連線速度測試的對端是 M-Lab 的伺服器，數值裡同時包含最後一哩與到 M-Lab 節點的國際線路，單筆結果無法把兩段分離。延遲欄位正好回應該項疑慮：最小 RTT 全程維持在 17 到 20 ms，與封包路徑未改變的情形一致，也降低了「速度變化來自國際線路」的可能。平均 RTT 從 67 到 82 ms 升到 115 到 168 ms，代表封包在某處出現佇列延遲（queuing delay）。重傳率四筆裡有兩筆從降速前的近乎 0 升到 0.522% 與 0.202%，相對變化不小，絕對值仍低於 0.6%，較符合延遲送出而非大量丟棄的樣態。
三個欄位合起來，構成流量整形（shaping）在資料上的特徵。若手段是丟棄封包，重傳率會上升得更明顯。若成因是訊號劣化或換了基地台，最小 RTT 通常會跟著變動。以上判讀同樣建立在單一裝置上。
行政院對演練做法的說明是核心網路限流，將行動網路下載速率調降至 256KB2。原始說法沒有標明單位，若解讀為每秒 256 KB，換算後是 2,048 kbit/s。若解讀為 256 kbit/s，量級則完全不同。本文不做數值精確度的比對，列出官方說法是讓讀者知道公布的量級落在哪裡。
沒有降速訊號的量測撐起了對照¶
47 支裝置裡，46 支在降速時段量到的是正常速度。降速時段三家行動業者的下載中位數是 42.2 Mbps，降速前是 53.2 Mbps，恢復後是 58.5 Mbps，三個時段落在同一個量級。
正因為有整批正常數值墊底，單一裝置的 788 kbit/s 才能被認定是特殊的。若當天所有人都測到低速，合理的解釋會變成全台網路普遍變慢，或當天的一般波動。若只有一支手機在測，低速也可能來自該裝置自身的狀況，例如訊號不良或背景程式佔用頻寬。同時段有 32 支裝置執行同一組測試，其中 31 支正常，單一裝置的異常才站得住。
號召文請不在降速範圍的人也測一次，用意即在於此。範圍外的量測不是白測的，它們決定了範圍內的數字能不能被解讀。人在台南、在高雄，或當天根本不在台灣，只要在同一個時間點按下執行，資料都落在同一個公開資料庫裡，都是對照的一部分。
當天全球有數千筆同樣的效能測試在執行，台灣的差別只在於有明確的事件與時間邊界可以對應。缺了對照組，剩下的就只是一個孤立的低速數字，說明不了任何事。
體感怎麼對應到欄位¶
社群沒有做體感問卷，以下從資料回推當時使用手機會遇到的狀況。
影片轉圈圈¶
影音串流測試會記錄開始播放前的等待時間。降速前的兩筆都是 0 秒，降速中的三筆分別是 0.12 秒、0.12 秒與 5.29 秒。最後一筆等了超過五秒緩衝才開始播放，正是點開影片後盯著圈圈轉的等待時間。
傳訊息、傳照片出去反而順暢¶
降速中的四筆上傳分別是 26,300、31,789、22,370 與 32,695 kbit/s，與降速前的 21,510、16,348 kbit/s 相比沒有下降。上傳與下載的倍率達到 33、36、14、19 倍。限流是單向的，只作用在下載方向。單向限流也解釋了號召文提醒過的一件事：量測結果的上傳在降速期間仍然順暢，資料能即時送出，不需要等網路恢復後補傳。
點下去要等一下才有反應¶
平均 RTT 翻倍，每一次點擊到畫面更新之間的空檔會被拉長。
網頁還是開得出來，只是慢¶
降速時段全台有 1,893 筆網路連線測試（Web Connectivity），異常率 1.0%，降速前與恢復後都是 0.6%。確認封鎖的筆數在所有時段皆為 0。網站連得到，Tor 與 Psiphon 也連得上，降速時段的 33 筆 Tor 測試與 33 筆 Psiphon 測試異常數都是 0。
降速的 30 分鐘在資料上呈現為速度下降，連線本身沒有中斷。
降速與斷網在資料上是兩種樣態¶
OONI 的多數測項在做封鎖判定，例如網路連線測試、Telegram、Signal。真正的封鎖或斷網發生時，異常率會飆升、出現確認封鎖的紀錄，嚴重時量測直接失敗，連報告都送不出來，資料庫裡留下的是一段空白。降速時連線全部成功，報告照常送出，判定欄位一動也不動。
| 封鎖或斷網 | 降速 | |
|---|---|---|
| 連線是否成功 | 大量失敗 | 全部成功 |
| 異常率 | 明顯上升 | 不動 |
| 確認封鎖 | 可能出現 | 維持 0 |
| 吞吐量 | 未必反映 | 明顯下降 |
| 該看哪一組測項 | 有封鎖判定的測項 | 效能測項的數值 |
判準因此很清楚。想觀測降速，要看效能測項的數值。想觀測封鎖，要看有判定的測項。兩者用錯了，得到的數字都會指向錯誤的結論。
號召文事前只請大家執行效能測試，原因也在於此。限速期間執行有封鎖判定的測項，手機端大量逾時而輔助伺服器一切正常，比對出來會被標成封鎖的簽名，等於在台灣的公開資料裡注入一批看起來像審查的紀錄。當天的結果顯示假訊號沒有出現。
兩種樣態都可以自行查看。台灣 8 月 13 日的逐小時分布裡，確認封鎖整天維持在 0，降速的一小時同樣為 0。OONI 團隊查證過的封鎖事件收在 Findings，每則都連著對應的量測資料，可以看到確認封鎖的筆數在事件期間如何上升。兩邊查的是同一個資料庫、同一組欄位，差別只在數值。
結論怎麼從公開資料得出¶
第一步，把時間區間內的量測撈出來¶
measurements 端點免驗證，接受精確到秒的時間區間。
https://api.ooni.org/api/v1/measurements?probe_cc=TW&test_name=ndt
&since=2026-08-13T06:00:00Z&until=2026-08-13T08:00:00Z&limit=200
所有時間一律為 UTC，台灣時間需減 8 小時，降速時段對應 06:30 到 07:00。要取台灣時間的一整天，起訖要往前推 8 小時，寫成 2026-08-12T16:00:00Z 到 2026-08-13T16:00:00Z。回傳的每一筆都帶網路編號（probe_asn）與量測編號（measurement_uid）。筆數超過 limit 時回傳裡會有 next_url，要逐頁取完才不會漏資料，當天的連線速度測試就有 238 筆，一次 limit=200 取不完。
第二步，取原始 JSON 拿數值¶
列表本身不含吞吐量，要再開每一筆回傳的 measurement_url。連線速度測試的數值在 test_keys.summary，包含下載（download）、上傳（upload）、最小往返延遲（min_rtt）、平均往返延遲（avg_rtt）與重傳率（retransmit_rate）。影音串流測試的數值在 test_keys.simple，包含位元率中位數（median_bitrate）與播放等待時間（min_playout_delay）。
第三步，剔除非行動網路的量測¶
原始 JSON 的網路類型欄位（annotations.network_type）會標記行動網路（mobile）、Wi-Fi（wifi）、有線（wired_ethernet）或 VPN（vpn）。當天 238 筆連線速度測試裡，只有 170 筆標記為行動網路。少了篩選，家用光纖與 VPN 的量測會混進來，而兩者本來就不在降速範圍內。
第四步，用裝置識別碼串起同一支手機¶
識別碼在原始 JSON 的頂層，欄位名是 probe_id，與吞吐量所在的 test_keys 是平行的兩個位置。值是 OONI 為每台裝置產生的匿名雜湊，同一支手機的多筆量測會帶同一個值，把值相同的量測收在一起就是該裝置當天的完整紀錄。當天 238 筆連線速度測試裡有 18 筆沒有帶識別碼，無法歸戶到任何一支裝置，本文的裝置數也不計入。
單筆量測難以獨立判讀，因為手機型號、位置、訊號強度全都不同。同一支手機的自身前後對照直接得多。本文的關鍵表格即由此得出。
第五步，排除誤判¶
兩個當天實際遇到的例子。
一支台灣大哥大的裝置在 14:54 量到 3,124 kbit/s，看起來像降速。但它在當天 20:11 又量到 3,126 kbit/s，影音串流位元率整天落在 2,072 到 2,909 kbit/s 之間。數字全天穩定，來自該門號本身的速率上限，與演練無關。只看降速時段的資料，很容易把它算進證據裡。
降速時段另有 5 筆量測完全失敗，錯誤分別是連線逾時、DNS 查詢失敗與連線被拒。失敗的成因無法從單筆結果判定，可能來自降速，也可能來自一般的連線問題，因此不列入。
第六步，建立對照組¶
8 月 10 日、11 日、12 日的同一個時段，行動網路的效能量測沒有任何一筆低於 2,000 kbit/s，8 月 12 日的 7 筆裡最低是 8,399 kbit/s。低於 2,000 kbit/s 的量測只出現在 8 月 13 日的降速時段，當天其他時段都沒有。有了對照組，才能把觀察到的低速與一般波動分開。
超出本批資料範圍的問題¶
位置¶
OONI 記錄國家與 ASN，不記錄縣市，也不記錄基地台位置。從資料看得出一筆量測來自 AS17421，看不出手機當時在台北還是台南。47 支裝置裡只有 1 支留下明確的降速訊號，最可能的解釋是其他人不在降速的七個縣市內，但公開資料無法驗證。
不記錄位置是 OONI 的設計選擇，理由是保護參與者。在審查嚴重的國家，量測者的位置資訊會直接轉為人身風險。該取捨是對的，代價是地理範圍明確的事件難以精確對位。想補上位置維度，需要社群自己另外收集，例如一份自願填寫的縣市登記表單，且只收到縣市層級、不與裝置識別碼對應，避免補回 OONI 刻意拿掉的追蹤能力。
跨業者的資料涵蓋度¶
留下完整前後對照的裝置集中在中華電信行動一家。台灣大哥大與遠傳在降速時段的低值都是量測失敗，沒有可判讀的數值。落差來自參與者分布與資料落點，不代表各業者的網路狀況有差異。要看到不同業者在同一時段的樣態，需要每一家都有裝置完成降速前、降速中、恢復後的量測。
恢復所需的時間¶
留下完整降速紀錄的手機，最後一筆量測在 14:52，之後沒有再執行，本文的前後對照到此為止。恢復後的 30 分鐘有 38 筆量測，全部來自沒有降速訊號的裝置，同一支裝置跨越降速中與恢復後的比較無從談起。
公開資料裡留著恢復期的線索，是本文的篩選條件把它擋掉的。台灣大哥大的一支裝置在 15:08 量到 55 kbit/s，兩分鐘後的串流測試回傳 0，兩筆都落在演習公告的結束時間之後。本文的統計沒有納入，因為兩筆的網路類型欄位都是空的，而為了排除固網與 VPN，本文只計入明確標記為行動網路的量測。篩選擋掉雜訊的同時，也擋掉了訊號。
補上該時段的是 mashbean 的實地觀測。他記錄到 15:08 的下載仍然只有 55 kbit/s，串流測試從逾時轉為完成，一直到 17:47 才恢復到可用的水準，並據此主張恢復時間應該納入韌性演習的成效指標，功能恢復與回到基準要分開判讀。裝置在誰手上、當時走的是不是行動網路、人在哪個縣市，OONI 不記錄的維度，只有量測者本人說得出來。
把兩份觀測的時間點排在一起，當天下午的輪廓才完整。
- 當天下午的事件時間軸，灰帶為公告的降速時段，縱軸依資料來源分列
圖上最長的一段是空白。公告寫的結束時間是 15:00，最後一筆低速紀錄落在 15:08，實際恢復到堪用是 17:47。三個時間點各自代表不同的意思，中間隔了將近三小時。
時間軸的完整事件列表
| 台灣時間 | 發生的事 | 依據 |
|---|---|---|
14:30 |
公告的降速開始時間 | 行政院公告 |
14:36 |
單一裝置量到 788 kbit/s，全天最低 |
本文 |
14:39 |
同一裝置 881 kbit/s，上傳仍有 31,789 |
本文 |
14:52 |
同一裝置最後一筆，1,709 kbit/s |
本文 |
15:00 |
公告的降速結束時間 | 行政院公告 |
15:08 |
另一支裝置仍量到 55 kbit/s |
本文與 mashbean |
15:10 |
同一支裝置的串流測試回傳 0 |
本文與 mashbean |
17:47 |
恢復到可用水準 | mashbean 的實地觀測 |
單一裝置的代表性¶
本文對限流方向與層級的描述，建立在一支手機的 6 筆量測上。數字內部互相一致，兩個獨立測項也指向同一個結論，作為單一案例的紀錄是完整的。要談到分布、平均降幅或信賴區間，需要的樣本量遠不止於此。
另外，47 支裝置都是看到號召後自願參與的社群成員，並非隨機抽樣。要用來做跨業者或跨區域的推論，需要先處理選樣偏誤。
一起來研究 OONI 的公開資料¶
本次觀察沒有用到特別的工具，全部來自公開 API 與一點資料整理。OONI 的資料有四個入口，用途各不相同。
- OONI Explorer：網頁介面，適合查單筆量測、看某個國家或 ASN 的趨勢，無須寫程式。
- Aggregation API：
https://api.ooni.org/api/v1/aggregation，免驗證免金鑰，可依國家、測項、ASN 切分做統計。起訖只接受日期，適合看天級以上的趨勢。 - Measurements API：
https://api.ooni.org/api/v1/measurements，接受精確到秒的時間區間，回傳逐筆紀錄。本文的主要資料出自此端點。 - AWS S3 公開資料集：
ooni-data-eu-fra，逐筆原始 JSON，適合需要檢視量測細節或做大規模分析的研究。取用方式與 CSV 輸出格式寫在 ASN 觀測資料擷取與分析，社群維護的擷取程式也在該頁。
不寫程式也能參與。裝一次 OONI Probe 並執行，每一筆量測都會進入公開資料庫，成為台灣網路狀態的長期紀錄。前 30 天全台平均一天只有 34 筆連線速度測試，多一支手機的日常量測，基準就厚一分。下一次遇到非預期的網路變慢時，能不能分辨是自己的問題還是網路的問題，取決於平常累積了多少。
台灣還有不少題目尚待投入。行動網路的長期基準目前仍然很薄，三家業者的覆蓋差了一到兩個數量級，細節見 ASN 自治網路觀測資料分析。要判斷某個問題該用哪個測項，OONI 測項速查表整理了每個測項量測什麼、規格狀態，以及台灣是否有資料。
判讀資料時最常見的誤解，是把異常（anomaly）當成封鎖。異常只代表測試未照預期完成，成因包含審查、網路不穩、ISP 暫時故障，以及測試程式本身的問題。以 Tor 測試為例，加拿大、瑞士、紐西蘭等沒有審查的國家，異常率同樣落在 16% 到 22% 之間。把異常率直接當成封鎖率會產生假指控。
演習依分區實施，北部場是今年的最後一場，相同條件要等到明年。本次留下的資料是台灣目前唯一一筆有明確情境對應的降速紀錄，之後遇到非預期的網路劣化時，總算有可以比對的樣本。
想一起整理資料、規劃下一次的觀測，或是對 OONI 公開資料有任何問題，歡迎到社群的 Matrix Public Space 討論。
資料與前提¶
查詢日為 2026-08-14，量測資料仍會持續補傳，之後重查可能得到略高的筆數。所有日期以台灣時間為準，換算成 API 接受的 UTC 時再往前推 8 小時。以下的 test_name 等參數為 API 實際接受的值，照列以便重現查詢。
當天逐筆量測用 measurements 端點，probe_cc=TW、since=2026-08-12T16:00:00Z、until=2026-08-13T16:00:00Z，對應台灣時間 8 月 13 日整天。test_name 分別為 ndt、dash、web_connectivity、tor、psiphon。降速時段等時段統計另以 UTC 06:00 到 07:30 的區間查詢。
吞吐量、往返延遲與裝置識別取自每筆量測的原始 JSON，經由 measurements 回傳的 measurement_url 取得，欄位位置見上方的觀察流程。本文的行動網路量測僅計入網路類型為 mobile 者，排除 Wi-Fi 與 VPN。裝置以 probe_id 去重，部分量測沒有帶值，未帶值者不計入裝置數。當天三家的筆數為該 ASN 的全部量測，與前 30 天基準採同一種計算方式，扣掉 2 筆 VPN 與 3 筆未標記網路類型後，行動網路上完成的分別是 67、50 與 52 筆。行動網路的 170 筆裡另有 1 筆來自 AS9416，不屬於三家全國性業者，未列入業者表格。
前 30 天的行動網路基準（564 筆、中位 12,425 kbit/s、低於 2,000 kbit/s 的 4 筆、中華電信行動最低 42,197 kbit/s）用 measurements 端點，probe_cc=TW、test_name=ndt、since=2026-07-13T16:00:00Z、until=2026-08-12T16:00:00Z，對應台灣時間 7 月 14 日到 8 月 12 日，probe_asn 分別為 AS24158、AS17421、AS9674，同樣逐筆取原始 JSON 後剔除非行動網路的量測。
對照日用同樣的 measurements 參數，日期換成 2026-08-10、2026-08-11 與 2026-08-12，時間區間為 UTC 05:30 到 07:30。
本文不公開任何個別裝置的識別碼。該欄位雖然出現在 OONI 的公開資料中，寫出具體值等於為單一參與者的量測歷史建立索引，與量測本身的目的無關。
資料來源：OONI measurements 與 aggregation API（查詢條件見上方，量測資料授權 CC BY-NC-SA 4.0）、ASN 名稱取自 RIPEstat。
-
2026城鎮韌性（防空）演習：行動網路降速演練 - 行政院 ↩