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 背後的團隊。