Curl not working on new install

Pandamonium

New Member
Oct 26, 2025
8
1
1
Hi all,

Very new to Proxmox, just testing to see if I can use it to replace my home lab vCenter. Some Linux experience and I've read and watched numerous videos in preparation but this issue has me beaten.

Freshly installed PVE running as a VM under vSphere. Literally installed from latest image, opened a shell to PVE to try and run post install script and it doesn't work. I've tracked the problem down to Curl which just doesn't download anything, it eventually just times out...

root@pve:~# bash -c "$(curl -vfsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"
* Host raw.githubusercontent.com:443 was resolved.
* IPv6: 2606:50c0:8000::154, 2606:50c0:8002::154, 2606:50c0:8001::154, 2606:50c0:8003::154
* IPv4: 185.199.108.133, 185.199.111.133, 185.199.109.133, 185.199.110.133
* Trying [2606:50c0:8000::154]:443...
* Immediate connect fail for 2606:50c0:8000::154: Network is unreachable
* Trying [2606:50c0:8002::154]:443...
* Immediate connect fail for 2606:50c0:8002::154: Network is unreachable
* Trying [2606:50c0:8001::154]:443...
* Immediate connect fail for 2606:50c0:8001::154: Network is unreachable
* Trying [2606:50c0:8003::154]:443...
* Immediate connect fail for 2606:50c0:8003::154: Network is unreachable
* Trying 185.199.108.133:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1580 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* Connection timed out after 300183 milliseconds

Things I've tried to fix this...
  • Firewall - tried disabling - no change
  • VMWare networking - Allowed Mac Address changes, Promiscuous mode and Forged Transmits - no change
  • IPv6 - disabled to force IPv4 to be used - no change
  • wget - works perfectly for the same file
I would really appreciate some help with this please as I really want to evaluate Proxmox. I've heard some great things and I think it will be a great move for me.

Thanks in advance.
 
wget - works perfectly for the same file

So... why not use wget then? (Instead of debugging curl.)

Just use wget to get that file (which is a bash script!), set permissions to include the executional bit and start it.

If that (my) sentence is a miracle for you then you need to learn some Linux basics first. You should never run some random script from "the net" in the way you tried: by piping it directly into a command interpreter with root access to everything!

If that sounds harsh: sorry, that's intended.
 
Wow. Bit harsh. I have some Linux skills.

Using wget will only work for that script as it doesn't download any other scripts. I need to fix the curl issue as other scripts also use curl and downloading them from wget won't help with those.
 
Wow. Bit harsh.
May be.

I need to fix the curl issue

Try it without "-silent" and all the other options (or read about them in man curl - which is a really-too-long-to-read manual, unfortunately). Directly on a console I get this:

Code:
$ curl  https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh
#!/usr/bin/env bash

# Copyright (c) 2021-2025 tteck
# Author: tteckster | MickLesk (CanbiZ)
# License: MIT
# https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE

...

That's it from my side regarding this topic.
 
  • Like
Reactions: Johannes S
Thank you for your replies. I just want to clarify a couple of things.

I am not looking for help with the script. It is just a simple example to show the curl issue.

I appreciate the risks of random script downloaded from the net, but this script comes from the Proxmox community which I was recommended to use plus it is referenced directly in some of the videos I watched, so I thought it was OK to try. Additionally, this is a test environment which is purely for evaluation and holds no data, so I considered the risk was low.

I did try removing silent previously but I didn't include the output as it didn't really help much. It just shows that curl fails to even start the download. I include it here though.

root@pve:~# bash -c "$(curl -vfSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pv
e-install.sh)"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Host raw.githubusercontent.com:443 was resolved.
* IPv6: 2606:50c0:8001::154, 2606:50c0:8003::154, 2606:50c0:8000::154, 2606:50c0:8002::154
* IPv4: 185.199.110.133, 185.199.111.133, 185.199.108.133, 185.199.109.133
* Trying [2606:50c0:8001::154]:443...
* Immediate connect fail for 2606:50c0:8001::154: Network is unreachable
* Trying [2606:50c0:8003::154]:443...
* Immediate connect fail for 2606:50c0:8003::154: Network is unreachable
* Trying [2606:50c0:8000::154]:443...
* Immediate connect fail for 2606:50c0:8000::154: Network is unreachable
* Trying [2606:50c0:8002::154]:443...
* Immediate connect fail for 2606:50c0:8002::154: Network is unreachable
* Trying 185.199.110.133:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1580 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
0 0 0 0 0 0 0 0 --:--:-- 0:04:59 --:--:-- 0* Connection timed out after 300349 milliseconds
0 0 0 0 0 0 0 0 --:--:-- 0:05:00 --:--:-- 0
* closing connection #0
curl: (28) Connection timed out after 300349 milliseconds

