Provider-neutral self-test pilot
Two things ExpressVPN documents change what these checks return: it resolves DNS on its own servers instead of handing queries to a third-party resolver, and its kill switch - marketed as Network Lock, labelled Internet Kill Switch in the app - is on by default and blocks IPv4, IPv6 and DNS traffic outside the tunnel. What follows is a walkthrough of your own session, not a verdict on ExpressVPN's servers.
Live test
ExpressVPN resolves DNS on its own servers and Network Lock blocks IPv6 outside the tunnel, so read the resolver line first and expect IPv6 to stay quiet.
Current-session checks
Each tool reads one signal. Take a reading once on your normal connection and once with Network Lock active; the difference between the two is what the app is doing for this browser.
Before you read the result
Everything below is drawn from ExpressVPN's own feature and support pages. Knowing the intended behaviour first is what lets you tell a normal reading from one worth chasing.
ExpressVPN states that it runs private, encrypted DNS on every VPN server rather than passing queries to an outside resolver. A DNS check while connected should therefore show ExpressVPN infrastructure answering, not your ISP and not a public resolver. Your ISP's resolver appearing in the result is the reading that deserves a closer look.
ExpressVPN describes the Internet Kill Switch as blocking IPv4, IPv6 and DNS traffic outside the encrypted tunnel rather than letting IPv6 fall back to the local interface. In practice that means an IPv6 check normally returns nothing while you are connected, and an IPv6 address matching your home network is worth investigating.
If a check shows an address you did not expect, the first setting to confirm is Network Lock, which ExpressVPN says is enabled by default. It lives in the app's preferences, not in your browser, and the app labels it Internet Kill Switch rather than Network Lock.
ExpressVPN lists the kill switch as available on Windows, Mac, Linux, routers, Android and iOS. That last one matters here: when the tunnel is established by a router, a browser check run on a device behind it is measuring the router's connection, and nothing you change in a desktop app will move the result.
WebRTC runs inside the browser. With the whole system routed through the app, WebRTC candidates should carry the tunnel address, but a browser extension, a second adapter or a split-tunnel rule can change that. ExpressVPN's TrustedServer claim that its servers run in RAM only is a statement about the server, not about your session; only the checks here speak for your browser.
Between the readings
Network Lock is ExpressVPN's name for its kill switch, and it is the setting every surprising reading traces back to. What a recording adds is the interval: how long the tunnel address was gone, and whether anything of yours was reachable inside that gap.
Safe Copy exports use safe summary categories and remove raw IP, exact city, full user-agent, raw fingerprint data, raw resolver IPs and WebRTC candidates. It is not a certificate, provider audit, or proof of anonymity.
FAQ
ExpressVPN states that it runs private, encrypted DNS on every VPN server and does not hand queries to third-party resolvers. The DNS check on this page shows which resolver actually answered for your session, which is the part you can confirm yourself.
ExpressVPN documents its kill switch as blocking IPv4, IPv6 and DNS traffic outside the tunnel. An empty IPv6 reading is the expected outcome of that design rather than a failure of the test.
Network Lock is ExpressVPN's name for its kill switch; the app calls it the Internet Kill Switch, and ExpressVPN says it is enabled by default. It is the setting to check first when an unexpected address appears.
It changes what the check measures. ExpressVPN supports the kill switch on routers as well as on desktop and mobile, and with a router tunnel the browser is reporting on the router's connection rather than on any app running alongside it.
No. These checks read signals visible to your own browser in one session. Server-side behaviour, including logging and the RAM-only TrustedServer claim, is outside anything a browser test can observe.
Confirm the kill switch is active, restart the browser so it drops cached connections, then rerun the focused DNS, WebRTC and IPv6 tools. Read the methodology before treating a single reading as conclusive.