8/13 台湾北部移动网络降速 30 分钟的 OONI 测量记录
台湾长期没有经历大规模的网络降速或断网，想理解网络异常的人手上因此缺少当地的对照样本。OONI 的公开数据库里，台湾的记录一直是正常运作的网络。
8 月 13 日之前的 30 天，台湾三家移动运营商在 OONI 上留下 564 条成功的连接速度测试（测试项名称 ndt），下载中位数 12,425 kbit/s。低于 2,000 kbit/s 的只有 4 条，其中 2 条是测量失败（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 记录。准备时两边分工，社区整理号召与操作说明，他在当天实地观测。他的记录写成另一篇文章，追到演习公告结束之后网络仍然受限的情形，补上本文数据看不见的时段。
47 台设备里有一部中华电信移动的手机，在降速时段测到 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 |
OONI 只记录到 ASN 层级，不记录使用者位置。下表的设备数以 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），全球使用者执行的都是同一张。当天光是台湾以外就有上千条带着同一个编号，号召的效果只能从前后量的对比推估。
单一设备的前后对照
用设备标识符可以把同一部手机的多条测量串起来。当天有一部中华电信移动的 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 台在降速时段测到的是正常速度。三家移动运营商的下载中位数在降速前、降速中、恢复后分别是 53.2、42.2、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。
降速与断网在数据上的差异
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城镇韧性（防空）演习：移动网络降速演练 - 行政院 ↩