fatal: unable to update url base from redirection - What It Means and the 5 Causes (git clone, git push, proxy login page, wrong URL, renamed repo)

TL;DR

• What it means: git sent its first request (GET <your-url>/info/refs?service=git-upload-pack for clone and fetch, git-receive-pack for push) and the server answered with a redirect to a different path. git only follows a redirect that keeps the same /info/refs?service=... tail; anything else, for example /404.html or /login, triggers unable to update url base from redirection.
• The two lines under the error tell you everything: asked for: is the URL git built from your remote, redirect: is where the server tried to send it. If the redirect ends in 404.html, the repository URL is wrong or the repository is gone. If it ends in a login page, you are behind a proxy, VPN portal or captive Wi-Fi page.
• The fix in 90% of cases: git remote -v, then git remote set-url origin https://github.com/<user>/<repo>.git with the URL copied from the repository page. For the proxy case, connect to the VPN or clear http.proxy and HTTPS_PROXY.
• On GitHub, a missing .git suffix is fine (I checked with git 2.55: git ls-remote https://github.com/rahulwagh/vpc-subnet-planner works). A deleted or private repository gives a different error, remote: Repository not found. The redirect error on GitHub today almost always means a typo that lands on a user page, or a proxy in between.
• Reproduced below on 2026-10-12 with git 2.55.0 for both clone and push, against a server that redirects to a 404 page.
• Not your exact case? The closest post on this site is git@github.com.

Table of Content

1. What the error means, with the real output
2. The 5 causes and how to tell them apart in one command
3. Cause 1 - the repository URL is wrong or the repository is gone
4. Cause 2 - a proxy, VPN portal or captive Wi-Fi page answers instead of the server
5. Cause 3 - the remote URL is stale after a rename or transfer
6. Cause 4 - http instead of https, or a mirror that moved
7. Cause 5 - an editor or tool with its own proxy setting
8. What broke when I ran this
9. Errors that look similar but are not this one
10. Conclusion

1. What the error means, with the real output

I first hit this years ago while cloning one of my own repositories with a URL I had copied wrong. Here is the error exactly as git 2.55.0 prints it today. I reproduced it on 2026-10-12 with a small local server that answers the way a 404 page or a proxy login page does - it redirects git's very first request to a different path -

1$ git clone http://127.0.0.1:8765/rahulwagh/k8s-jenkins-aws.git
2Cloning into 'k8s-jenkins-aws'...
3fatal: unable to update url base from redirection:
4  asked for: http://127.0.0.1:8765/rahulwagh/k8s-jenkins-aws.git/info/refs?service=git-upload-pack
5   redirect: http://127.0.0.1:8765/rahulwagh:/404.html

And the same thing on a push, where the only difference is the service name, git-receive-pack -

1$ git push origin master
2fatal: unable to update url base from redirection:
3  asked for: http://127.0.0.1:8765/rahulwagh/k8s-jenkins-aws.git/info/refs?service=git-receive-pack
4   redirect: http://127.0.0.1:8765/rahulwagh:/404.html

What is going on: the smart HTTP protocol starts every clone, fetch and push with one GET request for <repo-url>/info/refs?service=git-upload-pack (or git-receive-pack). git is happy to follow a redirect for that first request - that is how http://github.com/... silently becomes https://github.com/... - but only if the redirected URL still ends with the same /info/refs?service=... path. Then it can work out the new base URL of the repository. If the server redirects to anything else, git cannot derive a repository URL from it and stops with this error. The git-config documentation describes the setting behind this, http.followRedirects, whose default initial is exactly "follow redirects on the first request only".

So the error is never about your credentials and never about the git version. It is the server (or something in front of it) sending git to a web page.

2. The 5 causes and how to tell them apart in one command

Read the redirect: line. It tells you which case you are in -

The curl check is the fastest way to see what git sees, because it prints the Location: header of the redirect -

1curl -sI "https://github.com/rahulwagh/k8s-jenkins-aws.git/info/refs?service=git-upload-pack" | head -5

A healthy repository answers HTTP/2 200 (or a 401 asking for credentials on a private one). A 301 or 302 with a Location: pointing at a web page is this error.

3. Cause 1 - the repository URL is wrong or the repository is gone

The most common cause, and the one I caused myself. A typo in the user or repository name, a copy-paste that grabbed the page URL of a profile rather than a repository, or a repository that the owner deleted. The server has no repository at that path, so it sends git to its 404 page, and the redirect line ends with 404.html -

1redirect: https://github.com/rahulwagh:/404.html

Resolution - open the repository in a browser, click the green Code button and copy the HTTPS URL from there instead of retyping it. Then point your remote at it -

1git remote -v
2git remote set-url origin https://github.com/rahulwagh/k8s-jenkins-aws.git
3git remote -v

If the repository really is gone, ask the owner for the new location; GitHub keeps redirects for renamed repositories but not for deleted ones (see the GitHub documentation on renaming a repository).

About the .git suffix. The first version of this post told you to always add .git. That advice is out of date for GitHub: today both https://github.com/rahulwagh/k8s-jenkins-aws.git and https://github.com/rahulwagh/k8s-jenkins-aws clone fine (I verified it with git ls-remote in section 8). On some self-hosted servers and corporate proxies the URL without .git is still routed to the web UI, so if you are not on github.com, keep the suffix.

4. Cause 2 - a proxy, VPN portal or captive Wi-Fi page answers instead of the server

The second most common cause, and the one that produces the most confusing redirect lines, is something in front of the server answering with a login page. Three flavours -

1. Corporate proxy that requires authentication: git's request never reaches GitHub, the proxy answers 302 Location: https://proxy.company.com/login.
2. VPN disconnected: your internal GitLab or Bitbucket is only reachable on the VPN; the DNS name resolves to a portal that redirects to a sign-in page.
3. Captive Wi-Fi (hotel, airport, train): every request is redirected to the "accept the terms" page until you click it.

Check what git is using -

1git config --global --get http.proxy
2git config --global --get https.proxy
3env | grep -i proxy

Resolution - connect to the VPN or sign in to the portal first, then retry. If a proxy is configured that you do not need any more, remove it -

1git config --global --unset http.proxy
2git config --global --unset https.proxy

And if the proxy is needed but it also inspects TLS, you will next meet SSL certificate problem: self signed certificate in certificate chain - that one is covered in two ways to fix the self-signed certificate error, and the same proxy breaks pip in the same way (pip install trusted host).

5. Cause 3 - the remote URL is stale after a rename or transfer

Working with many repositories over years, the remote URL in an old checkout can point at a repository that has since been renamed, moved to an organisation, or migrated from Bitbucket to GitHub. GitHub redirects renamed repositories to the new name, which git follows fine - but a migration to a different host, or a server that redirects to the web page of the new location instead of the git endpoint, ends in this error.

1# what does this checkout think the remote is?
2git remote -v
3
4# point it at the current location
5git remote set-url origin https://github.com/<org>/<new-name>.git

Here is what the fix looks like on a checkout I pointed at my planner repository on 2026-10-12 -

1$ git remote set-url origin https://github.com/rahulwagh/vpc-subnet-planner.git
2$ git remote -v
3origin	https://github.com/rahulwagh/vpc-subnet-planner.git (fetch)
4origin	https://github.com/rahulwagh/vpc-subnet-planner.git (push)
5$ git ls-remote --heads origin
6816d52eba0696a1e22c2ed6be0fdaa6028b69c06	refs/heads/main

git ls-remote is the cheapest test of a remote URL: it only performs the info/refs request, so it fails with exactly the same error as a clone would, without touching your working copy. Against GitHub it took 707 ms on my connection (about 0.7 seconds), and the raw curl -sI check of the same endpoint answered 200 in 0.26 seconds - so if either of them hangs for 15 seconds or more, you are looking at a proxy or a VPN that is not connected, not at this error.

6. Cause 4 - http instead of https, or a mirror that moved

A plain http:// URL is normally fine: GitHub redirects it to https:// with the same path, git follows it and prints a one-line warning -

1$ git clone http://github.com/rahulwagh/vpc-subnet-planner redir-test2
2Cloning into 'redir-test2'...
3warning: redirecting to https://github.com/rahulwagh/vpc-subnet-planner/

That warning is harmless; the clone continues. The error in this post appears only when the redirect also changes the path - for example a mirror that moved from http://git.internal/repos/app.git to https://code.internal/app and redirects old URLs to its landing page. The fix is the same as above: use the URL the new server advertises.

7. Cause 5 - an editor or tool with its own proxy setting

If git on the command line works but TortoiseGit, IntelliJ, Eclipse or Visual Studio fails with this error, the tool has its own proxy configuration that overrides your environment. Each of them has a proxy page in its settings; clear it, or set it to the same proxy the command line uses. The same applies to a url.<base>.insteadOf rewrite in your .gitconfig that quietly sends requests to an old mirror -

1git config --global --get-regexp 'url\..*insteadof'

8. What broke when I ran this

To get real output for this post I tried to reproduce the error on 2026-10-12 with git 2.55.0.windows.3, and the first three attempts did not produce it at all. That is useful to know, because each one is an error people confuse with this one.

1. A non-existent GitHub repository does not give this error any more. GitHub answers the info/refs request for a missing repository with a proper error, not a redirect -

1$ git ls-remote https://github.com/rahulwagh/does-not-exist-xyz
2remote: Repository not found.
3fatal: repository 'https://github.com/rahulwagh/does-not-exist-xyz/' not found

So if you see Repository not found, the URL points at GitHub correctly and the repository is missing, private, or you are not logged in as a user who can see it. The redirect error on GitHub needs the URL to land somewhere that is not a repository endpoint at all - a profile page, or a proxy.

2. The missing .git suffix is not a cause on GitHub. Both forms work -

1$ git ls-remote https://github.com/rahulwagh/vpc-subnet-planner
2816d52eba0696a1e22c2ed6be0fdaa6028b69c06	HEAD
3816d52eba0696a1e22c2ed6be0fdaa6028b69c06	refs/heads/main

The first version of this post listed it as cause number 3. I have kept the advice only for self-hosted servers, where it still bites.

3. A server that redirects every request produces a different error. My first test server redirected the login page itself as well, and git gave up with fatal: unable to access '...': Maximum (20) redirects followed. Only when the login page answered with a 200 did git produce the unable to update url base error. If you see the Maximum (20) redirects message, the diagnosis is the same (a proxy or portal in the way), git just hit the loop before it could complain about the base URL.

9. Errors that look similar but are not this one

10. Conclusion

unable to update url base from redirection is git telling you that the server sent it to a web page instead of a repository. The redirect: line names the page, and that line is the whole diagnosis -

1. 404.html or a profile page: wrong or deleted repository. Copy the clone URL from the repository page and git remote set-url origin <url>.
2. A login or portal page: proxy, VPN or captive Wi-Fi. Connect, sign in, or unset http.proxy.
3. The repository moved: update the remote.
4. An editor with its own proxy: fix it in the editor.

git ls-remote <url> reproduces the error in a second and is the first thing to run. The protocol detail behind it is in the git-config documentation for http.followRedirects, and the GitHub side of cloning in the GitHub documentation on cloning a repository.