getaddednodeinfo怎样审计手工节点？

发布 2026-08-14 更新 2026-08-14 陈嘉伟浏览 --

getaddednodeinfo展示通过addnode RPC或-addnode配置维护的目标、连接状态与当前连接端点，但它不是全部Peer清单或DNS候选列表。本文说明核心字段的读法，以及如何再用getpeerinfo核对当前manual连接。

getaddednodeinfo怎样审计手工节点？图 1 — getaddednodeinfo怎样审计手工节点？ · 图 1

手工节点列表、当前连接列表和地址管理器是三套相关但不同的数据。getaddednodeinfo只围绕通过addnode RPC或-addnode配置登记的目标返回信息；自动选择的Peer不在这里，列表中的目标也不保证此刻已经连接。审计时必须先核对配置意图，再把返回的当前连接端点映射到getpeerinfo的实时连接。

先定义应有的手工节点清单

getaddednodeinfo返回通过addnode RPC或-addnode配置添加的节点信息。

从配置管理系统导出期望目标、用途、网络、所有者和有效期，再与RPC返回比较。没有所有权的遗留addnode应进入复核，而不是直接删除；少一个目标也可能是启动参数未加载、配置文件路径错误或变更尚未重启。

列表目标可以是主机名或地址。保留原始addednode字符串很重要，因为它代表配置意图。addresses不是DNS候选清单；若要审计某个主机名的全部DNS结果，应独立解析并保存当时的DNS答案，不能从该RPC反推。

三层返回字段逐层读

仅当顶层connected为true时才返回addresses；每个address是当前已连接的Bitcoin服务器IP与端口，不是DNS候选清单。

层级	字段	审计问题
目标	addednode	配置希望维护谁
汇总	connected	当前是否存在相关连接
地址	address	当前已连接的Bitcoin服务器IP与端口
地址	addresses[].connected	此地址当前方向是outbound还是inbound

connected是目标层面的当前快照，短时DNS切换和连接重建可能让它变化。仅当顶层connected为true时才会返回addresses，数组中的每个条目都是当前已连接端点，并由addresses[].connected标明方向；它不列出尚未连接的DNS候选。

过滤参数既方便也会报错

可选node参数用于过滤特定目标；目标不在added node列表时会返回错误。

可选node用于查询一个特定目标。如果它不在added node列表，RPC会返回错误。这种错误应解释为“当前手工列表没有该目标”，不是网络不可达；要检查拼写、端口、主机名形式和配置来源。批量巡检可以先取全量，再按原始addednode精确匹配。

自动化不要把错误吞掉并生成connected=false，否则会把“未配置”和“已配置但未连接”混成同一种状态。前者需要核对变更，后者需要排查网络或Peer。

用getpeerinfo确认具体manual连接

每个addresses[].connected以outbound或inbound标识当前连接方向；要核对具体Peer的manual类型和id，应继续查询getpeerinfo中的connection_type和id。

getaddednodeinfo不能替代当前Peer详情。对connected目标，把addresses中的当前端点与getpeerinfo的addr交叉匹配，确认connection_type为manual，并记录id、连接时长、lastrecv、ping和版本信息。可参考getpeerinfo连接质量建立健康判断。

主机名可能解析到多个地址，但addresses只呈现当前连接端点，不呈现全部DNS答案；入站连接也可能碰巧来自相同地址。仅凭IP相等不足以证明那就是addnode维护的连接，应结合connection_type、日志和配置。