Bilibili-oversea: Browser 2.5.1 and Mobile 0.5.5 Candidate

当前版本

Bilibili-oversea 针对同一视频在不同 B 站媒体 CDN 上表现差异明显的情况，在设备本地观察、选择和切换线路。当前浏览器版为 2.5.1，本轮交付代码固定为 r19；iPhone / iPad 版为独立的 0.5.5 媒体候选版，普通 bilivideo、精确 Akamai、MCDN 的视频与音频统一采用直接优先线路与后续有限复核（playbackPolicyChanged: true）。

浏览器安装入口更新于 2026-10-19；手机候选版说明沿用 2026-10-07。个别视频仍可能慢开播；本轮仅做有限验证，不能保证所有视频不卡顿。

从商店安装浏览器版

在电脑的 Chrome 或 Edge 中打开 Bilibili-oversea · Chrome 商店，按浏览器提示确认安装；Edge 若提示“允许来自其他商店的扩展”，按提示允许即可，不需要开发者模式。独立 Edge 商店尚未上架。已加载 ZIP 或旧候选版的用户，先停用旧版，只保留一个版本启用，再刷新 B 站视频页并核对 2.5.1。

商店无法访问时，详情页的 ZIP 备用安装与 SHA-256 保留原包和手动加载步骤。商店审核通过不代表全部视频的播放性能已经验收。

浏览器 2.5.1 怎样工作

自动模式优先使用近期可信的网络缓存；没有可信缓存时，以常用 08CT 作为默认起点。健康线路会保持，不会为每个视频先把 500 余目录项全部测速；只有真实媒体失败形成证据时才有限轮换，必要时回到原始线路。播放器已有安全缓冲后，扩展才可能按条件做轻量复核；手动测速仍由用户明确发起。

界面选中线路、收到真实媒体响应和连续播放成功是三个不同状态。“未测速”只表示没有对应实测证据，不等于不可用或从未尝试。匿名预连接也不等于测速：它只可能提前进行 DNS 和连接握手，不包含媒体路径、签名或 Cookie。

本轮有限复测中，两条自有短视频以最高可用 AVC 1080P60 完整播放，未记录目标卡顿；首显示帧为 6.385 / 11.139 秒。样本很小，完整验收仍未通过，不能据此宣称所有节点最快、所有视频顺滑或整体性能普遍领先。

手机端 0.5.5 候选版的边界

手机端通过 Surge、Loon、Shadowrocket、Stash 或 Quantumult X 的本地脚本能力工作。desktop-like-passive-first 让普通 bilivideo、精确 Akamai、MCDN 的视频与音频首条请求统一直接优先 08ct，同时尊重自定义线路；开播前不等待测速或原路参考。首次路由为 provisional，不会虚构已验证状态或 scores。同一资源的稳定线路会保持；视频缓存最多记录 8 个资源并保留 5 分钟，到期时先复核当前线路，不强制回到 08ct，失败资源彼此隔离。

403、404、416 或 429 会让后续请求立即进入有限备用队列；5xx 默认须在 30 秒内连续失败两次才触发，200/206 会清零，队列耗尽则回到原始线路。音频不会测速、与视频竞速或定时复核。视频在 15 秒后由下一条请求复核；合格线路保持 45 秒，低速或尾部样本保持 15 秒。复核当前线路使用 512 KiB 样本，不再请求原始 Akamai 参考；低速或失败时最多尝试两个备选。750 ms 时可以启动 hedge，但仍等当前线路完成或共享的 1950 ms 预算到期，再统一校验。

完整 512 KiB、至少 3200 kbps、备选至少 1.5 倍更快和 30 秒冷却都只是本轮启发式门槛，不是视频码率、持续带宽或真机流畅保证。复核请求仍可能带来约 2 秒等待与额外流量。当前线路与备选都有样本时，返回区段、文件总长和参考字节必须一致，已知不匹配就拒绝。当前线路没有样本时，可选择通过 206/Range 校验且容量达标的 provisional 备选，但不能记为 verified；复核不再要求原始 Akamai 参考。

交付方报告 63 项本地 Node/VM 手机回归与最终 8 项控制复核通过；这是交付自动化证据，不是真机播放验收。playbackHealthObservable: false、inFlightRecoverySupported: false、physicalIPhoneAcceptancePassed: false，不能据此宣称真实手机卡顿已经改善。

