Cloudflare の IPFS ゲートウェイ経由でコンテンツにアクセスしようとして no link named "ipfs" under <<CID>> というエラーメッセージが出る場合、DNSLink の値なしでゲートウェイを作成しています。
Cloudflare は現在 restricted gateway のみをサポートしており、universal gateway はサポートしていません。そのため、DNSLink の値を指定するまで、これらのリクエストは失敗し続けます。
ゲートウェイに影響した可能性がある最近のインシデントは、Cloudflare の ステータスダッシュボード ↗ で確認する価値があります。ただし、IPFS の問題について最新情報を得る最善の場所は IPFS Discussion Forum ↗ です。
IPFS は発展中のプロトコルであり、コンテンツが利用できない、または読み込みが遅いことは、Cloudflare の管理外の理由でよく起きます。通常、原因は次のいずれかです。
無料および匿名のピン留めサービスは、急場でコンテンツを IPFS に載せるのに使えることがあります。ただし、アップロード直後にピン留めを止めることがよくあります。推奨される代替は、自分でサーバーを運用するか、ピン留めサービスを使うことです。こちらの方が、コンテンツを安定してオンラインに保てます。
コンテンツは、配信しているノードが少なくとも 1 台あるあいだだけ IPFS ネットワーク上に残ります。あるコンテンツを配信していたノードがすべてオフラインになると、いずれかが復帰するまでそのコンテンツにはアクセスできません。
自宅の Wi-Fi で IPFS ノードを動かすと、待ち時間が非常に長くなる、またはリクエスト失敗率が高くなることがよくあります。IPFS ネットワーク上の他のノードが、NAT（インターネットルーター）越しに接続しにくいためです。解決するには、ルーターでポートフォワーディングを設定し、ポート 4001 への外部接続を IPFS ノードのあるホストへ向けるか、ノードをホスト型サーバー / VM に移します。
IPFS ノードにファイルをアップロードして数分経っても、他のゲートウェイから発見できない場合、ノードがネットワーク全体への告知に失敗している可能性があります。コンテンツを持つノードがピン留め済みかを確認するには、次を実行します。
ipfs pin -r <content id>実際の告知を強制するには、次を実行します。
ipfs dht provide -rv <content id>2 つ目のコマンドは無期限に動き、出力もかなり複雑です。バックグラウンドで実行し、-v フラグは外すとよい場合があります。
IPFS は、破壊的なプロトコル変更を伴う必須アップデートをときどき出します。Cloudflare はこれらの更新に先行するよう努めており、その結果、古いノードとの接続が切れることがあります。