I am trying to host content on IPFS by adding it to my local IPFS node but most often I get a gateway timeout when trying to access them via ipfs.io. This behavior is the same whether it’s a tiny image or a large video. Sometimes it works and the content is delivered and sometimes it doesn’t and the behavior is very black and white: the content will either deliver immediately without delay or not at all. UPnP seems to be working to open a port on the firewall, and I can access IPFS via this port externally, but that doesn’t seem to matter, I still get gateway timeouts.
If I connect to my node externally on the port opened by UPnP it connects and the server responds:
telnet my.public.facing.node 51429
Connected to my.public.facing.node
Escape character is '^]'.
If I run
ipfs dht findprovs x on one of my files’ hashes it hangs forever
If I run
ipfs dht provide x on one of my files’ hashes it hangs forever
If I add the
-v flag I get a whole bunch of errors from a sea of nodes it attempts to talk to:
- failed to negotiate security protocol: connected to wrong peer
- connect: connection refused
- dial attempt failed: stream reset
- i/o timeout
I’ve removed these files and re-added them using the command line to recursively pin them to be sure:
ipfs pin add x
My aim is to host files permanently on this decentralized system but with this strange and erroneous behavior I am still very far from that goal.
Go IPFS Version: 0.4.20
Unfortunately, the DHT is in a really sorry state at the moment which is causing problems for content routing. The primary issue is that we have a ton of unreachable DHT nodes which is effectively acting like a massive sibyl attack on the network.
Isn’t there any interim work-around for this such as forcing a list of well-known peers?
I have a user-base that is being barred from my content right now until I figure-out how to resolve this.
Maybe setting a private network for your users will enable to have a smaller and healthier DHT? But AFAIK, you won’t ve able to fetch content outside your user base, I don’t know if it is compatible with your use case or not.
Update: I found a problem in my configuration, which I think is either the configuration out-of-the-box or not explicitly discussed in the quick-start documentation.
“ipfs id” showed that my private LAN address was part of the advertised “Addresses” and that may have caused problems. I resolved this by explicitly adding that address to the “NoAnnounce” section of “Addresses” in the IPFS server configuration. It no longer shows-up in the advertised list of addresses, just my public IP address is listed there now.
I don’t know if this is improving the accessibility of my pinned files, it’s still very slow and sluggish. But it would seem to me that a peer might give-up on my node after failing to connect via the erroneous private LAN IP address in lieu of proceeding to the next (public) IP address in the list of advertised IPs for my node.