Daniel's been circling Speedify for a few episodes now without ever landing on it, so this week he sent in exactly the questions that matter for his actual setup. He wants to know two things. Can he bond his phone's eSIM cellular with whatever Wi-Fi he's on using no extra hardware, and what's the catch nobody mentions until after you've bought something. And second, the one he really cares about: does Speedify play nicely with Tailscale, or does it silently break his tailnet while ordinary browsing looks perfect. Underneath both of those is the real question. Speedify is the most consumer-friendly thing in this space, but it's also the most opaque. You subscribe and it does something to all your traffic. What is it actually doing, what control does it genuinely give you, and where does its opacity leave you vulnerable.
So let's start with the thing Speedify doesn't really want you to think about. How it actually works under the hood.
Right. Because the website talks about bonding and seamless failover and faster internet, but the moment you ask what's happening to your packets, the documentation gets... polite.
It gets very polite. So here's what's actually happening. Speedify installs a virtual network adapter on your machine. This adapter sits above your physical interfaces — your Wi-Fi, your Ethernet, your phone tethered over USB. When you connect, Speedify manipulates your routing table so the default route points to its virtual interface. All outbound traffic gets intercepted there.
It captures everything.
It captures everything by default, yes. Then it encapsulates your traffic in UDP packets and sends them to Speedify's relay servers. The clever part is that it doesn't just pick one connection and send everything over it. It stripes packets across all available connections simultaneously, and the relay server reassembles them in order before forwarding them to their actual destination. So a single TCP flow might have packets going out over Wi-Fi and cellular at the same time.
Which is not multipath TCP.
It is not multipath TCP. Multipath TCP is a protocol extension where both endpoints negotiate multiple paths at the transport layer. Speedify is a proprietary tunnel that does per-packet load balancing at a layer above. The remote endpoint is always Speedify's relay, not the server you're actually talking to. The relay is what reassembles everything.
So your traffic takes a detour through their infrastructure before it goes anywhere.
Always. And they add forward error correction and packet duplication on top of that. If a packet gets lost on Wi-Fi, the relay might already have a redundant copy from the cellular path, or it can reconstruct the missing data from FEC parity. That's how they sell the seamless failover story — you can walk out of Wi-Fi range and your video call doesn't drop.
Which is impressive when it works. But we should name the opacity problem right here, because it's the thread that runs through both of Daniel's questions. Speedify takes over your routing table and gives you almost no visibility into what it changed. You can't see which routes it added, which it removed, or how it's prioritizing interfaces. The UI tells you you're connected and bonded and everything is great.
And for most users, that's exactly what they want. They don't want to see a routing table. But Daniel runs a tailnet, and tailnets also manipulate the routing table, and that's where this gets interesting. With that mechanism in mind, let's tackle his first question — the one about bonding his phone's eSIM with hotel Wi-Fi.
So the scenario. Daniel's got a phone with an eSIM providing cellular data. He's got a laptop with one Wi-Fi radio. He wants to bond the phone's cellular with the hotel Wi-Fi. No extra hardware. Does it work?
It does not work out of the box, and the catch is exactly what he suspects. If the phone shares its cellular connection by creating a Wi-Fi hotspot, the laptop has to connect to that hotspot to receive the internet. That uses the laptop's one Wi-Fi radio. There is no second radio left to join the hotel Wi-Fi network. You can't be connected to two Wi-Fi networks simultaneously on a single radio.
So the out-of-the-box experience for the most obvious setup is that it fails silently. You turn on the phone hotspot, you connect the laptop, you fire up Speedify, and it sees... one connection.
One connection. And bonding one connection is not bonding. Speedify's own support documentation confirms this, and they recommend USB tethering as the solution. You plug the phone into the laptop with a USB cable, the phone shares its cellular connection over USB, and it appears on the laptop as a virtual Ethernet adapter. Now the laptop's Wi-Fi radio is free to join the hotel network. Speedify sees two interfaces and bonds them.
So the real answer is a cable.
It's a cable. Or a second Wi-Fi adapter — a USB dongle would also work, and then you could do it wirelessly. But that's extra hardware either way. The cleverer thing Daniel was hoping for doesn't exist, because the physics of a single radio don't allow it.
And this is the kind of thing that's never on the sales page.
It's never on the sales page. The sales page says bond Wi-Fi and cellular, and you imagine your phone in your pocket and your laptop on the desk and everything just working. The reality is you're fishing a USB-C cable out of your bag.
What about the upstream provider question? If both connections trace back to the same ISP, does bonding still do anything useful?
It does. Bonding at the IP layer doesn't care about provider diversity. Speedify will happily bond two connections from the same ISP, and you still get bandwidth aggregation — if your phone's cellular and the hotel Wi-Fi both ultimately route through the same carrier's backbone, you're still combining their throughput. You also still get loss mitigation, because packet loss on one link gets covered by the other. What you lose is resilience against a provider-level outage. If that one carrier goes down, both your connections go down together.
So it's not pointless, just less redundant.
Right. And in practice, a phone eSIM and a hotel Wi-Fi network are rarely the same provider anyway. The hotel's probably got a business cable connection from someone local, and your eSIM is whatever carrier you're roaming on. They might converge somewhere upstream, but the last mile is different, and that's where most problems happen.
So to summarize Daniel's first question: the catch is real, the cable is the answer, and the provider thing matters less than you'd think. That's the phone and Wi-Fi story. But the question he really cares about is Tailscale. And that's where the routing table conflict gets interesting.
This is where the opacity problem stops being philosophical and starts breaking things. Tailscale works by creating a WireGuard-based mesh network. Every device in your tailnet gets an IP address in the 100.64.0.0/10 range — that's the carrier-grade NAT space, and Tailscale uses it for all tailnet addresses. When you install Tailscale, it adds routes to your routing table that say traffic for 100.x.y.z goes through the Tailscale virtual interface. Everything else goes out your default route as normal.
And Speedify changes your default route.
Speedify changes your default route to point to its own virtual interface. And depending on how aggressive it is — and it can be fairly aggressive — it may also add more specific routes to capture traffic that would otherwise bypass the tunnel. The routing table becomes a battleground. Whichever service wrote the most specific route wins.
So if Speedify writes a route that covers the tailnet range, or if it just captures everything because that's its default behavior...
Then traffic destined for your tailnet addresses gets encapsulated and sent to Speedify's relay servers instead of going through the Tailscale WireGuard tunnel. Your SSH session to a remote box times out. Your internal services become unreachable. Your Tailscale agent connections fail. But here's the insidious part: your ordinary internet browsing looks perfect. Google works, Slack works, YouTube works. You might not notice the tailnet is broken until you try to SSH into something and it just hangs.
And you lose an afternoon before you work out why.
You lose an afternoon running ping and traceroute and wondering if the server is down, if Tailscale is having an outage, if your firewall rules changed. The fact that Speedify did something to your routing table is not the first thing you think of, because Speedify's whole pitch is that it's seamless and invisible.
So what's the fix?
Split tunneling. Speedify has a split tunneling feature that lets you specify traffic that should bypass the Speedify tunnel entirely. The configuration options are per-application — you pick which apps bypass Speedify — or by IP range or domain. For Tailscale, the practical approach is to add a bypass rule for the tailnet IP range, 100.64.0.0/10. Traffic destined for those addresses goes straight out through the Tailscale interface instead of being captured by Speedify.
But that's a manual configuration. Speedify doesn't auto-detect Tailscale.
It does not auto-detect Tailscale. There's no Tailscale-specific preset in the split tunneling UI. You have to know the CGNAT range Tailscale uses, and you have to add it yourself. And the bypass is at the IP level — you can't configure it by DNS suffix. So you can't say bypass everything ending in dot tailnet-name dot ts dot net. You have to know the IP range.
Which most people don't.
Most people have never heard of 100.64.0.0/10. And even if you know the range, there's a subtler problem. Tailscale uses 100.64.0.0/10 for tailnet addresses by default, but some tailnets use additional ranges for subnet routing. If you've configured Tailscale to route a subnet — say a 10.x.x.x range behind a subnet router — those addresses are also part of your tailnet, and they're not covered by the 100.64.0.0/10 bypass rule.
So you'd need to add those too.
You'd need to add each additional range manually. And you'd only discover you needed to when something on that subnet stopped responding. It's a trial-and-error process. Speedify's support documentation acknowledges split tunneling exists, but it doesn't provide troubleshooting steps for VPN-on-VPN conflicts. There's no guide that says here's how to make Speedify and Tailscale coexist.
And this is the vulnerability Daniel's sensing. Not that Speedify is malicious, but that its opacity means you're debugging with command-line tools while the friendly UI tells you everything is fine.
To figure out what's actually happening, you need to open a terminal and run route print on Windows or netstat minus r n on macOS and Linux. You need to inspect the routing table yourself, find the conflicting routes, work out which service added them, and then configure the bypass rules accordingly. Speedify's UI does not expose any of this. It doesn't show you which routes it added, which it modified, or how it's prioritizing interfaces.
Compare that to something like OpenMPTCProuter, where the routing table is exposed and you can configure per-interface policy routing directly. That's more complex to set up, but when something breaks, you can see why.
And that's the tradeoff Speedify made. They optimized for the user who never wants to see a routing table. The problem is that when you're that user and something breaks, you have no tools to fix it except the ones Speedify hid from you.
Let's walk through what a real fix looks like for Daniel's setup. He installs Speedify, he installs Tailscale, he fires up both. Tailscale works, Speedify bonds, browsing is fast. Then he tries to SSH into a box on his tailnet and it hangs. What does he do?
First, he confirms the routing table conflict. He runs netstat minus r n and looks for routes to 100.64.0.0/10. If Tailscale is working correctly, there should be a route sending that traffic through the Tailscale interface — usually something like utun or tailscale0. If Speedify has overridden it, he'll see a different route, or the traffic will be caught by the default route pointing to Speedify's interface.
Then he opens Speedify's split tunneling settings.
He goes into the Speedify app, finds the split tunneling section, and adds a bypass rule. He selects bypass by IP range and enters 100.64.0.0/10. He applies it, Speedify updates its routing rules, and tailnet traffic starts flowing through Tailscale again. He tests SSH, confirms it works, and he's done. For the basic case.
For the basic case. But if he has subnet routing set up in Tailscale, he's not done.
If he has subnet routing, he needs to add bypass rules for every additional subnet range his tailnet routes. And he might not remember all of them. He might not even know some of them exist if someone else on the tailnet set up the subnet router. He discovers them one at a time, when something breaks.
The half-working scenario Daniel described is exactly right. Browsing is perfect, the tailnet is quietly broken, and you lose an afternoon.
The afternoon is spent not in Speedify's UI but in a terminal, which is the place Speedify was supposed to save you from.
There's another angle here I want to pull on. Speedify's split tunneling lets you bypass by application or by IP range or domain. The domain bypass is interesting — could you bypass Tailscale's coordination server that way?
You could, but that wouldn't solve the problem. Tailscale's coordination server is just for key exchange and configuration. The actual data traffic between your devices is peer-to-peer over WireGuard, and it uses those tailnet IP addresses directly. Bypassing the coordination server domain wouldn't help traffic reach 100.64.0.0/10 addresses. You need the IP range bypass for that.
The domain bypass is a red herring for this use case.
It's not designed for this use case. The domain bypass is for things like streaming services that you want to access from your real IP address instead of through the Speedify relay. It's not a VPN coexistence tool.
Which brings us back to the core complaint. Speedify doesn't think of itself as something that needs to coexist with other VPNs. It thinks of itself as the thing that handles your internet.
For the target market, that's correct. The target market is someone on a train who wants their Zoom call to survive going through a tunnel. They're not running Tailscale. But the feature set is good enough that power users look at it and think this could work for me, and then they hit these edge cases that the documentation doesn't cover.
Let's talk about what Speedify could do to close this gap. Auto-detection of common VPN interfaces seems like the obvious one. If it sees a Tailscale or WireGuard interface, it could offer to bypass the relevant IP ranges automatically.
That would be the cleanest fix. Detect the presence of a Tailscale interface, read the routes Tailscale added, and automatically add bypass rules for those routes. Or at least prompt the user: we detected Tailscale, would you like us to configure split tunneling for it? That's a one-time dialog that would save hours of debugging.
DNS-based bypass would also help. If you could say bypass everything under my tailnet's domain suffix, you wouldn't need to know the IP ranges at all.
That's harder technically, because the bypass decision happens at the IP layer before DNS resolution in most cases. But it's not impossible. Other tools do it. Speedify just hasn't prioritized it.
None of this is to say Speedify is bad software. The bonding works. The failover works. When it's the only thing managing your routing table, it's impressive.
It is. The forward error correction alone is clever engineering. They're doing per-packet decisions about which link to use based on real-time latency and loss measurements. The relay infrastructure is well-distributed. For the use case it was designed for, it's excellent.
But Daniel's use case is slightly outside the design envelope, and the opacity that makes it friendly for the train-Zoom user makes it hostile for the tailnet user.
That's the real answer to his underlying question. What control does Speedify give you? Enough for the common cases, not enough for the interesting ones. Where does its opacity leave you vulnerable? In the gap between the friendly UI and the routing table you can't see, where your tailnet breaks silently and you don't know why.
That routing table conflict isn't theoretical. Hilbert has actually lived it.
Wait, you've run into this?
Hilbert: I spent six months in 2019 as a network engineer on a cruise ship. Satellite, LTE, and a microwave link to shore. Three connections, all terrible in different ways. I tried Speedify to bond them for the crew's internet.
Did it work?
Hilbert: For browsing, it was beautiful. YouTube, Slack, everything looked perfect. But we had a Nagios monitoring system on a 10.x subnet, and the heartbeats went silent the day I installed it. Took me three days with Wireshark to figure out Speedify was encapsulating the monitoring traffic and sending it to the relay instead of keeping it on the local network.
Same routing table problem.
Hilbert: Same problem, earlier version. The split tunneling existed, but it was per-app only back then. You couldn't bypass by IP range. I had to disable Speedify entirely on the monitoring machine. The current version's IP-range bypass is a genuine improvement, but you still have to know the exact range, and most people won't.
How fast was the microwave link?
Hilbert: Fifty megabits, but only when the ship was pointed the right direction. The satellite was ten down, two up. Speedify actually made the combination usable — until it broke something else.
That's the thing. When it works, it really works. Three terrible connections become one tolerable one.
Hilbert: The crew loved it. Until Nagios went quiet and I had to explain why the engine room temperature alerts weren't getting through. Then they loved it less.
That's exactly the half-working scenario Daniel described. Everything looks perfect while something critical quietly fails.
Hilbert: The part that stuck with me wasn't the technical problem. It was that the Speedify UI showed three green connections and a bonded speed number. Everything looked healthy. There was no indication anywhere that local traffic was being routed wrong. The tool told me it was working perfectly.
That's the transparency gap in one sentence. The tool said everything was fine while it was silently breaking something else.
Hilbert: I still have the Wireshark captures somewhere. Three days of packet traces, and the answer was one routing table entry I couldn't see from the UI.
Where does that leave us? Speedify works, but its opacity is a real cost for certain setups. The split tunneling improvement is real but incomplete. DNS-based bypass and auto-detection of common VPN interfaces would close most of the remaining gap.
The question hanging over all of this is whether Speedify sees those users as worth serving. The power users with tailnets and mesh VPNs and local subnets are a small fraction of their market. The train-Zoom user is the business. But as tools like Tailscale become more common, the demand for bonding that coexists with other network layers is only going to grow.
The cutting-room floor detail that didn't fit anywhere: Speedify's forward error correction isn't just a fixed overhead. It dynamically adjusts the redundancy ratio based on measured packet loss on each link. If your Wi-Fi is dropping five percent of packets, it adds just enough FEC to cover that, and it recalculates continuously. That's elegant engineering, and it's the kind of thing that makes you wish they'd put the same care into their routing table transparency.
It's a good product with a specific blind spot. The blind spot happens to be exactly where Daniel lives.
Something to watch is whether the Tailscale user base grows large enough that Speedify has to address this directly. A Tailscale-aware routing preset would be maybe a week of engineering work, and it would unlock a whole category of users who are currently doing the trial-and-error dance.
Or a competitor fills the gap. There's nothing technically preventing someone from building a bonding tool that exposes routing policy properly and auto-detects common VPN interfaces. The market is small today, but it won't stay small.
Thanks to Hilbert Flumingtop for producing, and for the cruise ship story that turned out to be exactly the cautionary tale this topic needed.
This has been My Weird Prompts. If you want to send us your own questions about software that half-works in interesting ways, email the show at show at my weird prompts dot com.
We'll be back soon.
