节点在偷偷给谁发消息：getnettotals 的流量账本与隐私自查

一、一台节点的流量表

getnettotals 字段表很短：totalbytesrecv 与 totalbytessent 是累计收发字节，timemillis 是当前的毫秒级时钟读数，uploadtarget 是一组上传预算状态——测量窗口长度、目标字节、是否触顶、是否还在供历史区块、本周期剩余字节与剩余秒数，只有配置了 maxuploadtarget 时才有肉。它是消息层的累计，不含 TCP、IP 协议头那层皮，也不含被压缩算法省掉的部分——同一秒的账单，网卡和这条命令各说各话。

两个累计字段都只增不减，节点重启归零。想比较两代版本的带宽表现，得等两台机器跑过同样的时长与同样的网络事件，不然读到的差距多半是采样窗口造成的。

二、读法一：判断连接结构

单看总量意义有限，按时间差分才出故事：拿两次读数的差除以 timemillis 差就是平均速率。正常同步完成的稳态节点，接收端主要由新区块广播贡献；发送端在纯下载姿态（onlynet=onion 的隐身节点、blocksonly 的只看块节点）下明显偏薄，这是预期内的不对称。若节点长期对外服务历史区块请求，发送曲线会随请求脉冲爬坡——对照 uploadtarget 的 target_reached 与剩余字节，能立刻分清是正常服务还是超预算。

差分观察还有个副产品：速率曲线上的尖峰与区块高度的对应关系。每次出块后的集中收块是心跳级的规律信号，尖峰与出块对不上号时，说明流量来自服务请求而不是网络本身——这个粗筛比翻日志快得多，适合放进监控脚本做第一道报警器。

三、读法二：逐连接与逐消息归因

总量只回答多少，不回答谁。getpeerinfo 每台连接各记一本账：bytessent_per_msg 与 bytesrecv_per_msg 按消息类型细分。区块广播时代 inv 与 block 消息占大头属常态；某类历史拉取消息异常膨胀，说明有对端在借你的节点补课。隐私自查的动作就在这里：发现异常连接就核对其服务消息构成，必要时白名单限制或断开重连观察。单台连接的账与全局账对不上时，差额通常落在握手、ping 与被拒消息这类杂项上，量级应该很小；差额大说明有连接的统计被截断或重置过。

四、读法三：家宽预算视图

家宽节点的流量焦虑有现成仪表：配置 maxuploadtarget 后，uploadtarget 的六个字段构成一个滑动窗口账本——周期内余量、是否触顶、触顶后是否停止供历史区块。预算分级丢数据的策略在启动参数一侧，读数在这一侧，两边对照才知道节点今天是在服务网络还是在保护自己。触顶之后节点先砍的是最贵的历史区块服务，新区块广播与交易中继保留，网络角色的底线守得住，让出的是善意带宽。

五、操作建议

定期看趋势，把 getnettotals 与 uptime 同屏轮询取差分，或写进采集脚本按小时落一行。怀疑异常时先用 setnetworkactive 一键断流复测，让流量表归零重启计数再观察增量来源。把数据发到社区求助前，记下采集时间窗口与客户端版本；与身份绑定的时间戳先做脱敏。

六、流量与指纹

节点的流量形状也是指纹：区块请求的节奏、对端数量、上传预算档位，都可能让长期观察者在多跳之外认出同一台机器。做隐私取舍时把流量曲线也放进考虑范围——公网上没有沉默的中继，读数的形状同样在说话。想压低指纹的影响面，常见做法是让流量形状贴近大众：保持常规连接数、不做极端预算、避开特征化的服务画像，把自己的尖峰藏进群体的噪声里。

风险提示：本文仅为技术机制科普，不构成任何投资建议。