I have also tried using curl to fetch other files with the same result. Put simply, curl will not fetch anything but wget will and I can't figure why.
 
Last edited:
Well, you can try few other things. For example, add "-4" to your curl options.
Try a well known site, ie "curl https://www.google.com"

Are you sure there is no proxy of any sort involved? May be you have wget specific config file?

Just keep in mind that PVE is based on Debian Linux userland. DNS, TCP/IP , curl - all parts of standard Linux packaging and are unchanged by PVE developers. There is nothing special about them.
The only thing special is your particular environment - nobody else has it the same way.

Cheers


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Thanks for the reply.

I get the same with the -4 option and on various common websites. I'm with you that it's likely something in my environment but I can't figure what. I have no proxy. I've tried everything I can think of to check DNS. I found articles talking about issues with networking under VMWare but I've tried every suggestion I can find to resolve those and every other network function appears to work OK.

I also get the thing about it using basic Debian which supports the theory of something in my environment being screwy.

I'm thinking I might just have to abandon the VM option and dust off an old laptop to test without VMWare interfering and see if it's the same. I guess that's something for tomorrow.
 
  • Like
Reactions: Kingneutron
Thanks for the reply. I have made a LITTLE progress...

First, to remove any misunderstanding and keep things as simple as possible, I am now only running this to test...


I have now rebuilt PVE on an old laptop to remove any VMWare issues and the problem remains. However, during my testing I discovered that curl will work OCCASIONALY (Maybe 1 in 10 times), so I got to thinking maybe it's a MTU issue but changing the MTU value doesn't seem to make it any better. I have been changing it on both the NIC and the Bridge each time which is correct as far as I can see. Other Linux boxes on the same switch can run this command perfectly every time and they appear to use the default MTU of 1500.

So, it's something in my environment but only affects PVE and is intermittent.

The error when curl fails now seems to change occasionally, but it always seems to amount to a break in the communication...

curl -4vL https://google.com
* Host google.com:443 was resolved.
* IPv6: (none)
* IPv4: 142.250.129.139, 142.250.129.138, 142.250.129.113, 142.250.129.101, 142.250.129.102, 142.250.129.100
* Trying 142.250.129.139:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* TLS connect error: error:00000000:lib(0)::reason(0)
* OpenSSL SSL_connect: Connection reset by peer in connection to google.com:443
* closing connection #0
curl: (35) Recv failure: Connection reset by peer

I'd still love to solve this so if anyone has any further suggestions I would be very grateful.
 
Are there VLANs involved? Have you tested MTU max size between the internal hosts on the switch? Does your switch implement some sort of "smart" filtering?
The best approach is to keep reducing the number of variables and complexity of the test.

Install vanilla Debian instead of PVE - do things work?


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: Johannes S
Well, now my head hurts...

First, no VLans involved. Very simple setup with only a single switch in my lab.

Thought the idea of trying raw Debain was a great idea so I gave it a go, and then tried some other OS's and here are the results...

Centos - Works perfectly
Rocky - Works perfectly
Debian Raw - Works very occasionally
PVE - Works very occasionally

ALL of these machines are on the same VM Host connected to the same vSwitch which is in turn connect to my only switch.

So now I have to try and work out what does Debian do with curl and/or networking which is different to the others that my environment doesn't like?
 
This is a good read: https://forum.proxmox.com/threads/temporary-failure-in-name-resolution-help-needed.164020/

I think the summary is:
DNS resolution failure that affected only PVE and only when used with internal router. Caused by new version of openwrt, running on Pi , affecting Debian clients only. Because of the network driver bug on the router side

Remove the switch from the equation.

The point is, even if your issue is not the one described above, the possibilities are many.



Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
Another test...

Just connected the laptop directly to the Broadband router, removing my switch all together, and the problem remains. :rolleyes:
 
It might also worth a shot to try installing Ubuntu since ProxmoxVE Kernel is based on the Ubuntu kernel. Not sure which would be the fitting Release though
 
Last edited:
This is a good read: https://forum.proxmox.com/threads/temporary-failure-in-name-resolution-help-needed.164020/

I think the summary is:
DNS resolution failure that affected only PVE and only when used with internal router. Caused by new version of openwrt, running on Pi , affecting Debian clients only. Because of the network driver bug on the router side

Remove the switch from the equation.

The point is, even if your issue is not the one described above, the possibilities are many.



Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

Thanks for that link. I've read it but not yet fully understood it all but, the main takeaway is that this is now a Debian issue, not a PVE issue. I will re-read this and follow anything relevant and follow up with the Debian forums.

I will report back if/when I make any progress.

Thanks again everyone.