Mixcloud Proxy: Long Shows, Rate Limits and Egress Reputation
On Mixcloud a show is not ten minutes long but usually one or two hours. That alone changes the proxy decision: you need a fixed egress, predictable bandwidth and a request pattern that respects the rate limit. This page covers those three topics in turn.
Public APIPagination and rate limit behaviour of the read endpoints.
02
Egress reputationThe impact of ASN classification and shared addresses.
03
Long streamingThe load that shows lasting several hours put on quota and connections.
04
Session managementSeparating the access token, cookies and device signals from one another.
Mixcloud hosts mixes and radio shows that run for hours in a single piece. This content format produces three concrete consequences on the proxy side: connections stay open for a long time, the volume of data transferred is high, and a session that breaks midway is far more annoying to the user than a short track cutting out.
The second topic is the public API. The platform offers read endpoints that return publicly available information about shows and users as JSON. These endpoints are suitable for programmatic access but, like every public service, they cap the number of requests. A script written without knowing how the limit behaves hits a wall on its first heavy run.
The third topic is identity: the web session carried by a cookie, the access token issued on behalf of the application, and the device signals produced by the browser are independent layers. A proxy touches only one of them, namely the address the request comes from.
Which endpoints does the client connect to?
When a show page opens, at least four different targets come into play. The first is the web interface itself: the HTML document, scripts and style files. The total size of these requests is small and one-off; once the page has loaded, they are not repeated.
The second is the public API. The interface pulls show lists and metadata as JSON; it is also what you talk to when you write your own script. The responses are compact, but the request count can climb quickly because of pagination.
The third is the audio stream. Long-form content is not downloaded as a single huge file; the player fetches it chunk by chunk as it progresses. That means new requests are opened at regular intervals throughout the session. The fourth is the cover and profile images; separate addresses are used for image delivery, and these requests carry no session information.
If your proxy rule does not cover all four of these targets, you end up with a hybrid picture: the interface comes from one country, the stream from another egress. If you are doing regional verification, that hybrid state invalidates your result outright.
DIAGRAMThe four targets a single show page connects to
You can scroll the diagram horizontally to inspect it
If all four targets do not fall within the same rule, the interface and the stream come from different egresses; regional verification then loses its meaning.
Public API endpoints and rate limit behaviour
The publicly accessible read endpoints are addressed via a username and a show identifier and return the response as JSON. Lists are paginated; after receiving one page of results, an additional request is needed to move to the next. If you want to scan hundreds of shows, that means hundreds of separate requests.
Public services cap the number of requests. The unit of measurement for the limit is usually the number of requests within a given time window, and the counter is generally tied to the client address or the application key. When the limit is exceeded, services return a rate limit response; the HTTP standard equivalent is 429 Too Many Requests but some services return 403 and report the wait time in the response body. Your client must handle both forms and respect the reported duration. A client that looks only at a single status code repeats the same request without ever noticing it has hit the limit and prolongs the situation; the correct behaviour is to log every unexpected error response together with its body and decide from there whether it is a rate limit.
The practical rule that follows is simple: slowing down the request is a more correct solution than changing the address. If the counter works per address, cycling through a large number of addresses means going around the limit, and that may conflict with the service's terms of use. Instead, reduce concurrency, put a wait between requests, and cache the responses you receive locally so you do not request the same record twice.
Another detail is the cacheability of responses. Show metadata does not change often; keeping the record locally and only checking for changes, instead of requesting it again every hour, noticeably reduces the request count. If the server supports conditional requests, an unchanged record returns a very small response, preserving both the counter and the bandwidth.
Note
The trio of pagination, conditional requests and a local cache reduces the request count substantially in most setups. For a read design at scale, see the web scraping proxy page, and for how to read the parallel request limit, see concurrent connection limit article.
Access token, cookies and device signals
Calls acting on behalf of an account are authorised with an access token. The token is tied to the application and the account, not to the egress address. That is why changing the proxy does not invalidate the token, and refreshing the token does not change the egress. The two mechanisms are independent and are tested separately when troubleshooting.
On the browser side, identity is carried by cookies and cookies are written to the profile. Using a single egress per profile is recommended, because it reduces the number of variables when troubleshooting. Using the same profile with egresses in different countries during the day makes it impossible to interpret the interface's regional behaviour.
The third layer is the one the proxy never touches: browser version, time zone, language preference, screen dimensions and similar signals. If you move your egress to Singapore but leave your time zone local, the result is an inconsistent picture. How this layer is aligned is covered in the antidetect browsers and proxies article. In practice the work is sequential: first choose the egress country, then set the browser's time zone and language preference to the same country, and sign in last.
Test the token and the cookie separately; do not change both at once.
Keep to one egress and one country per profile.
Keep the time zone and language preference consistent with the egress country.
Do not embed authorisation details in the script; keep them in environment variables.
Which egress fits which job?
There are three separate jobs on this platform, and all three call for different characteristics. Reading publicly available metadata from the public API calls for speed and low cost; listening to a long show end to end calls for a stable line with plenty of capacity; signing in with an account and managing content calls for a consistent, fixed address.
Datacenter addresses are the most efficient option for the first job: connection setup is fast, transfer capacity is high and the cost is low. They also work without issue for long stream listening; their real limits show in scenarios where you sign in, because which autonomous system the address belongs to is plainly visible.
Fixed addresses hosted on a provider network and genuine subscriber pools give the most consistent results in session-based use. Their data charges are higher, so using them to listen to streams for hours is expensive. Carrier network addresses make sense where mobile behaviour needs to be verified; they are not economical for high-volume reading.
The matrix below pairs these three jobs with three egress families. If your provider offers more than one type, splitting the work by type is both cheaper and more stable than making one type do everything.
DIAGRAMSuitability of egress families by job type
You can scroll the diagram horizontally to inspect it
The matrix is not an absolute ranking but a starting point for splitting the work by type; you need to verify it with your own measurements.
An egress plan for long shows and API work
Rather than loading metadata reading and hours-long stream listening onto the same plan, splitting the work by type is usually more economical.
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.
Address reputation, autonomous systems and shared egresses
When a request reaches a server, the first piece of information the server has is the source address. That address belongs to an autonomous system (ASN), and the type of the autonomous system — datacenter, fixed-line provider, mobile carrier — can be read from public records. The classification does not produce a decision on its own, but it is an input to the behavioural assessment. The detail ASN and IP reputation article.
The second factor is sharing. How many people use the same address affects how behaviour from that address looks. On carrier networks it is normal for a large number of real subscribers to share a single public address; this mechanism is called carrier-grade address translation (CGNAT), and many subscribers can sit behind a single public address, which is why behaviour on carrier addresses cannot be attributed to a single user. In a datacenter, the number of users sharing the same address depends on your provider's product definition.
The third factor is diversity. Hundreds of addresses taken from a single subnet are more fragile than the same number spread across different subnets; when a subnet is assessed as a block, the entire pool is affected at once. The background to this topic is in the subnet diversity article.
The fourth factor is time. An address's history comes along with you the moment you take it over; a second-hand address may have been affected by its previous user's behaviour. That is why a provider's address refresh policy matters as much as price. You cannot know the history precisely, but in a regularly refreshed pool this effect is short-lived.
The practical conclusion: in a long-running monitoring setup, how you use the address is as decisive as how "clean" it is. Use at a reasonable rate, in a predictable pattern and limited to publicly accessible areas works without trouble even on the most ordinary address.
Bandwidth, buffering and dropouts on long shows
Listening to a two-hour show end to end carries far more data than browsing dozens of pages over the same period. The amount transferred depends on the chosen audio quality and the length of the show; on an egress billed by data, that is a direct line item on the bill. Keeping long listening sessions off the proxy and monitoring and verification work on it is the right balance for most teams.
The second topic is the lifetime of the connection. The player requests new chunks as it progresses; if the proxy in between closes the connection after a certain period of inactivity, you will see dropouts during playback. How keep-alive and pool behaviour are configured is keep-alive and connection pooling article.
Beyond that, the number of concurrent listening sessions must also be taken into account. Starting many long streams at once from the same egress strains both the provider's connection limit and the capacity of the line; the symptom is usually not a full disconnection but a drop in quality or a buffer that keeps emptying. Work out in advance how many concurrent streams you need and choose your plan accordingly.
The third topic is latency, and there is a common misconception here: using a proxy does not speed up the connection. Because a hop is added in between, total round-trip time usually gets longer; if you have chosen an address exiting in a distant country, the increase becomes noticeable. In stream listening this increase mostly goes unnoticed, because the player buffers ahead. Where it is noticed is page browsing and API calls. You can take your own measurement with a ping test, and the conceptual background proxy latency article.
Where do you define the proxy?
Where the rule is written determines which traffic gets routed. The broadest scope is the operating system setting: every application on the machine is affected, no request stays outside, but you cannot do proxy-free work on the same machine. For setup steps the Windows proxy settings article is enough; on macOS the setting follows the same logic, defined on the proxy tab of the network interface and ticked separately per protocol.
One level down is the browser profile. Only the tabs in that profile go out via the proxy; your other work is unaffected. This is the most practical method for monitoring and regional verification work, because you can point several profiles on the same machine at different countries.
The third level is application-based rules: only the traffic of selected processes is routed. For clients working at socket level, SOCKS5 is more flexible for this job, because it carries the TCP connection as it is and does not require the application to speak HTTP; on the other hand, support varies from application to application, and if there is no SOCKS option on the settings screen, routing cannot be done.
The outermost level is a gateway setup: a rule defined on the router covers every device on the network. It is useful in corporate scenarios but makes it harder to distinguish individual devices; when a problem arises, you need to keep separate logs on the network side to see which device made the request.
DIAGRAMThe four levels at which a proxy rule can be written
You can scroll the diagram horizontally to inspect it
As you move from top to bottom, the scope narrows and control increases; for monitoring work the browser profile is usually enough.
What to test after setup and common mistakes
When setup is complete, four things are tested in order. Verify that the egress really changed with my IP address the tool, that domain resolution is being done on the proxy side with DNS leak test , that the browser is not leaking the real address with a WebRTC leak test, and that the egress is alive with a proxy check tool.
Symptom
Possible cause
Recommended step
Playback stops every few minutes
The connection is being closed while idle
Raise the keep-alive setting and the timeout duration
The script starts receiving a rate limit response after a while (429 or 403)
The rate limit has been reached
Respect the reported wait time, reduce concurrency, cache the results
The interface goes via the proxy, the audio goes out directly
The rule only covers the main domain
Widen the rule so that it also covers the media addresses
An authorised call is being rejected
The token has been revoked or the scope is insufficient
Verify the token's validity and scope; test this before changing the proxy
The proxy connection cannot be established
Missing credentials or IP authorisation
Compare the username/password against the allowed address list
Page browsing has noticeably slowed down
The exit is geographically distant
Choose a closer location; a proxy does not reduce latency, it increases it
The last line is worth stressing once more: a proxy does not lower your ping. The only exception is the rare case where the default route is convoluted and the proxy happens to take a shorter path; this is not a rule and cannot be guaranteed.
If you are working with free lists, most of the dropouts come from the address itself. An up-to-date free proxy list is handy for experiments, but work that demands continuity, such as long stream listening, needs a stable egress.
Using a proxy with Mixcloud: frequently asked questions
01I hit a rate limit while reading data from the public API — what should I do?
The right fix is to slow down your requests. If the server returns a rate limit response, respect the wait time it reports (in a header or in the response body), reduce concurrency, and cache the responses you receive locally so you do not request the same record again. Changing addresses to get around the limit may conflict with the service's terms.
02Why does audio cut out during playback?
Long-form content is fetched chunk by chunk; if the proxy in between closes the connection while idle, the request for the next chunk fails. Raise the keep-alive duration and use an egress with sufficient capacity. The same symptom is also seen on shared addresses whose capacity is exhausted.
03Does my access token break when I change proxies?
No. The token is tied to the application and the account, not to the egress address. If an authorised call is being rejected, first verify that the token is still valid and has the scope the request requires; changing the proxy does not fix an error of that kind, it only increases the number of variables.
04Is listening to long shows over a proxy expensive?
On egresses billed by data, yes. A stream lasting several hours carries many times more data than page browsing over the same period. The common approach is to run monitoring and verification tasks over the proxy and leave long listening sessions to the direct connection.
05Which egress type is most efficient for public API reads?
A datacenter proxy is the most efficient option for this job in most setups: connection setup is fast, capacity is high and the cost is low. What matters is not the data charge but the request count and the concurrency limit.
06A show will not play in my country — will a proxy fix it?
Some shows may not be offered in certain regions for licensing reasons. Another egress country can make such a difference visible, but the restriction placed by the rights holder and the platform's terms of use are binding. Keep that limit in mind when making comparisons for verification purposes.
07Page browsing has slowed down — should I blame the proxy?
Most likely yes, and this is an expected outcome. A proxy adds an extra hop to the traffic; total round-trip time usually gets longer, not shorter. Choosing a geographically closer location reduces the difference. Take your own measurement with a ping test and compare it with the value before setup.
08What should I watch out for when connecting from a corporate network?
Corporate inspection proxies can open and re-sign traffic; in that case clients performing certificate validation may refuse to connect. The details are in the TLS certificate validation article. Compliance with company policy and the platform's terms of use is also mandatory.