Bilibili Proxy: Exit Scope on the Web and Mobile Clients

Bilibili is a platform that combines long-form video, live streaming and the on-screen scrolling comment layer in the same interface. These three components behave differently on the network side: video downloads segment by segment, live streams arrive as a continuous flow, and the comment layer updates in real time over a long-lived connection.

From a proxy standpoint, this variety raises a direct question of scope. A rule defined in the browser covers most of these components; a rule defined at the operating system level covers more; in the mobile app, scope depends on the app's own preferences and is not always predictable.

The sections below first separate these three surfaces, then cover the classification of the exit address, the request chain, the regional licensing mechanism and the behaviour of persistent connections.

The same account, three different client surfaces

The first surface is the browser. Here everything works predictably: the browser honours the system proxy setting or its own profile setting and sends all requests over that rule. This is the easiest environment for troubleshooting, because with developer tools you can see directly which request goes where.

The second surface is the mobile app. On Android and iOS, the HTTP proxy you write into the Wi-Fi network settings routes requests that go through the system; however, apps that build their own network stack or do not read the system setting can fall outside this rule. The result can be that part of the app exits via the proxy and part of it exits directly. It is not possible to see this from the settings; it can only be understood by measuring.

The third surface is the embedded player. A player placed in a blog post or forum message loads from its own source independently of the page it sits on. If your browser rule covers only certain domains, the embedded player's assets fall outside that scope and the frame appears empty.

Separating these three surfaces resolves most "it works for me but not on the phone" problems at the very first step. Changing settings without testing scope usually turns into looking for the right setting in the wrong place.

Where does the difference in scope between the mobile app and the browser come from?

On desktop browsers, proxy support is standard and all of the application's network traffic passes through that channel. On mobile operating systems the situation is different: the proxy details written into the Wi-Fi settings are offered to the system's shared network layer as a suggestion, and apps are free to use them or not. Apps that use their own connection library can ignore this setting.

The second difference comes from the connection type. The proxy in the Wi-Fi settings applies only to that wireless network. The moment the device switches to cellular data, the rule disappears and traffic exits directly over the operator. Because there is no visible change on screen, users often do not notice this. The setup steps are explained in the Android and iPhone proxy settings articles.

The third difference is protocol support. The mobile Wi-Fi setting typically lets you define an HTTP proxy; defining SOCKS5 is not directly possible on most devices and requires a separate client. Which apps support routing at the application level is applications that support SOCKS5 .

The only reliable way to verify scope is to measure: with the proxy on and off, run the my IP address tool in the mobile browser and compare the two results.

Which signals is your exit address classified by?

Which autonomous system your exit address belongs to is a public record, and the party serving the content matches the request against that record first; the general framework of the definition is set out in the ASN and IP reputation article. On the Bilibili side, the real issue is not the definition but the mixed picture produced by the same account connecting from more than one surface.

Concretely: when you use the mobile app over cellular data, your traffic exits from the operator's ASN; when you connect with the same account from a desktop browser, it exits from the ASN of the proxy you have configured. One of the surfaces is routed, the other is not, and the account appears from two different network types at short intervals. Even if this picture causes no problem, it increases the number of variables when troubleshooting: you cannot tell whether a behaviour stems from the exit type or the client surface. The solution is to decide up front which work runs from which surface and which exit.

The second Bilibili-specific detail is connection lifetime. Watching a live stream means pulling an uninterrupted flow from the same exit address for minutes or even hours; on top of that comes the permanently open comment connection. Unlike short-lived page requests, this leaves long-running, regular traffic from a single address. In a shared pool, the same address also being used for other work at the same time makes the picture denser still; how the pool is designed therefore matters, and the proxy pool with subnet diversity articles explain this side.

The third detail is that the choice of location also determines the exit ASN. When working in the APAC region, choosing a Singapore or Japan exit changes not only the geographical mapping but also what kind of network the address appears to belong to; within the same country a hosting block and a provider block are two entirely different profiles. The practical upshot is this: choosing the exit type suited to the nature of your work from the outset is far more effective than tinkering with settings afterwards.

The request chain: from exit selection to the first segment

A playback request proceeds through three stops. The first stop is determining the exit. With a provider using a gateway architecture, you are given a single set of access details, and which country you exit from is selected via parameters in the username or via a different port. How this architecture works is explained in the gateway architecture article.

The second stop is name resolution, and it is the step most often overlooked. If resolution is done on the client, the domain you are going to is visible to your local resolver and name-based rules on your network remain in force. When you use SOCKS5 and send the destination as a domain name, resolution is done on the exit side. The details of the difference are in the article on where DNS is resolved in SOCKS5, and verification is in the DNS leak test tool.

The third stop is the playback request itself. The TLS handshake completes, the player fetches the manifest file and starts pulling segments. The only address visible on the server side is the proxy exit; on the other hand, which host name the request goes to is visible on the proxy side. How certificate validation works in this chain is explained in the proxies and TLS certificate validation article.

Breaking the chain down this way makes troubleshooting systematic. When you hit a fault, determine which stop you are at: if the exit cannot be established, look at the first; if the domain cannot be resolved, the second; if the connection is established but no content arrives, the third.