DEV Community: Mak Atomic

How to Test Geo-Dependent Features in Your App

Mak Atomic — Tue, 27 Oct 2026 09:38:51 +0000

Your app shows prices in euros to visitors from Germany, hides a feature in one country, and shows a cookie banner only in the EU. You tested it by overriding the location in Chrome DevTools. It passed. In production, a user in Berlin still sees dollars.

I've hit this pattern more than once, and the cause is always the same: the DevTools override changes one signal of location, and the server reads a different one. Below is the checklist I use now.

Disclosure: I work on Atomic VPN. The method works with any VPN or proxy that has exit servers in the countries you need, and I say where a VPN is the wrong tool at the end.

The four signals that mean "where is this user"

Signal	Who reads it	How I fake it
Geolocation API (`navigator.geolocation`)	Frontend JS, after permission	DevTools Sensors, Playwright `geolocation`
Client IP	Server, CDN, WAF	VPN, proxy
`Accept-Language`, `Intl` locale, timezone	Server and frontend	Playwright `locale`, `timezoneId`
DNS resolver location	CDNs that route by resolver	A VPN with its own DNS, or change the resolver

Most "works on my machine" geo bugs come from testing one row and shipping logic that depends on another.

What the DevTools override actually does

The Sensors panel lets you pick a preset city, enter coordinates, or simulate "location unavailable". It overrides what the page gets from the Geolocation API. That's right for a store locator or a weather widget.

It does not change the IP address of your requests. If your backend calls a GeoIP database, reads the CF-IPCountry header that Cloudflare adds, or your CDN applies country rules, all of them still see your real IP.

Step 1: check what the internet thinks my location is

Before any test, I check the exit IP and country. Cloudflare exposes a plain-text endpoint:

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc|colo)='

You get three lines: your IP, a two-letter country code (loc), and the Cloudflare data center that served you (colo). Run it with the VPN off, then on. If loc doesn't change, the VPN isn't routing that traffic. That happens with split tunneling or a proxy set only in the browser.

Step 2: route traffic through the target country

I connect to a server in the country I want to test. When the app has region-specific rules, such as state-level restrictions in the US, I pick a location closest to that region. Then I run the curl check again and confirm loc.

Two things I verify at this point:

The country matches in more than one database. IP geolocation is an estimate. Cloudflare's docs say nothing inherently binds an IP address to a country, and providers can disagree. If your app uses MaxMind and your CDN uses its own data, check both.
DNS follows the tunnel. If the VPN doesn't handle DNS, your resolver may still sit in your home country, and a CDN that routes by resolver will send you to the wrong edge.

Step 3: add the other signals with Playwright

An IP in Germany with a browser set to US English and a New York timezone is not a German user. It's a user your own analytics will flag as odd. Playwright sets the rest in code:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({
  locale: 'de-DE',
  timezoneId: 'Europe/Berlin',
  geolocation: { latitude: 52.52, longitude: 13.405 },
  permissions: ['geolocation'],
});

const page = await context.newPage();
await page.goto('https://your-app.example/pricing');
console.log(await page.locator('[data-test=price]').innerText());
await browser.close();

I run this while the VPN is connected to Germany. The IP, locale, timezone and coordinates now describe the same person.

I keep one script per target market and the expected values next to it. A short matrix is enough:

Market	Expected currency	Consent banner	Blocked features
DE	EUR	yes	none
US-CA	USD	yes (state privacy notice)	none
JP	JPY	no	feature X

What breaks, and why

The VPN IP is classed as a datacenter or VPN address. Some services detect that and show a CAPTCHA, a paywall variant or a block page. That says something real about how those users see your app, but it isn't the same as a residential visitor.
Shared IPs trigger rate limits. Many VPN users share an exit IP. A login form with aggressive IP throttling can lock you out mid-test.
Caches hide the bug. A CDN may serve you a cached "German" page, or serve your cached page to the next tester. Add a cache-busting query string, or send Cache-Control: no-cache.
Cookies carry state. A country=US cookie from the first run beats the IP in the second. Playwright starts every context clean, which is why I use it for this.
IPv6 leaks the real location. If the VPN tunnels only IPv4 and your network has IPv6, the app may see your real IPv6 address. Run curl -6 https://www.cloudflare.com/cdn-cgi/trace and see whether it answers.