一次短验证分五步：停用旧模块并保留回退后导入一项 0.5.5 候选，只启用 0.5.5；重新使用当前配置并确认 Shadowrocket 实际引用的四个脚本都来自 mobile-0.5.5，已有完全信任的自有 CA 无需重装；断开重连，只有原来处于固定或原始模式时才打开一次自动模式，随后刷新只读状态，确认本机 JSON 同时包含 ok: true、local: true、service: "bili-cdn-auto" 与 controlVersion: "0.5.5"；播放原先卡顿或未完整缓存的视频 30–60 秒，观察缓冲耗尽后的速度与恢复，无需大量重复播放；最后再次刷新只读状态并保存 JSON。自动模式会重置状态，不能当状态页反复点击；“重新测速”只安排下一条视频请求显式复核，控制请求本身不测速；Quantumult X 仍需手动合并。

真实网站 404 表示本机脚本没有命中。视频与音频仍分别保存在 videoDiagnostics 和 audioDiagnostics，后来的音频不会覆盖视频记录；新版尚未执行或无法归属的轨道为 null，用 videoDiagnostics.streamCode 核对视频分类。videoDiagnostics.routingPolicy 应为 desktop-like-passive-first；videoDiagnostics.reason 的主要值包括 preferred-route-direct、stable-resource-route、http-failure-priority-fallback、current-route-reviewed 与 range-qualified-fallback。videoDiagnostics.routeProvisional 标出尚未完成兼容验证的路由；videoDiagnostics.verificationBasis 可为 none、range-only 或 current-route-byte-match；videoDiagnostics.referenceVerified 表示当前线路与备选样本的兼容比较，不再表示 Akamai 原始线路参考。videoDiagnostics.probeRangeStart、videoDiagnostics.nextReviewAt 与 videoDiagnostics.decisionCompletedAt 描述 URL 决策，不代表媒体传输完成。顶层 scores 是最近抽样列表，需结合 resourceTag、stage、sampledAt、rangeStart、rangeValidated、capacityKnown 与 verified 判断，不自动属于最新视频。顶层媒体字段仍表示最新一次请求，最新音频请求不能代替视频判断；lastResponseStatus 为 200/206 只表示 HTTP 状态，不证明持续速度恢复或整段不卡。状态查询只读，不写缓存也不触发测速；这些诊断不是实时播放器缓冲。

安全与隐私边界

• 浏览器权限限于 activeTab、declarativeNetRequestWithHostAccess、storage、webRequest 和必要的 B 站媒体主机；不申请代理、Cookie、浏览历史或所有网站权限。
• 设置、缓存和状态保存在本机；完整媒体 URL 与签名只在当前标签页及后台临时处理。“复制诊断”会脱敏且不会自动上传。
• 正常播放、测速和备用尝试仍会让媒体 CDN 收到正常的 IP、媒体路径与请求签名；条件性复核或手动测速可能产生额外流量。
• iOS 端只使用用户自己客户端生成的 CA。精确域名 limitedrush.online 的全部 HTTPS 会在本机解密，只有 /bili-cdn-auto/ 专用路径执行控制。0.5.2 起增加模板列出的媒体候选解密家族；0.5.5 不扩大该范围，也不增加账户或播放 API 域。
• 手机诊断只保存在本机，不保存原签名 URL、查询或样本字节，也不上传。候选探测会发送原媒体路径与签名查询，只复制必要的 User-Agent、Referer、Origin、Accept，不带原 Cookie、Authorization 或 Proxy-Authorization；实际跨主机改写也会剥离这三项认证头。不能据此推断所有请求都无 Cookie，原始线路也没有全局无 Cookie 承诺。
• 工具不会绕过版权、地区、登录、会员或平台签名限制。

维护与恢复

商店版由浏览器管理更新。若需回退到保留的 ZIP，先停用商店版，再按备用说明加载旧目录并刷新播放页；只保留一个版本启用。遇到卡顿，可先复制一次脱敏诊断，再用原始线路或停用扩展作对比。手机端体验变差时可在必要时使用一次原始线路并退出重进视频，或停用 0.5.5、启用保留的 0.5.4 / 0.5.3 / 0.5.2 / 0.5.1 / 0.5.0 后重新使用配置；切换不会取消已经进行的下载，0.5.0 旧状态地址仍可能因 .invalid 解析失败。完整安装、版本记录、隐私与诊断入口均保留在详情页。

