# Curl: (28) Resolving timed out after 3000 milliseconds RPi3
**URL:** https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813
**Category:** Troubleshooting
**Created:** [2 February 2023 19:05 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813 "2023-02-02T19:05:03Z")
**Posts on this page:** 11
**Page:** 3
### Author:  [@cc13](https://dietpi.com/forum/u/cc13)
#### Post date: [6 February 2023 05:54 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/41 "2023-02-06T05:54:06Z")
Unfortunately I don’t have an USB-Ethernet-Adapter…
Let me summarize:
RPi3 with Ethernet
RPi Zero W with Wifi
Both run in the same curl issue with a fresh installed system. If I setup the upstream DNS to the local PiHole or to the Fritzbox (and then PiHole) it works fine. If I connect the RPi Zero W via Wifi with my smartphone hotspot it looks good. By end of this week I can start a test with this RPi Zero W and another ISP. Probably with another RPI Zero W and an older RPi too.
What I also can do is to remove the PiHole setup from the RPi and from the Fritzbox. I know with e.g. Cloudflare as an upstream DNS PiHole should not impact the setup. Just for testing.
---
### Author:  [@cc13](https://dietpi.com/forum/u/cc13)
#### Post date: [10 February 2023 09:38 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/42 "2023-02-10T09:38:38Z")
As I wrote last time, I test actually with a different ISP. Also different: SD-Card and the laptop to write the image to the SD-Card.
At the moment it looks good. Login after the installation does not show the curl error message. Anything what I can test now?
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [10 February 2023 10:58 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/43 "2023-02-10T10:58:45Z")
I don’t have other ideas to test.
---
### Author:  [@cc13](https://dietpi.com/forum/u/cc13)
#### Post date: [12 February 2023 11:51 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/44 "2023-02-12T11:51:10Z")
That’s so strange. With the same setup (worked on Friday) back behind the original ISP (from the first days) I run in the curl issue again.
It’s the same ISP company, but the difference is: The access is working via “DS-Lite-Tunnel” shown in the Fritz!Box. The working ISP is not showing this in the Fritz!Box. And if I remember right, the working one get a public IP4 address.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [13 February 2023 09:37 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/45 "2023-02-13T09:37:53Z")
hmm that would mean issue is related to IPv6 only connection where no public IPv4 is available?
---
### Author:  [@morbiddk](https://dietpi.com/forum/u/morbiddk)
#### Post date: [23 March 2023 14:52 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/46 "2023-03-23T14:52:25Z")
I’ve been trying to track this down and reading all the posts and I think this last comment on being IP version related might be onto something. I have IPv6 disabled through dietpi-config and can confirm there are no IPv6 addresses on any interface, but curl and wget tests fail resolving DNS in the 3000 milliseconds timeframe however if I force them to use IPv4 only they process like a regular DNS lookup and under 1000 milliseconds. I’m running v8.15.2.
```auto
dietpi@Main:~$ time wget --spider -T 3 dietpi.com
URL transformed to HTTPS due to an HSTS policy
Spider mode enabled. Check if remote file exists.
--2023-03-23 14:21:01-- https://dietpi.com/
Resolving dietpi.com (dietpi.com)... failed: Connection timed out.
wget: unable to resolve host address ‘dietpi.com’
real 0m3.108s
user 0m0.063s
sys 0m0.042s
dietpi@Main:~$ time wget --inet4 --spider -T 3 dietpi.com
URL transformed to HTTPS due to an HSTS policy
Spider mode enabled. Check if remote file exists.
--2023-03-23 14:21:10-- https://dietpi.com/
Resolving dietpi.com (dietpi.com)... 172.67.170.219, 104.21.28.141
Connecting to dietpi.com (dietpi.com)|172.67.170.219|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.
real 0m0.730s
user 0m0.103s
sys 0m0.044s
```
```auto
dietpi@ADSB-Main:~$ time curl -I -m 3 dietpi.com
curl: (28) Resolving timed out after 3000 milliseconds
real 0m5.118s
user 0m0.021s
sys 0m0.057s
dietpi@ADSB-Main:~$ time curl --ipv4 -I -m 3 dietpi.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 23 Mar 2023 14:22:11 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Thu, 23 Mar 2023 15:22:11 GMT
Location: https://dietpi.com/
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=GwG1w1glYCXlIGp31GiCXxVNUhwiamoOOpnouuzn%2FKAnmxSQ5Do%2B8Co8WsnnlM42NIZrpTdbXWJm6m0Pp8DyIi6KjsUG8ROjuH8m3EzBQr9gXo8xgbCMAn0vDy%2Fo"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
X-Content-Type-Options: nosniff
Server: cloudflare
CF-RAY: 7ac75336e94a8c59-EWR
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
real 0m0.118s
user 0m0.020s
sys 0m0.047s
```
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [6 April 2023 21:35 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/47 "2023-04-06T21:35:33Z")
Sorry for the late reply. Can you verify that directly after you added the `-4` and when it resolved fast, that it again resolves slowly or times out when you remove the `-4` flag again? It may be just a coincidence that the issue solved itself when you added the `-4` while the reason is different, e.g. that on a global scale a switch of the route was needed. … On the other hand very unlikely as you have the same result with `curl` and `wget`.
Otherwise, can you test:
```sh
time getent ahosts dietpi.com
cat /etc/resolv.conf
```
the letter to assure that only one IPv4 address is given as `nameserver`.
And does `apt update` resolve `deb.debian.org` immediately?
---
### Author:  [@morbiddk](https://dietpi.com/forum/u/morbiddk)
#### Post date: [10 May 2023 13:21 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/48 "2023-05-10T13:21:02Z")
Haven’t visited this in some time but appears this has been resolved in 8.17.2 that I just recently installed on a new pi. No delays on the banner thus far and no delays running any of the resolver tests.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [10 May 2023 19:15 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/49 "2023-05-10T19:15:43Z")
I’m not sure we did anything on this from our side.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [13 May 2023 15:11 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/50 "2023-05-13T15:11:57Z")
Probably a system package upgrade which fixed it.
---
### Author:  [@cc13](https://dietpi.com/forum/u/cc13)
#### Post date: [7 August 2023 13:32 UTC](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813/51 "2023-08-07T13:32:30Z")
Sorry, It’s me again. 😉
I setup a new RPi 4 with a fresh 8.20.1 Bookworm image behind the same internet provider. First I run in the same issue:
```auto
DietPi v8.20.1 : 5 APT updates available
─────────────────────────────────────────────────────
- Device model : RPi 4 Model B (aarch64)
- CPU temp : 52 °C / 125 °F : Running warm, but safe
- LAN IP : 192.168.0.222 (eth0)
curl: (28) Resolving timed out after 3000 milliseconds
```
This morning the `curl` issue doesn’t appear and I thought all is good. Since then I installed a view docker containers and recognized an issue with the IPV6 connection on this system. E.g. I’m using a cron-job to update my IPV4 and IPV6 address to an external provider hosting a web-address for me. For that the following URL’s are used:
```auto
https://ip6.seeip.org/
https://v6.ident.me/
```
Both did not work and no IPV6 address was sent back to me. After rebooting the system the `curl` issue was showing again, but the second URL is working fine and give me an IPV6 address back if I curl them.
Any what I can check why IPV6 run in an issue and after a reboot it looks better. If needed I can create/send log files.
PS: The 5 apt updates are not shown this morning. Will update now.
[Previous page](https://dietpi.com/forum/t/curl-28-resolving-timed-out-after-3000-milliseconds-rpi3/15813.md?page=2)