我把视频的链接直接放到浏览器也无法播放

Air

npub1nr0runywca4fl3dujvy3s76az06hldhcsk9z5dfcnhuhtpynzhjs28gqtu

hex

9306d1f085c5c00fd3095a845ec90f69ed54561f5ab2a732e7424497ae81ea1a

nevent

nevent1qqsfxpk37zzutsq06vy44pz7ey8knm252c044v48xtn5y3yh46q75xsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsf3h37fj8vw65lck7fxzgc0dw38atlkmugtz32x5ufm7t4sjf3tegy7z8xh

Kind-1 (TextNote)

2026-09-05T01:37:01Z

我把视频的链接直接放到浏览器也无法播放

你这两个链接打不开,主要有两层原因:IPFS 公共网关的迁移/限流策略 + 浏览器对 IPFS 视频流的播放条件,而 Amethyst 能播是因为它用的是自己的播放器栈和更“宽容”的网络层。[1][2]

1) dweb.link 已经转向 inbrowser.link(服务工网关)

从 2026 年开始,ipfs.iodweb.link 的公共网关都在逐步把直接访问重定向到 inbrowser.link 的 Service Worker 网关,不再像以前那样由中心化服务器替你拉数据。[1][2] 这意味着:

  • 浏览器地址栏直接打开 dweb.link/ipfs/... 会被重定向到 inbrowser.link,走的是浏览器内的 service worker 逻辑,而不是传统 HTTP 直连。[1]
  • 对某些内容类型(尤其是大文件、视频、后端 hotlink 流量),公共网关已经开启更严格的限流/拦截,甚至返回 451/403/504 等错误。[2][3]

你给的 CID 是 QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1,属于老式 CIDv0,有些网关对这类内容的路由和缓存策略跟 CIDv1 不一样,更容易碰到“暂时找不到提供者/超时”的情况。[4][5]

2) 浏览器播放 IPFS 视频还有额外门槛

即使网关返回了 MP4,浏览器要顺利播放,还需要:

  • 正确的 Content-Type / 支持 Range 请求:视频播放依赖 HTTP Range(206 Partial Content),如果网关或中间代理没正确支持,浏览器会认为“不可seek/不可流式播放”。[6]
  • CORS / Referrer 策略:有案例显示,在 <head><meta name="referrer" content="no-referrer"> 后,从某些站点嵌入的 IPFS 视频才能正常播放,否则网关会因为 referrer 拒绝流。[3]
  • MIME 类型:如果网关返回的 Content-Type 不是 video/mp4 而是 application/octet-stream 或其他,有些浏览器/播放器组件会直接拒绝当成视频播。

很多公共网关对“直接 hotlink 视频”的流量会做更严格检查,而 Amethyst 这种原生客户端通常不会受浏览器这些策略限制得那么死。

3) 为什么 Amethyst 能播

结合之前查到的信息,Amethyst 的视频能力来自:

  • 原生播放器(ExoPlayer/Media3)+ OkHttp 网络层:它不依赖浏览器的 <video> 标签和浏览器的 CORS/referrer 策略,而是直接用 OkHttp 去拉流,再喂给 ExoPlayer。
  • 多源 fallback:NIP‑71 事件里通常会有多个 url / fallback,客户端可以依次尝试不同网关或镜像,直到有一个能通。
  • 可选 Tor/代理:它支持把播放器流量走 Tor 或其他代理,绕开某些网关对 IP/地区的限制。

所以同样是 dweb.link/ipfs/... 这个 URL:

  • 浏览器:受网关重定向、限流、CORS/referrer、MIME、Range 等一堆策略影响,很容易“看起来有链接但播不了”。
  • Amethyst:用原生 HTTP 客户端 + 播放器,自己处理重试、切换源、忽略部分浏览器策略,更容易把流拉出来并解码播放。

4) 你可以怎么验证/绕过

