A down website on a running Linux server usually traces back to a stopped service, a blocked port, or a DNS fault. The machine answers ping, uptime reads healthy, and every browser request still hangs.
That gap between a live server and a dead site can confuse even experienced admins, and at Basic Linux, we see the same pattern nearly every week. Checking each layer in order beats guessing which piece broke.
This Linux web server troubleshooting guide walks you through service status, ports, DNS, and config, with the commands that prove where the fault sits.
Let’s get started.
Linux Web Server Troubleshooting: Start at the Service Layer
Most admins ping the box, see it reply, and stop one layer too early. Ping proves the network card and the kernel are alive. It says nothing about whether Apache or NGINX ever started.
According to W3Techs data, NGINX (30.8%) and Apache (22.0%) together run just over half of all websites. The same three checks below cover both:
Is the Web Server Service Running?
Run systemctl status httpd or systemctl status nginx first. That one command tells you whether the service is active, failed, or never came back after the last reboot. On Debian and Ubuntu, Apache runs asapache2, so use systemctl status apache2 instead. A stopped daemon answers nothing, however healthy the rest of the box looks.
If the status reads active, run ss -tlnp to confirm the process is listening. We once chased a client outage in Brisbane for an hour while systemd reported active and every worker had died (the status line can flatter a broken service).
Treat active as a starting point, not proof. Check that the daemon is listening on the correct ports, 80 and 443, and that it runs under the right user account.
Reading Linux Server Logs With journalctl and grep httpd
If the service is stopped or misbehaving, the logs usually name the cause. Use journalctl -u httpd --since "1 hour ago" to trim the output down to the hour you care about.
From there, run grep httpd against /var/log/messages, or pipe the journal into grep for the word error. Most faults name themselves: a missing module, a bad certificate path, a port already in use.
Read the last failed start before you edit anything. The error line usually gives you the filename and the line number, which saves a Friday afternoon of blind editing.
Restarting the Service Without Making the Problem Worse
Test the config before any restart. Both apachectl configtest and nginx -t catch a syntax problem while the old process keeps serving traffic.
Choose reload over restart wherever the software allows it. Reload applies new settings without dropping live connections, while restart ends every open session.
One rule we give every new admin: never restart twice hoping for a different outcome. Push the fix with a configuration management tool like Ansible when a wide range of servers share the same fault.
Why Is the Web Server Not Responding on Its Port?
If the service is healthy but the site still fails, the port is the next suspect. Either nothing is listening there, or a firewall is dropping the packets. Both look identical from a browser.
Split them apart from the command line. Running ss -tlnp | grep :80 on the box itself is the fastest test. An empty result tells you the port never got bound, which puts the fault back on the service.
Bound locally but dead from outside? Look at the firewall next. Try firewall-cmd --list-all on Rocky Linux, or iptables -L -n for iptables rules that never allowed 80 and 443 through.
Another factor is a second listener. Two processes can fight over the same port, and the loser fails silently at boot. Apache and a stray Docker container both claiming 80 is a classic (containers grab ports without asking).
Widen the search to whatever sits in front. Reverse proxies accept the connection and return nothing once the backend port changes during a version jump. Watch for a slow response too, because that points to the backend rather than the network.
Checking DNS Settings and IP Address From Outside the Box
Server checks out, but visitors still see nothing? The fault may sit between your server and the wider internet. Testing from outside catches DNS misconfiguration and routing faults in minutes rather than hours. Browsers on your local network can hit a cached record and hide the actual problem.
Honestly, the step most people skip is testing from a phone on mobile data. Run these four checks from any machine sitting off your LAN.
- DNS Record Check: Run
dig yourdomain.com shortfrom a machine off your network. The command returns the IP address the rest of the world sees. If it differs from your server’s address, stale DNS settings are the likely cause. Wait for the TTL to expire, or correct the record at your registrar. - Port Reachability Check: Run
nmap -Pn -p 80,443 yourdomain.comfrom outside your network. The scan shows whether the ports respond from the internet. A “filtered” result means a router or upstream firewall is blocking traffic. - Full Request Path: Run
curl -I https://yourdomain.comto see the response headers. A 502 from the proxy then reads as a 502 instead of a silent failure. The status code shows which layer to check next. - Resolver Comparison: Run
dig yourdomain.comagainst your own DNS server, then rundig @1.1.1.1 yourdomain.com. Compare the two answers. Split-horizon DNS serves different answers to internal and external users. Staff can then reach the site while customers get nothing.
If all four pass, print the routing table with ip route. One wrong default gateway after a network change strands replies that left the box just fine.
Bottom line: two of these run in under ten seconds and rule out half the likely causes. Before you blame the box, make sure the domain still points where you expect.
Four Common Config Mistakes That Take Sites Offline
Moving to the file layer, one wrong line in an Apache config can silence a machine that is otherwise working fine. Typos survive a reload on some distributions and hard-fail on others, so file locations deserve as much attention as syntax.
Here are the four mistakes that come up most in our support queue.
| Mistake | What it breaks | Quick fix |
|---|---|---|
| Wrong DocumentRoot path | Every page returns 403 or 404 | Point it at a directory that exists |
| Listen directive commented out | Nothing binds to port 80 | Restore the line, then test the config |
| SELinux context lost after a move | 403 despite correct permissions | restorecon -Rv /var/www |
| Duplicate ServerName in two vhosts | The wrong site loads | Rename one, reload, recheck |
All four show up in the error log within a second of a reload. Check your distribution’s Administration Guide, where the Table of Contents lists exact paths for your operating system.
Get Your Site Back Online Faster Next Time
A server can stay online while the website it hosts stops responding. This “server up, website down” situation hides many common faults, which is why checking each layer in order helps you find the cause faster.
Keep these commands somewhere you can reach from a phone, because outages rarely wait until you are at a desk. Go through them top to bottom before you change a line.
Basic Linux publishes practical Linux web server troubleshooting guides and system administration walkthroughs for admins who keep production sites online. Contact us for a hand with a stubborn outage.