How I run this with Atomic VPN

Here's the workflow:

Open the Atomic VPN homepage. It shows your current IP, city, ISP and DNS, so I get a "before" reading without leaving the browser.
Connect in the app and pick the country (the app lists locations by country and city, with ping next to each).
Reload the page and compare the "after" reading, then run the curl trace from Step 1 to confirm loc.
Run the Playwright script for that market.

Why this works for me: there are 6,500+ servers in 88+ countries, so a new market is a click rather than a new proxy contract. The WireGuard protocol is the default, so connecting and switching countries is quick. If you're on a restrictive network that blocks UDP, there's an OpenVPN option over TCP 443.

Any VPN with similar coverage does the same job. If you need exit nodes in only one or two countries, a cheap VPS you control may be simpler (I wrote about that trade-off in Self-Hosted WireGuard vs a VPN Service).

Where a VPN is the wrong tool

CI. Pipelines need deterministic, scriptable exits. Use a proxy service with an API or geo-distributed runners, not a desktop VPN client.
Compliance-critical rules. Cloudflare's docs advise against using IP geolocation as the sole signal when location must be precise, such as state-based access restrictions. I test that logic with a VPN, but I design it with more than the IP.
Other people's services. Test your own app. Using a VPN to get around a third party's regional restrictions may break their terms, and in some places the law.

FAQ

Does Chrome DevTools location override change my IP?
No. It changes what the Geolocation API returns to the page. Server-side checks based on your IP see your real address.

Why does my app still show the wrong currency after I connect a VPN?
Usually a cookie, a cached response, or a second signal (locale, account country) that outranks the IP. Clear storage, use a fresh browser context, and check which signal your pricing logic reads first.

Can I test geo-blocking in CI with a VPN?
Not reliably. Use a proxy service with an API, or runners in the target regions.

Is IP geolocation accurate?
At country level, mostly. At city level it varies by provider and drifts as IP ranges change hands. Cloudflare states it can't guarantee its data matches other providers.

Why do some sites block my VPN exit IP?
Many services keep lists of datacenter and VPN ranges. The IP is shared and not residential, so it gets caught.

Is it legal to use a VPN to test my own app?
Using a VPN is legal in most countries. Check local rules, and don't use it to bypass restrictions on services you don't own.

Sources

Fake Wi-Fi in the Sky: What an Evil Twin Can See and What HTTPS Still Protects

Mak Atomic — Fri, 23 Oct 2026 11:25:29 +0000

In April 2024, airline staff in Australia noticed a suspicious Wi-Fi network on a domestic flight. They reported it. When the flight landed in Perth, Australian Federal Police searched a passenger's bags and seized a portable wireless access device, a laptop and a phone. BleepingComputer reported on the charges in July 2024: the man was accused of running fake access points on flights and at the Perth, Melbourne and Adelaide airports, with the networks leading to fake login pages that asked for email or social media credentials. Bitdefender covered the same case. The allegations were not proven at the time of those reports.

The trick has a name: the evil twin. This post explains why it works, what the person running one can and cannot read, and three checks that take less time than boarding.

TL;DR

An evil twin is an access point that copies a real network's name. Your device cannot tell them apart by name alone.

HTTPS still protects page content on a fake network. What leaks is the site list, plain HTTP, and anything you type into a fake login page.

A VPN hides your traffic from the access point, but it cannot save a password you type into the attacker's portal.

Why the copy works

A Wi-Fi network is announced by a name (SSID). Your phone remembers names it has joined before and reconnects automatically. On an open network, such as airport or in-flight Wi-Fi, there is no password the access point must prove it knows, so a second access point with the same name and a stronger signal looks identical to the original.

Then comes the captive portal. Most public networks redirect you to a page where you accept terms or sign in. That page is also the attacker's best tool: it is a normal thing to see, and it asks for credentials. In the Australian case, that is how the alleged login-page theft was supposed to work.