Current versions

Bilibili-oversea addresses cases where the same video behaves very differently across Bilibili media CDNs. Route observation, selection, and switching happen locally on the device. The current browser edition is v2.5.1 with its r19 runtime frozen for this delivery. The separate iPhone / iPad edition is the v0.5.5 media candidate. Ordinary bilivideo, exact Akamai, and MCDN video and audio now use unified direct preferred routing with bounded later review (playbackPolicyChanged: true).

Browser installation updated October 19, 2026; the mobile candidate notes remain from October 7, 2026. Some videos may still start slowly. This delivery has limited validation and cannot guarantee smooth playback for every video.

Install the browser edition from the store

Open Bilibili-oversea in the Chrome Web Store in desktop Chrome or Edge and confirm installation. If Edge asks, allow extensions from other stores; Developer mode is not needed. A separate Edge Add-ons listing is not available yet. Disable an existing unpacked ZIP or older candidate first, keep only one version enabled, then refresh Bilibili and check v2.5.1.

If the store is unavailable, the detail page retains the original package, checksum, and manual steps under ZIP fallback installation and SHA-256. Store review does not establish full playback-performance acceptance.

How browser v2.5.1 works

Automatic mode prefers a recent trusted network cache. Without one, it starts from the commonly used 08CT route. A healthy route is retained instead of benchmarking the 500-plus catalog entries for every video. Real media failures provide evidence for bounded rotation, with the original route available when needed. Conditional light review can run after the player has safe buffer; manual measurement remains an explicit user action.

A selected route, a real media response, and sustained successful playback are distinct states. “Not measured” only means there is no matching measurement evidence; it does not mean unusable or never attempted. Anonymous preconnect is not a benchmark either: it can set up DNS and a connection without a media path, signature, or cookie.

In the limited rerun, two own short videos completed at their highest available AVC 1080P60 tier without a recorded target stall; first displayed frames were 6.385 / 11.139 seconds. The sample is small and full acceptance still did not pass, so it does not support claims that every node is fastest, every video is smooth, or performance is universally better.

Mobile v0.5.5 candidate boundaries

Mobile works through the local scripting capabilities of Surge, Loon, Shadowrocket, Stash, or Quantumult X. desktop-like-passive-first makes the first ordinary bilivideo, exact Akamai, and MCDN video or audio request directly prefer 08ct while respecting a custom route; it does not wait for a benchmark or original-route reference before playback. The first route is provisional and does not fabricate verified state or scores. A stable route is retained for the same resource. The video cache holds at most 8 resources for 5 minutes; expiry reviews the current route first rather than forcing 08ct, and failed resources remain isolated.

An HTTP 403, 404, 416, or 429 sends a later request into the bounded fallback queue immediately. A 5xx response requires two consecutive failures within 30 seconds by default, while 200/206 clears the count; exhaustion returns to the original route. Audio does not benchmark, race video, or run timed review. Video review is triggered by the next request after 15 seconds. A qualified route remains valid for 45 seconds, while a slow or tail sample remains valid for 15 seconds. Review samples the current route with 512 KiB without requesting an original Akamai reference and tests at most two fallbacks after a slow or failed sample. A hedge may start at 750 ms, but validation still waits until the current route completes or the shared 1950 ms budget expires.

A complete 512 KiB sample, at least 3200 kbps, a fallback at least 1.5 times faster, and a 30-second cooldown are only heuristics for this decision round, not the video's bitrate, sustained bandwidth, or a guarantee of smooth physical-device playback. Review may still add about two seconds of waiting and traffic. When both the current route and a fallback have samples, their returned range, total length, and reference bytes must match; a known mismatch is rejected. If the current route has no sample, a fallback that passes HTTP 206/Range validation and the capacity threshold may be selected provisionally, but cannot be marked verified. Review no longer requires an original Akamai reference.

The delivery reports 63 local Node/VM mobile regression checks and a final 8 control rechecks passing. This is delivery automation evidence, not physical-device playback acceptance. playbackHealthObservable: false, inFlightRecoverySupported: false, and physicalIPhoneAcceptancePassed: false, so this does not establish that real-phone stalls improved.

