HestiaCP very Slow - DNS errors - SSL errors - Hetzner

At least here in Europe, Hetzner is a good supplier of dedicated servers.
Good price and excellent quality and features.

But I’ve been in despair for almost two weeks to get a working HestiaCP installation.

Despair becomes panic when you realize that other panels work and Hestia is in chaos.

But without stress …
I understand the problem.

Hetzner uses its own linux templates that for one or several reasons are incompatible with HestiaCP.

To solve the problem definitively, you have to install Debian or Ubuntu using the “rescue” option.
IMPORTANT, you do not install Linux directly through the Hetzner panel.

1- You enter the Rescue option
2- Reset System
3- Enter as root and type:
root @ rescue ~ #installimage
4- Then follow the steps indicated

Hetzener automatically configures your DNS, it is imperative to change the respective files
nano /etc/resolv.conf
nameserver 2001: 4860: 4860 :: 8888
nameserver 2001: 4860: 4860 :: 8844

UBUNTU: Google it :slight_smile:


Hope this helps

Many of the developers working on the Hestia. The basic “infrastructure” of Hestia is hosted on servers from Hetzner.

I have never experienced any issue with Hetzner Cloud or Bare metal (Dedicated) server

1 Like

I don’t say no, but that was my problem this past week.
If my experience helping one user is already good :wink:

In addition: We also use Hetzner Cloud as testing infra for the most prerelease checks. Also I use their own dbs servers for all hetzner based hostings, no issues here. Can you share your server informations (ax41, ex41, whatever you took) and steps which you did to install hestia?

I would like to be able to reproduce your issue.

At the moment I have about 6 Hetzner servers all AX41-NVMe.
I installed HestiaCp in two so far.
In the first I only had problems with SSL Certificates and DNS, in the second it was chaos, I was clicked any button and I waited 5m to do anything.
So it leads me to believe the Hetzner has different configurations in the same product depending on the clusters.
On the other hand, I tested HestiaCP on an OVH Server and I found zero problems, but on OVH servers I install the original version of Linux by default.
It was really the experience I did on the OVH servers that led me to insist on solving Hetzner’s problems.
I have several servers with Vesta and I have need to solve this issues shortly.

If it helps:
The big problem: AX41-NVMe #1365406
Some problems: AX41-NVMe #1361670

Currently using ax41 with proxmox on top, do you use it baremetal? The load issue could be something with the firewall, did you have the issues directly after install or after doing some modifications?

My steps to error
1- Install Debian 10 Hetzner Version
2- apt-get update apt-get upgrade
3- apt-get install sudo
4- sudo passwd root
5 - reboot
6- wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
7- bash hst-install.sh
8- reboot
9- Hestia with errors

Ok, that’s weird. I’ll try to reproduce it, but as @eris wrote, there should be no issues. Do you have another ax41 to test it?

I forgot
Step 4.1 - update-locale LC_CTYPE = pt_PT.UTF-8
I will convert all my servers to HestiaCP, except the servers with Moodle, I tried with Moodle, saw some errors and gave up without paying much attention to it due to lack of time.
This week I don’t have much time because I delayed all the work due to this situation, but I have to convert all the servers soon because I no longer trust Vesta.
I prefer to spend time with online servers than wasting my time with offline servers :wink:

I disable the Hetzner firewall by default

I never used the cloud, all my servers are dedicated

I also tried with Ubuntu, it was not slow but it showed errors in DNS and SSL certificates.
But I gave up because I personally don’t like Ubuntu very much for these things.

Me too

1 Like

Hestiacp works well with Hetzner

I use Hetzener

I have installed Hestiacp (for all our servers Hetzner) for most of the customers in our hosting service No problem

1 Like

Obviously I’m not making up problems, because I don’t even have time to solve the ones I already have.
I just created this post in an attempt to help all those who encounter the same problems that I encountered and thus save them several days of work to debug, research and solve.
I have been using dedicated OVH servers for a long time and the experience of the years has led me to the discovery that equal servers assembled on different dates have different configurations that manifest themselves in small details depending on the specific needs of each project.
On OVH servers a couple of years ago I chose to always install the original Linux version to avoid surprises after the Servers are working in production.
We all know that our work is dynamic and is not always the same in similar terms.

But if you believe that my post is abusive or that it somehow misrepresents the truth, please let me know.


I still haven’t had time to look in more detail and I may be mistaken in what I’m going to write next, but my suspicions are that the problem is in the configuration of Iptables because during the installation of Hestia Iptables takes too long to configure and when this happens the error also happens.

About the ssl errors triggered by the fact that the system cannot resolve the DNS I found this article.
Check post 4 from 2016

I use Hetzner and there is no such problem.

You try this

Create A Record 2


Value or IP - Provide your VPS IP

Once this is done I am sure your problem will definitely be solved

I allways do that,
I don’t have VPS, all my servers are dedicated servers

The solution is easy, it’s in the first post :wink:

I was running into a similar issue (on other server though) just after a fresh install and enabling iptables manually (because it didn’t get automatically started after reboot).

Well, even on sudo I was getting this:
sudo: unable to resolve host example.com: Temporary failure in name resolution
Every request was taking ages to response back …

Result is that I needed to allow established connections to continue in iptables:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Why it wasn’t even there at first glance, I have no idea, but my iptables rules didn’t mention that before I added it.

1 Like