stats/dht如何区分WAN和LAN？

DHT统计里出现几百个peer，能否说明IPFS全网有几百个节点？不能。每个Kubo实例维护自己的路由视野，WAN和LAN又属于不同协议环境。stats/dht适合观察本节点的路由系统，却不提供一份权威全网成员清单。

一次请求可能面对多个DHT实例

stats/dht返回当前节点一个或多个DHT实例的统计，可通过可选参数选择目标DHT。

调用时保存可选dht参数、返回对象、Kubo版本和节点配置。解析器不能假设永远只有一个实例，也不能按数组顺序给WAN或LAN贴标签；应读取实现提供的标识，并和本节点路由配置核对。未知实例保留原名，避免丢数据。

stats对象内部结构可能随Kubo和底层libp2p版本演进。日常指标从已验证字段抽取，原始JSON用于升级后重放。关键字段缺失时标unknown，而不是用上一次值无限延续。

Kubo通常区分WAN DHT与LAN DHT，协议标识和节点角色不同，不能把两个路由表直接相加比较。

WAN DHT面向广域内容与peer路由，LAN DHT服务本地网络发现，并使用不同协议标识。一个peer可能出现在某一层而不在另一层。看板把两层分开显示，告警也依据各自正常基线；直接相加会把不同集合和角色混成没有意义的总数。

DHT路由表由本节点维护的对等条目组成，是局部快照而非全网节点清单。

Kademlia路由表保存本节点为路由需要而维护的一部分peer，不复制全网所有成员。大小和分桶变化受在线时长、网络质量、查询活动与维护过程影响。跨节点比较时，节点角色、地区、在线时长和版本不同，绝对数字没有直接可比性。

合理的告警更关注持续变化：路由条目长期下降、刷新失败、连接同步退化或查询耗时上升。节点刚启动时路由表成长属于正常阶段，应与稳定运行基线分开。

RPC返回成功或路由表有peer都不能单独证明指定CID可取回，应与findprovs、连接和实际块读取联合。

stats/dht回答路由系统的局部状态，findprovs回答特定CID能否发现provider候选，swarm与拨号检查连接，block或DAG读取才验证内容。四层中任何一层失败，都不能由其他层的绿色指标替代。

例如路由表稳定却findprovs无结果，可能是内容未提供或记录过期；findprovs返回Peer却无法连接，可能是地址或NAT；能够连接但缺子块，则进入Bitswap和DAG完整性排查。把这条分流写入告警链接，值班人员不必从头猜。

每个样本至少携带node peer ID、Kubo版本、启动ID、DHT实例、模式、最新采样时间和原始结果哈希。进程重启或升级作为序列断点；缺采样显示空洞，不插值。配置变更单关联到看板，解释预期变化。

容量与可用性阈值来自同一实例在稳定阶段的历史分布。可以设置“持续多个窗口偏离基线且查询探针同时失败”的组合告警，减少启动和网络短抖动造成的噪声。

准备一台提供内容的节点和两台查询节点，分别位于局域网与外部网络。保存三者stats/dht、findprovs、连接和实际读取结果。这样能直接观察LAN发现、WAN提供、NAT与内容交换的边界，也能验证监控是否把实例标记正确。

测试结束后撤销临时暴露和凭据。Kubo RPC仍是管理接口，不为方便采样直接开放公网；通过受控网络收集并限制方法范围。最终报告只对被测试的节点、网络和时段下结论。

将每份stats/dht结果绑定到实例、模式、版本和时点，再用provider发现和实际读取回答内容问题。越清楚地区分局部观测与全网事实，监控越可靠。

资料访问时间为2026-08-07。当前仍需按部署核验：stats对象内部字段会随Kubo和go-libp2p-kad-dht版本变化，采集器应保留原始JSON。

相关站内主题：bitswap stat、stats bw、swarm peers。本文用于技术教育与节点运维参考，不构成投资、收益或资产安全承诺。