一台刚启动的节点连上第一批对端之后，通常要几十分钟到几小时才追上链尖；但同一台机器把数据目录整包拷到另一台机器上，重启之后往往几十秒就继续出活。差别不在网络，而在两份被很多人忽略的本地文件：peers.dat 存“认识谁”，banlist.dat 存“别理谁”。它们的读写规则决定了节点冷启动与热启动的巨大差异，也决定了误删之后要付什么代价。
先看 peers.dat。比特币核心把地址管理器（addrman）里的已知对端表持久化在这个文件里，v31.0 的 net.cpp 写死了落盘节拍：每十五分钟做一次完整转储。addrman 内部把地址分成两个区，一个装从未成功连过的候选（new），一个装曾经建立过连接的（tried），节点挑下一批连接对象时的优先级、重试退避、防集群打散，全部基于这份状态。转储的作用是把“这台机器跑了半年攒下的对端画像”冻在磁盘上。重启时读回，节点直接从 tried 区挑成熟地址发起连接，跳过“先撒网、再碰运气”的阶段——这就是热启动快的根本原因。
再看冷启动为什么慢。v31.0 的连接管理逻辑里有一条清晰的判断：当活跃出站连接数低于一个很小的阈值（源码常量 SEED_OUTBOUND_CONNECTION_THRESHOLD，值为 2）时，节点才会去求助引导渠道，每次并行查询三个 DNS 种子（常量 DNSSEEDS_TO_QUERY_AT_ONCE 为 3）；另外还有一类带端口号的种子节点，规则是只要没连上任何一个就总是尝试。注释里写得明白：第一次运行、或者 peers.dat 被删掉时，地址表是空的，节点会一次性查询全部种子。也就是说，DNS 种子在成熟节点的生命周期里几乎不出场，它只服务于两种场景——全新安装，以及地址库被意外清空。理解了这一点，就不会有人再纠结“我要不要配 dnsseed”，对运行过一天的节点它基本是休眠代码。
顺带澄清一个流传的说法：种子给的不是“官方节点列表”，而是随机抽样。每个种子域名后面是一组运维者自己维护的节点池，一次解析返回的是一小批随机挑选的地址，且按服务位过滤。拿到的地址进 new 区，连上并存活一段时间后才升入 tried。这个两区结构自带自愈：网络里节点更替、机房下线、某些地址变成僵尸，都会在几轮连接尝试后自然沉底或被淘汰。peers.dat 因此不需要人工维护，它是结果不是配置。
banlist.dat 是另一本账。手动或自动封禁的地址写在这个文件里（v31.0 的 banman 代码在文件缺失或损坏时会记一条“Recreating the banlist database”然后重建空表）。它的读回时机是启动时，写入时机是封禁发生时。这个文件对隐私有实际意义：封禁记录意味着“这些 IP 曾经被你判定有问题”，它不出网，但会留在磁盘上；反过来说，删掉它也删掉了防护记忆——节点会以空名单重启，此前因发送坏数据被封的地址可以再试一次。
两份文件合起来解释了三个常见现象。第一，把数据目录整体迁移到新机器时，如果连同 peers.dat 一起搬，新机器第一次联网就能连上大量旧对端，看起来像“它认得路”；漏搬这个文件则表现为连接建立缓慢、日志里出现大量种子查询。第二，长期使用同一个数据目录的节点比频繁重置的节点更容易维持在健康的连接图谱上，因为 tried 区的画像无法在一夜之间重建——这也是“不要总删 peers.dat 来解决连接问题”的原因，它在多数情况下是把诊断信息删了。第三，如果节点反复出现连上又断开同一批对端，检查 peers.dat 的写盘是否失败（磁盘满、权限变化都会让转储静默不成功，节点运行不受影响，但记忆停止更新）比手动塞地址更对症。
还有一条运维边界值得记录：peers.dat 不是设计给人编辑的。它是序列化数据库，版本间格式会变，手改的后果通常被“读不回来就重建空表”的容错路径吸收——节点照样启动，但你失去了全部画像。同理，把别人机器的 peers.dat 复制过来也不构成隐私改进：地址画像的价值在于“我与它们交互过的历史”，抄来的历史不产生任何信任，反而可能与自己的网络位置不匹配，让初始连接分布变得古怪。
最后把机制放回大局：比特币网络没有中心目录服务，每个节点用自己的连接史构建对端集合，peers.dat 就是这份个人记忆的载体。十五分钟一冻、重启读回、空表才查种子——这三条朴素的规则加在一起，让网络既能在灾难后靠种子重新长出来，又让绝大多数节点永远不需要走冷启动那条慢路。记住这两份文件的存在与分工，节点连接类问题的排查就从玄学变成了查账。
风险提示：本文为节点机制说明，不构成任何投资建议；文中常量与行为以比特币核心 v31.0 源码为准，后续版本可能调整。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。