# Troubleshoot common issues



Troubleshooting confusing scenarios while developing with the peer-to-peer building blocks.

Looking for Pear CLI or deployment issues instead? See [Pear's troubleshooting guide](/pear/how-to/troubleshooting). Looking for Bare runtime issues? See [Bare's troubleshooting guide](/bare/how-to/troubleshooting).

### Joining a Hyperswarm topic takes a long time [#joining-a-hyperswarm-topic-takes-a-long-time]

[Hyperswarm](/p2p/reference/building-blocks/hyperswarm) topic discovery can stall for several common reasons:

* Random NAT networks can take longer as another node may be needed to facilitate the connection. See [Peer-to-peer, demystified](/p2p/explanation/peer-to-peer-demystified#what-peers-learn-from-your-ip) for what's actually happening at the IP level.
* Not destroying the hyperswarm instance during application teardown so Hyperswarm can unannounce and clean up the [HyperDHT](/p2p/reference/building-blocks/hyperdht).
  It's recommended to clean up the hyperswarm instance with [`swarm.destroy()`](/p2p/reference/building-blocks/hyperswarm#await-swarmdestroy-force---) before exiting the application. This prevents conflicting records in the DHT for the application's peer which cause it take longer to join a topic. See [Connect to many peers by topic with Hyperswarm](/p2p/how-to/connect-to-peers/connect-to-many-peers-by-topic-with-hyperswarm) for the full one-instance-per-app pattern.
* A firewall is blocking the traffic.
  Please let Holepunch know if this is the case.

## See also [#see-also]

* [Hyperswarm reference](/p2p/reference/building-blocks/hyperswarm)—full API including `swarm.destroy()` for clean teardown.
* [HyperDHT reference](/p2p/reference/building-blocks/hyperdht)—the DHT layer whose records accumulate when Hyperswarm instances aren't destroyed.
* [Dependencies and network](/pear/explanation/dependencies-and-network)—what's actually happening when peer discovery stalls at the IP layer.