For our Blog Visitor only Get Additional 3 Month Free + 10% OFF on TriAnnual Plan YSBLOG10
Grab the Deal

How to Fix Apache on Linux Server in 2026? – Complete Guide

To fix Apache on a Linux server, verify the service status, read the error logs, run a syntax check, and resolve port, permission, or module conflicts.

Common fixes include restarting the service, correcting VirtualHost config, freeing port 80/443, re-enabling required modules, and repairing SSL or PHP-FPM integration.

If your website is down or Apache won’t start, this step by step guide shows exactly how to fix Apache on Linux server distributions like Ubuntu/Debian and CentOS/RHEL/AlmaLinux.

You’ll learn fast diagnostics, precise commands, and real world fixes from enterprise hosting experience, plus prevention tips so it doesn’t break again.


Quick Diagnosis Checklist (Use This First)

  • Check service status and logs
  • Run syntax test to catch config errors
  • Confirm ports 80/443 are free and listening
  • Fix file/dir permissions and SELinux contexts
  • Validate VirtualHost, modules, and .htaccess
  • Verify PHP-FPM and SSL certificates
  • Review firewall rules and network reachability
  • Restart Apache gracefully and re-check logs

How to Fix Apache on Linux Server – (Step by Step)

Step 1: Verify Apache service status

Service names differ by distro. Use the right one before debugging further.

# Ubuntu/Debian
sudo systemctl status apache2
sudo systemctl restart apache2
sudo journalctl -u apache2 --no-pager -n 200

# CentOS/RHEL/AlmaLinux/Rocky
sudo systemctl status httpd
sudo systemctl restart httpd
sudo journalctl -u httpd --no-pager -n 200

If status shows “failed,” the subsequent logs usually reveal syntax errors, missing modules, or port conflicts.

Step 2: Read error logs (your best clue)

Apache’s error log points straight to the problem. Check both the service journal and per site logs.

# Common global error log locations:
# Debian/Ubuntu:
sudo tail -n 200 /var/log/apache2/error.log

# RHEL/CentOS/AlmaLinux:
sudo tail -n 200 /var/log/httpd/error_log

# Also check vhost-specific logs (often in sites' configs)
# And recent journal entries:
sudo journalctl -xe --no-pager | tail -n 200

Look for keywords like “AH00558,” “(98)Address already in use,” “File does not exist,” “client denied by server configuration,” or “Invalid command.”

Step 3: Run a configuration syntax test

Before restarting, validate Apache syntax and loaded VirtualHosts.

sudo apachectl configtest
sudo apachectl -S   # show vhosts and name-based/IPv6 bindings

Fix any “Syntax error” lines. Common culprits: unclosed tags, wrong directives in vhost files, wrong file paths in SSLCertificateFile/Include, or a module directive used before it’s loaded.

Step 4: Resolve port 80/443 conflicts

If another process is using the same port, Apache will fail to bind. Identify the process and stop or reconfigure it.

sudo ss -tulpn | grep -E ':80|:443'
# or
sudo netstat -tulpn | grep -E ':80|:443'

Common offenders: another web server (Nginx/httpd duplicate), Node.js, Docker services, or a leftover Apache instance. Either stop the service or change its port. Ensure Apache has “Listen 80” and “Listen 443” only once.

Step 5: Fix file permissions and ownership

Wrong ownership or permissions can trigger 403s and 500s. Apache runs as www-data (Debian/Ubuntu) or apache (RHEL family).

# Debian/Ubuntu
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

# RHEL/CentOS
sudo chown -R apache:apache /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

If SELinux is enabled, restore contexts and allow HTTPD to access the network and home dirs if needed.

# SELinux fixes (RHEL family)
sudo restorecon -Rv /var/www
sudo setsebool -P httpd_can_network_connect 1
sudo setsebool -P httpd_read_user_content 1

Step 6: Check .htaccess and AllowOverride

Incorrect RewriteRules or disabled overrides can cause 500 errors. Ensure the vhost permits overrides where your CMS needs them.

<Directory /var/www/example.com/public_html>
    AllowOverride All
    Require all granted
</Directory>

Enable required modules like rewrite and headers on Debian/Ubuntu:

