Provider-neutral self-test pilot
Twingate is not a full tunnel, and its documentation makes that a matter of mechanism rather than marketing: the client watches for connection requests to protected Resources and builds a connection only when the destination matches one in the access list. Everything else leaves your machine the way it always did. That single design decision explains most of what these checks return here, including a public address that has not moved. The reading is about this browser.
Live test
Twingate routes traffic only when the destination matches a Resource in its access list, so the address below is normally your own. The line that can move is DNS.
Current-session checks
Read the signals once with the client signed out and once signed in. On Twingate the line that can move is DNS, because resolution for protected Resources is proxied while everything else is not.
Before you read the result
The points below come from Twingate's own documentation, which describes the client as matching destinations against an access list rather than capturing everything a device sends.
Twingate documents the client as detecting network connection requests to protected Resources, and states that if the destination address matches a Resource in the access list, a connection is initiated via Twingate to the remote network. Traffic to anything else is untouched. A public IP check run during a Twingate session is therefore reading your ordinary connection, correctly, and there is no tunnel address for it to report.
The client proxies DNS requests for protected Resources, forwarding them for resolution to a Connector inside the remote network. That is split DNS: private names resolve on the far side, public names resolve the way they always did. A DNS leak test asking about a public domain is measuring the second half of that arrangement, which is the half Twingate deliberately leaves alone.
Twingate documents native DNS-over-HTTPS for users running its macOS, Windows or Linux clients, and states that it encrypts all DNS traffic regardless of the originating application with no configuration changes required. That changes what a resolver check can observe about this device, so it is worth knowing which state you were in before you read one.
Twingate's Internet Security features include DNS filtering, which decides at resolution time whether a name is answered at all. A page that will not load during a check may have been filtered rather than blocked by a network fault, and those are different findings that a single reading will not separate for you.
Twingate publishes its own comparison against traditional VPNs, and the difference is the point. A consumer VPN is judged by whether your visible address changed. This product is judged by whether a named Resource became reachable to the people entitled to it. Reading one result with the other's expectations is the usual route to concluding that something has failed.
Between the readings
A Twingate client that stops running does not expose internet traffic, because that traffic was never inside it. What ends is a private hostname resolving, and a recording is still the way to see how quickly the change takes effect.
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
Because Twingate documents the client as initiating a connection only when the destination matches a Resource in the access list. Traffic to everything else keeps its ordinary path, so a public IP check reports the address it always would.
Twingate publishes its own comparison against traditional VPNs and describes a per-Resource model rather than a device-wide tunnel. That difference is why leak-test expectations carried over from a consumer VPN produce confusing readings here.
The client proxies DNS requests for protected Resources and forwards them to a Connector in the remote network for resolution. Public names are resolved the way they were before, which is what a public DNS check will see.
Twingate documents it as encrypting all DNS traffic regardless of the originating application, with no configuration changes required, on its macOS, Windows and Linux clients. Whether it was on changes what a resolver check can observe.
It can be. Twingate includes DNS filtering as part of its Internet Security features, and a filtered name is refused at resolution time. Check the filtering policy before treating the failure as a network fault.
No. It reports what this browser exposed to a public site in one session. Access to private Resources happens between the client and a Connector and is never visible here.