What the person running the fake network sees

Assume you joined it. The operator is now your network. They get:

Every plain HTTP request in full: URL, headers, cookies, form fields.
Your DNS queries, so a list of the hostnames you look up.
The hostname of every HTTPS site, because it travels in the clear in the TLS handshake (a 15-line Python script can show you this on your own machine: build a TLS ClientHello offline and look for the hostname in the raw bytes).
Destination IPs and traffic volume.
Whatever you type into a page they serve you.

What they do not get: the content of pages loaded over HTTPS with a valid certificate. They cannot read your bank's page or your mail over a TLS connection unless your device accepts a forged certificate, and modern browsers show a loud warning when that happens.

HSTS closes the downgrade trick

A common attack on an open network is to strip HTTPS: you type bank.com, the attacker answers on plain HTTP and proxies the rest. HSTS, defined in RFC 6797, is the countermeasure. A site sends a header telling the browser to use HTTPS only for a set time. After that visit, the browser refuses plain HTTP for that site, even if you type http://. First visits and sites without HSTS remain exposed, which is why "just look for the padlock" is only half the advice.

Three checks for a network you do not control

1. Is the portal the real portal?

Before you type anything into a login page, look at the address bar. A portal you reached by redirect should still use HTTPS with a certificate that matches the airline's or airport's domain. If the page asks for your email password or a social login to get online, close it. A genuine Wi-Fi portal needs, at most, an email address, a booking reference or a payment on the operator's own domain.

2. Is plain HTTP being tampered with?

neverssl.com is a site that stays on HTTP on purpose, so captive portals can intercept it. Fetch it and look at the answer:

curl -sI http://neverssl.com | head -n 5

On an ordinary network you get HTTP/1.1 200 OK with the site's own headers (mine returned Server: Apache/2.4.68). On a network that intercepts traffic, you get a redirect (302) to a portal or an unexpected host. That is not proof of an attack, since real portals do the same, but it tells you something is in the middle and which page it wants you on.

3. Does the certificate match what you expect?

Ask for a site's certificate and read the issuer:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

On my machine this printed an issuer of Cloudflare TLS Issuing ECC CA 3 and a subject of CN=example.com. Run it on a trusted network first to get a baseline, then on the new network. A different issuer for the same site, or an s_client error about verification, is a red flag. Do not click through the browser warning that goes with it.

Where a VPN fits

A VPN builds an encrypted tunnel between your device and the VPN server. The access point, real or fake, then sees one connection to one endpoint and encrypted packets. The plain HTTP, DNS queries and SNI hostnames from the list above stop being readable to the access point. That is the real benefit on untrusted Wi-Fi.

A VPN does not change three things:

A password you type into the attacker's portal. The VPN protects the path, not your choice to submit credentials to the wrong page.
The order of operations. On most captive-portal networks you have to pass the portal before a VPN can connect. Verify the portal first, then connect, then do anything sensitive.
Trust. You moved from trusting the café router to trusting the VPN operator.

If you want a quick sanity check after connecting, run the three checks above again, plus the curl trace. The visible IP should now be the VPN server's. Atomic VPN is one you can use for that comparison.

A small habit list

Turn off auto-join for open networks on your phone and laptop.
Forget a network after you use it, especially airport and flight Wi-Fi.
Treat any "log in with your email or social account to get Wi-Fi" page as hostile.
Keep file sharing off on untrusted networks.
Do payments and logins on mobile data when you can.

FAQ

What is an evil twin attack?

A fake Wi-Fi access point that copies the name of a real one, so devices connect to it. The operator can then read unencrypted traffic and serve fake login pages.

Can someone read my passwords on public Wi-Fi if the site uses HTTPS?

Not from the encrypted connection, as long as the certificate is valid. They can still capture what you type into a fake page they control.

How can I tell a fake Wi-Fi network from a real one?

You often cannot by name. Check the portal's domain and certificate, watch for requests for email or social credentials, and compare behavior against a trusted network.

