# VPN exit discipline — stop using one exit for everything > If your exchange login and your Tor session share an endpoint, you've built the bridge yourself. Rotate servers, separate contexts, assume everything connects eventually. Markdown twin of https://xmr.club/opsec/01-vpn-exit-discipline. CC-BY-4.0. Attribute "xmr.club". ## At a glance - Canonical: https://xmr.club/opsec/01-vpn-exit-discipline - Series: #OPSEC52 — weekly threat-model-first OPSEC cards - Week: 01 - Pillar: Network / VPN / Tor stack - Difficulty: beginner - Cost: $0 (with the VPN you already have) - Published: 2026-06-02 ## Body # OPSEC52 / Week 1 — VPN exit discipline > If your exchange login and your Tor session share an endpoint, you've built the bridge yourself. Rotate servers, separate contexts, assume everything connects eventually. **Threat model:** a correlator (chain analyst, ISP-level adversary, exchange compliance team) trying to link otherwise-unconnected accounts via shared exit IP. **Difficulty:** beginner · **Cost:** $0 (with the VPN you already have) · **Published:** 2026-06-02 --- ## The practice A VPN does two things, and most users only think about the first one. It hides your real IP from the destination, *and* it gives the destination a consistent exit IP for every connection you make through that tunnel. If you don't rotate, that second property leaks more than the first one protects. Concrete example: you log into your KYC exchange (Bybit, Kraken, whoever) from VPN exit `199.21.x.y` on a Tuesday. On Wednesday you open Tor Browser, also egressing the same VPN exit (because you're tunneling Tor over VPN for the "extra hop"). You sign into a privacy forum, send a Monero address to a buyer, do whatever you do in your private context. Exchange compliance + forum operator + your VPN provider's logs (if any) now share a partial timeline: same exit IP, two different identity contexts, hours apart. Correlation is trivially possible — even *if* the VPN provider itself never sees you. The adversary doesn't need to see you; they need to see the *pattern*. A VPN exit is a fingerprint. Re-using it across identity contexts is no different from re-using a username. **The fix is operational, not technical.** Most modern VPN clients let you select an exit server (or country) per profile. You don't need a different VPN provider for each context — you need a different *exit* per context. ## How to apply it today 1. **Map your identity contexts.** Three minimum: *KYC stack* (exchanges, banks, anything tied to your real name), *pseudonymous stack* (forums, X account, GitHub if pseudonymous), *no-identity stack* (Tor, privacy services, Monero swaps). Some users add a fourth for *research stack* (just reading, no logins). 2. **Assign an exit (or country) per context.** Mullvad, IVPN, Proton all let you bookmark a city or specific server. Pick three or four cities you'll consistently use. Don't share cities across contexts. 3. **Build the habit of switching when the context switches.** Easiest pattern: dedicated browser profiles tied to each context, each with the VPN profile pre-selected. Firefox containers, Brave profiles, even separate browser apps (Tor Browser for `no-identity`, Brave for `pseudonymous`, regular Chrome for `KYC` — the trust boundary doubles as the visual cue). 4. **Rotate within each context periodically.** Even within your `pseudonymous` stack, swap city every few weeks. Avoids long-term static fingerprinting. 5. **For Tor over VPN, pick a VPN exit you don't use anywhere else.** Tor's exit-IP rotation already handles destination-side; what matters is the entry-side (the IP your VPN gives Tor). That entry should never appear in any non-Tor connection. ## Common mistakes - **Setting "auto" or "fastest server" globally.** Convenience-first VPN routing picks the same exit repeatedly. Convenience kills exit discipline. - **Sharing exit across the KYC and pseudonymous stacks.** This is the most common slip. Once a single login crosses the streams, the rest of the stream is correlated forever. - **Trusting that "no-logs" means "no IP correlation possible."** No-logs is about the VPN provider's records. The destination still sees your exit IP. The correlation is downstream, not at the provider. - **Forgetting mobile.** Your phone connects to dozens of services. If it auto-VPNs through the same exit your laptop uses for Tor, you've linked them. Mobile needs its own context map. - **Using a "dedicated IP" for any pseudonymous identity.** Dedicated IPs are unique to you. They are the worst possible choice for OPSEC. ## See also **xmr.club listings (where these picks live):** - `/vpns/mullvad` — port-forwarding, anonymous payment, no email, per-server selection - `/vpns/ivpn` — open-source clients, multi-hop, anonymous payment - `/vpns/proton-vpn` — secure-core, P2P-friendly, less anonymous signup **Cited sources:** - @kyc_rip OPSEC tip (2026-05-29) — *"Stop using the same VPN exit for everything. If your exchange login and your Tor session share an endpoint, you've built the bridge yourself..."* — the seed post for this week - @DoingFedTime OPSEC365 (Sam Bent's ongoing daily series — worth subscribing for the daily dose) - PrivacyGuides — VPN section **Adjacent #OPSEC52 weeks (forthcoming):** - Week 2 — Tor entry-guard discipline (the entry-side mirror of this week's exit-side practice) - Week 3 — Browser containers and identity-context separation (the layer above network routing) --- *#OPSEC52 is xmr.club's weekly OPSEC series. Curated by [Cyber Satoshi](https://x.com/xbtoshi). Series index: [/opsec](https://xmr.club/opsec). Built as a complement to (not replacement for) Sam Bent's daily [#OPSEC365](https://x.com/DoingFedTime) — both worth following.* ## Related - HTML: https://xmr.club/opsec/01-vpn-exit-discipline - Series index: https://xmr.club/opsec - Twin index: https://xmr.club/llm/opsec.txt