Last.fm Proxy: Two Separate Identities, Two Separate Streams of Traffic

What makes Last.fm interesting from a proxy perspective is that it produces two different types of traffic for the same user. When you open a profile or artist page in the browser, a classic web session is at work: a cookie is carried, HTML arrives, cover images are pulled from separate addresses. When a music application or your own script talks to the service interface, the picture changes; there, identity is carried not by a cookie but by the application key and the session key.

In practice this distinction means: defining a proxy for your browser profile does not change the exit of a desktop client running in the background. In the same way, defining a proxy in your script does not touch your session in the browser. You need to configure the two routes separately.

Below we will first separate these two routes, then look at where regional differences come from, which exit type fits where, how to calculate data volume and how to read publicly accessible statistics on a regular basis.

Why are a browser session and a service call not the same thing?

When you request a page in the browser, what goes to the server is your cookie. The server recognises you by that cookie; the exit address only says where the request came from. After the page arrives, additional requests open for cover images and static files, which are usually served from separate addresses and do not need to carry session information.

On the service side the setup is different. An application makes requests signed with an application key in order to send the listens you record or to read statistics. Calls that act on behalf of the account also carry a session key; this key is tied to the account and the application, not to the exit address. Changing the address does not invalidate the key.

The conclusion that follows makes troubleshooting easier. If pages open in the browser but your application cannot send data, the fault is not in the proxy country but in the application's network configuration. In the opposite case, that is, the application working while the browser stalls, the place to look is cookies and the browser profile.

There is one more practical distinction. A browser request pulls a large number of small assets; a single page load turns into dozens of separate requests. A service call, on the other hand, can return many records in a single request. Using the publicly accessible read endpoint instead of scraping the page to obtain the same information means both fewer requests and less data, and it also creates less load on the server side.

Routing both paths through the same exit is not mandatory, but if you are making a regional comparison, having them exit from the same country makes the results easier to interpret. Two routes exiting from different countries can produce contradictory pictures for the same account.

Submission of listening records and the timestamp

Listening record submission is small, frequent traffic: the request body is a few hundred bytes and the response is usually even shorter. It is therefore negligible in bandwidth terms; what really matters is the number of requests and their timing.

Records are sent together with a timestamp. Mobile clients accumulate records on the device while offline and deliver them in bulk when the connection returns. This behaviour produces a side effect in a proxy setup: a client that has been offline for a long time can open a large number of requests back to back as soon as it connects. If you use an exit with a narrow concurrency limit, this sudden pile-up can cause timeouts; the concurrent connection limit article explains how to read the limit.

Another point is protocol choice. Desktop clients mostly talk over HTTPS, and this traffic can be carried with a standard HTTP proxy . If the application only accepts socket-level routing, SOCKS5 is more flexible; the basic difference is that an HTTP proxy handles the request at the application layer, while SOCKS5 carries the TCP connection as it is and never looks at the content.

Where do regional differences come from: the exit country or the language preference?

The platform's own text content is largely the same; three separate mechanisms produce the regional difference, and they come into play in order. The first is the language and country preference in your account settings. If you are signed in, this preference takes precedence over the exit address; even if you connect from another country, the interface arrives in the language you chose.

The second is the Accept-Language header the browser sends. In a signed-out session the interface language is mostly determined by this header. A proxy does not change the header; it only carries the request. If you connect from a Japanese exit with a Turkish browser, you appear as a client coming from Japan but asking for Turkish. If you genuinely want to verify a regional appearance, align the browser language preference with the target country as well.

Alongside these two mechanisms come localisation details such as currency and date format; these too mostly come from the account preference, not from the exit. So when testing how a page looks in another country, using a signed-out browser profile gives a cleaner result. What you see in a signed-in session may not be what a visitor in that country sees.

The third is third-party players embedded in the page. A video or audio embed on an artist page is subject to the source platform's own regional rules; that content may be unavailable in some countries. In such a case the Last.fm page opens and the embed stays empty. This is a restriction of the source, not of the platform. For an example of a country-based exit, see the Japan proxy page; trying the same embed from two different countries is the fastest way to tell whether the restriction comes from the source platform or from your own setup.

Where exit types sit on the cost and appearance axes

The choice of exit type is made at the intersection of two axes. The first axis is cost and speed: the charge per address, the charge for data transferred and the transfer capacity. The second axis is how much the address looks like a "typical subscriber" on the network side. These two usually move in opposite directions.

Datacenter addresses are the fastest and cheapest end; for reading pages that require no sign-in they are more than sufficient in most setups. Static addresses hosted on a provider network offer a balanced middle ground for jobs involving sign-in, because they combine datacenter stability with a typical subscriber appearance. Real subscriber pools are the strongest option on the appearance side, but their speeds vary and the data charge is high.

Addresses exiting from an operator network are a separate category: it is normal on these networks for the same address to be shared by many real subscribers. The details of this structure are explained in the what is CGNAT article, and how addresses are classified in the ASN and IP reputation article.

The positions on the diagram are not a measurement but a relative placement used when making a decision. The way to find the right point for your own work is to try both types on the same query with a small sample and compare the results.