如果您在尝试通过 Cloudflare IPFS gateway 访问内容时收到 no link named "ipfs" under <<CID>> 错误消息，这意味着您创建的 gateway 没有 DNSLink 值。
由于 Cloudflare 目前仅支持受限网关（restricted gateways），而不支持 通用网关（universal gateways），因此除非您指定 DNSLink 值，否则这些请求将继续失败。
不妨检查 Cloudflare 的状态仪表板 ↗，以了解可能影响到我们的 gateway 的最新事件，但获取有关 IPFS 所面临问题的最新信息，最好的途径是 IPFS 讨论论坛 ↗。
IPFS 仍是一种正在开发中的协议，出于 Cloudflare 无法控制的原因，内容通常会不可用或加载缓慢。通常这是由以下原因之一导致的。
免费和匿名的 pinning 服务通常可以在紧要关头用来将内容放置到 IPFS 上，但它们通常会在内容上传后不久停止对其进行固定。 建议的替代方案是运行您自己的服务器或使用付费 pinning 服务，这将使您的内容更可靠地保持在线。
只有在至少有一个节点提供内容的情况下，内容才会留在 IPFS 网络上。如果所有提供给定内容的节点都离线，那么在其中一个节点重新上线之前，该内容将无法访问。
对于在家庭 Wi-Fi 环境中运行 IPFS 节点的人来说，等待时间极长或请求失败率很高很常见。这是因为 IPFS 网络中的其余节点很难通过他们的 NAT（Internet 路由器）与他们连接。要解决此问题，可以在路由器上设置端口转发（Port Forwarding），将目标端口为 4001 的外部连接定向至运行 IPFS 节点的 主机，或将节点移至托管服务器/虚拟机。
如果文件上传到 IPFS 节点后已经过了几分钟，其他 gateway 仍无法发现它们，这可能是节点在向网络其余部分宣布这些文件时遇到了问题。您可以通过运行以下命令确保拥有该内容的节点已将其固定：
ipfs pin -r <content id>您可以通过运行以下命令强制执行实际的宣布操作：
ipfs dht provide -rv <content id>第二条命令将无限期运行，且输出非常复杂，因此您可能希望在后台运行它并省略 -v 标志。
IPFS 会不时发布强制更新，这些更新会引入破坏性的协议更改。Cloudflare 会努力紧跟这些更新，但这也可能导致与较旧节点的连接丢失。