云服务器按流量计费，跑一个爱供数的比特币节点是什么体验？maxuploadtarget 就是为这类账单准备的闸门。v31.0 的帮助文本写得信息量十足：Tries to keep outbound traffic under the given target per 24h. Limit does not apply to peers with ‘download’ permission or blocks created within past week. 0 = no limit，并注明单位后缀支持 k K m M g G t T、缺省按 M，且小写按 1000 进制、大写按 1024 进制。
默认值先说清：源码常量 DEFAULT_MAX_UPLOAD_TARGET 是字符串 0M，即默认不限速；至少自 v22.0 起默认即为零，历史记忆里的”自带千兆额度”在近期版本并不成立，判断标准永远是看自己版本的帮助输出。
机制分三层。时间窗口：源码里的常量是二十四小时，节点滚动统计这段时间内的对外发送量。达到目标后进入节食模式：若对等节点索取的是最近一周之外的历史区块（或过滤器区块），连接会被断开——权限说明原文写得很直白，download 的含义是”允许在初始块下载期间取头、达到上传上限后不被断开”；同理，达到目标后其他节点索取内存池全量的请求也会被拒绝。两类豁免与限额本身：带 download 权限的连接（例如你自己的同步伙伴专用连接）不受断开惩罚，最近一周产出的区块照常服务，保证新鲜传播不受影响。
按帮助文本的单位规则，有一个值得做配置评审的细节：同一个数字配大小写并不等价。100m 是 100 个 1000 进制单位，100M 是 100 个 1024 进制单位，后者的额度比前者大约多百分之五；从聊天里复制的示例值还常混进不间断空格或全角字符，直接触发 Unable to parse 启动错误（这个报错值得单独讲，另文展开）。
什么场景该设、什么场景别碰？该设的是按量计费链路：4G/5G 路由器、流量封顶 VPS，在追块同步期不设上限能烧穿预算；设一个匹配额度后，节点会自动在预算内分配服务。不该设的是包月宽带、带宽充足的节点：白白牺牲为网络供数的能力，还会让向你要历史块的 peers 体验变差。误区也要点名：它不是隐私工具，豁免流量完全不受控，指望它隐藏行为会换来错误安全感；它也不限制下载方向，只管上传。
验收建议：改动前后各看一次 getnettotals 的上传目标区块与总量字段，确认目标值被正确解析；再在日志中观察是否按预期进出节食状态。数值按账单预算定，不要抄别人的”标准值”。
把预算设定过程写成可复用的三步。第一步测量：不动任何参数跑几天，记录每日上传量与用途构成——同步历史块、供 peers 块、供交易与地址各占多少。第二步定标：以账单预算除以安全系数（建议留三成余量给突发传播）作为目标值，写在配置里时单位用大写字母明确 1024 进制语义，并在注释里写明测算日期，方便续费季复核。第三步验证：观察 getnettotals 的上传目标字段与周期剩余信息，确认节点报告的目标与你的意图一致；再对照计费面板确认节流效果。预算、参数、账单三方对齐后，这个参数就进入”配完忘掉”的稳定态。
顺带纠正一个把节流当安全机制的传言：断开超时连接、拒绝历史请求都是资源行为，不构成对恶意对等节点的防御层；节点对异常行为的处置策略在别处定义，与本参数无关。同理，它也不会降低你的下载流量——同步阶段该下的历史块一个不少，节流只发生在”你往外卖”的方向。想同时压缩双向流量，手段是修剪 peers 数量与保留策略，那是另一组参数的职责。参数帮助文本、默认值可能随版本调整，以你版本 -help 输出为准。
风险提示：过紧的上传目标会损害网络服务与其他节点同步体验，误设计费额度也可能造成费用或频繁断连。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。