$ guides / apache-httpd / apache-httpd-ah00558-server-name ▌

Operations Guides

Apache AH00558: Could not reliably determine the server's fully qualified domain name

You restart Apache, run apachectl configtest, or check the error log after a deploy, and you see it again:

AH00558: httpd: 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

The short answer: Apache is still serving traffic. This warning does not stop startup, does not drop requests, and is not a security issue. It means no global ServerName directive is set, so Apache guessed a name for itself and is telling you what it guessed.

The longer answer, and the reason this page exists: the warning is benign but not harmless. It fires on every restart and every config test, which trains operators to ignore the error log. It also tells you that Apache is making up its own identity, and that guess leaks into name-based virtual host fallback behavior and self-referential URLs in ways that occasionally matter. The fix is one line of configuration. This article explains when you should care beyond log hygiene, how to pick the right value, and how to verify the fix.

What this means

Apache needs to know its own canonical name for three things: building self-referential URLs (redirects and Location headers it generates itself), populating the SERVER_NAME variable passed to CGI and similar modules, and resolving name-based virtual host matching. When you do not set ServerName in the global server config context, Apache deduces one at startup: it asks the operating system for the system hostname, and if that fails, it performs a reverse lookup on an IP address present on the system. The IP or hostname in the warning is whatever that deduction produced.

Two details in the message trip people up:

127.0.1.1 versus 127.0.0.1. On Debian and Ubuntu, the default /etc/hosts maps the machine hostname to 127.0.1.1, not 127.0.0.1. Seeing 127.0.1.1 in the warning is normal on those systems and is not an error.
It appears in configtest too. apachectl configtest runs enough of startup to emit the warning, so “Syntax OK” plus AH00558 is a common and confusing combination. The syntax really is OK; the warning is about runtime identity, not syntax.

Where it stops being purely cosmetic:

Name-based vhost fallback. When a request arrives with a Host header that matches no ServerName or ServerAlias in any vhost, Apache routes it to the first-listed vhost for that address and port. A missing global ServerName does not change that rule, but an unset or auto-deduced name makes it easier to end up with a default vhost you did not intend, especially in container images and auto-generated configs.
Self-referential URLs. With UseCanonicalName On, Apache builds redirects from ServerName. With the default Off, it uses the client-supplied Host header. If you rely on UseCanonicalName On and ServerName is auto-deduced to 127.0.1.1 or a container IP, generated redirects point at an address your clients cannot use.
Log noise. The warning fires on every restart and every config test. In a fleet with frequent config reloads, it becomes the most common line in the error log, and that is exactly how operators stop noticing lines like AH00484: server reached MaxRequestWorkers setting sitting next to it.

You may also see its companion, AH00557: httpd: apr_sockaddr_info_get() failed for <hostname>. That one means the OS hostname could not be resolved to an IP at all. Setting ServerName globally suppresses both, but AH00557 also tells you the host’s own name resolution is broken, which is worth fixing for its own sake.

Common causes

Cause	What it looks like	First thing to check
No global ServerName anywhere	AH00558 on every start and every configtest	`grep -rn "ServerName" /etc/apache2/` or `/etc/httpd/`
ServerName only inside VirtualHost blocks	Same warning; vhosts work, but the global context is still unset	Check whether every match is inside a `<VirtualHost>` block
Container image without ServerName	Warning on every container start, with the container’s internal IP (for example 172.17.0.2)	Inspect the Apache config baked into the image
Hostname does not resolve (AH00557 also present)	Both AH00557 and AH00558 at startup	`getent hosts $(hostname)`
Debian/Ubuntu /etc/hosts convention	Warning shows 127.0.1.1	`cat /etc/hosts`; this is normal, not a fault

Quick checks

All read-only.

# Reproduce the warning and confirm config syntax is otherwise fine
apachectl configtest 2>&1

# Find every ServerName directive and its file and line number
# Debian/Ubuntu:
grep -rn "^[[:space:]]*ServerName" /etc/apache2/
# RHEL/CentOS:
grep -rn "^[[:space:]]*ServerName" /etc/httpd/