如果你想让浏览器也能播,可以试几种方式:

  1. 换网关
    把 URL 改成其他公共网关,例如:

    • https://ipfs.io/ipfs/QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1?filename=video_converted.mp4
    • https://<cid>.ipfs.dweb.link/(CIDv1 更适合子域名网关;CIDv0 有时需要先用工具转成 CIDv1 再试)[7]
  2. 用 inbrowser.link 的子域名形式
    尝试:

    • https://bafy .ipfs.inbrowser.link/(需要先把 Qm... 转成 CIDv1 的 bafy... 形式)
      inbrowser.link 对浏览器内验证和 Range 请求支持更好,但 CIDv0 可能要先转换。[1][6]
  3. 检查响应头
    curl -I "你的链接" 看:

    • Content-Type 是不是 video/mp4
    • 是否支持 Accept-Ranges: bytes
    • 状态码是不是 200/206 而不是 451/403/504[3][4]
  4. 本地节点 / 扩展
    如果你跑本地 IPFS 节点(Kubo/Helia)或用 IPFS Companion 扩展,可以让浏览器通过本地节点拉流,绕过公共网关的限流和重定向。[8][9]

如果你愿意,可以把你在浏览器里访问这个链接时拿到的完整 HTTP 响应头(或用 curl -I 的结果)贴出来,我可以帮你判断是网关限流、MIME 问题、还是 Range/CORS 导致的。

nostr:nevent1qqsqhvf3f0gag0ez6d0g8que085hefswnazhwys8s3zzamz0j8k36jsprdmhxue69uhkummnw3ezuumpw35x7ctjv3jhytnrdakj7q3qnr0runywca4fl3dujvy3s76az06hldhcsk9z5dfcnhuhtpynzhjsxpqqqqqqzy43kc6

原始 JSON

