IPFS 性能优化：提升文件检索速度与 gateway 响应时间

“IPFS 太慢了”是开发者最常见的抱怨之一——也是最容易解决的问题之一。问题几乎总是出在访问方式上，而非协议本身。本指南介绍四种在生产环境中消除 IPFS 延迟的技术。

快速参考：按速度排列的 IPFS 访问方式#

如果你在生产环境中使用公共 gateway，切换到专用 gateway 后大部分延迟会立即消失。

公共 gateway 为何缓慢#

公共 gateway 对每个近期未见过的 CID 都会执行 DHT（Distributed Hash Table）查询。DHT 查询意味着需要向网络中数十个 peer 发起请求，以找到持有该内容的节点——冷请求的这次往返需要 2–15 秒。

即使命中缓存，公共 gateway 也要为数百万用户服务。你刚 pin 的文件缓存优先级较低，可能在两次请求之间被驱逐。

解决方案 1：专用 gateway#

专用 gateway 仅对你的账户私有。你 pin 的文件会立即在该 gateway 上缓存——无论请求是冷是热，都不会有 DHT 查询。

# 之前：公共 gateway，缓慢且不可靠
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# 之后：专用 gateway，快速且稳定
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

在你的 IPFS.NINJA 控制台 中创建 gateway，并将 slug 设置为与项目匹配的名称。Gateway slug 支持受限访问模式（需要 token）或开放模式（用于公共静态资源）。

解决方案 2：写入时 pin，而非读取时 pin#

在文件创建时立即 pin，这样 gateway 在用户请求之前就已持有它们。最快的请求是永远不会导致缓存未命中的请求。

# 一步完成上传和 pin
curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "data": "BASE64_ENCODED_CONTENT",
      "type": "image/png"
    },
    "description": "Product hero image v2"
  }'

# 响应——保存 CID，立即使用 url
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

如果你有来自其他节点或 pinning 服务的现有 CID，可以重新 pin 而无需重新上传：

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

查看如何上传文件到 IPFS 获取完整的上传 API 参考。

解决方案 3：在 gateway 前添加 CDN#

专用 gateway 从固定区域提供服务。如果你的用户遍布多个大洲，可以添加 CDN edge 层，从最近的接入点（PoP）提供服务。

由于 IPFS 采用内容寻址——给定的 CID 始终解析为完全相同的字节——你可以永久缓存：

Cache-Control: public, max-age=31536000, immutable

Cloudflare 示例（免费套餐可覆盖大多数静态资源工作负载）：

1. 将你的 gateway 子域名（my-app.gw.ipfs.ninja）添加为 Cloudflare 代理的 CNAME。
2. 创建 Page Rule：my-app.gw.ipfs.ninja/ipfs/* → Cache Everything，Edge Cache TTL: a month。
3. 第一个请求到达 gateway 并在最近的 edge PoP 缓存。所有后续请求由 Cloudflare 提供服务。

结果：全球 TTFB 从 50–200 ms 降至 10–50 ms。

解决方案 4：图片优化 API#

以原始分辨率提供 IPFS 图片会拖慢页面并损害 Core Web Vitals。使用图片优化端点在 edge 处调整大小并提供现代格式：

# 原始（通过 gateway 的完整分辨率）
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# 缩放至 800 px 宽，转换为 WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# 方形缩略图
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

在 React 中：

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

优化端点会缓存每个 (cid, width, format) 组合——使用相同参数的后续请求完全跳过源站。

检查清单#

• 从公共 gateway 切换到专用 gateway
• 在写入时（上传时）pin 内容，而非读取时
• 在 gateway 响应上设置 Cache-Control: immutable
• 在 gateway 前添加 CDN 以处理全球流量
• 通过优化端点提供图片，而非原始 gateway URL

关于 pinning 为何对可用性（而不仅仅是速度）至关重要的背景知识，请参见什么是 IPFS pinning。

准备开始 pin 内容？ 创建免费账户 — 50 个文件，1 GB 存储，2 GB 带宽/月。无需信用卡。

关于本文：本文由 AI 助手使用 IPFS.NINJA 的内容生成工作流起草，随后由 Nacho Coll 审阅和批准。所有代码示例均已在 IPFS.NINJA 线上 API 中验证。如果发现错误，请在 https://github.com/ipfs-ninja/feedback 提交 issue。了解更多关于我们如何在内容中使用 AI 以及IPFS.NINJA 背后的团队。