Does a VPN protect me on airport Wi-Fi?

It hides your traffic from the access point, including DNS and the site list. It does not protect credentials you hand to a fake login page.

Is in-flight Wi-Fi more dangerous than other public Wi-Fi?

The mechanism is the same. The 2024 case is notable because it was alleged to span flights and airports, but home, café and hotel networks have the same weakness.

What is HSTS?

A header, defined in RFC 6797, that tells a browser to use only HTTPS for a site for a set period. It blocks protocol-downgrade tricks after the first visit.

Bottom line

On a network you do not control, assume the operator can read plain HTTP, your DNS and the hostnames you visit. HTTPS keeps the content private. A VPN hides the rest from the access point. Neither helps if you type a password into the wrong page, so the habit that matters most is the dull one: do not log in to anything just to get online.

What is the strangest captive portal you have seen? Describe it in the comments.

HTTPS Hides the Page, Not the Hostname: What Your ISP Still Sees

Mak Atomic — Fri, 23 Oct 2026 11:23:39 +0000

Everyone knows the padlock means "encrypted". Fewer people know what it leaves out.

When your browser opens https://example.com, it sends a first message to the server called the ClientHello. That message contains the hostname, in plain text, in a field called SNI (Server Name Indication). Your ISP, the café router and anyone else on the path can read it. They cannot read the page, the URL path or the form data. They can read which site you went to.

You do not have to take that on trust. Here is a script that builds a ClientHello and looks inside it.

TL;DR

The SNI field carries the site name unencrypted in every classic TLS connection, including TLS 1.3.

Encrypted Client Hello (ECH), now RFC 9849, hides it, but only when the browser, the server and DNS all cooperate.

A VPN moves the observer: your ISP sees one tunnel endpoint instead of a list of hostnames, and the VPN operator can see what the ISP used to see.

Look inside a ClientHello (15 lines)

This script performs the first step of a TLS handshake against nothing at all. It never touches the network. It only asks Python's ssl module what it would send.

import ssl

host = "example.com"
ctx = ssl.create_default_context()
incoming, outgoing = ssl.MemoryBIO(), ssl.MemoryBIO()
tls = ctx.wrap_bio(incoming, outgoing, server_hostname=host)

try:
    tls.do_handshake()  # no server: it only produces the ClientHello
except ssl.SSLWantReadError:
    pass

client_hello = outgoing.read()
print("first byte:", hex(client_hello[0]), "(0x16 = TLS handshake record)")
print("hostname readable in raw bytes:", host.encode() in client_hello)

Run it with python3 sni_demo.py. On my machine it prints:

first byte: 0x16 (0x16 = TLS handshake record)
hostname readable in raw bytes: True

Those raw bytes are exactly what leaves your laptop before any encryption starts. The hostname is sitting in them.

Why TLS 1.3 did not fix this

TLS 1.3 encrypts most of the handshake, but the ClientHello has to come first, before client and server share any keys. The server needs the name in order to pick the right certificate when one IP address hosts many sites. So the name goes out in the open.

You can see the same thing from a command line against Cloudflare's trace endpoint:

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep sni

On my machine this prints sni=plaintext. Cloudflare is telling you what it saw.

What an observer on your line sees

For a single HTTPS visit, a passive observer gets:

The server IP address. Always visible, it is how packets get there.
The hostname from SNI. The part this article is about.
The DNS lookup that came before. A separate channel, covered in the next section.
Timing and volume. Roughly how much data moved and when.

They do not get the URL path, query string, cookies or page content. example.com/health-clinic/appointments leaks example.com, not the path.

DNS is the second leak

Before the ClientHello, your device looked up the IP of example.com. By default that lookup is unencrypted and goes to a resolver your network chose. Even if SNI were hidden, the DNS query would still name the site. That is why ECH is paired with encrypted DNS: the browser fetches the ECH key from DNS, and doing that over plain DNS would tell the observer where you are going anyway.

What ECH changes