# See what Apache thinks its hostname is
hostname
hostname -f 2>/dev/null

# Check whether the hostname resolves (AH00557 territory)
getent hosts $(hostname)

# Dump the vhost map, including which vhost is the default per address:port
apachectl -S 2>&1

# Confirm the warning cadence in the error log
grep -c "AH00558" /var/log/apache2/error.log 2>/dev/null || \
  grep -c "AH00558" /var/log/httpd/error_log

# Confirm Apache is actually serving (the warning alone never stops it)
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 http://localhost/

The apachectl -S output is the most useful of the bunch: it shows every vhost, its ServerName and aliases, and which vhost is marked default server for each address and port. If the default is not the vhost you expect, that is a separate finding from the warning itself.

How to diagnose it

flowchart TD
  A[AH00558 in log or configtest] --> B{Is Apache serving traffic?}
  B -- No --> C[Different problem: check process state and error log]
  B -- Yes --> D{Global ServerName set?}
  D -- Yes --> E[Directive misplaced or duplicated: check context with apachectl -S]
  D -- No --> F[Set ServerName globally, configtest, graceful reload]
  F --> G[Warning gone from configtest output]

Confirm service health first. Run the curl check above. If Apache is serving, this is a configuration hygiene issue, not an incident. If it is not serving, AH00558 is a bystander; look at process state, the scoreboard, and the rest of the error log instead. See How Apache HTTPD actually works in production for the broader triage model.
Locate the active config root. Debian/Ubuntu uses /etc/apache2/ with apache2.conf as the entry point; RHEL/CentOS uses /etc/httpd/ with conf/httpd.conf. Use the grep from the quick checks to see whether ServerName exists at all and in which context.
Check the vhost map. apachectl -S shows whether each vhost has an explicit ServerName and which vhost is the default catch-all. Decide whether that default is intentional.
Check hostname resolution. If AH00557 appears alongside AH00558, the system hostname does not resolve to an IP. That is a host-level misconfiguration: add the hostname to /etc/hosts or fix DNS.
Decide the correct value. The right value depends on the role of the server: the site’s public FQDN for a single-site host, or a neutral value like 127.0.0.1 when vhosts carry the real names. See the fixes below for the tradeoffs.
Apply, test, reload. Set the directive, run apachectl configtest (the warning should be gone), then apply with a graceful reload, not a hard restart.

Metrics and signals to monitor

AH00558 is not a capacity or latency problem, so the relevant signals are about log hygiene and configuration state, all drawn from the standard Apache monitoring set.

Signal	Why it matters	Warning sign
Error log rate and content	The warning inflates log volume and buries real entries such as AH00484 (MaxRequestWorkers reached) and segfaults	AH00558 dominating recent entries; any [error] or [crit] lines you have never reviewed because the log is noisy
Configuration reload success	A graceful reload that fails its config check is silently ignored, leaving stale config running	`apachectl configtest` output changing between runs; reloads without a following “resuming normal operations”
Uptime and restart events	Each restart re-emits the warning, so AH00558 frequency tracks restart frequency	Warning appearing more often than your expected deploy or log-rotation cadence

For a fuller treatment of error-log-based monitoring, see Apache error log monitoring: severity levels, AH codes, and what to alert on.

Fixes

Set ServerName globally

The fix the warning itself tells you about. Place one ServerName directive outside any <VirtualHost> block.

Debian/Ubuntu, as a dedicated drop-in:

# Create a small config fragment and enable it
echo 'ServerName web01.example.com' > /etc/apache2/conf-available/servername.conf
a2enconf servername
apachectl configtest && apachectl graceful

RHEL/CentOS, as a drop-in in conf.d:

echo 'ServerName web01.example.com' > /etc/httpd/conf.d/servername.conf
apachectl configtest && apachectl graceful

