From @jbenet on Sat Jan 23 2016 15:16:59 GMT+0000 (UTC)
It’s likely a nat problem. we’re aware of it.
On Sat, Jan 23, 2016 at 6:34 AM Enrico Fasoli notifications@github.com
wrote:
The files should be available through their gateway! Or any other gateway.
Sometimes it just takes a few minutes for them to propagate the first time.—
Reply to this email directly or view it on GitHub
https://github.com/ipfs/support/issues/15#issuecomment-174190335.
From @adamc199 on Sat Jan 23 2016 15:36:27 GMT+0000 (UTC)
hmmm. Yet was unable to find a bug report for NAT in the tracker.
From @RichardLitt on Thu Mar 10 2016 18:32:35 GMT+0000 (UTC)
@adamc199 We’re actively working on fixing this right now. Do you still have this problem?
From @adamc199 on Thu Mar 10 2016 23:25:12 GMT+0000 (UTC)
This appears to have been fixed on the 4.x releases.
AC
——————————————
K5ACC
Governments are reading your email.
Slow them down with encryption.
My public key: pubkey.curry.com
——————————————
On Mar 10, 2016, at 12:32 PM, Richard Littauer notifications@github.com wrote:
@adamc199 We’re actively working on fixing this right now. Do you still have this problem?
—
Reply to this email directly or view it on GitHub.
From @RichardLitt on Thu Mar 10 2016 23:30:35 GMT+0000 (UTC)
Woo! 
From @RichardLitt on Thu Mar 10 2016 23:30:55 GMT+0000 (UTC)
Reopen as needed. Thanks!
From @cerberusaeon on Sat Jun 11 2016 17:18:03 GMT+0000 (UTC)
I just added a file to ipfs. It should be available at the following URI but never appears to resolve. My ipfs version is 0.4.2 (same as the gateway). I was following the demo, am I missing something?
https://gateway.ipfs.io/ipfs/QmU6ub9mcBtigipmzTZvaZbjmCMgh3aPYHPqi6JzjAQqz4
From @ShariqT on Thu Jul 28 2016 18:39:26 GMT+0000 (UTC)
I am having this problem as well. Using version 0.4.2
From @lgierth on Thu Jul 28 2016 19:30:12 GMT+0000 (UTC)
Could you try it with the most recent v0.4.3-rc1 from https://dist.ipfs.io?
From @norzak on Mon Nov 21 2016 14:29:47 GMT+0000 (UTC)
I am using 0.4.4 and have this problem on macosx
From @VictorBjelkholm on Tue Nov 22 2016 11:55:20 GMT+0000 (UTC)
@norzak are you connected to other peers? You should be able to see that if you run ipfs swarm peers. Also, could be that the gateways can’t fetch the content for the hash you’re trying to load. Do you happen to know where the hash come from and if someone is seeding it?
From @norzak on Thu Nov 24 2016 17:11:54 GMT+0000 (UTC)
It worked today. I do not know why because I didnt do anything different just run the “ipfs daemon”. It must be a glitch at gateway.ipfs.io backend.
I am attempting to use js-ipfs in the browser following the example here - https://github.com/doctuary/js-ipfs/tree/master/examples/browser-script-tag
It appeared that I was able to successfully add a file using the node.files.add() method, and I received the following hash as part of the response: QmYWxNNP3tUp5FSLZgAvQLzqcL3ER19aECAr1EqHoPudLp
However, when I try to retrieve the file using .files.cat(hash), nothing happens. No error, nothing. I have also tried to access the file from the command line and from the public gateway - http://gateway.ipfs.io/ipfs/QmYWxNNP3tUp5FSLZgAvQLzqcL3ER19aECAr1EqHoPudLp - no joy. It just sits and spins. Any thoughts?
I learned recently that gateway.ipfs.io is deprecated. You should use https://ipfs.io/ipfs/HASH instead.
However, that doesn’t work either:
❯ curl -o TEST https://ipfs.io/ipfs/QmYWxNNP3tUp5FSLZgAvQLzqcL3ER19aECAr1EqHoPudLp
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:05:47 --:--:-- 0
Usually, you’ll get the total filesize pretty quickly, even if the gateway doesn’t have the (complete) file yet. So it seems that you’ve added the file to the IPFS using your in-browser node, but it isn’t seeding it to the network. (No daemon?)
Thanks, Jay. How could I tell if there was a daemon running? Assuming there isn’t, how would I fire one up in the browser so that the file gets seeded?
I had a similar problem with my IPFS redirect userscript, and @lidel had a great solution, namely to check whether a png in the WebUI can be accessed or not, meaning IPFS daemon is enabled or not. See here:
How to enable the daemon in the browser, I don’t yet know. Maybe someone can chime in.
There is however one node test (start?) function in your index.html, isn’t there?
So maybe the problem is of completely different nature. (?)
Yes, there is a node, and I do get the message that the node is online when the site loads, so I guess I’m a bit stymied.
I’m seeing the same issue from time to time. I’m running ipfs version 0.4.17.
Some days first request to the file may take some time but eventually it will come in. Subsequent requests will come in almost immediately. However, today it’s spinning forever on my desktop chrome browser. Here is one of the ipfs link https://cloudflare-ipfs.com/ipns/QmRknUZ69ifupZion2DCMrerEwUZgApqa5dsqEzuF1GYpQ/ or using ipfs gateway directly https://gateway.ipfs.io/ipfs/QmSrDGabFK37MxeU63QW2LYGmhzZFEuAMGjvkTo7YYkN4g/
Hitting the same link on my Pixel 2 phone it works fine though.
In addition to using the local webui (http://localhost:5001/webui) the public one on webui.ipfs.io was helpful to troubleshoot (i.e. configuring api gateway and configuring access control as per https://github.com/ipfs-shipyard/ipfs-webui#configure-ipfs-api-cors-headers).