RFC 9849 defines Encrypted Client Hello. The idea: the client sends an outer ClientHello with a generic public name, and puts the real one inside an encrypted inner ClientHello. The server publishes a public key for this in DNS. RFC 9848 covers how that key is bootstrapped through DNS service bindings.

For ECH to work on a given connection, three things have to line up:

The browser supports it. Mozilla documents the state of Firefox's implementation on its ECH wiki page, and Chrome has shipped support too. Check the current release notes for your version, because defaults have changed over time.
The site's DNS publishes the key. No key, no ECH.
DNS itself is encrypted. Otherwise the lookup gives the site away.

When all three hold, the observer sees the outer name, which is often a CDN's shared hostname, and the destination IP. If many sites sit behind the same IP, that is a real hiding place. If a site has an IP of its own, the IP alone still gives it away. ECH hides the name, not the address.

You can check your own browser: open https://www.cloudflare.com/cdn-cgi/trace and read the sni= line. My curl prints plaintext. A browser that actually sent an encrypted inner name should show something different. If yours still says plaintext, ECH is not active on that connection.

What a VPN does to this picture

A VPN does not make SNI encrypted. It moves your connection to the website out of your ISP's sight.

Your ISP sees a tunnel to one VPN server and a stream of encrypted packets. No per-site hostnames, no per-site IPs.
The VPN operator sees the traffic leaving its servers, including the SNI of connections that do not use ECH. You have moved trust from one party to another, so the operator's logging policy matters more than the protocol it uses.
The website still knows you connected. It sees the VPN server's IP instead of yours.

So the two tools solve different problems. ECH hides the name from everyone on the path. A VPN hides the whole list from your local network. They stack.

Optional: see it on the wire

If you have Wireshark's tshark installed, you can watch your own handshakes (I have not run this variant on this machine, so check the interface name for yours):

sudo tshark -i en0 -Y 'tls.handshake.extensions_server_name' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Open a few sites and you will see hostnames scroll by. Now connect to a VPN, capture on the physical interface again, and compare: the hostnames should be gone from that interface and the list shrinks to one destination.

FAQ

Does HTTPS hide which website I visit?

No. It hides the content and the path. The hostname goes out in the ClientHello and in the DNS lookup unless ECH and encrypted DNS are both in use.

What is SNI?

Server Name Indication, a field in the TLS ClientHello that tells the server which hostname you want, so one IP can serve many certificates.

Does TLS 1.3 encrypt SNI?

Not in the standard handshake. The ClientHello comes before any shared keys exist, so SNI is sent in plain text. ECH is the extension that fixes this.

What is Encrypted Client Hello?

A TLS extension standardized in RFC 9849 that wraps the real ClientHello, and with it the hostname, in encryption using a key the server publishes in DNS.

Does a VPN hide the sites I visit from my ISP?

Yes, from your ISP. It sees an encrypted tunnel to one server. The VPN provider can see what your ISP no longer can, so choose the provider as carefully as the protocol.

Can the website still identify me behind a VPN?

Yes, through cookies, logins and browser fingerprint. A VPN changes your IP, not who you are signed in as.

Bottom line

If you are worried about the person sitting on your network, hide the whole list with a tunnel. If you are worried about everyone on the path, you need ECH and encrypted DNS as well, and you need sites that support them. Try the 15-line script first: seeing your own hostname in the raw bytes explains the problem better than any diagram.

If you want a tunnel to compare against, Atomic VPN is one you can use for that comparison.

Got a different sni= result in your browser? Tell me which browser and version in the comments.

WireGuard in Under 4,000 Lines: What Developers Get From a Smaller VPN Codebase

Mak Atomic — Fri, 23 Oct 2026 11:14:28 +0000

A VPN protocol is code that runs with high privileges and parses data from the open internet. The less of it there is, the less there is to get wrong.

That was the pitch of the original WireGuard paper. Its authors wrote that they implemented the protocol for Linux "in less than 4,000 lines of code", excluding cryptographic primitives, and that this makes it easy to audit and verify. They contrast it with OpenVPN, which the paper describes as a user-space daemon that supports the entire plethora of TLS functionality and is therefore "enormously complex".