sudo a2enmod rewrite headers
sudo systemctl reload apache2

Step 7: Validate required modules and MPM

Using directives from an unloaded module (e.g., proxy, ssl) will break Apache. Also, don’t load conflicting MPMs simultaneously.

# List loaded modules
sudo apachectl -M

# Debian/Ubuntu: enable modules
sudo a2enmod ssl proxy proxy_fcgi http2
sudo systemctl reload apache2

# Disable conflicting MPMs (example)
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

On RHEL family, modules are managed via packages and config includes under /etc/httpd/conf.modules.d/.

Step 8: Repair PHP-FPM integration (502/503/timeout)

If you use PHP-FPM with Apache (recommended with mpm_event), ensure the service and socket align with your vhost config.

# Check PHP-FPM status and pool socket
sudo systemctl status php-fpm    # RHEL
sudo systemctl status php8.2-fpm # Ubuntu (version may vary)

# Typical vhost snippet using ProxyPassMatch or SetHandler
<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
</FilesMatch>

Match the socket path exactly. If using TCP, confirm the port (e.g., 127.0.0.1:9000) is correct and reachable.

Step 9: Fix SSL/TLS and certificate chain issues

Incorrect file paths or missing chain files will fail startup or trigger browser warnings. Ensure your SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile (or fullchain) are valid.

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

# Test
sudo apachectl configtest
sudo systemctl reload apache2  # or httpd

For Let’s Encrypt, renew and re-link certificates if they’ve expired:

sudo certbot renew --dry-run
sudo systemctl reload apache2  # or httpd

Step 10: Check firewall, DNS, and network reachability

Ensure your server can be reached on ports 80/443 and that DNS A/AAAA records point to the correct IP.

# UFW (Ubuntu)
sudo ufw allow 80,443/tcp
sudo ufw status

# firewalld (RHEL family)
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

Use curl locally and from outside the server to validate connectivity:

curl -I http://127.0.0.1/
curl -I https://example.com/

Step 11: Tweak performance limits (busy/high-traffic sites)

Under heavy load, Apache may hit MaxRequestWorkers or OS limits. Tune MPM and file descriptors.

# Example mpm_event tuning (Debian: /etc/apache2/mods-available/mpm_event.conf)
<IfModule mpm_event_module>
   StartServers             2
   MinSpareThreads         25
   MaxSpareThreads         75
   ThreadLimit             64
   ThreadsPerChild         25
   MaxRequestWorkers      200
   MaxConnectionsPerChild   0
</IfModule>

# Increase open files for Apache service
sudo bash -c 'echo "LimitNOFILE=65535" > /etc/systemd/system/apache2.service.d/limits.conf'
sudo systemctl daemon-reload
sudo systemctl restart apache2

Monitor error logs for “server reached MaxRequestWorkers” and adjust accordingly. Use graceful restarts to avoid dropping connections.

Step 12: Fix log rotation and disk space issues

Full disks and stale PID files break restarts. Verify free space and rotate logs.

df -h
sudo logrotate -f /etc/logrotate.conf
sudo rm -f /var/run/apache2/apache2.pid /run/httpd/httpd.pid
sudo systemctl restart apache2 # or httpd

Step 13: Package, upgrade, and module ABI issues

After OS upgrades, mismatched modules can crash Apache. Update packages and disable third-party modules compiled for older versions.

# Debian/Ubuntu
sudo apt update && sudo apt upgrade
sudo apachectl -M  # review modules

# RHEL family
sudo dnf update
sudo httpd -M

If you installed Apache from source, ensure it matches the system’s OpenSSL/PHP versions, or switch to distro packages for stability.


Common Apache Error Messages and What They Mean

  • (98) Address already in use: Port 80/443 conflict. Stop the other service or change ports.
  • AH00558: Could not reliably determine the server’s fully qualified domain name: Set a ServerName in the global config.
  • Invalid command ‘X’: A required module isn’t loaded. Enable the module or remove the directive.
  • Client denied by server configuration: Directory permissions or “Require all granted” missing.
  • AH00072: make_sock: Could not bind to address: A Listen directive duplication or port conflict exists.
  • SSLCertificateFile: file not found or wrong permissions: Fix paths and ensure Apache can read key files.

