Provider-neutral self-test pilot
Speedify is built around a different idea from the rest of this list. Rather than picking one connection and tunnelling it, it opens an encrypted link over every connection your device has, splits traffic across them packet by packet, and reassembles the stream at its own server. A website therefore sees one address while your device may have been using Wi-Fi and a mobile connection at the same moment. That gap is what makes a single reading here worth interpreting carefully.
Live test
Speedify bonds several connections at once and rebuilds the stream at its server, so the single address you see here does not tell you which of your links carried the packets.
Current-session checks
Take a reading before and after connecting. On Speedify the address is a statement about the bonding server, not about which of your own connections was in use at the time.
Before you read the result
The points below come from Speedify's own descriptions of channel bonding and how the client and its servers work together.
Speedify describes opening an encrypted link over each connection you have, splitting traffic across all of them and bonding it into a single session reassembled at its server. The address a website records is that server's. It is not a clue about whether the packets travelled over Wi-Fi, over a mobile connection, or over both in the same second.
Because the division is packet by packet rather than session by session, there is no simple mapping from a browser tab to one of your connections. This is why comparing two readings taken minutes apart can be less informative here than elsewhere: the underlying path may have changed without the visible address moving at all.
Speedify says it monitors each connection for latency, packet loss and throughput and reroutes in milliseconds if one fades, so an interruption on one link does not surface as a dropped VPN. A reading that stays stable across a bad Wi-Fi moment is consistent with the design rather than a sign that nothing was tested.
Everything this page can observe arrives at the site from the bonding server. The composition of the path behind it is known to the client and the server and to nothing in between. Any account of which link carried what would be invention, so this page does not offer one. That is worth stating because bonding is exactly the arrangement where a reader is most likely to want the missing detail, and the honest answer is that the client's own connection view is the only place it exists.
It can settle whether your browser presented the bonded exit address rather than one of your own, whether the resolver moved, and whether WebRTC produced anything unexpected. Those are real answers. They are simply narrower than the question people usually arrive with.
Between the readings
Speedify moves traffic between connections by design, so a changed address is not automatically a failure. A recording separates a handover from an exposure by comparing whatever appeared against your own captured address.
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
Speedify describes it as opening an encrypted link over each connection you have, splitting traffic across them packet by packet, and bonding it into one session that is reassembled at its own server.
No. The traffic reaches a site from the bonding server, so the composition of the path behind it is not observable from a browser. Nothing here should be read as naming one of your links.
Speedify says it monitors each connection and reroutes in milliseconds when one fades. A stable reading across a bad moment is consistent with that behaviour rather than a sign the check failed.
It should be the address of the server that reassembles your traffic. If a reading shows an address that belongs to your own connection, that is the difference worth investigating in the client.
WebRTC candidates are produced by the browser from the interfaces it can see. What they contain depends on how the client presents those interfaces, which is why the WebRTC line is worth reading separately from the address.
No. Everything above describes this browser in this session. Other applications on the device are outside what a page can measure, however the connections underneath are arranged.