This post is for developers who use a VPN every day and want to know what that difference means in practice: what the config looks like, what you gain, and where the older option still wins.

TL;DR

WireGuard's codebase is small by design, which makes review and reasoning about it easier. Small code is not the same as a verified provider.
A working tunnel is about ten lines of config, and the keys are the identity. There is no certificate authority to run.
OpenVPN still has a place: networks that block UDP, and setups that need its TLS tooling.
Most commercial clients ship several protocols. The useful question is which one is the default and what the fallback is.

In this post: Comparison · Config · OpenVPN · Commercial clients · FAQ

What you are actually comparing

The paper compares WireGuard with IPsec and OpenVPN on three axes: simplicity, performance and cryptography.

Axis	WireGuard	OpenVPN
Code size	Under 4,000 lines for the Linux implementation, excluding crypto primitives	Full TLS stack, including certificate parsing
Where it runs	Linux kernel implementation	User-space daemon
Transport	UDP	UDP or TCP, including port 443
Cryptography	Fixed modern primitives, no cipher negotiation	Negotiated through TLS
Identity	Public keys	Certificates and a CA

Code size. The paper's figure is under 4,000 lines for the Linux implementation, excluding crypto primitives. OpenVPN carries the full TLS stack, including certificate parsing, and runs as a user-space daemon.

Performance. The authors benchmarked WireGuard against IPsec and OpenVPN with iperf3 and reported that WireGuard won on both throughput and ping. They explain the OpenVPN gap by its user-space design, which adds copying between kernel and user space. These are the authors' numbers from the paper, so treat them as a starting point and measure on your own link.

Cryptography. WireGuard's site lists a fixed set of modern primitives, including ChaCha20, Poly1305 and Curve25519. There is no cipher negotiation, so there is no downgrade path to a weak suite. If a primitive is ever broken, the protocol version changes rather than a setting.

What a config looks like

The WireGuard quickstart shows the low-level tools, and wg-quick automates the rest. A client config with placeholder keys looks like this:

[Interface]
PrivateKey = <client-private-key>
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Bring it up and check it:

sudo wg-quick up wg0
sudo wg show

Three details that matter:

AllowedIPs = 0.0.0.0/0, ::/0 sends all traffic through the tunnel. A narrower value gives you a split setup for just one subnet, which is how many teams reach a private network.
PersistentKeepalive = 25 keeps the mapping alive through NAT. The quickstart suggests 25 seconds as a sensible value.
Keys are the identity. A peer is a public key. You do not run a CA or revoke certificates; you remove a peer from the config.

Where OpenVPN is still the right tool

WireGuard runs over UDP. That is fine at home and at the office, and it fails on some hotel, airport and corporate networks that only let TCP on port 443 through.

OpenVPN can run over TCP, including port 443, so it looks like ordinary HTTPS to a basic firewall. It is slower there, because TCP inside TCP behaves badly on lossy links, but a slow tunnel beats no tunnel. It also has mature tooling for certificate-based setups, which some organizations already depend on.

So the rule I use: WireGuard by default, OpenVPN when UDP is blocked.

What to look for in a commercial VPN client

If you do not run your own server, you pick a provider, and the protocol list is one of the few things you can check from outside.

Default protocol. It should be WireGuard unless you have a reason otherwise.
A fallback. At least one TCP-capable option for hostile networks.
Many devices per account. One config per device is the WireGuard model, so check the device limit.

Atomic VPN lists WireGuard as its default, with OpenVPN and IKEv2/IPsec as alternatives. The apps are available for Windows, macOS and Android, and iOS is listed as coming soon. If you are on a network that eats UDP, switching protocol in the app is the first thing to try before you blame the provider.

One caution that applies to every provider: a small protocol codebase says nothing about what a company logs. The protocol protects the tunnel. The privacy policy decides what happens at the other end.

FAQ

Is WireGuard more secure than OpenVPN?

It has a much smaller codebase and no cipher negotiation, which reduces attack surface. Neither protocol is secure if the provider logs your traffic.

