How to set up my own bootstrap nodes to enable discovery and connection between nodes with public IP and nodes on a local network?

My private IPFS setup:
All nodes mentioned below are using the dht package I forked from the official project. The current address for the dht package in my project is, and I only modified the value of the DefaultPrefix from “/ipfs” to “/signipfs”.

  1. Node A - I removed all the default bootstrap nodes and set Node A as the bootstrap node. It has a public IP. The code used for the bootstrap node is
  2. Nodes B and C - I removed all the default bootstrap nodes and added Node A as the bootstrap node. They have public IP.
  3. Nodes D and E - I removed all the default bootstrap nodes and added Node A as the bootstrap node. These nodes are on a local network.

Observation: By running nodes 2 and 3, I have confirmed that nodes 2 and 3 can discover and connect to each other. The two nodes in node 2 can discover and connect successfully, as well as the two nodes in node 3. However, when the nodes in node 2 try to connect to the nodes in node 3 or vice versa, the following error occurs: `QmThEh1WhwspRaKuwc6AwH2hJPbEyk6BiX4veMAGV8mQfw,err:failed to dial: failed to dial QmThEh1WhwspRaKuwc6AwH2hJPbEyk6BiX4veMAGV8mQfw: all dials failed

  • [/ip4/] dial backoff
  • [/ip4/] dial tcp4 connect: connection refused. However, if I don't modify the value of DefaultPrefix` and use the default bootstrap nodes, node 2 can discover and connect to the nodes in node 3, and vice versa.

Question 1: How can I set up my own bootstrap nodes so that the nodes in node 2 and node 3 can discover and connect to each other successfully?

It seems to be a connectivity problem rather than a problem with the protocol.ID / DefaultPrefix.

In your setup, nodes 3 should always be able to reach nodes 2. However, nodes 2 can have a hard time to establish a connection to nodes 3, because nodes 3 are on a local network and are probably behind a NAT. libp2p NAT hole punching doesn’t have a success rate of 100%, which may be a reason why the dials failed.

It is possible that dials succeed more in the “public IPFS DHT” because there are nodes running the libp2p relay protocol facilitating connections to nodes behind a NAT.

So your problem probably doesn’t come from the DHT implementation, but rather from the DHT network which doesn’t include Relay nodes.

Thank you for your quick response. What should I do to achieve the ‘public IPFS DHT’ effect? Is there any similar code available? I’ve noticed that there are many people with similar questions, but there are few solutions. Could you please provide the code or solution for the bootstrap nodes in ‘public IPFS DHT’?

I suggest that your nodes 2 should be libp2p Relays, in order to allow communication to nodes 3.

However, I am not sure on how to make sure that circuitv2 (relay protocol) is enabled. The best place to get this question answer is

Can I handle the relay processing within Node A, the bootstrap node, for a solution similar to ‘public IPFS DHT’?Instead of Node B or Node C.

Yes, you could. However, if you plan on running a large network, you probably don’t want to rely on a single relay. To share the load all nodes with a public address can act as relays (so A, B and C in your example).

Thank you for your response. Next, I will attempt to fix my bootstrap node code.

I’m sorry for taking up more of your time. Currently, I’m working on implementing relay functionality in my bootstrap node. However, in my bootstrap node program, I can only obtain their peer.ID. How can I proceed?

I am not familiar with configuring relays in libp2p, however you can ask for help at

I posted a thread on, but it has been in the ’ pending’ status for a while. Sorry to bother you again, is there any method to determine if a node is behind NAT?

The AutoNAT protocol helps your node discover whether it is behind a NAT.

hi ,I have the same problem. Do you have a final solution

sorry, there is currently no solution available.

Are you also trying to do the same thing as me?

yes,are your in china?

This problem indicates that tcp also supports nat over private networks

In this problem, some people also say that it is related to the number of boot nodes, and the number of three boot nodes is required

Yes, you can contact me through WeChat,ID is:361663126