I am currently accessing my RPi on my local network (which is working perfectly fine*) via SSH. On the RPi I can ping any website and it correctly resolves, but I cannot curl or wget the same webserver. Using X11 forwarding, I confirmed this behaviour on the chromium-browser too. Furthermore, apt update also times out as a result of this whilst being stuck on "Waiting for headers".

Both my router, and the rpi have their DNS servers set to, and

$ uname -a
Linux raspberrypi 5.15.61-v7l+ #1579 SMP Fri Aug 26 11:13:03 BST 2022 armv7l GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye
$ cat /etc/resolv.conf
cat /etc/resolv.conf
# Generated by resolvconf
domain broadband
nameserver fe80::a2b5:3cff:fe0a:39f7%wlan0
$ ping google.com
PING google.com ( 56(84) bytes of data.
64 bytes from lhr25s34-in-f14.1e100.net ( icmp_seq=1 ttl=119 time=19.4 ms
64 bytes from lhr25s34-in-f14.1e100.net ( icmp_seq=2 ttl=119 time=19.2 ms
$ wget google.com
--2022-10-09 17:52:14--  http://google.com/
Resolving google.com (google.com)..., 2a00:1450:4009:81f::200e
Connecting to google.com (google.com)||:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Any suggestions on what could be causing this?

*: I say it's working fine because I have not had any issues with any other devices. My desktop runs linux, my laptop runs windows, and both ok. Chromecast, mobile, phones, etc. are working correctly. Or so it seems at least

  • I can ping any website ... no ... that should say I can ping any web server ... pinging a web server and getting data from a web server are two different things
    – jsotola
    Commented Oct 9, 2022 at 18:08
  • 1
    please add a clear, answerable question to your post
    – jsotola
    Commented Oct 9, 2022 at 18:09
  • Your wget google.com works fine on my (headless) RPi. You said, "... my local network (which is working perfectly fine)", but I suspect that's not actually the case. You could improve your question by explaining why you think your network is "perfectly fine", but I'll guess that if you do some additional testing you'll find something wrong.
    – Seamus
    Commented Oct 10, 2022 at 1:33
  • long shot here ... that time --2022-10-09 17:52:14-- in wget, is that the correct time? Though, I think that would only cause issues with https if your time is wrong Commented Oct 10, 2022 at 3:14
  • @jsotola edited Commented Oct 10, 2022 at 6:32

1 Answer 1


First point to make is that I do not believe this is an "RPi Problem", and might be considered "off-topic" by some. That said:

The fact that 6 to 8 (or even 800) other hosts have no issue isn't particularly useful - unless they're identically configured. "Connection reset by peer" means that google.com's host issued the RST - we have no idea what condition prompted it to issue a RST.

You may have noted my comment stating that your original command (wget google.com) executed successfully on my RPi. Why did it work on my RPi, and not on yours? Maybe it was because Google is my ISP, maybe it's because my packets originated from an area of the world that Google thinks is "safe", maybe it was because my version of wget is different than yours, maybe..... My point is this: No one outside of Google (unless it's in their published documentation - which I doubt) can tell you what conditions triggered their server to issue a reset (RST). Run a million tests, and you might get some theories on their logic, but you still won't get a definitive answer.

You might try this:

wget https://google.com  

Other than that, there are some troubleshooting steps to take that might help you resolve this. This search turned up a few that looked promising.

  • Hi @Seamus, thanks for your response. wget https://google.com works but wget google.com doesn't, likewise for curl. However, when running as proxy server on my desktop, curl -x "" google.com works perfectly fine ... Commented Oct 10, 2022 at 7:23
  • As I said, Google's server issued the reset (RST); it is doing what Google programmed it to do under the circumstances. Therefore, only Google (or their documentation - if it's published) can tell you why it issued the RST. Hopefully, this is clear to you now???
    – Seamus
    Commented Oct 10, 2022 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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