getpeerinfo怎么看连接质量？

getpeerinfo像一张逐连接体检表。它既不是“peer越多越好”的排行榜，也不是看到一个高ping就立即断开的黑名单。真正有用的读法，是先确认连接是什么，再看它是否持续传递新数据，最后才评估是否需要人工处置。

从连接身份证开始分组

getpeerinfo按peer返回inbound、connection_type、network和transport_protocol_type等连接语义；connection_type的输出值可能随版本变化。

先记录addr、network、inbound、connection_type与transport_protocol_type。inbound只说明连接由对方发起，不代表对方危险；outbound-full-relay、block-relay-only、manual、feeler等连接承担的职责不同，也不能用完全相同的流量期待去打分。使用Tor、I2P或代理时，网络路径本来就可能比直连更慢。

观察层	关键字段	要回答的问题	常见误判
身份与方向	network、inbound、connection_type	它为何存在	入站就是恶意
时延	pingtime、minping、pingwait	网络是否持续变慢	一次尖峰就是故障
同步	synced_headers、synced_blocks	对方给的数据是否跟上	peer数多就一定同步快
中继	last_block、last_transaction、bytessent_per_msg	它实际传了什么	没有交易流量就是失联

监控程序应保存原始枚举值，不把未知connection_type强行映射成“异常”。官方明确提醒该输出可能变化，稳妥做法是把新值标为待识别并继续采样。

用两条延迟线识别瞬时抖动

pingtime是最近完成的ping往返时间，minping是观测到的最小往返时间；单次高ping不能单独证明peer不可用。

若pingtime突然升高而minping仍低，说明这条路径曾经表现良好，当前可能只是拥塞或调度抖动。若pingwait存在，则说明一次主动ping尚未完成；此时应等待下一次采样，而不是把未完成值与已完成往返时间直接比较。至少保留多个时间点，并同时记录本机CPU、网络出口和其他peer的延迟分布。

一个实用告警可以要求三个条件同时满足：连续多个窗口高于本节点历史分位数、同网络类型的其他peer没有同步升高、并且同步或中继指标也出现退化。这样比固定写死“超过200毫秒就踢掉”更能适配跨地区和隐私网络。

把同步差距换算成可解释证据

synced_headers、synced_blocks、last_block、last_transaction及按消息统计的字节数可交叉判断数据新鲜度与流量特征。

将synced_headers和synced_blocks与本机当前tip比较，而不是只看绝对值。落后一两个块可能只是传播时序；长时间不更新、last_block也没有推进，才更像区块中继失效。交易流量同样要结合连接职责：block-relay-only本就不负责普通交易中继，不能因last_transaction旧就判为坏连接。

按消息类型的发送与接收字节可帮助识别连接究竟在交换地址、区块还是交易，但累计数字必须做时间窗口差值。节点重启后基线会变化，监控系统要保存启动时间，避免把重置后的低计数当作流量骤降。

31.0升级先修监控兼容

Bitcoin Core 31默认不再返回startingheight，仅启用-deprecatedrpc=startingheight时保留，监控程序需先做版本兼容。

若旧看板把startingheight设为必填字段，升级后可能把所有peer误报为数据缺失。正确迁移是允许字段不存在，并改用synced_headers、synced_blocks及本机链高度做主要判断。确需短期兼容旧程序时可了解deprecatedrpc开关，但不应把临时兼容当成长期接口契约。

同时对JSON解析器做向前兼容：忽略不认识的附加字段、保留未知枚举、只对真正必需字段设硬失败。发布新版监控前，用至少一个31.0节点和一个旧版本节点回放样本。

一次十分钟的连接体检

先运行getnetworkinfo建立全局连接与网络基线，再每隔固定时间抓取getpeerinfo，按peer id或稳定连接标识比较变化；随后检查高延迟连接的同步差距与消息流；最后才查看是否是单peer问题、某类网络问题，还是本机整体出口异常。涉及隐私网络时不要在工单公开完整地址。

真正需要处置时，记录触发条件、时间窗口、替代连接是否充足和处置后的同步变化。一次断连后指标改善，仍不等于对方恶意；它只能证明本次更换对当前性能有帮助。

把踢掉peer变成最后一步

好的节点监控先证明异常持续存在，再判断它影响的是延迟、区块同步还是交易中继。只有证据指向单个连接且更换有明确收益时，才进入连接处置。