Using a Proxy with Likee: Name Resolution, Media Paths and Sessions
In short video apps, most of the volume is media downloads; session and API requests are a small but decisive slice. When setting up a proxy for Likee, you need to know that these two slices travel by separate paths, where name resolution happens, and that live stream transport is subject to different rules.
Name resolutionWhether the domain name is resolved locally or remotely, and what that exposes.
02
WebRTC and UDPThe relationship between live stream transport and the HTTP tunnel, and the leak risk.
03
Media pathVideos and cover images being delivered separately from the main domain.
04
Multiple devicesThe consequences of concurrent sessions appearing from different networks.
Likee is one of the short video platforms operated by BIGO Technology, and its centre of gravity is the mobile app. The web side is used mostly for viewing individual videos and profiles. This imbalance affects the proxy setup: a setting you make in a desktop browser represents only a small part of the traffic the app actually generates.
Another decisive point is how content is carried. Video files, cover images and profile photos come not from the main domain but from addresses dedicated to delivery. When you write a partial proxy rule, the app opens but the feed stays empty; the source of this picture is not authentication but coverage.
The sections below cover name resolution and leaks first, then the transport layer and traffic distribution, and after that session behaviour and setup layers.
Where is the domain name resolved, and what does that tell you?
Before a connection is established, the domain name must be translated into an address. This operation can happen in two places: on the device where the client runs, or on the proxy server. Which one applies depends on the protocol you use and on the client's settings.
On an HTTPS connection over an HTTP proxy, the client says CONNECT server:443 and the proxy resolves the name. SOCKS5, because it can send a domain name as the address type, can leave resolution to the remote side; some clients, however, still resolve the name locally and send only the IP. The technical detail of this distinction is where DNS is resolved in SOCKS5 article.
The practical result is this: if the name is resolved locally, which service you connect to is visible on the provider side even if the traffic is encrypted. This means not that the content is read, but that the service name is exposed. For measurement, use DNS leak test tool.
Modern operating systems and browsers complicate this picture further. When the browser's own encrypted DNS setting is on, name resolution goes neither to the local resolver nor to the proxy; it goes to the remote resolver the browser has chosen. As a result, two applications on the same device can resolve the same domain name by two different paths. Taking measurements while testing without pinning down which component performs resolution produces contradictory results.
Tip
Take the measurement in two stages: first turn off the browser's encrypted DNS setting and note the result, then turn it on and repeat. The difference between the two results clearly shows where name resolution actually goes.
WebRTC and UDP transport fall outside the proxy tunnel
The WebRTC interface on the browser side queries STUN servers while gathering connection candidates, and in the process learns your local network address and, in most configurations, your public address as well. This information can be handed to a script on the page. An HTTP proxy rule does not cover this process, because candidate gathering follows a separate path. You can measure the situation with WebRTC leak test .
Considering live streaming and video interaction features, a second limit comes into play: the transport layer. An HTTP proxy carries only TCP; it does not relay UDP packets. The SOCKS5 protocol defines the UDP ASSOCIATE command, which permits UDP relaying, but many providers keep this feature disabled and many clients never request it. For details, see SOCKS5 UDP support article.
The same limit also affects part of modern web traffic. HTTP/3 uses QUIC as its transport, and QUIC runs over UDP. Behind a proxy that carries only TCP, the client usually falls back silently to a TCP-based version. This behaviour often goes unnoticed; it appears only as an unexpected performance picture when you take measurements.
The combination of these three facts means this: watching or going live is the weakest link in a proxy setup. While the rule routes only TCP traffic, the media stream can travel by another path, and you will not see that in the interface.
What difference remains between the browser and the app?
When you view Likee content in a desktop browser, the requests resemble classic web traffic: document, script, style and media. On the app side, the client applies its own protocol preferences; apps that ignore the system proxy setting and connect directly are common.
Verification therefore matters more on the mobile side: once the rule is defined, the change of exit address should be seen through an external check, not through the app's own interface. For per-app routing options, the applications that support SOCKS5 article offers a useful list.
The second difference is in certificate validation. The browser checks the certificate chain against its own trust store and shows you a visible warning on a mismatch. Apps, on the other hand, do the validation silently and, if there is a problem, most often just say "could not connect". If there is a corporate inspection layer in the middle, this difference shows up plainly in the browser and as a meaningless error in the app.
For the live streaming app in the same ecosystem, the BIGO Live proxy page covers the differences on the broadcasting side.
How is traffic split between the main domain, media and the live channel?
In a short video feed, the vast majority of bytes come from downloading videos and cover images. Session requests and like and comment calls are small but constant traffic. The third branch is real-time notifications and the live stream channel.
This distribution has two practical consequences. The first is cost: if you use an exit billed by volume, media makes up most of the bill. For the calculation method, see the calculating proxy bandwidth article. The second is coverage: a rule that routes only the main domain carries a small slice of the traffic and leaves the large slice outside.
If you want to measure the distribution for your own usage, a simple method is enough: use the service normally for a fixed period and read the volume counter in your proxy panel at the start and the end of that period. When you repeat the same measurement once with autoplay on and once with it off, the weight of the media slice becomes clear.
When a video is cached, the same content is not downloaded a second time; measurements made without clearing the cache are misleading for that reason. In comparative tests, resetting the cache the same way before each round is what makes the result meaningful.
DIAGRAMClient traffic splitting into three branches
You can scroll the diagram horizontally to inspect it
The shares are relative weights: in short video use most of the volume goes to media delivery, while session and API requests make up a small but critical slice.
Set up your exit plan for Likee
Volume cost is decisive in media-heavy use and consistency in session-heavy use; both needs are met from the same panel.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
Choosing an exit on a single "good/bad" axis is misleading. Regional appearance, session stability, bandwidth, concurrency and cost pull in opposite directions.
Mobile proxy is strong in regional verification and in scenarios close to app behaviour because it exits from a carrier network, but its cost per unit of volume is high and bandwidth is shared. Datacenter proxy offers wide bandwidth and high concurrency; it is sufficient for work such as viewing public content or checking how a video appears in different countries.
For the cases in between, ISP proxy is a balanced option: it is hosted in the provider's ASN and retains datacenter stability. In practice, most teams split the work in two rather than choosing a single type; high-volume monitoring and regional verification are run through different exits.
As you read the axes in the diagram, keep this in mind: the values are relative weights and show where the two profiles diverge from one another. If you decide in advance which of the axes is decisive for you, the decision becomes clear at a glance; looking for an option that is good on every axis leads nowhere.
DIAGRAMThe profile of two exit types across five criteria
You can scroll the diagram horizontally to inspect it
The axis values are relative weights out of a hundred, not measurement results; the aim is to show in which respects the two exit types differ from one another.
What happens when the same account connects from two devices?
Most mobile platforms allow concurrent sessions; a phone and a tablet can stay connected at the same time. The problem is not the concurrency but the sessions appearing with network identities very different from one another.
If the phone connects from a carrier network and the desktop from a remote datacenter exit, the distance and ASN difference between the two sessions grows; this difference is a known cause of session checks tightening. The solution is not to spread the devices across different networks but to establish a consistent exit policy.
The state chain in the diagram makes it easier to see where the problem begins: login succeeds, a second device comes into play, the difference between the network identities becomes pronounced, and at the end of the chain re-verification is requested. The way to shorten the chain is not to intervene at the last step but to maintain consistency at the second.
Pin an account to a single exit country.
When adding a device, change only the device, not the exit.
If you have to change exits, make the transition gradually.
Open the first session after a change with a period of calm usage.
DIAGRAMSession states across multiple devices
You can scroll the diagram horizontally to inspect it
When a second device comes into play, what matters is not the concurrency but the two sessions appearing with very different network identities.
Setup layers and the traffic they cover
Where you define the proxy determines which requests are routed. The table lists the layers by breadth of coverage; as you go from top to bottom, coverage narrows and control increases.
Layer
Where it is defined
Traffic covered
Router
The network device's WAN or rule settings
All devices connected to that network
Operating system
System network settings
All applications that honour the setting
Wi-Fi profile
The mobile device's network details
Only that wireless network
Browser profile
Profile or extension configuration
Only the tabs in that profile
Application rule
The client's own network setting
Selected processes
Broad coverage is not always a good choice. A rule set at router level affects every device at home or in the office; while trying to test a single app, you end up changing the behaviour of the whole network. Narrow coverage, on the other hand, easily ends up incomplete. The right choice is to pick the narrowest scope the job requires and do the verification within that scope.
Reading observations correctly: the order of measurement
The most common mistake when troubleshooting is taking measurements in a random order: first the exit, then name resolution, and performance last. When that order is broken, the measurements invalidate one another.
If you want to compare response times, the ping test tool gives a basic reference. Because a proxy adds an extra stop along the way, it usually increases total latency; in exceptional cases where the default route is circuitous, however, a shorter path can emerge. This is not a rule but an exception that needs to be measured.
Repeating measurements at different times of day is also valuable. On a shared exit, the picture during peak hours can differ markedly from the picture during quiet hours; changing exits on the basis of a single measurement is often a premature decision.
A framework for responsible use
A proxy is a legitimate tool in terms of access and privacy: exiting a corporate network with a fixed address, verifying how a campaign appears in different countries, or regularly monitoring public data all fall within that scope.
Generating fake engagement, creating accounts in bulk or attempting to defeat security checks, on the other hand, is contrary to terms of service and falls outside the scope of this page. Such uses do not produce lasting results technically either; assessment on the platform side looks not at a single signal but at behaviour as a whole.
Using a proxy with Likee: frequently asked questions
01The cover image loads but the video does not play — where should I look?
The cover image is a single request; playback, on the other hand, runs through consecutive segment requests. The cover arriving only shows that the rule covers that address, not that the segments arrive too: when the player cannot fetch the first segment, a permanently spinning loading indicator remains in the interface instead of an error. As a first check, turn off autoplay and start the video manually; if the behaviour changes, the problem lies in the number of concurrent connections opened during preloading. If it does not change, look at the transport layer: behind a rule that carries only TCP, the client falls back from HTTP/3 to a TCP-based version, and on some networks that fallback turns into a silent timeout.
02Does live streaming work over a proxy?
It can work if the connection is established over TCP. If the transport is UDP-based, an HTTP proxy will not carry it; SOCKS5's UDP ASSOCIATE support is required, and that feature is disabled at many providers. Live streaming is therefore the most fragile part of the setup.
03Is a WebRTC leak a problem for me?
If you are viewing Likee content in a browser, yes, because the WebRTC interface can expose your real address to a page. In the mobile app this risk is not as direct as in a browser. Measure the situation with WebRTC leak test .
04Does a DNS leak make my encrypted traffic readable?
No. What leaks is not the content but the name of the service you connect to. The traffic itself stays encrypted with TLS. Even so, which service you connect to being visible is meaningful information in privacy terms.
05Does it make sense to use different proxies on my phone and computer?
For the same account, usually not; the further apart the network identities of two sessions are, the harder consistency becomes. Separating exits by job rather than by account builds a more robust arrangement: monitoring and regional checks can run on separate exits, while logged-in devices stay on a single exit.
06Which type of exit is more economical?
In volume-heavy use, datacenter proxy is the most economical option per byte. For work requiring regional accuracy, mobile proxy gives more accurate results but costs more.
07Does a proxy reduce connection latency?
Usually no. A proxy adds an extra stop along the way and lengthens the total time. Only in exceptional cases, where the default route is circuitous, can a shorter path emerge; this is not expected behaviour but an exception that needs to be measured.
08How do I reduce bandwidth consumption?
Turning off autoplay, choosing a lower resolution and not downloading the same content over and over are the most direct methods. For measurement, use the method in the bandwidth calculation article.