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

npub1nr0runywca4fl3dujvy3s76az06hldhcsk9z5dfcnhuhtpynzhjs28gqtu
hex
9306d1f085c5c00fd3095a845ec90f69ed54561f5ab2a732e7424497ae81ea1anevent
nevent1qqsfxpk37zzutsq06vy44pz7ey8knm252c044v48xtn5y3yh46q75xsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsf3h37fj8vw65lck7fxzgc0dw38atlkmugtz32x5ufm7t4sjf3tegy7z8xhKind-1 (TextNote)
我把视频的链接直接放到浏览器也无法播放
你这两个链接打不开,主要有两层原因:IPFS 公共网关的迁移/限流策略 + 浏览器对 IPFS 视频流的播放条件,而 Amethyst 能播是因为它用的是自己的播放器栈和更“宽容”的网络层。[1][2]
1) dweb.link 已经转向 inbrowser.link(服务工网关)
从 2026 年开始,ipfs.io 和 dweb.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) 你可以怎么验证/绕过
如果你想让浏览器也能播,可以试几种方式:
-
换网关
把 URL 改成其他公共网关,例如:https://ipfs.io/ipfs/QmUGLjwfioAA8MSJFtp8C4upd5A8op4m5UuFrNysjjHnw1?filename=video_converted.mp4https://<cid>.ipfs.dweb.link/(CIDv1 更适合子域名网关;CIDv0 有时需要先用工具转成 CIDv1 再试)[7]
-
用 inbrowser.link 的子域名形式
尝试:https://bafy .ipfs.inbrowser.link/(需要先把 Qm... 转成 CIDv1 的 bafy... 形式)
inbrowser.link 对浏览器内验证和 Range 请求支持更好,但 CIDv0 可能要先转换。[1][6]
-
检查响应头
用curl -I "你的链接"看:Content-Type是不是video/mp4- 是否支持
Accept-Ranges: bytes - 状态码是不是 200/206 而不是 451/403/504[3][4]
-
本地节点 / 扩展
如果你跑本地 IPFS 节点(Kubo/Helia)或用 IPFS Companion 扩展,可以让浏览器通过本地节点拉流,绕过公共网关的限流和重定向。[8][9]
如果你愿意,可以把你在浏览器里访问这个链接时拿到的完整 HTTP 响应头(或用 curl -I 的结果)贴出来,我可以帮你判断是网关限流、MIME 问题、还是 Range/CORS 导致的。
nostr:nevent1qqsqhvf3f0gag0ez6d0g8que085hefswnazhwys8s3zzamz0j8k36jsprdmhxue69uhkummnw3ezuumpw35x7ctjv3jhytnrdakj7q3qnr0runywca4fl3dujvy3s76az06hldhcsk9z5dfcnhuhtpynzhjsxpqqqqqqzy43kc6
Raw 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"
}