DEV Community

cynthia
cynthia

Posted on

Deep Dive: Resolving DNS Issues with GitHub and Understanding SSH vs HTTPS

#git #github #networking #devops

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 — and what started as a frustrating blocker turned into a genuinely useful deep dive into DNS, network routing, and Git's connection methods. 🚀

Let me walk you through every step.

The Problem: GitHub, You're Killing Me 😩

Everything was going fine until I ran a routine push:

git push origin feat/add-tests
Enter fullscreen mode Exit fullscreen mode

Instead of the usual success, I got:

fatal: 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 server
Enter fullscreen mode Exit fullscreen mode

75 seconds of waiting, then nothing. Time to dig in. 🔍

Step 1: Is GitHub Actually Down? 🌐

Before blaming my own setup, I checked whether GitHub was reachable at all:

curl -s -o /dev/null -w "%{http_code}" https://github.com
Enter fullscreen mode Exit fullscreen mode

The response? 000

A 000 status code from curl means the request never even got a response — no HTTP handshake, no connection, nothing. GitHub's HTTPS port was completely unreachable from my machine.

Step 2: Ping & DNS Lookup — Finding the Culprit 🕵️‍♂️

Ping test 

$ ping -c 2 github.com
PING 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 ms
Enter fullscreen mode Exit fullscreen mode

Packet loss right away. The IP 20.87.245.0 was responding inconsistently — not the behavior you'd expect from GitHub's infrastructure.

Note: Packet loss in a ping doesn't always mean slow internet. It often means the specific IP you're being routed to has a problem.

DNS lookup 

$ nslookup github.com
Name:    github.com
Address: 20.87.245.0
Enter fullscreen mode Exit fullscreen mode

There it was. DNS was resolving github.com to 20.87.245.0 — a broken or misrouted IP. Large services like GitHub use many IPs across their infrastructure. When DNS caching or propagation goes wrong, you can end up pointed at one that's temporarily dead.

Step 3: Port Check — Confirm It's Not Just a General Outage 🔌

To rule out a broader network issue, I checked whether GitHub's HTTPS port (443) specifically was blocked:

nc -zv github.com 443 -w 5
Enter fullscreen mode Exit fullscreen mode

No connection. Port 443 was unresponsive via that IP.

But this raised an interesting question — if HTTPS (port 443) is blocked, what about SSH (port 22)? I kept that in mind for later.

Step 4: Traceroute — Where Is the Connection Actually Dying? 🗺️

Running a traceroute showed exactly where packets were getting dropped:

$ 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  * * *
Enter fullscreen mode Exit fullscreen mode

(Local IPs anonymised)

Hops 1 and 2 — my local router and ISP gateway — responded fine. After that: silence. The connection was dying somewhere in the ISP's routing infrastructure, well before reaching GitHub's servers.

This is a classic sign of either:

  • A routing failure at the ISP level
  • Traffic being directed to a bad IP that simply drops packets

The DNS evidence from earlier made the latter the most likely culprit.

Step 5: Verify the Fix With a Known-Good IP 🧪

Before touching any system config, I tested whether the network itself was fine by bypassing DNS entirely:

curl --resolve github.com:443:140.82.121.3 https://github.com
Enter fullscreen mode Exit fullscreen mode

This forces curl to connect to 140.82.121.3 (a legitimate GitHub IP) while keeping the hostname intact for TLS. The result? 200 OK. ✅

The network was fine. The problem was purely DNS returning a bad IP.

How to find legitimate GitHub IPs: Check https://api.github.com/meta — GitHub publishes their official IP ranges here.

Step 6: Override DNS via /etc/hosts 🔧

With the root cause confirmed, the fastest fix was to bypass DNS locally:

echo "140.82.121.3 github.com" | sudo tee -a /etc/hosts
Enter fullscreen mode Exit fullscreen mode

Or edit the file manually:

sudo nano /etc/hosts
# Add this line:
140.82.121.3 github.com
Enter fullscreen mode Exit fullscreen mode

This tells your OS: "Don't ask DNS where github.com is — I'm telling you directly."

After saving, GitHub loaded instantly in the browser. But the git push was still failing — because my remote was still using HTTPS.

Step 7: Switch Git Remote from HTTPS to SSH 🔑

Here's what I had been missing. Even with the /etc/hosts fix, port 443 was still being affected by the underlying routing issue. SSH uses port 22, which was completely unaffected.

Check your 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)
Enter fullscreen mode Exit fullscreen mode

Switch to SSH: 

git remote set-url origin git@github.com:your-username/your-repo.git
Enter fullscreen mode Exit fullscreen mode

Verify: 

git remote -v
# origin  git@github.com:your-username/your-repo.git (fetch)
# origin  git@github.com:your-username/your-repo.git (push)
Enter fullscreen mode Exit fullscreen mode

Then:

git push origin feat/add-tests
# ✅ Success
Enter fullscreen mode Exit fullscreen mode

Here's a quick comparison of both methods:

Method Port Auth Best For
HTTPS 443 Username + PAT token Simple setups, one-off clones
SSH 22 SSH key pair Frequent pushes, automation, CI/CD

SSH is worth setting up properly if you haven't — 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 💡

  1. A curl status of 000 means zero connectivity — not a server error, not a redirect. Nothing got through.

  2. DNS can return broken IPs. Large services like GitHub use many IPs. Caching issues can leave you pointed at one that's dead or misrouted.

  3. Traceroute tells you where things break. If packets die at hop 3+, the issue is upstream of you — your ISP or beyond.

  4. /etc/hosts is 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.

  5. 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.

  6. Always verify IPs against official sources. Hardcoding a rogue IP in /etc/hosts is a real MITM vector. Use api.github.com/meta 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.git
Enter fullscreen mode Exit fullscreen mode

Conclusion

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 push failed with a port 443 timeout
  • curl returned 000 — 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/hosts pointing to a working IP
  • Fixed properly by switching Git remote from HTTPS → SSH (port 22)

Top comments (0)