Syntax notes: the directive accepts ServerName [scheme://]domain-name|ip-address[:port]. IPv6 addresses are not supported here and produce a startup error. Use a graceful reload to apply it; a hard restart drops all connections for no benefit.

Choosing the value:

The public FQDN is the right choice for a single-site server, or anywhere UseCanonicalName On is in play, because self-referential URLs and SERVER_NAME will use it.
ServerName 127.0.0.1 or ServerName localhost is a legitimate choice on vhost-heavy servers where every real name lives in vhost-level ServerName and ServerAlias directives. It suppresses the warning and gives Apache a stable identity without implying a canonical public name that does not exist.
What not to do: do not set a made-up name that collides with a real vhost name, and do not “fix” the warning by raising LogLevel to hide it. Hiding it also hides the real warnings sharing that severity.

Containers

Containers hit this warning constantly because the container hostname is ephemeral and usually resolves to the container’s internal IP, which changes on every restart. Do not try to fix it at runtime per container. Bake a ServerName line into the image’s Apache config (for the official-style images, a drop-in under the distro-appropriate config directory), or render it from an environment variable in your entrypoint template. The value barely matters inside a container fronted by a load balancer or ingress; ServerName 127.0.0.1 is a common, safe default, with vhosts or the ingress layer carrying the real names.

Hostname resolution (when AH00557 is also present)

If the companion error appears, make the hostname resolvable: add it to /etc/hosts pointing at 127.0.0.1 (or keep the Debian-style 127.0.1.1 convention), or fix DNS. Setting ServerName suppresses the warning either way, but a hostname that does not resolve will bite other software on the same host.

Verify the fix

# Should print "Syntax OK" with no AH00558 line
apachectl configtest 2>&1

# After a graceful reload, the next startup block in the error log
# should contain no AH00558
tail -20 /var/log/apache2/error.log 2>/dev/null || tail -20 /var/log/httpd/error_log

Prevention

ServerName in base configs and images. Include a global ServerName in configuration management templates and container base images so new hosts never emit the warning.
Configtest in CI. Run apachectl configtest in your deployment pipeline and fail on new warnings, not just syntax errors. AH00558 disappearing from and reappearing in output is a cheap regression signal.
Explicit default vhost. Decide which vhost is the catch-all for unmatched Host headers and make it the first-listed one deliberately, rather than inheriting whatever order the config files happen to load in.
Alert on error log rate, not on this line. Do not page on AH00558; Apache logs it as a startup alert, but it does not stop the server or affect request processing. Do track overall error log rate and the specific high-signal codes (AH00484, segfaults, “No space left”) so the noise never drowns them.
Hostname hygiene. Provision hosts with a resolvable hostname from the start. This eliminates AH00557 and removes one variable from the deduction path.

How Netdata helps

Error log parsing by AH code. Netdata’s Apache error log monitoring breaks messages down by severity and code, so you can see AH00558 volume separately from the codes that indicate real trouble, such as AH00484 (worker exhaustion) or proxy errors like AH01114.
Restart correlation. Uptime and restart event tracking lets you line up bursts of the warning with deploys, config management runs, or unexpected restarts, which is how you catch a host restarting more often than intended.
Config reload visibility. Correlating “resuming normal operations” events with your deploy pipeline tells you whether the reload you expected actually happened, which matters because a failed graceful reload leaves stale config running silently.
Log noise versus signal. Tracking total error log rate alongside the rate of actionable messages shows whether cosmetic warnings are crowding out the entries you actually need during an incident.
Baseline for the real problems. Once the warning is fixed, the same dashboards keep watching worker utilization, scoreboard states, and 5xx rates, which is where Apache incidents actually live.

Netdata’s Apache HTTP Server monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

The Netdata solution

Apache HTTP Server monitoring with Netdata

Netdata monitors Apache HTTP Server with per-second metrics from mod_status, pre-built dashboards, and ML-powered anomaly detection. Watch busy versus idle workers and the scoreboard state mix, requests per second, bytes served per second, and request processing duration alongside the rest of your stack, so you catch the worker-exhaustion, slow-backend, and memory incidents in these runbooks before they page anyone.

See web server monitoring → Start monitoring free