bind 与 port 的分工：比特币节点监听地址、端口与 =onion 后缀

比特币节点的监听参数看起来只有两个：-bind 指定在哪个地址哪个端口监听，-port 指定端口号。但涉及 Tor、多网卡、IPv4 与 IPv6 分离绑定这些真实部署场景时，两者的组合规则、onion 后缀和”洋葱端口自动加一”这些细节决定了节点可达性的成色。

一、两者的分工 -port=<port> 设定 P2P 监听端口的主号：默认 8333（testnet3/testnet4/signet/regtest 各有自己的默认值），它是节点对外公告时使用的”服务号”，路由器端口映射、防火墙规则都围绕它。-bind=<addr>[:<port>][=onion] 则回答”在哪块门牌上营业”：可以重复出现，把监听分别绑到不同网卡地址或协议族——典型用法是系统禁用 IPv6 时显式 -bind=0.0.0.0 只接 IPv4，或用 [::] 单独绑 IPv6。不写 -bind 时节点默认在所有接口上监听 -port 的端口。两个参数同写且都给了端口时，以 -bind 的为准；-port 还继续决定公告里的默认洋葱端口。

二、=onion 后缀不是装饰 在 -bind 的值尾部加 =onion，意思是”凡是打到这里进来的连接，一律标记为来自 Tor”。这个标记影响节点对本机地址表的认知：它据此把洋葱地址归入 Tor 组，影响向对端公告哪些地址、按网络类别做对端多样性统计。v31 的帮助文本里可以看到，各网络默认都带了 127.0.0.1:<端口+1>=onion 这一条——洋葱监听端口自动取 -port 值加一（默认场景即 8334），与明文 8333 分开。手工跑 Tor 隐藏服务的人要把这条对应关系写对：隐藏服务的目标端口应指向这个带 =onion 标记的绑定（文档示例中 8333 对外映射到 127.0.0.1:8334），否则进来的 Tor 连接会被当作普通本地连接，节点既不公告自己的洋葱地址，可达性统计也会失真。

三、announce 与 bind 是两回事 监听（bind）解决”听得见”，公告（announce）解决”别人知道往哪打”。节点默认会尝试从网卡地址、UPnP 映射等渠道猜出自己的公网地址并公告；-externalip 则是你亲口告诉节点该公告哪个地址，优先级最高。家庭宽带做端口映射后节点明明可达却不进公网对端池，常见原因恰恰是：监听正常，但猜出的地址是内网地址而被公告规则丢弃——这时补一条 -externalip=公网地址 往往就通了。反过来，-nobind 或 -connect 列表把节点变成纯出站，监听端口整条链路就都不存在了。

四、多实例与容器的端口账 同一台机器跑多个节点实例时，每个实例要独立的 -datadir、-port 和 RPC 端口，洋葱端口随 -port 自动错开的规则同样生效。容器环境里还要多算一层：节点监听容器内端口，宿主机映射改不了节点对外公告的端口号，所以公告地址与映射端口的对应要靠 -externalip 手工对齐。I2P 模式下 -port 完全不适用——I2P 的地址与端口语义自成体系，帮助文本也明确标注了这一点。

五、改动后的自查顺序 调整监听参数后按这个顺序验证：第一步看启动日志，绑定失败会打印具体地址与错误（端口被占用、权限不足都会在这里现形）；第二步 getnetworkinfo 看 localaddresses 里公告出去的地址对不对；第三步用外网工具从公网打一次节点端口；第四步几小时后回看 getpeerinfo 里是否开始出现 inbound 方向的连接——三者齐了，才算”对外开放”真正生效。只改配置不看日志，是很多”映射了却没人连进来”问题的最后一步漏检。

六、容易踩的语义陷阱 -bind 不给地址只给端口、地址给成 0.0.0.0:port、或者同一端口绑两次，都会踩到解析与冲突分支；IPv6 地址必须方括号包端口写，直接冒号分隔会被解析成协议前缀；-port 是 NETWORK_ONLY 类参数，写在运行时能改的清单之外的地方不会生效。还有一条隐性规则：显式设置 -externalip 会让自动发现（-discover）自动关闭，节点只公告你指定的地址——这是参数联动日志里会明示的一条，动手前先看日志总没错。

风险提示：本文所述参数语义以 Bitcoin Core v31.0 源码与官方 tor 文档核对为准，版本迭代可能改变默认行为。对外开放节点意味着暴露可被扫描的入站端口，请配合防火墙与系统加固评估，本文不构成任何投资建议。