不少比特币节点操作员都遇到过同一幕：给某个对端单独开一条点对点通道，用 -connect 写死、重启后连上又断开，翻遍 -help 也找不到一个”重连这个对端”的开关。比特币核心确实有一个专门建立指定连接的面板，但它不在常规使用路径里——addconnection，源码帮助文本里明确写着”仅用于测试”。这篇文章把这扇门拆开：它和 -connect、addnode 到底差在哪，四种连接类型各自派去干什么活，以及为什么生产节点不该拿它当补丁。
先分清楚三把钥匙：connect、addnode、addconnection
-connect 是一个启动参数：填了它，节点基本上放弃地址库自主选邻居，只维护你写死的那几个目标，断线后由后台不断重试。addnode 是一个运行时 RPC：给固定节点名单加上或移除一个主机，常用于 -connect 想临时增删但不想重启的场合。这两者面向的都是”我要长期和谁连”。
addconnection 完全不同：它一次性地”现在立刻对某个地址开一条指定类型的连接”，参数是一条 IP 加端口、一个连接类型、再加一个是否使用 v2 加密传输的布尔开关。它不进固定名单、不进地址库、没有自动重连的语义——链接断了就是断了，再来一次就得再敲一次命令。源码在实现上还有一道硬闸：非 regtest 链直接抛出”仅回归测试可用”的错误，普通主网节点连参数校验这关都过不去。
四种连接类型，对应节点内部的四个岗位
命令要求的 connection_type 有四个合法值，正好对应比特币节点连接分层里的四类专业角色：
outbound-full-relay：标准全中继出站连接，交易和区块双向都走，是你日常看到的”八个槽位”里的员工。block-relay-only：只收不发的区块专线。对端知道你的存在，但你从它那里只拿区块、不拿交易，也不替它中继。addr-fetch：地址-fetch 连接，进去的目的只有一个——向对端要一批新地址充实自己的地址库，拿到就满足。feeler：探针连接，连上确认对端地址还活着、值得留在地址库，随即主动断开，不做任何数据交换。
第三个参数 v2transport 控制这次握手尝试是否按 BIP324 的 v2 加密传输发起。对端不支持时的协商回退行为遵循握手协议本身，不因这条命令改变。
为什么它被锁在 regtest 后面
这类”外科手术式连接”的价值在测试：集成测试需要精确造出一台只有区块专线的节点、一台只靠 addr-fetch 活着的节点，或者验证 v2 传输在某种连接类型下的行为，靠启动参数和巧合排期都不可靠，需要一个 RPC 级别的操纵杆。放到主网就是另一回事：地址库、连接配额、驱逐逻辑是一整套相互牵制的账本，手工插一条不受任何账户记账的连接，等于绕开调度器手动改队列——这正是核心开发者宁可加链类型闸门也不提供它的原因。
主网排障时真正该用的动作
回到现实场景。如果是 -connect 的对端连不上，排查顺序应该是：对端是否还在监听（端口、防火墙、UPnP 映射）、你的 peers.dat 里这条地址是否被反复失败打进了”不良”待遇、以及是否触发了封禁（listbanned 看一眼，必要时 clearbanned）。如果只是想主动够一个不在名单上的节点一次，addnode 的 add 方向配合 getaddednodeinfo 才是设计内的路。想确认某地址存活，节点自己会派 feeler 去做，不需要人肉代理。
还要澄清一个高频误解：addconnection 不会”修好”一条断掉的连接。连接在比特币节点里是一次 TCP 会话加一套状态机，旧会话的序列号、过滤器、版本协商都已作废，任何”重连”本质都是新建会话。官方给生产的工具从头到尾都是”持续维护名单”这一种，而不是”手动缝合会话”。
一句话收束：addconnection 是测试实验室里的万能夹子，不是运维台面上的接线钳。主网环境里它连门都进不去；能进得去的环境里，用它才是正途。看到教程把这条命令写进生产部署清单，基本可以判定那份教程没跑过源码里的链类型检查。
风险提示：本文涉及的都是节点运行与排障知识，不涉及任何资产操作与收益安排；修改节点配置前请备份数据目录，所有命令行示例仅说明机制，不构成投资、配置或买卖建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。