比特币节点记着一本不断更新的”熟人通讯录”：谁在什么地址、上一次什么时候露面、是谁介绍给我们的。平时你只能通过 getaddrmaninfo 看到各组各网的新旧地址计数，而另有一个实验性质的命令能把整本通讯录连格子带页码摊开——getrawaddrman。它的帮助文本开头就挂着一行”实验性警告：本调用可能在后续版本中改变”，这行字本身就是一个重要事实：输出结构不受长期稳定承诺，脚本依赖它的人要为此负责。
两张表、一格一格地看
命令没有任何参数，返回一个两层动态对象：第一层是表名，只有 new 和 tried 两张；第二层是”桶号/格位”形式的位置键，每个格位里躺着一个地址记录。这正是地址管理器的真实物理布局——新地址先按来源和网组散进 new 表的海量小桶，经过一次成功连接、活过考察期的才升进 tried 表接受更严格的轮换管理。getaddrmaninfo 给你的是每格平均值的统计口径，getrawaddrman 给你的是原始格子：哪个桶哪个位置、住了谁、什么时候被安排搬走，一目了然。
每条记录固定带地址、端口、网络类型、服务位和最后露面时间，再带两件溯源信息：source 是”把这个地址介绍给我们”的那个对端，source_network 是介绍人所走的网络。若启动时配置了 -asmap，记录里还会多出 mapped_as 与 source_mapped_as 两个自治系统号，分别对应地址本身和介绍人的运营商归属。也就是说，一次调用就能回答两个排障问题：我的地址库有多少地址是从同一个源听来的（同源集中是 eclipse 攻击的经典前兆），以及我的新地址在运营商维度上有多分散。
从”计数对不上”到”谁在喂我地址”
日常巡检中它的用处集中在三类。其一是怀疑地址库被污染：把 new 表里的 source 字段聚合一下，如果大量地址出自一两个介绍人，你的地址来源多样性已经退化，该考虑多接几个不同网络的邻居了。其二是调试 -onlynet 或代理配置：命令输出里的 network 字段直接告诉你哪些记录还留在退出路由的网组里，对照重启前后的分布，能确认新策略是否生效。其三是理解驱逐行为：桶位分布让你看到算法如何把同一网组的地址塞进不同桶以拉开距离，教科书画的”表与桶”模型在这里能逐格验证。
但要注意几条边界。first：输出里的时间戳是”最后被确认活着”的时间而非首次见到；第二，同一地址在 new 表里可能同时存在多条不同 source 的记录——地址库按”介绍事件”记账，不以地址去重；第三，格位号只是内部数据结构的位置编号，不同版本、不同启动序列下没有任何可比性，把某次 dump 的桶位截图当作”这个地址应该在哪”的证据链，是用错了工具。
读它的安全感来自哪里
值得强调的是该命令的只读属性：它不改动地址库、不影响下一条 addr 消息的处理，随时可查、查完即走。真正的敏感性在输出内容本身——地址库是一份关于”网络上谁活着”的观测样本，包含大量公网端点，把它贴到公开论坛求助前先想清楚。同样，输出里的 mapped_as 来自你本机的 asmap 映射文件，反映的是你对互联网拓扑的本地认知，不是链上事实。读它还有三个口径细节：时间戳字段是”最后被确认活着”的时间而非首次见到；同一地址在 new 表里可能有多条不同 source 的记录，因为地址库按”介绍事件”记账、不以地址去重；桶位号只是内部数据结构的位置编号，不同版本、不同启动序列下互不可比。
对绝大多数用户，getaddrmaninfo 的分组计数已经够用；当问题真的下钻到”某格里的地址是从哪灌进来的”这一粒度时，才轮到 getrawaddrman 出场。它是节点给自己的地址库装的透明抽屉：默认没人看，需要取证时拉开，每一格都写得明明白白。它的实验性标签也不意味着不稳定得不能用，而是提醒你：核心团队保留了随地址管理算法演进而调整输出形状的权利，把它接进自动化之前，请在升级说明里多看一眼。
风险提示：本文描述的是节点诊断工具，不构成任何投资、组网或买卖建议；公开分享节点数据前请自行做脱敏处理。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。