Once traffic goes through a gateway, changing your address is a credentials question, not a networking one — you ask for a different exit and the next request uses it. The harder half is everything the site already stored about you, which a new address does not touch.
Two addresses exist in this picture. Your own, assigned by your ISP or router, which the proxy does not alter at all — it is still the address your machine uses to reach the gateway. And the exit address, the one the destination site sees, which belongs to whichever node in the provider's pool carried your request. Changing your IP “after setting up a proxy” means changing the second one.
That matters because none of the usual advice applies. You do not renew a DHCP lease, reboot a router,
release and renew anything, or reconnect a modem. The gateway decides which exit you leave from, and you
influence that decision through the credentials you present. On PyProxy the endpoint never changes —
gw.pyproxy.com on port 1111 — and every option travels in the username.
There are two behaviours, and which one you are getting is a property of how you authenticate.
With a plain gateway username and no session parameter, each connection is assigned an exit independently. The address may differ on every single request:
curl -x http://USERNAME:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip curl -x http://USERNAME:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip
Run those two lines and you will usually see two different answers. Nothing was changed between them: rotation is the default behaviour, not an action you trigger. This suits high-volume, stateless work — independent page fetches, price checks, availability polling — where each request stands alone.
It is actively wrong for anything with state. A login flow, a multi-step form, a cart, or any site that binds a session to the address it was created from will break when the second request arrives from another country. If you have set up a proxy and are being logged out constantly, this is why.
A session token added to the gateway username tells the provider to keep sending you out through the
same exit. On PyProxy that lasts about thirty minutes, after which a fresh address is assigned. The token
is an arbitrary string you choose, so different tokens mean different simultaneous sessions, each pinned
to its own address, all through the same endpoint and the same credentials. The parameter is the word session followed by your token.
Given that, changing your address becomes deliberate rather than automatic, and there are three ways to do it:
In code, the practical shape is to generate a token per worker or per logical identity and keep it for as long as that identity needs to look continuous:
import requests, uuid
token = uuid.uuid4().hex[:8] # one identity
user = f"USERNAME-country-us-session-{token}"
px = {"http": f"http://{user}:PASSWORD@gw.pyproxy.com:1111",
"https": f"http://{user}:PASSWORD@gw.pyproxy.com:1111"}
print(requests.get("https://httpbin.org/ip", proxies=px, timeout=20).json())
# change `token` to get a different exit address
Note the scheme is http:// on both entries. PyProxy residential is HTTP and HTTPS only
and does not support SOCKS5, so a client configured for a SOCKS endpoint will simply fail to connect —
a mistake easily misread as “the proxy stopped working”.
Rotation and targeting are separate controls. The username carries the location as well, so
USERNAME-country-us asks for a United States exit, and region or city keywords narrow it
further where your dashboard offers them. Combine them with a session token and you get a stable address
in a chosen place; combine a country with no token and you get rotation confined to that country.
curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip curl -x http://USERNAME-country-de:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip
Two points people trip over. Narrowing the location narrows the pool, so a tight region filter rotates through fewer addresses and repeats sooner than a whole-country filter. And the geolocation a site shows you comes from its own IP database, which can lag behind reality, so an exit may occasionally be described differently from the country you requested. Verify against the lookup your target actually uses rather than a random checker page.
This is the part that makes people think rotation is broken. You confirmed a new exit, reloaded, and the site greets you by name, or shows the same block, or the same prices. The address changed; the identity did not.
Everything below lives on your machine and survives a new exit address untouched:
User-Agent — plus
timezone and Accept-Language, which keep reporting your real setup and will contradict a
foreign exit.So when the goal is to appear as a different visitor, changing the address is one of several steps, not the step. Use a clean browser profile or a container per identity, or clear site data before switching; in automation, use a new cookie jar per session token so the two rotate together. The pairing is the whole trick: one token, one cookie jar, one identity. Rotating the address while keeping the cookie jar achieves nothing at all, and rotating the cookie jar while keeping one address is only marginally better.
The reverse error is just as common. If you are only changing the address to reach content restricted by country, you do not need any of this — pick the country, keep one session, and leave your cookies alone.
Check from the client that does the real work, not from a browser that may be configured differently:
curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 -s https://ipinfo.io/json
Two different answers to the first line across runs means rotation is live. An identical answer means you are pinned by a session token, which is correct if you asked for one. If a browser shows your real address while curl shows the exit, the browser is bypassing the proxy — check its proxy settings and disable WebRTC, which can reveal your real address over a separate UDP path. And if traffic works but the country is wrong, the exit is in the pool you asked for and a database disagrees; test against the site you care about before changing anything.
All of this runs on PyProxy's per-gigabyte balance — residential, ISP, mobile and datacenter on one account, residential from $0.67/GB, and traffic that does not expire, so an idle rotation setup costs nothing while it sits there.
It depends which mode you are in. On a rotating gateway the next request simply goes out through a different exit, so there is nothing to do. On a sticky session the address is pinned by a token carried in the proxy username, so you change or remove that token and the following request leaves from a new address. Nothing needs restarting and no setting in the operating system changes.
With a PyProxy session token an exit is held for about thirty minutes, and it can end sooner if the underlying residential connection goes away, which is normal for real consumer lines. Without a token the gateway rotates per request, so the address may differ every time.
Because the address is only one signal. Cookies, local storage, IndexedDB and a logged-in server-side session identify you directly and travel with the browser, not with the connection. A new exit address plus the old cookie jar is the same visitor from a slightly different place.
Request an echo endpoint twice through the proxy and compare the answers, for example curl -x http://USERNAME:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip. Run it from the same client that makes your real requests, since a browser or another tool may be using a different configuration entirely.