Deep Dive: Resolving DNS Issues with GitHub and Understanding SSH vs HTTPS
Source: Dev.to
🚀 Pushing to GitHub — Why a Timeout Happens and How to Fix It
Ever tried pushing your code to GitHub, only to be stopped by a timeout error that makes zero sense?
That’s exactly what happened to me. What started as a frustrating blocker turned into a deep dive into DNS, network routing, and Git’s connection methods.
The Problem: “GitHub, You’re Killing Me” 😩
git push origin feat/add-testsfatal: unable to access 'https://github.com/your-username/your-repo.git/':
Failed to connect to github.com port 443 after 75079 ms: Couldn't connect to server75 seconds of waiting, then nothing. Time to investigate. 🔍
Step 1 – Is GitHub Actually Down? 🌐
curl -s -o /dev/null -w "%{http_code}" https://github.comResult: 000
A 000 status from curl means the request never got a response – the HTTPS port was completely unreachable from my machine.
Step 2 – Ping & DNS Lookup — Finding the Culprit 🕵️♂️
Ping test
ping -c 2 github.comPING github.com (20.87.245.0): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 20.87.245.0: icmp_seq=1 ttl=114 time=72.940 msPacket loss right away. The IP 20.87.245.0 was responding inconsistently – not what you expect from GitHub’s infrastructure.
Note: Packet loss in a ping doesn’t always mean a slow internet connection; it often means the specific IP you’re being routed to has a problem.
DNS lookup
nslookup github.comName: github.com
Address: 20.87.245.0DNS was resolving github.com to 20.87.245.0 – a broken or mis‑routed IP. Large services like GitHub use many IPs; a bad cache or propagation issue can point you at a dead one.
Step 3 – Port Check — Is It Just HTTPS? 🔌
nc -zv github.com 443 -w 5No connection – port 443 was unresponsive via that IP.
What about SSH (port 22)? I kept that in mind for later.
Step 4 – Traceroute — Where Does the Connection Die? 🗺️
traceroute github.com 1 192.168.x.x (192.168.x.x) 14.672 ms
2 10.x.x.x (10.x.x.x) 9.098 ms
3 * * *
4 * * *
5 * * *(Local IPs anonymised)
Hops 1‑2 (router & ISP gateway) responded fine. After that: silence. The connection was dying somewhere in the ISP’s routing infrastructure, well before reaching GitHub’s servers.
Typical causes:
- Routing failure at the ISP level
- Traffic being directed to a bad IP that simply drops packets (most likely here, given the DNS evidence).
Step 5 – Verify the Fix With a Known‑Good IP 🧪
Bypassing DNS entirely lets us test the raw network:
curl --resolve github.com:443:140.82.121.3 https://github.comResult: 200 OK ✅
The network is fine; the problem is DNS returning a bad IP.
How to find legitimate GitHub IPs:
curl https://api.github.com/meta– GitHub publishes its official IP ranges here.
Step 6 – Override DNS via /etc/hosts 🔧
Fastest local fix:
echo "140.82.121.3 github.com" | sudo tee -a /etc/hostsor edit the file manually:
sudo nano /etc/hosts
# Add this line:
140.82.121.3 github.comNow the OS will ignore DNS for github.com and use the supplied IP.
Result: GitHub loads instantly in the browser.
But git push still fails because the remote URL is still using HTTPS (port 443), which remains affected by the routing issue.
Step 7 – Switch Git Remote from HTTPS to SSH 🔑
SSH uses port 22, which was unaffected.
Check the current remote
git remote -v
# origin https://github.com/your-username/your-repo.git (fetch)
# origin https://github.com/your-username/your-repo.git (push)Change to SSH
git remote set-url origin git@github.com:your-username/your-repo.gitVerify
git remote -v
# origin git@github.com:your-username/your-repo.git (fetch)
# origin git@github.com:your-username/your-repo.git (push)Push again
git push origin feat/add-tests
# ✅ SuccessComparison: HTTPS vs. SSH
| Method | Port | Auth | Best For |
|---|---|---|---|
| HTTPS | 443 | Username + password or personal access token | Simple setup, works behind most firewalls, good for occasional pushes |
| SSH | 22 | SSH keys (public‑key authentication) | Frequent pushes, no token management, faster after initial setup |
TL;DR
- Diagnose –
curl,ping,nslookup,tracerouteshowed a bad DNS entry (20.87.245.0). - Confirm – Bypassing DNS (
curl --resolve …) proved the network itself was fine. - Fix – Either override DNS locally (
/etc/hosts) or switch the Git remote to SSH, which avoids the problematic HTTPS port.
Now pushes work again, and you have a solid troubleshooting workflow for any future “GitHub timeout” mysteries. 🎉
TTPS vs. SSH for Git
| Protocol | Port | Authentication | Use Case |
|---|---|---|---|
| HTTPS | 443 | Username + PAT token | Simple setups, one‑off clones |
| SSH | 22 | SSH key pair | Frequent pushes, automation, CI/CD |
Note: SSH is worth setting up properly if you haven’t already—no tokens to rotate, no passwords to enter, and, as this situation showed, port 22 is far less likely to be caught up in DNS/routing failures than 443.
Key Takeaways 💡
- A
curlstatus of000means zero connectivity – not a server error, not a redirect. Nothing got through. - DNS can return broken IPs. Large services like GitHub use many IPs. Caching issues can leave you pointed at one that’s dead or mis‑routed.
- Traceroute tells you where things break. If packets die at hop 3+, the issue is upstream of you – your ISP or beyond.
/etc/hostsis a surgical bypass tool. It skips DNS entirely for a specific hostname. Useful in emergencies, but remember to revert it once DNS is healthy again.- SSH over HTTPS for Git – always, if you can. It’s more secure, needs no token management, and uses a different port that’s often unaffected when HTTPS routes break.
- Always verify IPs against official sources. Hard‑coding a rogue IP in
/etc/hostsis a real MITM vector. Use to confirm.
Full Troubleshooting Cheatsheet
# 1. Check if HTTPS is reachable at all
curl -s -o /dev/null -w "%{http_code}" https://github.com
# 2. Check DNS resolution
nslookup github.com
# 3. Test connectivity to a known‑good IP without changing DNS
curl --resolve github.com:443:140.82.121.3 https://github.com
# 4. Check if port 443 is open
nc -zv github.com 443 -w 5
# 5. Trace where packets are dying
traceroute github.com
# 6. Override DNS locally
echo "140.82.121.3 github.com" | sudo tee -a /etc/hosts
# 7. Check your Git remote
git remote -v
# 8. Switch remote to SSH
git remote set-url origin git@github.com:your-username/your-repo.gitConclusion
What looked like a random GitHub outage turned out to be a DNS routing failure – solvable with a two‑line fix once you know what you’re looking for. The traceroute and curl tests were the real turning point: they made the invisible visible, showing exactly where the connection was breaking and why.
If you take nothing else from this, learn to read traceroutes, and set up SSH for Git. Both have saved me hours of confusion.
Got questions, or your own DNS war stories? Drop them in the comments 👇
TL;DR
git pushfailed with a port 443 timeout.curlreturned000– no connection at all.- DNS was resolving GitHub to a broken IP (
20.87.245.0). - Traceroute confirmed the failure was upstream, not local.
- Fixed short‑term with
/etc/hostspointing to a working IP. - Fixed properly by switching the Git remote from HTTPS → SSH (port 22).