Proxy Sessions and Cookies: Keep Routing and Browser State Separate

A proxy session controls a requested network route; cookies hold state that a website and client exchange. Reusing a proxy session does not preserve cookies for you, and changing the exit IP does not clear a browser's stored state. Reliable browser jobs need separate ownership rules for both.

This matters when a team runs regional QA, public catalog observations, or another authorized sequence in several workers. A page can load successfully while carrying the wrong market preference from a previous job. The route may be correct and the observation still be unsuitable for the comparison.

Two session identifiers can describe different things

A proxy provider may use a session identifier to request continuity of an exit assignment. A website may issue a different session identifier in a cookie to recognize client state. Similar terminology does not make these identifiers interchangeable.

The MDN cookie guide explains that servers can set cookies and clients can return applicable cookies with later requests. Cookie scope and lifetime follow cookie rules, not the proxy's rotation schedule. A website can also use other storage or server-side state.

On Magnetic Proxy, session routing options belong in the documented proxy configuration. Cookies, browser contexts, account state, and application storage remain responsibilities of the client. See the current proxy documentation for the supported routing parameters.

Give each independent job a clear owner

Define a job as the smallest sequence whose observations must share context. Assign that job a routing profile and a separate browser context or cookie store where your client supports it. Keep the association explicit so another worker cannot accidentally reuse the first job's preferences.

• Job identity: which business observation is being collected.
• Routing identity: the proxy profile and intended session behavior.
• Client-state identity: the browser context or cookie-store reference.
• Expected state: the requested market, selected options, and authorized account context if one is required.

These are suggested fields for your application, not a claim that Magnetic Proxy creates or stores them. Avoid copying raw cookies, passwords, or authenticated proxy URLs into the job record. Store references to secrets and restrict access to any diagnostic material that can identify a session.

A regional comparison that can go wrong

Imagine a test selects a shipping market in a storefront and records an offer. A second job changes the proxy route but reuses the first browser context. The storefront may retain the earlier shipping preference in client or server state. The second price is then not necessarily an observation of the second market.

Do not conclude that the proxy failed merely because the currency stayed the same. Inspect the requested route, observed exit, selected shipping market, and page state separately. Likewise, a changed currency does not prove the requested exit location was used.

For an independent market observation, start with the deliberately chosen state for that job, establish the market through the site's normal controls, and verify the result before recording it. For a dependent multi-step journey, keep the intended state together and detect changes rather than silently mixing observations.

Decide what resets after a failure

Resetting everything can discard useful evidence; resetting nothing can carry stale state forward. Decide according to the failed layer:

• Route changed: check whether the task requires continuity. If it does, mark the sequence incomplete and restart at the documented boundary.
• Website session expired: use the site's supported recovery or authentication flow. Reusing a proxy identifier does not restore that session.
• Unexpected preference persisted: inspect client and server state. A new exit alone is not a clean-browser operation.
• Access was denied: inspect the response and allowed workflow. Do not treat cookie deletion or IP rotation as permission to proceed.

Keep evidence of the failed attempt separate from the restarted attempt. Give the replacement its own observation identifier so partially collected fields are not merged into a fictitious successful journey.

Test isolation before running parallel workers

Use a small controlled test with a destination you are authorized to inspect. Start two independent jobs with distinct client-state stores. Set a harmless preference in one, then confirm whether the other remains independent. Run the test in the actual client, because a browser profile and a standalone HTTP library do not necessarily share cookie handling.

Next test your restart policy: expire or reset a test session through supported controls and inspect whether the application records an incomplete attempt. Validate observable behavior rather than assuming that creating another object in code isolated every layer.

The sticky versus rotating guide helps select routing behavior, while proxy concurrency covers scheduling limits. Once state ownership is explicit, choose a Web Scraping Capsule for the routing needs of the workload and keep browser-state management in your application.