A short check has five steps: disable the old module and retain it for rollback, import one v0.5.5 candidate, and enable only v0.5.5; reapply the current profile and confirm that all four scripts actually referenced by Shadowrocket come from mobile-0.5.5—an already fully trusted CA does not need reinstallation; disconnect and reconnect, use Automatic mode once only if the client was previously in a fixed or original mode, then refresh read-only status and confirm that local JSON contains ok: true, local: true, service: "bili-cdn-auto", and controlVersion: "0.5.5" together; play a previously stalling or not-fully-cached video for 30–60 seconds and observe speed and recovery after buffered content is exhausted without extensive repetition; finally refresh read-only status again and save its JSON. Automatic mode resets state and must not be repeatedly used as a status page. “Retest” only schedules explicit review on the next video request; the control request itself does not measure. Quantumult X still requires a manual merge.

A real-site 404 means the local script did not match. Video and audio remain separate in videoDiagnostics and audioDiagnostics, so a later audio request does not overwrite the video record. A track that has not run in the new version or cannot be attributed remains null; use videoDiagnostics.streamCode to check video classification. videoDiagnostics.routingPolicy should be desktop-like-passive-first; primary videoDiagnostics.reason values include preferred-route-direct, stable-resource-route, http-failure-priority-fallback, current-route-reviewed, and range-qualified-fallback. videoDiagnostics.routeProvisional marks a route whose compatibility validation is incomplete; videoDiagnostics.verificationBasis may be none, range-only, or current-route-byte-match; videoDiagnostics.referenceVerified now describes compatibility between the current-route and fallback samples, not an original-route Akamai reference. videoDiagnostics.probeRangeStart, videoDiagnostics.nextReviewAt, and videoDiagnostics.decisionCompletedAt describe URL decisions rather than media-transfer completion. Top-level scores is the most recent sample list. Interpret resourceTag, stage, sampledAt, rangeStart, rangeValidated, capacityKnown, and verified together; it does not automatically belong to the latest video. Top-level media fields still describe the latest request, so the latest audio request cannot replace the video assessment. A lastResponseStatus of 200 or 206 records only HTTP status and does not prove sustained-speed recovery or stall-free playback. Status is read-only: it neither writes cache nor starts a measurement. These diagnostics are not real-time player buffering.

Security and privacy boundaries

• Browser permissions are limited to activeTab, declarativeNetRequestWithHostAccess, storage, webRequest, and the necessary Bilibili media hosts. It does not request proxy, cookie, browsing-history, or all-sites access.
• Settings, caches, and status remain locally. Full media URLs and signatures are handled temporarily in the current tab and background. “Copy diagnostics” is redacted and does not upload automatically.
• Normal playback, measurements, and fallback attempts still expose the ordinary IP, media path, and request signature to the media CDN. Conditional review and manual retests may add traffic.
• On iOS, use only a CA generated by your own client. All HTTPS traffic for the exact limitedrush.online hostname is decrypted locally, while only dedicated /bili-cdn-auto/ paths execute controls. The template-listed media-candidate decryption families were added in v0.5.2; v0.5.5 does not expand that scope or add account or playback API domains.
• Mobile diagnostics stay locally, retain no original signed URL, query, or sample bytes, and are not uploaded. Candidate probes send the original media path and signed query and copy only necessary User-Agent, Referer, Origin, and Accept headers; they omit the original Cookie, Authorization, and Proxy-Authorization. Actual cross-host rewrites also strip these three authentication headers. This does not mean every request is cookieless, and no global cookieless claim is made for the original route.
• The tool does not bypass copyright, regional, login, membership, or platform-signature restrictions.

Maintenance and recovery

The browser manages updates for the store edition. To return to a retained ZIP, disable the store edition first, load the old folder using the fallback instructions, and refresh the video page. Keep only one version enabled. For a stall, copy one redacted diagnostic before comparing with the original route or the extension disabled. If the mobile experience worsens, use Original CDN once if needed and exit and reopen the video, or disable v0.5.5, enable the retained v0.5.4, v0.5.3, v0.5.2, v0.5.1, or v0.5.0 module, and reapply the profile. Switching does not cancel an in-progress download, and the v0.5.0 status address may still fail because of .invalid resolution. The detail page keeps the complete setup, release, privacy, and diagnostic references.