Does WireGuard work on Windows, macOS and Android?

Yes, WireGuard has clients for all three, and commercial VPN apps usually bundle it.

Why is WireGuard faster?

The paper attributes the OpenVPN gap to user-space overhead and reports better throughput and latency in its own benchmark. Your results depend on your link.

Why does WireGuard fail on some Wi-Fi networks?

It uses UDP. Networks that only allow TCP 443 block it. Use OpenVPN over TCP there.

Do I need to run my own WireGuard server?

No. You can use a provider. Self-hosting gives you control over the endpoint and logging, and costs you the maintenance.

What does `AllowedIPs` do?

It is both a routing table and an access list for the peer. 0.0.0.0/0 routes all IPv4 traffic through the tunnel.

Bottom line

If your network allows UDP, use WireGuard and spend your time on something other than tunnel configuration. If it does not, keep OpenVPN over TCP 443 as the fallback. Either way, check the protocol you actually connected with, because the default in the app is only a default.

Want WireGuard without running your own server? See the protocols on atomicvpn.io.

Which protocol do you run by default, and what made you switch? Tell me in the comments.

What Your Laptop Tells Every Server: A 10-Minute Leak Audit with curl, dig and DevTools

Mak Atomic — Fri, 16 Oct 2026 12:58:35 +0000

Open a terminal and run this:

curl -s https://www.cloudflare.com/cdn-cgi/trace

You get a dozen lines back:

ip=203.0.113.7

loc=LV

colo=RIX

sni=plaintext

ip= is your public address. loc= is the country Cloudflare maps it to. colo= is the data center that answered. sni=plaintext means the hostname you asked for travelled unencrypted in the TLS handshake.

That is one request to one server. Every site, API and package registry you touch gets the same data and more. Below is a small audit you can run in ten minutes: three tests, what each one shows, and a second run behind a VPN to see what changes and what does not.

TL;DR

our public IP, your DNS resolver and your WebRTC candidates are three separate exposure points. Fixing one does not fix the others.
A VPN changes who sees your IP and your DNS queries. It does not change cookies, logins or browser fingerprint.
Geolocation from an IP is a guess. Two services can disagree about the same address by a whole continent.

Test 1: What the server sees (public IP)

Start with the request above. Then ask a second service about the same address:

curl -s https://ifconfig.co/json | head -n 12

When I ran both from the same machine, Cloudflare reported Latvia and the second service reported Tokyo. Same IP, same minute. IP geolocation databases are built from registry data, routing hints and guesses, and they lag behind when blocks of addresses move.

Two things follow from this:

"My location leaked through my IP" is usually true only at country or region level.
A service that blocks or allows you by country is working from a database that can be wrong. If a site ever blocked you while you sat in the "right" country, this is why.

Test 2: Who answers your DNS questions

Your browser knows the IP of a site because something resolved the name. That something is a DNS resolver, usually your router or your ISP, and it sees every hostname you look up, even when the page itself is HTTPS.

Check which resolver the world sees when you ask:

dig +short whoami.akamai.net

The answer is the IP of the recursive resolver that reached Akamai's authoritative server on your behalf. If it belongs to your ISP, your ISP is reading your lookups. If it belongs to a public resolver you chose, that operator is.

Encrypted DNS closes the path between you and the resolver. DNS over HTTPS is defined in RFC 8484. It does not hide your lookups from the resolver itself, only from the network in between. The IETF's position on why this matters is blunt: RFC 7258 is titled "Pervasive Monitoring Is an Attack" and asks protocol designers to make mass surveillance harder.

Test 3: What the browser hands out via WebRTC

WebRTC lets two browsers connect directly. To do that, a browser gathers "ICE candidates", which are possible network addresses, and some of them come from a STUN server that reports your public address back. MDN documents the candidate types: host for local addresses, srflx for the address a STUN server saw.

Paste this into the DevTools console on any page:

const pc = new RTCPeerConnection({

  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],

});

pc.createDataChannel("probe");

pc.onicecandidate = (e) => {

  if (e.candidate) console.log(e.candidate.candidate);

};

