トラブルシューティング
CloudflareのIPFSゲートウェイを通じてコンテンツにアクセスしようとしたときに、no link named "ipfs" under <<CID>>というエラーメッセージが表示される場合、それはDNSLinkの値を指定せずにゲートウェイを作成したことを意味します。DNSLinkの値を指定するまで、これらのリクエストは失敗し続けます。
最近のインシデントがCloudflareのステータスダッシュボード ↗に影響を与えている可能性があるため、確認する価値がありますが、IPFSに関する問題の最新情報を得るには、IPFSディスカッションフォーラム ↗が最適な場所です。
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はこれらのアップデートの前に行動しようとしますが、その結果、古いノードとの接続を失うことがあります。