I’m setting up ipfs for the first time in a new network, I turned on Port Forwarding on my WiFi router for 4001 and IPv6. I’m able to retrieve files from the local gateway, but not public gateways. How do I troubleshoot this?
Port forwarding isn’t enough.
Port forwarding makes your peer physically reachable. But you also need to tell other peers that your port are open else they wouldn’t know to try it.
You need to add your public IPs in the
[ "/ip4/220.127.116.11/tcp/12345", "/ip4/18.104.22.168/udp/12345/quic" ]
(I’m assuming that your public IP is
22.214.171.124 and your outside port is
12345 change it with yours).
Once you done that and restarted your node, you can try https://ipfs-check.on.fleek.co/.
I ve just tried your suggestion. But it didn’t work. I’m still getting 504 Gateway message from browser.
I replaced my public ip and the port as 4001
same issue here, did you ever manage to resolve it? thanks a lot
@ylempereur the output from the page is as follows;
❌ Could not connect to multiaddr: context deadline exceeded ✔ Found multiaddrs advertised in the DHT: /ip4/100.83.41.16/tcp/11203 /ip4/100.83.41.16/udp/11203/quic /ip4/127.0.0.1/tcp/4001 /ip4/127.0.0.1/udp/4001/quic /ip4/126.96.36.199/tcp/4001 /ip4/188.8.131.52/udp/4001/quic /ip6/::1/tcp/4001 /ip6/::1/udp/4001/quic ❌ Could not find the multihash in the dht ❌ There was an error downloading the CID from the peer: could not connect to peer
That means your node isn’t reachable from the public internet. Your port forwarding isn’t set up properly. Once that is fixed, the top red X will go away. Then we’ll deal with the rest, if it’s still a problem.
Any update on the issue? Facing weird problem here.
I am getting SUCCESS in ipfs check page for ipv6 address but not for ipv4.
I have rechecked, port is open on VPS for both ipv4 and ipv6
If you try to connect to the advertised public ip4 address from a remote location using telnet/netcat/nc, it should connect and receive the string “/multistream/1.0.0” back. If that’s not the case, your firewall or port forwarding isn’t set up properly yet.
Thanks for this discussion. It has helped a lot in setting up and debugging this issue which seems to be common. I’m having the same problem, but the tests point out that I’m totally fine in my setup:
Successfully connected to multiaddr
Found multiaddrs advertised in the DHT:
Found multihash adverised in the dht
The peer responded that it has the CID
Still, if you try to connect to my shared folder on this URL (generated by IPFS desktop): https://ipfs.io/ipfs/QmcA31qYhjtvYVNaeftHTsU5pgLd5GC99AKkW3PDiZ1b3c
You guys should get a gateway timeout. Given the steps above to debug using the https://ipfs-check.on.fleek.co/ site were not enough, is there any other idea to solve this issue?
There are still some lingering connectivity problems:
> ipfs dht findprovs QmcA31qYhjtvYVNaeftHTsU5pgLd5GC99AKkW3PDiZ1b3c 12D3KooWKUWvueJoh6EcPAtnkwBf3caTUvFqccDKUHPh5EuopmkF > ipfs id 12D3KooWKUWvueJoh6EcPAtnkwBf3caTUvFqccDKUHPh5EuopmkF Error: failed to dial 12D3KooWKUWvueJoh6EcPAtnkwBf3caTUvFqccDKUHPh5EuopmkF: * [/ip6/2804:1b1:2209:cbf3:bc69:ed45:3e30:2876/tcp/4001] dial tcp6 [::]:4001->[2804:1b1:2209:cbf3:bc69:ed45:3e30:2876]:4001: i/o timeout * [/ip4/184.108.40.206/udp/4001/quic] timeout: no recent network activity * [/ip6/2804:1b1:2209:cbf3:bc69:ed45:3e30:2876/udp/4001/quic] timeout: no recent network activity >
I just checked the link. It’s working. I can see folder contents.
That might not mean much, it’s possible that the gateway has it in its cache, or that others (like me) have looked at the folder, so they have it in their cache. However, that will fade away, and only your node will remain.
I tried again, and the two nodes listed for that block aren’t responding. If one of the two is your node, it’s not reachable at the moment. If not, then your “reprovide” isn’t working properly. Either way, you have a problem.
We just published an elaborate blog post that goes into many of the reasons of why this happens and the tricks of the trade for resolving these: A Practical Explainer for IPFS Gateways - Part 2 | IPFS Blog & News