pc.createOffer().then((offer) => pc.setLocalDescription(offer));

Look at the lines that contain typ srflx. The address in that line is the public IP the STUN server saw. Modern browsers hide local host addresses behind random .local names, but the srflx candidate is the one that matters here. If it differs from the IP in Test 1, something in your setup routes WebRTC outside your tunnel or proxy. That mismatch is the classic "WebRTC leak".

Run it again behind a VPN

Write down three results: public IP, resolver IP, srflx address. Connect to a VPN, then repeat all three tests.

If you want a visual version of the same data, the homepage of Atomic VPN has an "exposure" panel that lists the IP, city, ISP, device, browser and DNS a site can read from a single visit. I use it as a quick before-and-after check, but the three commands above are the real test because you can script them.

What a VPN does not change

Be clear about the limits, because "VPN" is sold as a stronger promise than it is.

Cookies and logins. If you are signed in, the site knows who you are regardless of IP.
Browser fingerprint. Fonts, canvas, screen size and extensions identify a browser without any IP at all.
What the VPN provider sees. You move trust from your ISP to the VPN operator. Read the logging policy and decide whether you accept it.
Plain HTTP pages. The tunnel protects the path to the VPN server, not the path from there to the site.

A small script to keep

Save it as leakcheck.sh and run it before and after you connect.

#!/usr/bin/env bash

echo "== public IP / country / colo =="

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc|colo)='

echo "== resolver seen by Akamai =="

dig +short whoami.akamai.net

{% enddetails %}

Diff the output of the two runs. If the IP changed but the resolver did not, you have found a leak in about two seconds.

DEV Community: Mak Atomic

How to Test Geo-Dependent Features in Your App

The four signals that mean "where is this user"

What the DevTools override actually does

Step 1: check what the internet thinks my location is

Step 2: route traffic through the target country

Step 3: add the other signals with Playwright

What breaks, and why

How I run this with Atomic VPN

Where a VPN is the wrong tool

FAQ

Sources

Fake Wi-Fi in the Sky: What an Evil Twin Can See and What HTTPS Still Protects

Why the copy works

What the person running the fake network sees

HSTS closes the downgrade trick

Three checks for a network you do not control

1. Is the portal the real portal?

2. Is plain HTTP being tampered with?

3. Does the certificate match what you expect?

Where a VPN fits

A small habit list

FAQ

What is an evil twin attack?

Can someone read my passwords on public Wi-Fi if the site uses HTTPS?

How can I tell a fake Wi-Fi network from a real one?

Does a VPN protect me on airport Wi-Fi?

Is in-flight Wi-Fi more dangerous than other public Wi-Fi?

What is HSTS?

Bottom line

HTTPS Hides the Page, Not the Hostname: What Your ISP Still Sees

Look inside a ClientHello (15 lines)

Why TLS 1.3 did not fix this

What an observer on your line sees

DNS is the second leak

What ECH changes

What a VPN does to this picture

Optional: see it on the wire

FAQ

Does HTTPS hide which website I visit?

What is SNI?

Does TLS 1.3 encrypt SNI?

What is Encrypted Client Hello?

Does a VPN hide the sites I visit from my ISP?

Can the website still identify me behind a VPN?

Bottom line

WireGuard in Under 4,000 Lines: What Developers Get From a Smaller VPN Codebase

What you are actually comparing

What a config looks like

Where OpenVPN is still the right tool

What to look for in a commercial VPN client

FAQ

Is WireGuard more secure than OpenVPN?

Does WireGuard work on Windows, macOS and Android?

Why is WireGuard faster?

Why does WireGuard fail on some Wi-Fi networks?

Do I need to run my own WireGuard server?

What does AllowedIPs do?

Bottom line

What Your Laptop Tells Every Server: A 10-Minute Leak Audit with curl, dig and DevTools

Test 1: What the server sees (public IP)

Test 2: Who answers your DNS questions

Test 3: What the browser hands out via WebRTC

Run it again behind a VPN

What a VPN does not change

A small script to keep

What does `AllowedIPs` do?