比特币节点的手动黑名单：setban、bantime 与 banlist.dat 的边界

两种封禁，来源完全不同

比特币节点对坏对端有两套封禁机制。第一套是协议自动触发的：对端持续发送无效区块、违反消息节奏、行为异常，会被节点按惩罚规则自动断连并暂时拉黑，时长与条件由软件内置。第二套是本文的主角——运维手动封禁：setban 命令，把某个 IP 或子网加入黑名单，不需要对方做过任何错事。它的设计初衷是防御性的：比如同一网段的垃圾连接风暴干扰了你的节点，或者某个已知扫描源不停探测你的端口，手动封禁是最直接的止损动作。

命令与默认值的准确语义

setban 的参数形式是 setban "subnet" "command" ( bantime absolute )。第一个参数是 IP 或带掩码的子网，写法参照 getpeerinfo 里的地址，不带掩码时默认按单机处理。第二个参数取 add 或 remove，加和删。第三个可选参数是封禁秒数，不填或填 0 时用默认时长——源码里的默认值是 60 乘 60 乘 24，也就是 24 小时，并且可以用启动参数 -bantime 整体改写；把 absolute 标志置真时，这个数字的含义变成截止时间戳而非时长。查询当前名单用 listbanned，清空全部手动封禁用 clearbanned。所有手动封禁规则写进数据目录的 banlist.dat，重启不丢，但协议自动惩罚产生的临时封禁和这份名单是两套账。

需要澄清一个常见误解：封禁不影响网络对你的看法，只影响你的节点接受谁进入连接池。被手动封禁的地址仍可能从地址库再次被广播给你，封禁到期或清除后它随时可能回来。

滥用的代价

手动封禁是一把双向刀。对端在比特币网络里是匿名志愿者，你无法从一个 IP 推断它的意图；封禁面越大，你的连接图越窄，地址与区块传播在你这里越慢，被分区或 eclipse 攻击的暴露面反而上升。运维上几条防御性纪律：优先观察——getpeerinfo 与日志往往已能解释症状；优先封单机不封网段，除非确证整个网段是同一恶意源；给所有手动封禁设明确到期时间，别用超长永久封禁；建立一条例行审计，定期用 listbanned 翻一遍名单，清掉早已说不清理由的条目。封禁记录本身也是敏感信息，应视为节点运营日志管理。

本文只提供防御性运维建议，不构成任何投资建议；节点连接管理不当可能削弱传播与隐私，批量封禁前请先对照日志确认根因

封禁之外的第一道门

把 setban 放回节点防御的全局里看，它只是最末端的手动闸门。常规的第一道门是连接策略本身：默认出站连接限制、入站白名单（whitebind 与 whitelist 权限组）、以及把无关端口从公网收回的防火墙纪律。多数”连接风暴”的正确解法是关入站或收紧可达性，而不是逐个追封 IP——后者永远追不完。反方向的风险同样存在：把住宅拨号网段整体拉黑，可能把自己和主流基础设施关在门外；把某个云服务商网段全封，等于主动放弃一大片健康对端。防御动作应当可审计、可解释、可到期，这三条里”可到期”最容易被省略，却最能限制误伤的持续时间。封禁是止血钳，不是城墙。

把封禁写进值班手册

手动封禁最大的隐性成本不在技术，在交接：三个月后没人记得某条封禁的理由，名单就成了没人敢动的黑箱。工程上把每条封禁落成三行记录——触发时间、观察到的现象、预计到期日——存进与 banlist 分离的运维日志。这样 listbanned 的例行审计才有对照物，也才能在季度回顾里回答一个更重要的问题：这些封禁到底拦住过什么。没有记录的封禁，与没有封禁几乎等效，只是多了几分虚假的安全感。

本文不构成任何投资建议或收益承诺。加密资产价格波动剧烈，链上与钱包操作可能因操作失误、软件缺陷或服务变化导致损失，重要操作请先在测试网演练。