Fix Git Pull on a Mobile Hotspot: Step-by-Step

Updated 4 November 2026 · Standard formula, shown below

If you’re getting errors like “fatal: unable to access” or “Failed to connect to github.com port 443: Operation timed out” when running git pull over a mobile hotspot, the fix usually involves increasing Git’s timeout, switching to a more reliable protocol, or adjusting your hotspot’s DNS settings. This guide walks you through the most effective solutions, from quick command-line tweaks to hotspot configuration changes, so you can get back to syncing your repository.

Why Git Pull Fails on Mobile Hotspots

Mobile hotspots (phone tethering, portable Wi-Fi dongles, or built-in laptop SIM slots) are fundamentally different from wired or office Wi-Fi. They use cellular networks (LTE, 5G) that have higher latency, variable bandwidth, and frequent brief dropouts. Git’s default settings assume a relatively stable connection, so it gives up quickly when a request takes too long. Common symptoms include:

fatal: Unable to access 'https://...': Failed to connect to ... port 443: Operation timed out
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 (connection reset by server)
fatal: early EOF or index-pack failed when pulling large repositories

These errors are not usually caused by a bad repository or wrong credentials; they’re network reliability issues. The fixes below address the root causes: too-short timeouts, inefficient protocol negotiation, and DNS resolution problems.

Step 1: Increase Git’s HTTP Timeout

Git’s default HTTP timeout is 60 seconds, which is often too short for a slow or jittery hotspot connection. You can increase it globally (affects all repositories) or per-repository. Open your terminal and run:

Check the current value (optional): git config --global http.lowSpeedLimit and git config --global http.lowSpeedTime (they may be unset).
Set a longer timeout: git config --global http.lowSpeedLimit 1 and git config --global http.lowSpeedTime 300. This tells Git to wait up to 300 seconds (5 minutes) before aborting if the transfer speed drops below 1 byte/second.
Also increase the overall timeout: git config --global http.timeout 300 (some Git versions use this instead).

After making these changes, try git pull again. If it still fails, proceed to the next step.

Step 2: Switch from HTTPS to SSH (or Vice Versa)

HTTPS and SSH use different ports and handshake mechanisms. On some mobile networks, port 443 (HTTPS) is throttled or blocked, while port 22 (SSH) works fine, or the opposite. If you’re using HTTPS, switch to SSH:

Check if you have an SSH key: ls ~/.ssh/id_ed25519.pub or ls ~/.ssh/id_rsa.pub. If not, generate one: ssh-keygen -t ed25519 -C "your_email@example.com" (press Enter to accept defaults).
Add the public key to your Git hosting account (GitHub, GitLab, Bitbucket) under Settings â†’ SSH keys.
Change your remote URL from HTTPS to SSH: git remote set-url origin git@github.com:username/repo.git (replace with your actual host and path).
Test with git pull.

If you’re already on SSH and it’s failing, try switching to HTTPS temporarily. Sometimes the reverse works because SSH uses a different TCP connection that may be more stable on your carrier.

Step 3: Tweak Your Hotspot’s DNS and MTU

DNS (Domain Name System) resolution can be slow or fail on some mobile networks, especially if the hotspot’s DNS server is overloaded. Also, the Maximum Transmission Unit (MTU) on the hotspot may be set to a value that fragments Git’s large packets, causing corruption. Here’s how to address both:

Change DNS: On your computer, set a public DNS server (like Google’s 8.8.8.8 and 8.8.4.4, or Cloudflare’s 1.1.1.1) in your network settings. This is done in the OS network adapter properties, not in Git.
Reduce MTU: On Windows, open Command Prompt as Administrator and type netsh interface ipv4 show subinterfaces to see your MTU. Then set it lower: netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent (replace “Wi-Fi” with your hotspot connection name). On macOS, use sudo ifconfig en0 mtu 1400 (replace en0 with your interface). A lower MTU (1400 or 1450) avoids fragmentation issues common on cellular networks.