Prevention and Uptime Best Practices

  • Use a staging environment before pushing config/CMS changes.
  • Automate backups for configs and vhosts (sites available, conf.d, ssl certs).
  • Monitor with UptimeRobot, Prometheus, or CloudWatch; alert on 4xx/5xx spikes.
  • Enable logrotate and keep /var partition with headroom.
  • Pin stable versions; avoid mixing repo sources unless necessary.
  • Document modules you enable, MPM choice, and PHP-FPM socket/port mapping.
  • Harden with least privilege permissions, proper ownership, and SELinux/AppArmor policies.

If you host with YouStable VPS or Dedicated Servers, our support can audit your Apache stack, optimize MPM settings, and set up proactive monitoring and Let’s Encrypt auto renewal, so your sites stay online and fast.

When to Escalate or Migrate

  • Frequent crashes under load despite tuning
  • Complex multi-PHP or HTTP/2/3 edge cases
  • Security and compliance requirements (PCI, HIPAA)
  • Needing load balancing, autoscaling, or CDN integration

At that point, consider managed hosting or a migration plan. YouStable engineers can help you switch to a tuned Apache or hybrid Nginx+Apache stack with WAF, caching, and 24/7 incident response.

Real World Troubleshooting Examples

  • After enabling SSL, Apache fails to start: The SSLCertificateFile path pointed to a deleted file. Restored the certificate, ran configtest, and reloaded successfully.
  • WordPress permalinks 404: Missing mod_rewrite and AllowOverride. Enabled rewrite, set AllowOverride All, and reloaded.
  • Intermittent 503 on PHP pages: PHP-FPM pool name changed after upgrade. Updated vhost socket path and increased MaxRequestWorkers.
  • 403 Forbidden on uploads: Directory had 700 permissions. Corrected to 755 and fixed SELinux context, resolving access.

FAQs

Why won’t Apache start after an update?

Updates can change module ABIs, PHP-FPM sockets, or SSL paths. Run “apachectl configtest,” check “apachectl -M” for missing modules, verify PHP-FPM socket names, and confirm SSL files exist. Update packages system wide and restart Apache to load compatible libraries.

How do I fix “Address already in use” on port 80 or 443?

Find the conflicting process with “ss -tulpn | grep -E ‘:80|:443’.” Stop it or change its port. Remove duplicate “Listen 80/443” lines. If running both Nginx and Apache intentionally, ensure only one binds to 80/443 or use a reverse proxy setup.

What’s the quickest way to debug 500 Internal Server Error?

Check Apache error logs, then review .htaccess and vhost directives. Ensure mod_rewrite is enabled and that your CMS rules are correct. Confirm PHP-FPM is running and the socket/port matches. Fix syntax or permission issues, then reload Apache.

How can I safely reload Apache without downtime?

Use a graceful reload to apply config changes without dropping connections: “systemctl reload apache2” or “systemctl reload httpd.” Always run “apachectl configtest” first to avoid applying a broken config.

Should I use mpm_event or mpm_prefork with PHP?

Use mpm_event with PHP-FPM for better performance and scalability. mpm_prefork is older and typically used only when loading mod_php directly (less common now). Ensure conflicting MPMs are disabled, then tune MaxRequestWorkers and thread settings for your traffic.


Final Checks Before You Call It Fixed

  • apachectl configtest returns Syntax OK
  • No critical errors in error logs after restart
  • curl -I responds with 200/301/302 for both HTTP and HTTPS
  • Correct VirtualHost serves each domain (apachectl -S)
  • Monitoring confirms uptime and acceptable response times

Follow this workflow and you’ll resolve most Apache issues quickly and safely. If you want expert hands to handle it end to end, YouStable’s managed teams can harden, optimize, and monitor your Apache stack so it stays secure, fast, and worry free.

Share via:

Sanjeet Chauhan

Sanjeet Chauhan is a blogger & SEO expert, dedicated to helping websites grow organically. He shares practical strategies, actionable tips, and insights to boost traffic, improve rankings, & maximize online presence.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top