节点跑在远端服务器上，想快速看一眼对端连接情况，多数人的第一反应是拼一条 bitcoin-cli getpeerinfo 再用 jq 过滤——几十个字段的 JSON 在终端里几乎不可读。比特币核心其实自带一个专为人眼设计的仪表盘：bitcoin-cli -netinfo。它不是新命令，实现却和常规 RPC 有一个关键差别——它是命令行工具在本地把两个 RPC 拼出来的输出。v31.0 源码把这件事写得很清楚，值得按源码把用法读全。
底层是批量请求，不是独立命令
bitcoin-cli.cpp 的 netinfo 帮助文本原话是”底层通过调用 getpeerinfo 和 getnetworkinfo 取数”。也就是说服务器端不存在 netinfo 这个 RPC 方法，help 里查不到它；一切渲染都发生在你的终端上。这个事实有三个推论：一，任何能访问 RPC 的 cli 都能用，与节点版本无强绑定，新字段渲染不了只是列缺失；二，看到的表是两次非原子请求的拼接，行与行之间可能差一秒；三，防火墙只放行 RPC 端口的环境里，仪表盘不需要额外通道。顺带一提，同一个工具家族的 -getinfo 也是本地拼接，帮助文本明确警告其输出来自多个非原子请求——这两者是同一设计哲学的两个实例。
档位与开关
参数签名允许一个 0 到 4 的档位（源码常量 NETINFO_MAX_LEVEL 为 4）：0 档只给可达网络的连接计数、区块中继与手动连接数、本机监听地址清单；1 档在这些之前加一张对端表；2 档加地址列；3 档加版本列；4 档两列都要。另有一个 outonly 开关（可简写 o），只对非零档位有效，把表收窄为出站连接——入站多的大节点用它省屏幕。超过两个参数时只读前两个；help 或 h 打印完整说明。文档还建议配合 Linux 的 watch 命令做实时面板，这比反复手敲命令更能暴露连接抖动的节拍。
对端表默认按方向分组、组内按最小延迟排序，列里能看到连接类型、网络、在线时长、延迟均值与最小值、addrman 处理计数、最近收发区块与交易的时间差、服务位、传输协议类型（加密与否）。排查”我是不是只有入站没有出站”这类问题时，这张表的密度远高于逐字段翻 JSON；2 档的地址列也顺带替代了临时开 logips 的需要——看地址不必污染服务器日志。
与 getpeerinfo 的分工
选择逻辑可以很简单：肉眼巡检、演示、写故障报告时优先 -netinfo；脚本化处理字段时直接用 RPC，因为仪表盘的排版是给人看的，列宽与排序随版本调整，不是稳定的机器接口。另一个细节：1 至 3 档刻意不显示地址与版本列，不是故障而是防横向滚动；表里方向列的 in 与 out、服务位打星号的含义，在 help 文本里都有逐列说明，值得花一分钟通读一次。
常见误读三条
一是”在节点 RPC help 里找不到 netinfo 所以我的版本没有”——它本来就不在服务器端命令表里。二是”仪表盘和 getpeerinfo 数据必然完全一致”——两次请求之间节点状态会变，个别时间戳字段对不上属正常。三是把 outonly 用在 0 档——源码规定该参数只在档位非零时有效，0 档只有计数没有表，混用会得到无意义的输出。
最后给一个巡检套路：watch -n 5 bitcoin-cli -netinfo 4 挂一小会儿，重点看出站数量是否长期贴近下限、last_recv 与 last_trs 的时间差是否有个别对端持续膨胀、传输协议类型里明文连接占比。三个信号都健康，网络层基本不必再查；哪个异常，再回到对应 RPC 细看——仪表盘负责引起正确的怀疑，不负责给出全部结论。
上手前的两条准备
一是权限：仪表盘需要的 getpeerinfo 与 getnetworkinfo 都是普通读取命令，cookie 或 rpcuser 鉴权即可，但如果你在远端跳板机上操作，请通过 SSH 隧道而非放开 rpcbind 把端口暴露出去——仪表盘再好，也值得配一条 ssh -L 127.0.0.1:18332:127.0.0.1:8332 host 来看。二是脚本习惯：临时巡检用仪表盘，写进监控系统的取数逻辑仍旧建议用单条 RPC，输出格式稳定的接口才养得住告警规则。把”人看的路”与”机器走的路”分开，是让这个工具长期好用的前提。
风险提示：本文为命令行工具使用说明，对应 Bitcoin Core v31.0 源码；输出字段与排版随版本演进，以所用版本的 help 文本为准；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。