卫星与偏远场景的WiFi网络计费系统：NAC计费节点与内网外网分离计费

普通园区WiFi计费，流量可以粗着来，带宽便宜、差一点无所谓。可到了卫星、星链、海船、偏远乡村，计费精度直接关乎项目亏不亏。卫星带宽是光纤的十到一百倍价，流量糟蹋一字节都是真金白银，这时候得换精准计费的路数。

核心变化是计费节点的位置。传统场景以云端计费为主，卫星场景必须把NAC设备作为计费节点，在本地做流量统计和计费，不依赖云端。原因很直接：卫星链路本身不稳定，万一云端连不上，纯云端计费就会失准甚至停摆；而NAC在本地，用户流量到期后能直接把人下线，避免流量白白流失。

精准到什么程度？卫星场景要求按字节计费，精确到字节。认证之后，系统下发一个流量值参数给NAC，NAC以此对用户做精准流量计费。这和按套餐包月、按时长估算的思路完全不同——这里每一KB都要算清楚，因为带宽太贵，容不得"差不多"。

另一个关键设计是内网外网分离计费。卫星链路贵，但局域网内部的流量（比如本地流媒体、内容分发）不应该走卫星、也不该计费。通过RADIUS接口可以实现内网免费、外网计费，配合本地缓存/内容服务器减少卫星带宽消耗。如果内外网混着计费，用户看个本地视频都被按卫星流量扣钱，既不合理也容易造成纠纷。

高延迟带来的不只是慢，还有Portal体验问题。卫星链路物理延迟通常超过500毫秒，直接推送Portal页用户体验极差。方案是用Portal缓存技术：Portal服务器放云端，NAC把页面下载到本地缓存，用户连接时从本地NAC秒弹页面。这样即使卫星高延迟，认证页也能立刻出来，计费前的交互不卡。

断线保护也要重做。卫星链路易受天气、卫星过境影响，传统场景断线后用户下线即可，卫星场景要求断线后本地业务不中断——AP配置要持久化，局域网业务继续跑。计费侧同样，即使云端断连，本地NAC也能精准计费并在到期时正确处置，不让计费准确性随链路一起掉线。

这类场景还牵出本地化要求：多语言Portal、本地移动支付（比如非洲的M-Pesa、MTN Mobile Money）、甚至现金充值。计费的支付闭环要适配当地习惯，否则用户有钱也交不进来。这些虽然不算计费精度本身，但是计费能收回来的前提。

所以卫星和偏远场景的WiFi计费，本质是把"计费节点下沉、计费精度拉满、内外网分开算"三件事做到位。它和光纤园区那套"粗放包月"逻辑不在一个维度，硬套普通方案，结果就是带宽成本失控、账单争议不断。

断线保护是这套设计的另一根支柱。卫星链路易受天气、卫星过境影响，传统场景断线后用户下线即可，卫星场景要求断线后本地业务不中断——AP配置要持久化，局域网业务继续跑。即使云端计费连不上，本地NAC也能在用户流量到期后将用户下线，计费准确性不随链路一起掉线，避免流量在无人计费的情况下持续流失。

计费精度上，卫星场景要求精确到字节，和按套餐包月估算的思路完全不同。认证后系统下发流量值参数给NAC，NAC以此做精准流量计费，每一KB都要算清，因为带宽太贵、容不得"差不多"。这种精度依赖NAC作为本地计费节点，而不是把计量全压在云端。

内网外网分离计费则是成本控制的另一半：通过RADIUS接口实现内网免费、外网计费，配合本地缓存和内容服务器减少卫星带宽消耗。如果内外网混着计费，用户看个本地视频都被按卫星流量扣钱，既不合理也容易产生纠纷。把贵的出口流量和便宜的本地流量分开算，是卫星场景计费的底线逻辑。

这类场景的硬件选型也有讲究。兼容设备清单里，认证网关NAC覆盖从桌面式到机架式多个档次，对应不同的双向流量和并发用户数；无线侧有WiFi6的AP和路由器，支持高密度并发、QoS和多认证方式。重点是这些设备要能在电力不稳定、高温沙尘的恶劣环境下工作，必要时配UPS或太阳能加电池组。计费节点可靠，前提是整个边缘设备能在偏远环境里长期不掉线。

判断标准很简单：项目带宽是否昂贵且需要精准流量计费？是否要内网外网分别计费？是否网络延迟高需要Portal缓存？三个"是"里命中一个，就必须按卫星场景的NAC计费节点思路来设计，而不是沿用普通WiFi计费的粗放模型。

卫星场景还要考虑Portal缓存——高延迟链路下把认证页缓存在本地，避免每次弹窗都跨国回源，计费节点的NAC也放在本地，流量统计不绕路。普通WiFi计费那套"认证页随用随取"的假设，在卫星环境下会直接拖垮体验。

落到判断上就一句话：带宽贵且要精准流量计费、内网外网分开算、网络延迟高得缓存Portal——这三个“是”里中一个，就得按卫星场景的NAC计费节点思路设计，别拿普通WiFi计费的粗模型硬套，不然账单和体验一起翻车。