Bilibili Accelerator: a userscript that rewrites CDN choices for overseas playback

The overseas Bilibili problem this script targets

The README opens with a specific observation: from overseas, popular videos usually play without trouble, while less popular ones swing between smooth and frozen. That asymmetry is the whole reason the project exists. Popular videos are cached close to you by whichever CDN Bilibili hands out; obscure ones are not, and the player keeps whatever endpoint it picked.

The script's answer is not a proxy and not a VPN. It stays inside the browser tab, observes the playback session, and when a connection looks clearly unstable it changes which server the media requests go to. When playback is normal, the README says it does not intervene. That restraint matters: a tool that rewrites every request would break more than it fixes.

The intended audience is narrow and stated plainly. This is for people watching Bilibili in a desktop browser from outside mainland China, including Safari users, who have no Tampermonkey. It is not for phones, not for Apple TV, and not for fixing licensing restrictions.

How the CDN probing and stutter recovery actually work

The mechanism visible in the release notes is a candidate list plus measurement. v0.4.0 describes candidate servers now covering both domestic and overseas tiers, all of them participating in live measurement, with ranking by measured throughput rather than response time. That is a meaningful choice. A server that answers a ping quickly can still deliver video slowly, so ordering by throughput matches what the viewer actually experiences.

When stutter is detected, the recovery path walks the full list rather than jumping to a single backup. v0.2.3 notes that stutter recovery keeps retrying, and v0.4.0 changed the switching logic to traverse the complete candidate set. Automatic mode therefore has no fixed server: the README states the server is decided by speed test results unless you explicitly pick one.

The panel is the visible half of this. It shows current status at the top and a live download speed curve below. When speed data is unavailable, it falls back to showing how many seconds are buffered ahead. v0.2.2 explains why the curve can be trusted at all: it is computed over periods when data is genuinely moving, so a full buffer no longer reads as a fake drop to zero.

One failure mode is documented rather than hidden. v0.4.0 records that background playback used to freeze within seconds after switching tabs, most visibly in Safari, because the accelerator had rewritten Bilibili's own overseas mirror to a domestic CDN. The fix widened the candidate pool across both tiers. That is a useful reminder that rewriting endpoints is a blunt instrument when the original endpoint was chosen for a reason.

Installing the userscript and confirming it is running

On Chrome, Edge and Firefox you first install a userscript manager, then the script itself. The README lists Tampermonkey and Violentmonkey, and recommends the Greasy Fork page because it supports automatic updates. After installing, refresh any Bilibili tab that was already open; a lightning bolt appears in the lower right corner when the script is active.

Safari has no Tampermonkey, so the README points at the Userscripts extension from the App Store. The steps are: install it, enable it in Safari settings and allow access to bilibili.com, then open the Greasy Fork or GitHub Raw address to install, then refresh.

If you prefer not to run a script manager at all, the repository builds a Manifest V3 extension. The README gives this command:

npm run build

After it finishes, open chrome://extensions, enable developer mode, and load the dist/extension directory. The build emits two artifacts, dist/bilibili-accelerator.user.js and dist/extension/. Note that dist/ is committed to the repository and CI checks it against src/, so if you modify source you must rebuild before committing.

A first real use is to watch the panel rather than the video. Open a video that stutters, expand the panel, and look at the speed curve. If the curve is drawing numbers, the probe is getting throughput data. If instead you see buffered seconds, the script could not measure speed and is falling back. The advanced settings also expose a "still stuttering? push harder" switch that moves to a more aggressive mode and reloads the page, plus a bandwidth protection toggle that is off by default and limits how much upload bandwidth the page consumes. That toggle requires a page refresh to take effect.

Where Bilibili Accelerator is the wrong tool

The limitations section is unusually direct. The script only covers the Bilibili web player inside a browser; Apple TV and the mobile app are out of scope, so an Android user searching for a Bilibili accelerator will not find an answer here. The README also states that network conditions vary by region and carrier, and that the script can improve some cases but cannot solve copyright region restrictions, a broken source file, or problems in your own local network.

There is a second document, docs/router-proxy.md, referenced from the README, which explains why router-level proxy setups mostly do not help and why native apps have certificate pinning problems. The existence of that document is itself a boundary marker: this project is a browser-side intervention by design, not a network-layer one.

A concrete failure case is recorded in the version table. v0.4.1 notes that rewriting video requests to Akamai returns 403, which is why Akamai was removed from the built-in list and why other addresses must be entered through a "custom" option. If you were hoping to pin a specific CDN host that the project considers broken, the fixed-server dropdown will not offer it.

The fixed-server picker itself has a documented quirk. In v0.4.1 the previous input box, when it already held an address, would only list matching candidates, so you had to clear it before other servers appeared. That is now a dropdown, and the setting only appears after you choose to use a fixed server; in automatic mode the speed test decides.

How it differs from a proxy or a generic userscript

The obvious alternative is a network-level proxy or VPN, which changes the route your traffic takes before it reaches Bilibili. That approach addresses region restrictions, which this script explicitly says it cannot fix, but it does nothing about which CDN endpoint the player selects, and the README's router-proxy document argues that router-based setups mostly fail for this purpose.

The closer alternative is a general-purpose Bilibili userscript or extension that adds player features, such as blocking ads or restoring removed UI elements. Those modify the page but leave the media connection alone. Bilibili Accelerator does the opposite: it leaves the interface largely untouched and changes the connection, then reports what it measured. The panel with a live throughput curve is the visible consequence of that focus.

Within the project, the two delivery forms also differ in approach. A userscript manager updates the script automatically through Greasy Fork, while the Manifest V3 extension built from the repository is loaded manually and must be rebuilt and reloaded by hand. If you want updates without thinking about them, the userscript route is the one the README recommends.

Maintenance cost, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-09-15, which is two days before this writing, so it is being worked on. That matters less than the release cadence: v0.1.1 through v0.4.1 are all listed in the README, with v0.3.0 described as panel themes and dark mode and explicitly noting that core logic did not change. The project ships UI work and connection work in separate releases, which makes it easier to tell whether an upgrade affects playback at all.

Upgrade cost for userscript users is close to zero, since Greasy Fork handles updates. For anyone building the extension, the constraint is the committed dist/ directory: the README states that CI checks dist/ against src/, so a stale build will fail. Version numbers live only in package.json, and the build script syncs both the userscript header and the extension manifest from it. Changing a version in two places by hand is not an option here.

The licence is MIT, stated in package.json and in the LICENSE file. In practical terms that permits reuse and redistribution with the licence text retained; it offers no warranty. This is a description of what the licence says, not legal advice, and anyone embedding the code in a product should read the LICENSE file itself.

Editorial conclusion

Adopt it if you watch Bilibili in a browser from outside mainland China and your problem is stutter on less popular videos, not a geo-block. Skip it if you need Apple TV or the mobile app, since the README states the script only covers the browser player. Before trusting it, open the panel, confirm the speed curve is drawing real numbers rather than the buffered-seconds fallback, and check that the fixed-server list no longer offers Akamai, because v0.4.1 notes that requests rewritten to Akamai return 403.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. realzza/bilibili-accelerator on GitHub
5. Releases