On googling this error it seems that a lot of people are having this issue.

apt-get upgrade hangs at 0% [waiting for headers] apt-get install apache2 hangs at 0% [waiting for headers]. Some apt-get commands are working, but only certain packages.

Any ideas? I don't think this is an issue with slow repos because I've had it up for a long while and it hasn't budged from 0%. I have edited sources.list but I removed the lines I added when this issue presented itself and it hasn't made a difference.

Any clues would be really useful.

  • Your Internet connection is disconnected... Sep 27, 2014 at 5:13
  • askubuntu.com/questions/156650/… read the mtu related answer, might be a help Oct 5, 2014 at 22:30
  • I have tried all the solutions above, none of them work. I even tried a reboot at the command prompt, still the same,the 0% remains stuck forever. This is a serious issue because it hampers, slows down, or even prevents the user from installing and running programs or apps. I have never seen this happen in Ubuntu 14.04. I don't think it's caused by problems of Internet connection, because whenever the problem occurs I keep checking my browser by going to different websites and I am able to surf with no problem. I think it's a bug in Ubuntu 16.04 and it needs to be fixed fast.
    – Plutarc
    Nov 28, 2016 at 22:39
  • For me it was because I was connected to my work VPN - couldn't connect to deb.nodesource.com, for instance. Disconnected from VPN - no problem. Connect again to VPN - problem. Won't be the source of the problem for everyone but if you are using a VPN and having this problem, try disconnecting. (can't post answer 'cause not enough rep)
    – drkvogel
    Dec 17, 2020 at 11:29
  • I echo @drkvogel. As soon as I came off my VPN, quick and easy results. I also can't post because I don't have enough reputation.
    – Casivio
    Apr 19 at 17:19

5 Answers 5


Try to change the server selecting update manager, definitions,downloading from, then select a server more near you. and then try again.

Edit: see this link on how to add it by editing sources.list. How can I get apt to use a mirror close to me, or choose a faster mirror?

  • 2
    any idea how to do this over ssh? Jan 12, 2012 at 10:31
  • 2
    You edit /etc/apt/sources.list to point to a different mirror
    – tumbleweed
    Jan 12, 2012 at 10:35

The easiest approach consist of following commands:

sudo apt-get clean


sudo apt-get update


sudo apt-get install <package_name>


Let me know if it works


I had to

sudo apt-key update
sudo apt-get update

From manpages:

apt-key is used to manage the list of keys used by apt to authenticate packages. Packages which have been authenticated using these keys will be considered trusted.

  • 1
    apt-key does not magically make HTTP responses happen. Jan 26, 2018 at 20:17
  • @ChaiT.Rex It does however update the keyring which solved the problem for me.
    – Stiin
    Jan 29, 2018 at 21:25
  • The keyring isn't the problem with 0% [waiting for headers]. The problem with 0% [waiting for headers] is that the HTTP connection has stalled. Retrying the command will start a new HTTP connection, which might not get stuck. That (running sudo apt-get update again) is what solved the specific problem of 0% [waiting for headers] for you. Keys are involved in the process after the HTTP connection is finished, when checking the finished downloads. Jan 29, 2018 at 21:28

If you are using a proxy server and have those settings in your user environment, try:

sudo -E apt update

to run the command as root but using your current user's environment.


(Just reposting this as the original was inexplicably deleted)

I noticed this problem on a VM running Xenial in a data centre this week that had been running for 10 years ( upgraded through many Ubuntu LTS releases in that time).

I got tcpdump running to log requests to the URLs in /etc/apt/sources.list and didn't see any requests when I ran apt-get update


 tcpdump -i eth0 host archive.ubuntu.com

If I tried to fetch from the host using wget , it worked fine


wget archive.ubuntu.com/

Eventually I found that the ISP had set a proxy for apt in /etc/apt/apt.conf on my VM back in 2009 when the VM was first activated.

      Proxy "http://apt2.memset.net:3128";

Evidently the proxy recently stopped working correctly.

I deleted the block above from my /etc/apt.conf and normality was restored

Not the answer you're looking for? Browse other questions tagged or ask your own question.