Fix SSL Error on Mobile Data Only (Private DNS Fix)
A network failure that worked perfectly on WiFi and broke every time on mobile data — until the actual cause turned out to be neither WiFi nor mobile data.
*A network failure that worked perfectly on WiFi and broke every time on mobile data — until the actual cause turned out to be neither WiFi nor mobile data.*
Some bugs are intermittent in a way that makes them genuinely hard to diagnose, because the obvious variable you're staring at isn't the one causing the problem. This was one of those.
The Symptom
Git operations in Termux — push, pull, sometimes even clone — would fail with SSL/TLS handshake errors, but only when connected to mobile data (4G). Switch to WiFi, and the exact same command would succeed without issue. That pattern strongly suggests a network-layer problem, and the obvious suspect is the mobile carrier's network configuration.
Why the Obvious Suspect Was Wrong
The actual cause wasn't the mobile network itself — it was the phone's Private DNS setting interacting badly with certain SSL/TLS connections over the mobile carrier's DNS resolution path. Android's Private DNS feature (which routes DNS queries through an encrypted resolver rather than the carrier's default DNS) can, under specific carrier and network configurations, cause exactly this kind of intermittent SSL failure — connections that fail to establish cleanly, timing out or erroring during the handshake, specifically over mobile data where the DNS resolution path differs from WiFi.
The Fix
The resolution was in Android's network settings, not in git, Termux, or the repository: adjusting the Private DNS setting (switching providers, or in some cases disabling it and letting the carrier's default DNS handle resolution) resolved the SSL errors immediately and consistently.
Why This Was Hard to Diagnose
Nothing about the error message pointed at DNS. SSL handshake failures look like certificate problems, like proxy interference, like git configuration issues — and initial troubleshooting went down those paths first, checking git's SSL configuration and even considering whether a corporate-style network filter was involved. The actual fix required stepping back from the git tooling entirely and testing the network layer in isolation — confirming that the failure was reproducible on *any* HTTPS connection over mobile data, not just git operations, which narrowed the cause down to something below the application layer.
Confirming It Was Actually Fixed, Not Just Quiet
A single successful push after changing a setting isn't strong enough evidence that an intermittent bug is actually resolved — intermittent failures have a way of appearing fixed simply because they didn't happen to trigger on the next few attempts. The Private DNS fix was validated over several days of normal usage on mobile data specifically, across different times of day and different git operations, before it was trusted as the actual root cause rather than a coincidental change that happened to precede a lucky streak. That kind of deliberate patience is easy to skip when you're relieved a frustrating bug seems to have gone away, but it's the only way to distinguish a real fix from a temporary reprieve.
The Broader Pattern
Developing exclusively from a phone means the boundary between "app problem" and "phone/OS problem" blurs in a way it doesn't on a desktop, where the network stack is usually a known, stable quantity you don't think about. This bug was a reminder to check the platform layer — not just the code — when an error is intermittent and correlates with something as broad as "which network am I on," rather than assuming the problem lives in the tool you're actively using.
Ruling Things Out, One at a Time
Before landing on Private DNS as the cause, the troubleshooting process worked through several other suspects in order, mostly because they were easier to test first. Git's own SSL configuration (http.sslVerify, credential helper settings) was checked and ruled out by confirming the same failure happened on a completely unrelated HTTPS request outside of git entirely. A VPN app installed for unrelated reasons was temporarily disabled to rule out interference, with no change. Only after those more obvious candidates were eliminated did the investigation turn to Android's own network settings, and Private DNS specifically stood out as a setting that changes *how* DNS resolution happens rather than just *which* server handles it — a meaningful distinction once SSL handshake timing became the working theory.
Why Carrier Networks Make This Worse
Mobile carrier networks often have their own DNS infrastructure, sometimes with different latency characteristics or filtering behavior than a home WiFi router's DNS setup. Private DNS, layered on top of that, can interact with a carrier's network in ways that don't show up as a clean error — instead manifesting as intermittent timeouts during the TLS handshake specifically, which is exactly what looked, from the outside, like an SSL certificate problem rather than a DNS resolution timing issue several layers below it.
Takeaway
If a network-related error only reproduces on mobile data and not WiFi, don't stop at "mobile carrier issue" — check Private DNS settings specifically. It's an easy setting to forget exists, and an easy fix once identified.
📬 Get the latest AI tool reviews
Expert picks and comparisons, weekly. No spam.