Extremely slow transfers from GitHub's servers

[logiclrd]

Select Topic Area

Question

Body

I am seeing very slow transfers from GitHub's servers. For instance:

I can confirm these speeds right down to the bare metal connected to my network uplink. Meanwhile, speed tests such as Ookla Speedtest measure my downlink at ~5Mbps. But, if I provision a different IP address from my provider, I get (at least one) fast Git Clone of exactly the same repository URL. (I haven't checked whether the speed remains fast over a whole series of clones, such as the submodules being cloned in the first screenshot.)

I also tried this same Git Clone command, the particular one that's running in the first screenshot, on a test-drive VM provided by distrosea.com:

How can I figure out why I'm seeing such abysmal transfer rates? Is my IP specifically being throttled for some reason??

[Dakshaaaaa]

Hello @logiclrd
This usually happens because GitHub serves traffic through a CDN and routes can differ depending on your ISP/region. If you get much faster speeds with a VPN or different IP, it often means your ISP is routing you through a slower peering connection.

A few things you can try:

1. Switch to GitHub’s SSH or HTTPS endpoints

   bash
   git clone git@github.com:user/repo.git

   or

   git clone https://github.com/user/repo.git

   Sometimes one protocol performs better than the other.

2. Use a Git mirror / CDN acceleration
   Some regions have mirrors (like gitclone.com in China) that proxy GitHub repos with faster speeds.

3. Test different networks
   Try tethering via mobile data or a VPN to confirm whether the issue is with your ISP’s route to GitHub.

4. Shallow clones for speed
   If you only need the latest commit history:

   bash
   git clone --depth 1 https://github.com/user/repo.git

   This fetches far fewer objects and speeds things up.

5. Contact ISP if persistent
   If other services are fast but GitHub is always slow on your line, your ISP may be throttling or have poor peering with GitHub’s CDN.

👉 If this helps you resolve the slow transfer issue, you can mark this as the accepted answer so others with the same problem can find it more easily.

[logiclrd]

What's curious is that the uplink has two static IPs as well as support for dynamic IPs, and on the same uplink, the static IPs are extremely slow, but if I provision one of the dynamic IPs on the NAT's hypervisor, through that IP it saturates the downstream, same connection, same ISP. So, clearly there is a very significant difference between the static IP and the dynamic IP. They share the same locally-caching DNS resolver, so in both cases github.com resolves to the same IP (in this case 140.82.112.4, for what it's worth 😛). The route through the ISP is identical for both source IPs, so it seems to me the only explanation is that that particular GitHub CDN node really doesn't like my static IP. 🙁

[logiclrd]

Well, as far as I can tell this isn't something I can do anything about myself, and the only option is to try to sidestep the issue by switching my Internet uplink to a different IP address. Ah well.

[logiclrd]

There is no solution, the problem is not you nor your ISP so don't let them gaslight you into thinking you have the problem when Azure is the problem. This is specifically with Microsoft related services hosted on Azure, GitHub is one of the many victims. It's widely inconsistent. GitHub is just the latest victim of Microsoft.

Specifically, as far as I've been able to ascertain, the problem does lie in what IP you're using, but it isn't caused by anything on your end. For whatever reason, traffic involving that IP is processed very slowly on the other end. I have a suspicion that it's the result of some sort of denial of service protection mechanism that has been triggered by something on your IP and forever more (or for a long time) is now treating your IP as hostile and deliberately rate-limiting it. I don't currently know of a way to specifically verify this, though.

[ammarsalman94]

Specifically, as far as I've been able to ascertain, the problem does lie in what IP you're using, but it isn't caused by anything on your end. For whatever reason, traffic involving that IP is processed very slowly on the other end. I have a suspicion that it's the result of some sort of denial of service protection mechanism that has been triggered by something on your IP and forever more (or for a long time) is now treating your IP as hostile and deliberately rate-limiting it. I don't currently know of a way to specifically verify this, though.

I have had a session where it was going decently fast for some repos and extremely slow for other repos. So it is not really an IP thing. I also tried VPN with different addresses, same story. Another time I ran a similar script, it downloaded all repos within minutes.

[logiclrd]

I have had a session where it was going decently fast for some repos and extremely slow for other repos. So it is not really an IP thing. I also tried VPN with different addresses, same story. Another time I ran a similar script, it downloaded all repos within minutes.

Interesting. Sounds like there are multiple issues, in that case, with completely different underlying causes.

[ammarsalman94]

And the only common denominator is the server side of things.

[logiclrd]

That would be the case if there was one issue. In my case, I observed extremely slow transfers from any repository from one of my static IPs. When I configured a node with a dynamic IP assigned by my ISP, the exact same repositories performed well. That rules out the server side of things in my case. Hence why I described it as multiple issues with completely different underlying causes.