Bandcamp Proxy: Collection Sessions and Choosing an Exit IP

Thinking of Bandcamp as a single website is the most common mistake in proxy setup. The artist page HTML comes from one place, the cover images and preview stream from another host, and the download link for a file you purchased over a third path. If your proxy rule does not cover all of these addresses, the page loads without a hitch but the player stays silent or the download breaks off halfway.

The second source of confusion is identity. Your collection, purchase history and download rights are tied to your account; the exit IP does not own them. A proxy changes the route, not the identity. Every setup made without accepting that distinction looks for the fault in the wrong place.

The sections below cover, in order: which hosts the requests are distributed across, how cookies and device identity relate to the session, the coverage gap between the mobile app and the browser, bandwidth cost, choosing an exit type, and how to run public catalog research with discipline.

Which hosts do requests go to when a Bandcamp page loads?

When you open an artist page, the browser first makes an HTTPS request to the main domain. If that request goes through the proxy, the address the server sees is the proxy exit. The response body is nothing but HTML and scripts; it is small, so what determines how fast the first load feels is not the number of bytes downloaded but the round-trip time of this request.

Once the page has rendered, the second wave begins. Cover images, thumbnails and the audio segments the player pulls come from a separate content delivery host whose name differs from the main domain. If you wrote a rule in your browser extension for only one domain, the media requests fall outside the rule and go out directly. The result looks like this: the page comes from the new country and the audio from the old exit.

The third layer is the post-purchase download. File links are usually generated with a time limit and tied to your account. If the session in which you obtained the link and the connection from which you start the download come from different exits, some setups reject the transfer or ask for verification again. Finishing the whole job on a single exit removes this friction.

Collection sessions: cookies, device fingerprint and exit address

Your session is carried by a cookie, and that cookie is written to the browser profile, not to the proxy server. Changing the proxy does not delete the cookie, and deleting the cookie does not change the exit. The two mechanisms are independent and should be handled separately when troubleshooting.

A change of exit address does not by itself drop the session. What creates friction is sudden, large jumps: the same account appearing from countries far apart within a few minutes forms an inconsistent picture and can lead to additional verification. Use a fixed exit for every signed-in job; for the conceptual background, the sticky session article is useful. Rotating exits, on the other hand, are suitable only for reads that carry no session; an address changing on its own in a signed-in tab makes the account appear from another country in the middle of the job.

The third component is device identity. Language preference, time zone, screen dimensions, installed fonts and browser version are signals independent of the IP, and the proxy touches none of them. If your exit is in Germany while your browser's time zone stays Europe/Istanbul, the inconsistency persists. How this layer is aligned is covered in antidetect browsers and proxies is explained in that article.

In teamwork these three layers are often mixed up. Two people connecting to the same account from two different offices naturally appear from two different exits, and on the session side that is ordinary; what creates friction is not the number of people but the same session moving at short intervals. Defining a shared exit and having everyone connect through it produces a more consistent picture than giving each user a separate address.

• Use one browser profile per account, and one exit per profile.
• Keep the exit country the same as the account's usual country of use.
• Do not stack a VPN and a proxy on top of each other; you will not be able to isolate the source of an error.
• Once the session is open, do not change the exit until the job is done.

The coverage gap between the mobile app and the browser

On iOS and Android the proxy is defined in the Wi-Fi network's detail screen, and that setting applies only to that network. The moment the device falls back to cellular data the rule is out of play; the user does not notice, because the app keeps working, just from a different exit. For step-by-step setup, the Android proxy settings article is enough; the flow is the same on iOS, where the setting is again in the manual configuration section of the detail screen for the network you are connected to, and is disabled automatically when you leave that network.

The second limit is whether the app respects the system setting. Some clients build their own connection stack and use only the direct exit. In that case the interface opens and the listings load, but the audio stream goes around the proxy. In the web client, all requests pass through the browser's network layer, so coverage is predictable; that is why running tests and verification in the browser produces fewer surprises.

The third difference is the certificate. On an HTTPS connection the proxy opens a tunnel with CONNECT and carries the encrypted bytes; it cannot read the content and sees only which host you connect to and how many bytes flow. With corporate inspection proxies that decrypt and re-encrypt traffic, mobile apps may refuse to connect at all because of certificate pinning; the details of this topic are in TLS certificate validation article.

Where does bandwidth go in a listening and purchasing session?

Residential and mobile exits are mostly billed by data transferred. That makes "which request am I sending through the proxy" not a technical preference but a direct cost item. The page HTML and scripts are a small slice of the total; cover images are moderate, and the preview stream takes a markedly larger share.

The heaviest item is downloading the file you purchased. Lossless formats produce files many times larger than the lossy versions of the same recording; downloading a single album in lossless carries more data than hours of page browsing. The weights in the next diagram represent this ordering; they are not measured values.

The practical approach is to split the work in two: small requests such as verifying regional appearance, browsing the catalog and reading price and format options go through the proxy, while large file transfers are made over a direct connection unless there is a regional restriction. To do the math, the method in the bandwidth calculation article is enough: measure the average size of a single browsing session, multiply it by the number of sessions per day, and compare the result with your plan's quota. What burns through the quota mid-month is usually not browsing but a single unplanned large download.

Another way to lower the cost per connection is to reduce renegotiated handshakes. Using persistent connections (keep-alive) removes the TCP and TLS setup overhead on back-to-back requests to the same exit; on pages where many small requests such as cover images arrive one after another, the difference is clearly noticeable.