Apache AH00558 "Could not reliably determine": fix

Fix Apache AH00558: it's only a warning, set ServerName globally on Ubuntu or RHEL. If your site is still down, the real error is elsewhere, and here is how to find it.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

This is only a warning. Apache found no global ServerName, guessed a name, and carries on. On its own it doesn’t stop your site. It’s the most-noticed message of apachectl configtest, and that’s why it often gets blamed for problems it didn’t cause.

Silencing it takes one line. If your site is also down, keep reading to section 3: the real error is further down.

TL;DR

# Ubuntu / Debian
echo "ServerName localhost" | sudo tee /etc/apache2/conf-available/servername.conf
sudo a2enconf servername
sudo apachectl configtest
sudo systemctl reload apache2

# RHEL / Rocky / AlmaLinux
echo "ServerName localhost" | sudo tee /etc/httpd/conf.d/servername.conf
sudo apachectl configtest
sudo systemctl reload httpd

Syntax OK with no warning means it’s done.

1. Why it appears

When Apache builds self-referencing URLs, it needs to know its own name. Without ServerName at the top level of the configuration, it asks the system: it looks up the machine’s hostname, and the answer often isn’t a full domain name. That’s normal on most servers, and it’s all the warning says.

A ServerName inside a <VirtualHost> block doesn’t remove it, because the message is about the global setting. You need one outside all virtual hosts.

2. The fix

Ubuntu and Debian keep extra settings in conf-available, and a2enconf turns them on:

echo "ServerName www.example.com" | sudo tee /etc/apache2/conf-available/servername.conf
sudo a2enconf servername
sudo apachectl configtest
sudo systemctl reload apache2

RHEL, Rocky and AlmaLinux read everything in conf.d:

echo "ServerName www.example.com" | sudo tee /etc/httpd/conf.d/servername.conf
sudo apachectl configtest
sudo systemctl reload httpd

Use the server’s real name if it has one, otherwise localhost is fine: virtual hosts still answer on their own names.

3. The site is still down

Then the warning was a distraction. Get the real error:

sudo systemctl status apache2 --no-pager      # httpd on RHEL
sudo journalctl -u apache2 -n 30 --no-pager
sudo apachectl configtest
sudo tail -n 30 /var/log/apache2/error.log    # /var/log/httpd/error_log on RHEL

The usual culprits, right after the AH00558 line:

You see	Cause	What to do
`(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80`	Another program holds the port, often nginx	See Address already in use
`AH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/site.conf`	A typo; the message names the file and line	Fix that line, then run `configtest` again
`Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included`	A module is off	`sudo a2enmod rewrite`, then restart
`SSLCertificateFile: file '…' does not exist or is empty`	A wrong path to the certificate	Fix the path, or renew it
`AH01630: client denied by server configuration`	The site runs, and an access rule refuses you	Check `Require all granted`

For the general method when a service won’t start, see Job for … failed.

4. If the machine’s name is the real problem

A hostname that doesn’t resolve can cause more than this warning, like slow logins or sudo complaining. See sudo: unable to resolve host.

Shell, we have a problem!

Similar, but different: AH00557: apache2: apr_sockaddr_info_get() failed for myserver is the same kind of warning, and the same fix applies, with the machine’s name added to /etc/hosts. On a page in the browser, 403 Forbidden or 500 Internal Server Error come from the site’s configuration or application, not from this: the error log says which. A page that says You don't have permission to access this resource is a 403.

Apache "AH00558: Could not reliably determine the server's fully qualified domain name": what it means, and the fix

TL;DR

1. Why it appears

2. The fix

3. The site is still down

4. If the machine’s name is the real problem

Related articles

"Address already in use": find who is using port 80 (or any port)

Nginx "502 Bad Gateway": find the cause in the error log

Nginx "upstream sent too big header while reading response header": raise the right buffer

Related articles

bind() to 0.0.0.0:80 failed (98: Address already in use)
Networking
"Address already in use": find who is using port 80 (or any port)
Fix "bind() failed (98: Address already in use)": find the process holding the port with ss or lsof, then stop it, move it, or change your port.
Beginner · 5 min read

502 Bad Gateway
Networking
Nginx "502 Bad Gateway": find the cause in the error log
Fix nginx 502 Bad Gateway: read error.log, then fix the backend that is down, the wrong address or socket, the crashing app, or SELinux on RHEL.
Intermediate · 5 min read

upstream sent too big header
Networking
Nginx "upstream sent too big header while reading response header": raise the right buffer
Fix Nginx "upstream sent too big header while reading response header from upstream" and its 502: measure the headers, then raise the right buffer.
Intermediate · 3 min read