Cookie
A small piece of state a site stores in your client and reads back on every request, the mechanism behind logins, consent banners and a lot of bot scoring.
HTTP forgets you between requests. Every fetch arrives as a stranger, which is unworkable for anything involving a login, a cart or a preference, so the cookie exists to staple memory onto a stateless protocol: the server sends a Set-Cookie line with a name and value, the client stores it, and every later request to that site carries it back in the Cookie header. The site is not recognising you. It is reading its own note out of your hand.
The attributes on that note decide its reach. A cookie is scoped to a domain and path, expires either when the session ends or at a set date, and carries flags that restrict it to encrypted connections or hide it from page scripts. First-party cookies belong to the site you are visiting; third-party cookies belong to someone else's infrastructure embedded in the page, the variety browsers have spent recent years strangling for privacy reasons. The login sessions and regional preferences that matter for proxy work are almost all first-party.
For anyone rotating addresses, the cookie jar is where identity actually lives. A login is a cookie; present it and you are that account, from any address, which is why moving between exits does not log you out by itself, and also why a stolen cookie is a stolen session. The corollary deserves equal weight: rotating your IP while carrying the same cookies has not made you a new visitor. The site's note is still in your hand, and it says who you were yesterday.
Detection reads the jar in subtler ways too. A visitor with no cookies at all, ever, on every request, is a recognisable automation profile in itself: real browsers accumulate consent choices, session tokens and preference state within minutes of normal use. Some defences plant a cookie on the first response and simply check whether it comes back on the second, a free test that a naive script fails. And a jar whose contents describe one long session while the address hops continents describes an implausible traveller.
So the practical craft is jar management, not jar avoidance. Persist cookies per identity and keep each identity's jar on a consistent exit through a sticky session. Accept and return what a site sets during a flow. Clear the jar when you intend to be a new visitor, and keep it when you intend to be a returning one. The failure mode in both directions is the same: state and address telling different stories.
Frequently asked questions
Do cookies still work through a proxy?
Fully. Cookies live in your client and travel inside your requests, and a proxy relays them like any other traffic. That cuts both ways: your session survives an address change because the cookie is what identifies you, and your rotation achieves less than expected for the same reason. The proxy changes where you appear from, never what your requests carry.
Should my scraper accept cookies?
For any multi-step flow, yes, managed deliberately. Sites set state mid-flow and expect it returned, and some defences test exactly that on the second request. A client that accepts nothing fails those flows and matches a known automation profile. Keep a jar per identity, tie each identity to a consistent exit, and reset the jar only when you genuinely mean to arrive fresh.
Does clearing cookies make me anonymous to a site?
It removes the site's stored note about you, which is one identifier of several. Your address, TLS fingerprint and browser fingerprint remain, and a site correlating them can quietly re-associate the new empty jar with the old visitor. Cookie clearing is part of presenting a fresh identity; alone, it mostly signals that state vanished while everything else persisted.
Why did my login survive an IP change but fail a country change?
The session cookie made the login portable: presenting it is what authenticates you, from anywhere. What tripped the second case is risk scoring on top: an account whose session jumps to another country mid-use matches a stolen-cookie pattern, so the site invalidated the session or demanded re-verification. Keeping account work on a stable exit avoids triggering exactly that check.
Back to the full glossary.