After changing DNS or MTU, restart your network connection and try git pull again.

Step 4: Use a Shallow Clone or Fetch with Depth

If the repository is large (many commits or big binary files), a full pull can be too heavy for a hotspot. You can limit the amount of data transferred:

For a one-time sync, fetch only the latest commit: git fetch --depth=1 origin main (replace main with your branch). Then git reset --hard origin/main to update your working tree.
If you want to keep history but reduce initial transfer, use git pull --depth=1 (this creates a shallow clone). Note that this may limit some Git operations later.
Alternatively, use git pull --rebase instead of a merge; it can sometimes avoid large merge commits that cause timeouts.

Shallow pulls are a temporary workaround, not a permanent solution. Once you’re on a stable connection, you can deepen the history with git fetch --unshallow.

Step 5: Use a Download Manager or Alternative Transfer Method

If Git itself keeps failing, you can bypass it temporarily. For example, if you just need the latest files, download the repository as a ZIP archive from the web interface (GitHub’s “Code” â†’ “Download ZIP”). For a more Git-friendly approach, use a tool like git bundle:

On a machine with stable internet, create a bundle: git bundle create repo.bundle --all (inside the repository).
Transfer the bundle file to your hotspot-connected machine (via USB, Bluetooth, or cloud storage).
Then clone from the bundle: git clone repo.bundle (or fetch from it).

This is a great fallback when the hotspot is too unreliable for direct Git communication.

Common Problems and Misconceptions

Many users think the issue is with their Git credentials or the remote server, but it’s usually the network. Here are a few clarifications:

“I have full bars, so the connection is fine.” Signal strength doesn’t equal low latency or stable throughput. Congestion on the cell tower or carrier throttling can cause timeouts even with full signal.
“Git pull works on my phone’s browser, so the network is fine.” Browsers are more tolerant of slow responses and use different TCP settings than Git. Also, the browser may be caching.
“I tried increasing the timeout, but it still fails.” Sometimes the issue is not the timeout but the connection being reset by the server or a middlebox. In that case, switching protocols (SSH vs HTTPS) or using a VPN can help.
“Using a VPN will fix it.” Not always, but it can help if your ISP or carrier is throttling Git traffic. A VPN encrypts and reroutes traffic, which may avoid throttling. However, it adds overhead and may make things slower.

Frequently Asked Questions

Why does git pull work on my home Wi-Fi but not on my hotspot?

Because home Wi-Fi typically has a stable, low-latency connection to the internet, while mobile hotspots use cellular networks that are more variable. The higher latency and occasional packet loss cause Git’s default timeouts to trigger, leading to failures.

Will changing my DNS break anything?

No. Changing your DNS to a public resolver like Google’s or Cloudflare’s is safe and often improves speed. It only affects how domain names are resolved; it doesn’t alter your internet connection otherwise.

Can I use a different Git port to bypass blocking?

Yes. SSH can run on port 443 (commonly used for HTTPS) if your hosting provider supports it. For GitHub, you can use ssh -T -p 443 git@ssh.github.com to test. If that works, you can configure your SSH client to use port 443 for GitHub. This is useful when port 22 is blocked by the hotspot.

Is there a way to make git pull more resilient automatically?

You can write a small script that retries the pull a few times with backoff. For example, a shell loop that runs git pull and if it fails, waits 5 seconds and retries, up to 3 times. This is not built into Git, but it’s a practical workaround for flaky connections.

Why do I get “error: RPC failed; curl 56”?

This error usually means the connection was reset during the transfer. It can be due to a firewall or proxy on the hotspot that drops long-lived connections, or simply a weak signal. The fixes above (timeout increase, protocol switch, or shallow fetch) often resolve it.

Should I use a mobile hotspot for large Git operations at all?

It’s possible but not ideal. For large repositories, consider using a stable connection or the bundle method. If you must use a hotspot, use shallow fetches and increase timeouts to minimize the chance of failure.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.