打开美国国家气象局（NWS）阿拉斯加州安克雷奇预报办公室官网的一则通知页，顶部醒目地挂着全国雷达中断（Attention: National Radar Outage）的警告标题，紧接着就是内华达山脉周六大雪、得克萨斯州东部至路易斯安那州周日雷暴大雨的实时气象横幅。任何在这个页面停留的读者，第一反应都是全美气象雷达网正在恶劣天气下全面瘫痪。但只要把视线移到正文底部，就会发现一行不起眼的声明，指出该页面不再维护或更新，并引导用户前往 radar.weather.gov 查看实时状态。
核查页面档案可以确认，这则引发虚惊的通知实际发布于 2020年10月15日，当时仅针对公众网页端的访问异常。政府机构网站未及时清理历史应急页面，又在全站模板中嵌套了动态更新的全局天气横幅与 2026年4月陆地分区调整（Land Zone Changes April 2026）等新导航链接，直接拼凑出了一起跨时空的假突发新闻。比这起网页乌龙更值得追问的是，当官方真的宣布全国雷达中断时，究竟是物理雷达停转了，还是数据链路断了。
僵尸网页背后的三层解耦：网页宕机不等于雷达停转
普通公众眼里的雷达瘫痪，在气象工程体系里对应着三个完全独立的故障层级。美国国家气象局的 NEXRAD 雷达体系在架构上严格解耦，底层是分布在全美的物理多普勒雷达网，中间层是中央数据收集与分发网络，最上层才是面向公众的网页渲染端（radar.weather.gov）。
负责底层硬件维护的雷达运营中心（ROC）在官方问答中明确划清了责任边界，指出该中心只管物理雷达运行，不负责维护公众展示网站。2020年10月安克雷奇办公室发出的那则通知，仅仅是顶层的公网网页端出了故障。当时底层的物理雷达依然在正常扫描大气，各地气象站和专业机构也能照常接收原始数据。
把前端网页故障直接命名为全国雷达中断，很容易在极端天气期间制造不必要的公众恐慌。更严重的问题在于，这些不再维护的静态告警页长期留在公网域名下，一旦被搜索引擎抓取或在社交网络上二次传播，就会与页面顶部的实时暴风雪、雷暴预警产生化学反应，让公众误以为防灾基础设施在关键时刻掉链子。
真正的5小时断网惊魂：商业云分流救不了主干网单点故障
如果说 2020 年的网页通知只是一场前端乌龙，那么 2024年4月1日至2日 夜间发生的事故，则暴露了美国气象数据主干网真正的致命软肋。当时 NWS 遭遇了一次有完整记录的全国性数据分发中断，故障持续约 5个小时，直接切断了多个地方气象预报办公室与一线气象学家的实时雷达数据流。
那场断网发生时，美国中西部正在经历强对流天气。圣路易斯电视气象学家 Steve Templeton 在播报龙卷风警报的关键时段，突然失去了实时雷达的访问权限，只能被迫启用 NWS 的降级备用方案来研判风暴路径。直到美东时间 2024年4月2日早上 6:30，NWS 工程师将网络服务从马里兰州 College Park 的主节点硬切换到科罗拉多州 Boulder 的备份节点，全国数据分发才恢复正常。
前端网页宕机只是看不见图，主干网断流则会让预报员在龙卷风前夜失明。
为了规避官方网页宕机或单一服务器拥堵，许多风暴追逐者和专业气象人员会付费购买 RadarScope 等第三方专业雷达软件。这类商业软件支持在设置中手动切换数据源，提供 NOAA 官方源、RadarScope 自建源、AllisonHouse 以及 Amazon（亚马逊云）共 4种 数据分发通道。
但商业云分流解决不了源头断水的问题。无论是亚马逊云还是 AllisonHouse，它们扮演的都是二级批发商角色，底层原始观测数据依然百分之百依赖 NWS 中央节点向上游推送。一旦马里兰州主节点出现类似 2024年4月那样的主干网故障，所有第三方商业软件的四个切换选项会同时失灵。
在那场长达 5 小时的数字断网中，部分气象监视和警报出现了明显延迟，甚至未能送达互联网分发渠道。唯一没有受影响、保持正常播报的是古老的 NOAA 气象广播（Weather Radio）。对于身处龙卷风走廊的居民和应急管理部门来说，盯着政府清理历史遗留网页只是消除噪音的第一步；真正决定生死的变量，是 NWS 能否把 College Park 与 Boulder 双节点间的灾备切换时间从 5小时 压缩到分钟级，以及家庭防灾包里是否还留着一台不靠互联网的无线电气象收音机。
- 风险.第三方气象软件的云端多源切换只能防御分发服务器拥堵，无法免疫国家级气象主干网的上游断流，极端天气下仍需保留 NOAA 无线电广播作为保底手段。