Bitcoin Core 降低 P2P 流量实战：-maxuploadtarget、-listen、-maxconnections 与 -blocksonly 详解

2026-09-06 22:08:11作者：裴麒琰

本文基于 Bitcoin Core 仓库中的 reduce-traffic.md 展开，面向受运营商带宽限制约束的节点运营者。你将学会用四个官方命令行参数——-maxuploadtarget、-listen=0、-maxconnections、-blocksonly——分别削减上传配额、入站连接、总连接数和交易转发流量，并结合源码理解每个限制在 CConnman 与消息处理层的真实生效位置。

1. 先理解默认连接模型：流量从哪里来

Bitcoin Core 默认允许与最多 200 个对端建立连接，其中 11 个是出站连接，因此最多可有 189 个入站连接，且入站连接中只有约一半（由 -inboundrelaypercent 控制，默认 50%）可以占用交易中继（full-relay）槽位，其余只能用于低流量的“仅区块中继”（block-relay-only）对端。11 个出站连接构成为：8 个 full-relay 连接、2 个 block-relay-only 连接，以及偶尔出现的 1 个短连接 feeler 探测或额外的 block-relay-only 连接。

这些数字在源码中都有明确定义：

默认总连接数：DEFAULT_MAX_PEER_CONNECTIONS{200}，见 src/net.h；
出站构成：MAX_BLOCK_RELAY_ONLY_CONNECTIONS = 2、MAX_FEELER_CONNECTIONS = 1，以及 full-relay 出站上限，均定义在 src/net.h；
入站 full-relay 槽位百分比：DEFAULT_FULL_RELAY_INBOUND_PCT{50}，见 src/net.h；
-maxconnections 帮助文本明确说明“%u 个槽位预留给出站连接”，见 src/init.cpp。

默认设置下，节点同时向众多对端中继区块和交易，并会在初始区块下载（IBD）期间向新节点提供历史区块，因此流量消耗相当可观。下面四个手段按“削减上传 → 削减连接数 → 削减交易转发”的顺序逐层降流量。

2. 限制每日上传量：-maxuploadtarget=<MiB/天>

流量中一个主要来源是为其他节点提供历史区块——即其他节点做 IBD 同步时向你下载旧区块。-maxuploadtarget 以“MiB/天”为单位设定上传目标，默认值为 0M，即不限制（见 src/net.h 中的 DEFAULT_MAX_UPLOAD_TARGET{"0M"}）。

关键特性（与 reduce-traffic.md 原文一致）：

这不是硬性上限，而是最小化出站流量的阈值。当接近限制时，节点通过“不再提供历史区块”（定义为比当前 tip 时间旧一周以上的区块）来削减上传；
带 download 权限的对端永远不会被断开连接，但其流量仍计入目标额度。download 权限的语义在 src/net_permissions.cpp 中描述为 “allow getheaders during IBD, no disconnect after maxuploadtarget limit”，对应权限标志定义在 src/net_permissions.h。

参数解析与格式支持可在 src/init.cpp 的帮助文本中确认：支持 k|K|m|M|g|G|t|T 后缀，小写按 1000 进制、大写按 1024 进制；解析逻辑在 src/init.cpp 中调用 ParseByteUnits，解析失败会返回 Unable to parse -maxuploadtarget 错误。

源码层面的生效机制：CConnman::OutboundTargetReached 是判断入口，见 src/net.cpp。它维护一个以 24 小时为周期（MAX_UPLOAD_TIMEFRAME，注释见 src/net.cpp）的上传字节累计量 nMaxOutboundTotalBytesSentInCycle。值得注意的是，针对“历史区块服务”路径，该函数还会预留一块缓冲区：按周期内剩余每 10 分钟预留一个 MAX_BLOCK_SERIALIZED_SIZE，以“至少保证每个区块能被中继一次”，避免限流把正常区块广播也卡住。