{
  "kind": 1,
  "id": "9306d1f085c5c00fd3095a845ec90f69ed54561f5ab2a732e7424497ae81ea1a",
  "pubkey": "98de3e4c8ec76a9fc5bc9309187b5d13f57fb6f8858a2a35389df975849315e5",
  "created_at": 1788572221,
  "tags": [
    [
      "alt",
      "A short note: 我把视频的链接直接放到浏览器也无法播放\n\n你这两个链接打不开,主要有两层原因:**IPFS 公共网关..."
    ],
    [
      "p",
      "98de3e4c8ec76a9fc5bc9309187b5d13f57fb6f8858a2a35389df975849315e5",
      "wss://nostr.mom/"
    ],
    [
      "r",
      "https://ipfs.inbrowser.link/`(需要先把"
    ],
    [
      "r",
      "https://`ipfs.io/"
    ],
    [
      "r",
      "https://`inbrowser.link/"
    ],
    [
      "r",
      "https://\u003ccid\u003e.ipfs.dweb.link/`(CIDv1"
    ],
    [
      "r",
      "https://dweb.link/"
    ],
    [
      "r",
      "https://ipfs.io/ipfs/QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1?filename=video_converted.mp4`"
    ],
    [
      "r",
      "https://`dweb.link/"
    ],
    [
      "r",
      "https://`dweb.link/ipfs/...`"
    ],
    [
      "r",
      "https://inbrowser.link/"
    ],
    [
      "q",
      "0bb1314bd1d43f22d35e83839979e97ca60e9f4577120784442eec4f91ed1d4a",
      "wss://nostr.sathoarder.com/",
      "98de3e4c8ec76a9fc5bc9309187b5d13f57fb6f8858a2a35389df975849315e5"
    ],
    [
      "client",
      "Amethyst"
    ]
  ],
  "content": "我把视频的链接直接放到浏览器也无法播放\n\n你这两个链接打不开,主要有两层原因:**IPFS 公共网关的迁移/限流策略** + **浏览器对 IPFS 视频流的播放条件**,而 Amethyst 能播是因为它用的是自己的播放器栈和更“宽容”的网络层。[1][2]\n\n## 1) dweb.link 已经转向 inbrowser.link(服务工网关)\n\n从 2026 年开始,`ipfs.io` 和 `dweb.link` 的公共网关都在逐步把**直接访问**重定向到 `inbrowser.link` 的 Service Worker 网关,不再像以前那样由中心化服务器替你拉数据。[1][2]\n这意味着:\n\n- 浏览器地址栏直接打开 `dweb.link/ipfs/...` 会被重定向到 `inbrowser.link`,走的是浏览器内的 service worker 逻辑,而不是传统 HTTP 直连。[1]\n- 对某些内容类型(尤其是大文件、视频、后端 hotlink 流量),公共网关已经开启**更严格的限流/拦截**,甚至返回 451/403/504 等错误。[2][3]\n\n你给的 CID 是 `QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1`,属于老式 CIDv0,有些网关对这类内容的路由和缓存策略跟 CIDv1 不一样,更容易碰到“暂时找不到提供者/超时”的情况。[4][5]\n\n## 2) 浏览器播放 IPFS 视频还有额外门槛\n\n即使网关返回了 MP4,浏览器要顺利播放,还需要:\n\n- **正确的 Content-Type / 支持 Range 请求**:视频播放依赖 HTTP Range(`206 Partial Content`),如果网关或中间代理没正确支持,浏览器会认为“不可seek/不可流式播放”。[6]\n- **CORS / Referrer 策略**:有案例显示,在 `\u003chead\u003e` 加 `\u003cmeta name=\"referrer\" content=\"no-referrer\"\u003e` 后,从某些站点嵌入的 IPFS 视频才能正常播放,否则网关会因为 referrer 拒绝流。[3]\n- **MIME 类型**:如果网关返回的 `Content-Type` 不是 `video/mp4` 而是 `application/octet-stream` 或其他,有些浏览器/播放器组件会直接拒绝当成视频播。  \n\n很多公共网关对“直接 hotlink 视频”的流量会做更严格检查,而 Amethyst 这种原生客户端通常不会受浏览器这些策略限制得那么死。\n\n## 3) 为什么 Amethyst 能播\n\n结合之前查到的信息,Amethyst 的视频能力来自:\n\n- **原生播放器(ExoPlayer/Media3)+ OkHttp 网络层**:它不依赖浏览器的 `\u003cvideo\u003e` 标签和浏览器的 CORS/referrer 策略,而是直接用 OkHttp 去拉流,再喂给 ExoPlayer。  \n- **多源 fallback**:NIP‑71 事件里通常会有多个 `url` / `fallback`,客户端可以依次尝试不同网关或镜像,直到有一个能通。  \n- **可选 Tor/代理**:它支持把播放器流量走 Tor 或其他代理,绕开某些网关对 IP/地区的限制。  \n\n所以同样是 `dweb.link/ipfs/...` 这个 URL:\n\n- 浏览器:受网关重定向、限流、CORS/referrer、MIME、Range 等一堆策略影响,很容易“看起来有链接但播不了”。  \n- Amethyst:用原生 HTTP 客户端 + 播放器,自己处理重试、切换源、忽略部分浏览器策略,更容易把流拉出来并解码播放。\n\n## 4) 你可以怎么验证/绕过\n\n如果你想让浏览器也能播,可以试几种方式:\n\n1. **换网关**  \n   把 URL 改成其他公共网关,例如:  \n   - `https://ipfs.io/ipfs/QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1?filename=video_converted.mp4`  \n   - `https://\u003ccid\u003e.ipfs.dweb.link/`(CIDv1 更适合子域名网关;CIDv0 有时需要先用工具转成 CIDv1 再试)[7]\n\n2. **用 inbrowser.link 的子域名形式**  \n   尝试:  \n   - `https://bafy... .ipfs.inbrowser.link/`(需要先把 Qm... 转成 CIDv1 的 bafy... 形式)  \n   inbrowser.link 对浏览器内验证和 Range 请求支持更好,但 CIDv0 可能要先转换。[1][6]\n\n3. **检查响应头**  \n   用 `curl -I \"你的链接\"` 看:  \n   - `Content-Type` 是不是 `video/mp4`  \n   - 是否支持 `Accept-Ranges: bytes`  \n   - 状态码是不是 200/206 而不是 451/403/504[3][4]\n\n4. **本地节点 / 扩展**  \n   如果你跑本地 IPFS 节点(Kubo/Helia)或用 IPFS Companion 扩展,可以让浏览器通过本地节点拉流,绕过公共网关的限流和重定向。[8][9]\n\n如果你愿意,可以把你在浏览器里访问这个链接时拿到的**完整 HTTP 响应头**(或用 curl -I 的结果)贴出来,我可以帮你判断是网关限流、MIME 问题、还是 Range/CORS 导致的。\n\nnostr:nevent1qqsqhvf3f0gag0ez6d0g8que085hefswnazhwys8s3zzamz0j8k36jsprdmhxue69uhkummnw3ezuumpw35x7ctjv3jhytnrdakj7q3qnr0runywca4fl3dujvy3s76az06hldhcsk9z5dfcnhuhtpynzhjsxpqqqqqqzy43kc6",
  "sig": "0ca44de9257c2e5414b59022b08961e92006c02408341005f3f2673749ef37aa66072cdc847ac8e395ffeab0a5e7a029f73ace442691632799997bcd2aac52b7"
}