504 Timeout on Public Gateway

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?

1 Like

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 AppendAnnounce
Example:

[
  "/ip4/1.2.3.4/tcp/12345",
  "/ip4/1.2.3.4/udp/12345/quic"
]

(I’m assuming that your public IP is 1.2.3.4 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/.

Hi,
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

Try this:
https://ipfs-check.on.fleek.co

1 Like

same issue here, did you ever manage to resolve it? thanks a lot

No luck!
@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/95.70.154.211/tcp/4001
	/ip4/95.70.154.211/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.

1 Like

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.

Hello everyone,

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:

:heavy_check_mark: Successfully connected to multiaddr
:heavy_check_mark: Found multiaddrs advertised in the DHT:
/ip4/127.0.0.1/tcp/4001
/ip4/127.0.0.1/udp/4001/quic
/ip4/179.182.212.22/udp/4001/quic
/ip4/192.168.15.11/tcp/4001
/ip4/192.168.15.11/udp/4001/quic
/ip6/2804:1b1:2209:cbf3:bc69:ed45:3e30:2876/tcp/4001
/ip6/2804:1b1:2209:cbf3:bc69:ed45:3e30:2876/udp/4001/quic
/ip6/::1/tcp/4001
/ip6/::1/udp/4001/quic
:heavy_check_mark: Found multihash adverised in the dht
:heavy_check_mark: 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?

best regards,

  • Breno

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/179.182.212.22/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.

1 Like

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

2 Likes