比特币节点的连接不是一个数字决定的，而是一组配额共同决定的。配置文件里能看到 maxconnections，帮助文本告诉你默认是一百二十五，但那只是总闸；真正运行起来之后，节点内部把连接切成几种角色——完整中继的出站线、只下载区块的专线、两分钟一试的探针、手动固定的名单——每种角色各有上限与优先级。把这套配额读明白，才能解释为什么日志里连接数总在某个数字附近波动，以及为什么“多连节点”这件事并没有一个单开关可调。
v31.0 源码里的骨架是这样的：总闸 DEFAULT_MAX_PEER_CONNECTIONS 为 125，指的是自动管理的全部连接。其中出站完整中继连接最多八条（MAX_OUTBOUND_FULL_RELAY_CONNECTIONS），它们既收块也收交易，是你从网络获取信息的主力；出站区块专线最多两条（MAX_BLOCK_RELAY_ONLY_CONNECTIONS），只交换区块头与区块，用途是以极低成本保留第二条独立区块来源——主中继线被分叉或拥塞时不至于失明；此外还有一条探针线（MAX_FEELER_CONNECTIONS 为一），按 FEELER_INTERVAL 约两分钟的节奏随机尝试一个候选地址，能连上就保留成完整出站、连不上立刻丢弃，它的作用是把地址库里的新地址不断试进真实连接，防止节点图谱固化。三类加起来远小于总闸，剩下的名额主要留给入站连接——你的节点对外提供中继服务的部分。
数字之外是节流与例外。手动名单走独立通道：-addnode 或 addnode RPC 添加的连接不计入一百二十五，但自身另有上限，源码常量 MAX_ADDNODE_CONNECTIONS 为 8，且这些连接受固定间隔的重连调度管理。如果开了私有广播功能，它还有第三个平行池：广播用的匿名短连接最多六十四条（MAX_PRIVATE_BROADCAST_CONNECTIONS），用完即关，同样不占主名额。帮助文本对这一点写得很直白，很多人在这里误读，以为 addnode 挤掉了正常对端——实际上它挤不掉，两个池子在代码里是分开计数的。启动时的文件描述符预算还会再压一次总闸：预算不足时节点会打印收缩警告并以更小的数字运行，这是另一个会话里详述过的账本，此处只强调它与角色配额是两道独立的门。
这些配额如何影响你观察到的现象？第一，出站八条完整中继意味着“从少数大对端下载”是默认形态，同步速度取决于这八条线路的质量而非连接总数；盯着 inbound 数字爬到上百条并不会加快同步，那只是你在为网络出力。第二，探针连接让健康节点的地址结构保持新陈代谢，若一台节点长期不产生新的完整连接，往往是网络位置问题（无可达入站、NAT 后、时钟异常），修复可达性比调参数有效。第三，区块专线解释了为什么某些节点日志里会出现只发块不转发交易的“沉默对端”，它们不是故障，是设计中刻意保留的窄信道。
最后说隐私与配额的相互作用。连接角色同时是隐私边界：完整中继连接会收到交易邀请，你的交易先发给谁、区块从哪几条线先到，都可能被观察者统计。v31.0 在交易广播上做了按子网打散与延迟交错，在连接上则用角色分离降低单一观察面——配额体系在某种意义上是拓扑层面的隐私措施：把“谁在什么信道上能看到什么”固定成对小规模观察者的不均匀切片。普通用户不需要为此改动任何默认值，但在设计自托管服务、公共节点、网关时，这套配额表应当是架构评审的第一页材料。
风险提示：本文为节点网络机制说明，不构成任何投资建议；文中常量以比特币核心 v31.0 源码为准，后续版本可能调整，请以对应版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。