一、“代理”与”匿名”在节点里是两件事
比特币节点默认直接对公网发起连接。很多用户会把它挂到代理上：一种是为了绕过家庭网络的地址问题，一种是为了让流量经 Tor 之类的网络出去。Bitcoin Core 的参数集区分了全局代理与按网络指定的代理，例如 -proxy 与 -onion 各自管辖不同的地址族。代理解决的是”这台机器怎么出去”，它本身并不自动带来匿名——出去的连接在代理服务器上仍可能留下清晰的归并线索。
问题出在”能不能把不同连接区分开”。如果节点所有连接在代理侧都使用同一套登录身份，代理就有能力把”这条连接”和”那条连接”钉在一起：它知道两条连接来自同一个账户，进而可能推断它们属于同一个人。要切断这条推断链，需要让每条连接使用不同的身份。
二、proxyrandomize 到底改变了什么
参数说明只有一句话：“为每一个代理连接随机化凭证，这会启用 Tor 的流隔离”，源码默认值为真。它的机制是：每当节点要建立一条新连接，就在代理协议允许的范围内生成一套新凭证（在 Tor 上体现为不同的认证），使各条连接在代理服务器看来彼此独立。Tor 端把这件事称为流隔离——两条隔离开的流，在出口看来互不相关。
它改善的是两类关联面。其一，节点通过 Tor 与众多对端通信时，不希望代理侧能把这些连接归并成”同一个用户的活动画像”。其二，同一台节点同时跑多种用途的连接时，不同用途不会因共用身份而互相牵出对方。默认开启意味着普通用户什么都不做就已站在较难被归并的一边。
三、关掉它的后果与极少数合理理由
源码里有一条与这个开关相关的告警逻辑：如果关闭了随机化，节点通过 Tor 做私有广播时，不同连接可能共用同一条电路，隐私保护打折。换句话说，关它不会让节点连不上，只是把”连接互不相关”的证据主动交了出去，而这正是很多人挂代理想避免的事。
关它的合理场景几乎只剩排障：某些自建代理部署不接受随机凭证，或者复现特定网络问题时需要固定身份。遇到连接失败就顺手关随机化，是把隐私设定当成了故障变量——正确顺序是先确认代理支持的认证方式，再决定是否动这个开关。
四、与隐藏服务、I2P 的边界
隐私设定常常互相牵连。-listenonion 让节点自动创建并监听一个 Tor 隐藏服务，数据目录里缓存对应的私钥文件；i2p 网络则有自己的地址文件与 SAM 代理接口设定，文档分别写在仓库的 tor 与 i2p 说明里。proxyrandomize 管的是”出去”的方向，隐藏服务管的是”进来”的方向，各管一头。把它们当成同一个开关的延伸，会误判哪些流量真正被隔离。
另一个常见混淆是代理与监听：出站挂代理，不代表你的入站地址匿名；反过来，开隐藏服务收连，也不代表出站连接自动隔离。完整姿态需要两端分别配置、分别验证。
五、把设定写下来再验收
推荐三步。第一步，配置文件里把代理项、随机化、隐藏服务三项都显式写出，哪怕值就是默认——避免日后升级或换机时静默回退。第二步，用节点的运行时信息查看各网络族的可达与受限状态，确认代理确实接管了预期流量。第三步，回看连接记录与日志：若出站电路高度重合、或与代理身份呈固定关联，说明隔离假设不成立。
需要划清边界的是：proxyrandomize 不承诺强匿名。它消除的是”代理把多条连接归并到同一账户”这种低成本关联，挡不住全局观察者级别的流量分析，也不能替代隐藏服务的正确配置。把它理解为”用 Tor 时默认保持打开的一层基础卫生”，定位就准确了。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。