提到比特币节点的隐藏网络接入，多数教程只讲 Tor。但 Bitcoin Core 从 22.0 版起就内置了对 I2P 网络的支持，官方版本说明的原话是”节点现在可以连接到 I2P 服务并与这类服务互联”，专门的说明文档也随源码发布。它的接入方式与 Tor 那条路线完全不同：不再由节点自己起一个监听端口，而是把出入站都交给本机的 I2P 守护进程代办。这个代办接口就叫 SAM，对应的启动参数是 -i2psam。本文基于 31.0 版源码，拆解这个参数的帮助文本、默认值与三条常被忽略的行为边界。
SAM 代理的双重角色
-i2psam=<ip:port> 的帮助文本写得很紧凑：“用于接入 I2P 对等节点与接受 I2P 连接的 SAM 代理”。一句话包含两个方向：出，节点通过这个代理去联系 I2P 网络里的其他节点；入，外面的 I2P 节点也经这个代理连进来。这与 Tor 的隐蔽服务路线不同——Tor 路线上节点会借助控制端口让 Tor 起一个 .onion 服务监听，而 I2P 路线上帮助文本明确写道：监听 I2P 入站连接是通过 SAM 代理完成的，不是通过绑定本地地址和端口。换句话说，-i2psam 后面填的永远是 I2P 守护进程的控制地址，一般就是本机回环地址，而不是节点对外的服务地址。地址缺省端口时按 7656 解析，这是 I2P SAM 协议的常用端口。
入站开关与它的联动
接了 SAM 不等于一定要接客。-i2pacceptincoming 控制是否接受 I2P 入站连接，默认值为开；帮助文本同时注明，没设 -i2psam 时这个参数不起作用。一条容易漏看的源码行为是联动降级：当用户以 -listen=0 启动节点（全局不接收入站）时，初始化会把 -i2pacceptincoming 软性改写为关，并在日志里记一行参数交互。这意味着 -listen=0 的防火墙型部署里，I2P 入站是被自动带下的，不需要也不应该再手工配置第二个开关。配置完成后想确认效果，可以查 getnetworkinfo 输出里的网络可达性列表：I2P 一行会给出本节点对该网络的可达状态，出站通不通、能不能接客，都以这个字段为准，而不是配置文件写了什么。
值格式上比 onion 参数苛刻
Core 对一组网络类参数的取值做统一校验，校验表里 -i2psam 被标记为”不支持 UNIX 套接字、不允许等号后缀”。对照着看：-onion 允许填 UNIX 套接字路径，-proxy 允许等号后缀写法，-i2psam 都不可，只能写地址加端口的形态；端口部分写非数字或写 0，启动直接报无效端口错误。这类差异不影响日常使用，但在把各网络参数抄进同一份配置模板时是常见的报错来源。这些约束的共性很简单：这个参数只保留”一个地址加端口”这一条窄路，不追求其他网络参数的书写灵活性，记牢写法即可，不必类推。
参数之外的世界
-i2psam 只负责”把节点接到代理”这一件事。节点最终能不能被外界以 I2P 地址访问、可达性探测结果如何，属于地址广告与网络可达性管理的范畴，可以在 getnetworkinfo 的本地地址与可达性字段里观察结果；想把主动连接限制在单一覆盖网络里，则要配合 -onlynet 一类的网络隔离参数使用，-i2psam 与它是一对自然搭档：前者负责通路，后者负责纪律。运维上还有一条朴素建议：SAM 控制地址通常只绑回环，它不是给局域网里其他机器用的公共接口——代理一旦被越权使用，节点的网络身份就不完全属于自己了。至于选 I2P 还是 Tor，两者在威胁模型与性能特征上各有拥趸，本文不做裁判，只确认参数层面它们是并列可选的两条路。
风险提示：本文参数默认值与行为描述基于 Bitcoin Core 31.0 源码，I2P 生态与参数语义可能随版本演进，以你实际运行版本与官方文档为准；覆盖网络配置错误可能导致节点长期孤立，变更前请在测试网验证；本文不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。