It costed me a few hours of downtime after my hosting assigned me a new IP. This is how I solved the problem.

Example:

• Old IP: 100.100.100.100
• New IP: 200.200.200.200
• HestiaCP: 1.10.5

The important part is that Hestia uses several layers of configuration. Changing the IP in Hestia does not necessarily mean that every already-generated nginx, Apache and firewall configuration has been updated. And it wasn’t in my case.

1. Update DNS / Cloudflare

First change the A record for the server hostname, for example:

host.example.com → 200.200.200.200

If the websites are managed through Cloudflare, update their A records as well.

For mail, do not proxy mail-related records through Cloudflare.

The hostname/FQDN is important to Hestia, so make sure it resolves to the new server address.

2. Change the IP in Hestia

Make sure the new IP is configured on the server, then check Hestia’s current IP:

v-list-sys-ips

Check the API allowed IP:

grep -n "API_ALLOWED_IP" /usr/local/hestia/conf/hestia.conf

If the old IP is present, replace it:

sed -i 's/100\.100\.100\.100/200.200.200.200/g' /usr/local/hestia/conf/hestia.conf

Then run the official Hestia IP update:

v-update-sys-ip

Hestia-generated nginx domain configurations are located here:

/etc/nginx/conf.d/domains/

Make a backup first:

cp -a /etc/nginx/conf.d /etc/nginx/conf.d.before-ip-change

Check whether any generated nginx configuration still contains the old IP:

grep -Rl '100\.100\.100\.100' /etc/nginx/conf.d

If necessary, replace it:

grep -Rl '100\.100\.100\.100' /etc/nginx/conf.d | xargs sed -i 's/100\.100\.100\.100/200.200.200.200/g'

Then test nginx:

nginx -t

Do not restart nginx if the syntax test fails.

Hestia’s Apache domain configurations are located here:

/etc/apache2/conf.d/domains/

Back them up:

cp -a /etc/apache2/conf.d/domains /etc/apache2/conf.d/domains.before-ip-change

Check for the old IP:

grep -Rl '100\.100\.100\.100' /etc/apache2/conf.d/domains

Replace it if necessary:

grep -Rl '100\.100\.100\.100' /etc/apache2/conf.d/domains | xargs sed -i 's/100\.100\.100\.100/200.200.200.200/g'

Then test Apache:

apachectl -t

Expected result:

Syntax OK

For domains that need their Hestia configuration regenerated, use the native Hestia command:

v-rebuild-web-domain USER DOMAIN

For example:

v-rebuild-web-domain myuser example.com

Using Hestia’s rebuild command is preferable to manually editing individual generated virtual-host files.

6. Rebuild the Hestia firewall

This step is easy to overlook and can cause very confusing problems.

v-update-firewall

Then check the active rules:

iptables -L INPUT -n --line-numbers

The server’s new IP should appear in the appropriate ACCEPT rules, while the old IP should no longer be used as the server’s own address.

Why this matters

A typical Hestia nginx + Apache setup looks like this:

Internet
   |
   v
nginx :80 / :443
   |
   | proxy
   v
Apache :8080 / :8443
   |
   v
PHP-FPM
   |
   v
WordPress / PHP application

In this setup nginx can proxy requests to Apache using the server’s own public IP.

For example:

nginx → 200.200.200.200:8080 → Apache

If the firewall still contains configuration based on the old IP, it can block that connection.

The result is that nginx, Apache and PHP can all be running correctly while the websites still fail.

Running:

v-update-firewall

regenerates Hestia’s firewall rules using the current server IP.

Check that Hestia knows the new IP:

v-list-sys-ips

Check for remaining references to the old IP:

grep -R '100\.100\.100\.100' /etc/nginx/conf.d /etc/apache2/conf.d/domains 2>/dev/null

Test nginx:

nginx -t

Test Apache:

apachectl -t

Check the firewall:

iptables -L INPUT -n --line-numbers

Finally, test the websites, Hestia panel, mail services and SSL from outside the server.

After changing the server IP address, existing mail domains may still contain the old IP in their Exim configuration.

cat /etc/exim4/domains/example.com/ip

It should return the current server IP

If it still shows the old IP, rebuild the mail domain.

2. Rebuild the mail domain

v-rebuild-mail-domain USER DOMAIN

Example:

v-rebuild-mail-domain myuser example.com

This is the preferred way to regenerate the Hestia mail/Exim configuration after an IP change.

exim -bP transport remote_smtp

If it contains:

interface = ${if exists{OUTGOING_IP}{${readfile{OUTGOING_IP}}}}

Exim uses the IP stored in the mail domain’s ip file.

And that’s it. I guess that there is a more elegant way to do this. However, while you have 500 server error, elegance is the last thing to think of… any suggestions are welcome… 😉