在消息处理层，实际断开行为位于 src/net_processing.cpp：当 OutboundTargetReached(true) 为真、请求的区块时间比最佳头部旧于 HISTORICAL_BLOCK_AGE（即约一周）、且对端不具备 Download 权限时，节点直接置位 pfrom.fDisconnect 断开该对端。另一处调用 OutboundTargetReached(false) 则用于交易数据的发送路径（src/net_processing.cpp），此时检查的是不带历史区块缓冲的总上传额度。

示例配置：

# 每天上传上限 20 GiB（按 1024 进制解析）
bitcoind -maxuploadtarget=20G

需要牢记：新节点依赖愿意提供历史区块的节点完成同步，长期低限额运行意味着你在减少对网络的贡献，请酌情权衡。

3. 关闭入站监听：-listen=0

-listen 默认开启（DEFAULT_LISTEN = true，见 src/net.h）。关闭监听后：

入站连接为 0，节点最多只剩 11 个出站对端；
区块和交易只中继给更少的节点，总上传量随之下降。

此外源码中存在两处参数联动，见 src/init.cpp：当设置了 -connect 或 -maxconnections=0 时，节点会自动推定并设置 -listen=0 与 -dnsseed=0，并记录参数联动日志。也就是说，如果你走的是“白名单对端”路线，监听会自然被关掉，无需重复配置。

4. 压缩总连接数：-maxconnections=

如果流量限制非常苛刻，可以进一步把最大连接数压到最小。-maxconnections 表示“最多维持 n 个自动连接”（默认 200），其出站保留槽位数为 full-relay + block-relay-only + feeler 三者之和，帮助文本见 src/init.cpp。

行为边界由初始化校验保证：

必须大于等于 0，否则报 -maxconnections must be greater or equal than zero，见 src/init.cpp；
受文件描述符等系统资源限制时，启动阶段会自动下调该值并给出 Reducing -maxconnections from %d to %d, because of system limitations 警告，见 src/init.cpp。

原文档特别提醒：比特币的去信任模型在“连接了足够多的节点”时效果最好，过度压缩连接数会削弱你独立验证链的能力，请只在流量确实吃紧时使用。

5. 关闭交易转发：-blocksonly

交易转发（接收、中继、广播）会显著增加 P2P 流量。-blocksonly（默认 false，见 src/net.h）让节点只与对端同步区块，拒绝来自网络对端的交易。其完整影响（继承自 reduce-traffic.md）：

费率估算将不再工作——费率依赖内存池中的交易样本；
自动把未显式设置的 -walletbroadcast 置为 0，即禁用钱包交易自动广播。注意：当节点加载了钱包或你用它广播交易时，不中继他人交易可能损害隐私；
带 forcerelay 权限的对端仍然例外：其交易仍会被接收并中继。该权限描述为 “relay even in -blocksonly mode, and unlimited transaction announcements”，见 src/net_permissions.cpp；-blocksonly=1 时会自动关闭 -whitelistrelay，见 src/init.cpp；
区块传播会变慢：紧凑区块（compact block relay）只有在交易转发开启时才能使用。源码印证了两点：blocksonly 模式下节点从不向对端请求高带宽模式（src/net_processing.cpp）；若此时收到紧凑区块会打出 sent us a compact block even though we are blocksonly! 调试日志（src/net_processing.cpp）；
另外，-blocksonly 还会把默认内存池上限下调（DEFAULT_BLOCKSONLY_MAX_MEMPOOL_SIZE_MB），以避免意外的资源占用，见 src/init.cpp；在 blocksonly 模式下，对端需要 relay 权限才能向本节点发送交易（src/net_processing.cpp）。

6. 组合建议与适用前提

四个手段可叠加使用，按流量削减收益大致排序：

参数	削减的对象	代价
`-maxuploadtarget=<n>M`	IBD 期间向新节点服务历史区块的上传	新节点可能找不到足够愿意服务历史区块的节点
`-listen=0`	入站连接及其转发流量	失去入站多样性，仅剩 ≤11 个出站对端
`-maxconnections=<n>`	总连接数	去信任验证能力随节点数下降
`-blocksonly`	交易转发与内存池	费率估算失效、区块传播变慢、隐私与钱包广播受影响