You edited a virtual host, installed a new SSL certificate or enabled a module, and nothing changes until the web server picks it up. Knowing how to restart apache takes about ten seconds to learn, but the wrong command on a busy server can drop every visitor in the middle of a checkout. This guide gives you the exact commands for Ubuntu, CentOS-family servers and cPanel/WHM, plus the habit that stops a routine restart from turning into downtime.
Quick Answer (as of September 2026): On Ubuntu or Debian, run
sudo systemctl restart apache2. On CentOS, AlmaLinux or Rocky Linux, runsudo systemctl restart httpd. On a cPanel server, run/scripts/restartsrv_httpdor use WHM's Restart Services page. If you only changed configuration, usereloadinstead, because it applies the new settings without cutting live connections. Runapachectl configtestfirst, every time.
These commands come straight out of daily support work. On stacks like Hostaccent's, where Cloudflare sits in front of an Nginx reverse proxy and Apache handles the application layer behind it, our engineers resolve 20 to 30 client issues a day, and a fair number begin with a restart that went sideways. We wrote this so you can get it right yourself, first time. Everything below applies to Apache 2.4 and assumes SSH access with root or sudo rights.
Restart, Reload or Graceful: Which One Do You Actually Need?
For most configuration changes you need a reload, not a restart. A restart kills every Apache process and starts fresh. A reload (also called a graceful restart) re-reads the configuration and swaps workers over one by one as they finish their current requests.
That difference matters the moment you run a store. A full restart on a small server usually leaves the site unreachable for a second or two, and longer when Apache runs hundreds of workers. Any visitor mid-request in that window gets a failed page. A graceful reload avoids the gap, which is why the graceful restart vs reload apache question has a simpler answer than most guides admit.
On a systemd server, systemctl reload and a graceful restart are the same operation. As of September 2026, the stock apache2 unit on Ubuntu and the httpd unit on AlmaLinux and Rocky Linux both map reload to Apache's graceful signal, so sudo systemctl reload apache2 and sudo apachectl graceful do the same job with zero dropped connections.
| Action | Ubuntu / Debian command | CentOS / AlmaLinux / Rocky command | Drops live connections? | Use it when |
|---|---|---|---|---|
| Reload (graceful) | sudo systemctl reload apache2 | sudo systemctl reload httpd | No | You changed a vhost, SSL path, redirect or most directives |
| Restart (hard) | sudo systemctl restart apache2 | sudo systemctl restart httpd | Yes, briefly | You switched MPM, upgraded Apache, or workers are stuck |
| Graceful stop | sudo apachectl graceful-stop | sudo apachectl graceful-stop | No, but refuses new ones | You want open requests to finish before shutdown |
So when is a hard restart the right call? Three situations cover nearly every case:
- You switched the multi-processing module, for example from prefork to event.
- You upgraded the Apache package, or a module that needs a clean process.
- Apache is misbehaving: workers are hung, memory keeps climbing, or requests go unanswered while the process claims to be running.
In that last case, a graceful reload keeps the broken parent process alive, which is exactly what you don't want.
A full restart also frees memory held by leaky modules, which can buy breathing room on a server that's slowly filling up. That treats the symptom, not the cause. If you're restarting to free RAM every few days, work through why a VPS keeps running out of RAM before it takes the site down at 3am.
Pro Tip: The official Apache guide to stopping and restarting the server explains the signal behind each command: TERM for an immediate stop, HUP for a hard restart, USR1 for a graceful one. You'll rarely send them by hand, but knowing them helps when a panel button doesn't behave as expected.
How to Restart Apache on Ubuntu and Debian
On Ubuntu and Debian the service is called apache2, and the reliable command is sudo systemctl restart apache2. Test the configuration first, then restart or reload, then confirm the service is healthy. The whole sequence takes under 30 seconds.
- Connect:
ssh youruser@your-server-ip - Test the configuration:
sudo apache2ctl configtest. You wantSyntax OK. If you see an error with a file name and line number, fix that line before going further. - Apply the change. For a config edit, run
sudo systemctl reload apache2. For a genuine restart, runsudo systemctl restart apache2. - Check the service:
sudo systemctl status apache2. Look foractive (running)and a fresh start time. - Confirm from outside:
curl -I https://yourdomain.comshould return200or your expected redirect.
Older tutorials still show sudo service apache2 restart. It works on current Ubuntu releases because service simply hands the request to systemd. It offers no benefit on a modern server, though, and scripts read better with one consistent style.
Debian-family systems add a detail most guides skip. Enable a site with a2ensite and the tool tells you to run systemctl reload apache2. Enable a module with a2enmod and it tells you to run systemctl restart apache2. That isn't random: a new site is just configuration, while some modules need a fresh process to load cleanly. Read the line the tool prints and follow it.
Keep two more commands handy. sudo systemctl enable apache2 makes Apache start after a reboot, and sudo systemctl is-enabled apache2 confirms it. Useful paths on Ubuntu:
- Main config:
/etc/apache2/apache2.conf - Site files:
/etc/apache2/sites-available/ - Error log:
/var/log/apache2/error.log
The apachectl reference in the Apache documentation lists every option the wrapper supports.
Do I actually need a restart after editing .htaccess?
No. Apache reads .htaccess files on every request, so changes apply the moment you save. Restarting after an .htaccess edit does nothing useful and briefly interrupts traffic. If a change still isn't showing, the culprit is almost always a cache (browser, plugin or Cloudflare), not Apache. The same applies to most WordPress permalink and redirect changes made through a plugin, since those simply rewrite the .htaccess file.
Is this still affecting your store?
Tell us which customer journey is failing and what changed. We can investigate the application, payment, database, and hosting layers without moving your store.
Restart httpd on CentOS, AlmaLinux and Rocky Linux
On Red Hat-family servers the service is called httpd, so the command is sudo systemctl restart httpd. Everything else follows the same test, apply, verify pattern as Ubuntu.
A quick reality check first. CentOS Linux 7 reached end of life on June 30, 2024, and CentOS 8 ended in December 2021. Most people who search "restart httpd centos" today are actually on AlmaLinux or Rocky Linux, the free RHEL rebuilds that replaced it. If you're still on CentOS 7, plan a move soon, because it no longer receives security patches. The commands are identical across all of them:
- Test:
sudo apachectl configtestorsudo httpd -t - Reload:
sudo systemctl reload httpd - Restart:
sudo systemctl restart httpd - Status and boot:
sudo systemctl status httpdandsudo systemctl enable httpd
The file layout differs from Ubuntu, and that trips people up after a migration. The main config is /etc/httpd/conf/httpd.conf, extra files go in /etc/httpd/conf.d/, and errors land in /var/log/httpd/error_log. There's no a2ensite here; you add or remove .conf files directly and reload.
Across the 4,000+ sites Hostaccent has migrated since 2016, the step people most often get wrong after moving from Ubuntu to a RHEL-family box is exactly this. They edit a file in a folder Apache never reads, restart, and assume the restart failed. Run httpd -S to print the virtual hosts Apache actually loaded. If your domain isn't listed, the problem is the file location.
SELinux is the other gotcha. Move Apache to a non-standard port such as 8080 and a restart can fail with Permission denied: make_sock: could not bind to address. The config is fine; SELinux is blocking the port. Allow it with sudo semanage port -a -t http_port_t -p tcp 8080, then restart. Disabling SELinux also "works", but it removes a security layer you'll want later.
Insider Insight: When
systemctl restart httpdreturns instantly with no output, that only means systemd accepted the job. A config that loads but crashes a module can die two seconds later, so always follow up withsystemctl status httpdand read the start time.
Restart Apache from WHM and cPanel
To restart Apache from WHM, log in as root, open Home » Restart Services » HTTP Server (Apache), and confirm. From the command line on a cPanel server, run /scripts/restartsrv_httpd, the same script the WHM button calls.
cPanel servers need their own rules. cPanel manages Apache through EasyApache 4, generates its own configuration, and watches the service with a monitor that checks roughly every 5 minutes by default. That changes three things.
Use cPanel's scripts rather than raw systemctl. A plain systemctl restart httpd also works, but the restartsrv scripts add cPanel's own pre-checks, log the result properly and print a clear success or failure message. That makes later troubleshooting far easier. The useful variations are:
/scripts/restartsrv_httpdfor a normal restart/scripts/restartsrv_httpd --gracefulto apply changes without dropping connections/scripts/restartsrv_httpd --statusto check whether Apache is up
No SSH client handy? WHM's built-in Terminal (search "Terminal" in the sidebar) runs the same commands in your browser.
Don't edit httpd.conf by hand. On cPanel the main file is /etc/apache2/conf/httpd.conf. cPanel rebuilds it from templates, so manual edits vanish on the next rebuild. Put custom directives in WHM's Include Editor instead. The cPanel documentation for the rebuildhttpdconf script makes a point worth remembering: rebuilding the config does not restart Apache, so run restartsrv_httpd afterwards.
Stopping Apache doesn't keep it stopped. The service monitor notices and brings it back. For maintenance, disable Apache monitoring in WHM's Service Manager first, then switch it back on when you're done.
Can I restart Apache from my cPanel account on shared hosting?
No, and that's by design. On shared hosting one Apache process serves hundreds of accounts, so no single user can restart it. If your site is erroring, the cause is usually your account's limits, and our guide to shared hosting resource limit exceeded errors covers the fix. To restart Apache yourself you need root on your own server. Hostaccent's VPS plans give you full root access, so you can install cPanel/WHM or Plesk (licence sold separately) and run every command here. On Plesk, the restart button sits under Tools & Settings » Services Management.
What to Check When Apache Won't Come Back Up
When Apache refuses to start, the log almost always names the problem in its last few lines. Run sudo journalctl -u apache2 -n 50 --no-pager (or -u httpd) and read from the bottom up before changing anything.
A failed restart is a real outage: the old process is gone and the new one never started. Visitors see a connection error, or a 503 Service Unavailable response if a CDN sits in front. On a proxied stack it usually shows as a 502 instead, and our walkthrough on fixing a 502 Bad Gateway error with Nginx covers that side of the chain. The usual causes, most common first:
- Syntax error.
AH00526: Syntax error on line 42names the file and line. A missing</VirtualHost>is the classic. - Port already in use.
could not bind to address 0.0.0.0:80means something else holds the port.sudo ss -tlnp | grep ':80'shows what. - Missing SSL files.
SSLCertificateFile: file ... does not exist or is emptymeans a certificate moved. Fix the path, or disable that one vhost to bring the rest back. - Out of memory.
dmesg | grep -i oomreveals a kernel kill. Restarting repeats the crash until you lowerMaxRequestWorkersor add RAM.
Ignore AH00558: Could not reliably determine the server's fully qualified domain name. It's a warning that never stops Apache starting, so keep reading the log for the real cause.
Mistakes that turn a restart into an outage
Most restart downtime comes from habit, not Apache. Our engineers use a routine called the Test, Reload, Verify loop: run configtest, apply the change with a reload wherever possible, then check both systemctl status and a live curl request before closing the terminal. The loop takes about 15 seconds and prevents every mistake below.
- Restarting at peak traffic. A hard restart during a sale drops every open request. Reload instead, or schedule real restarts for your quietest hour.
- Restarting Apache to fix PHP. With PHP-FPM, a
php.inichange needssudo systemctl restart php8.3-fpm(match your version), not an Apache restart. - Rebooting the whole server. That takes one to three minutes instead of two seconds, and it hides the real cause.
- Using restarts as a speed fix. Slow first bytes point to server response time, which our guide on fixing high TTFB in WordPress tackles properly. If pages error while Apache runs fine, check the database next with our guide to MySQL server has gone away errors.
Pro Tip: Before editing any Apache file, copy it:
sudo cp site.conf site.conf.bak-$(date +%F). If a restart fails and you can't spot the problem within 5 minutes, restore the backup, get the site up, and debug calmly afterwards.
Your Next Step: A Server Where Restarts Are Never a Guessing Game
Now that you know a reload beats a restart for almost every config change, you can run the Test, Reload, Verify loop on any server you control. If you'd rather do it with engineers behind you, Hostaccent has supported 10,000+ clients since 2016 with 24/7 human help. The Basic plan at $7.99/mo (renewing at $7.99/mo) gives you full root access, NVMe storage, free 30 Gbps DDoS protection and a 99.99% uptime guarantee. One honest note: no control panel licence is included, so budget separately if you want WHM. Ready to practise how to restart apache on your own box? Start on the Basic VPS plan, backed by a 30-day money-back guarantee.
Frequently Asked Questions
How to restart Apache without downtime?
Use a graceful reload instead of a restart:
- Ubuntu:
sudo systemctl reload apache2 - AlmaLinux or Rocky Linux:
sudo systemctl reload httpd - cPanel:
/scripts/restartsrv_httpd --graceful
A graceful reload re-reads the configuration and replaces worker processes only after they finish their current requests, so visitors never see an error. It covers vhost edits, SSL changes and most directives. You still need a full restart after switching MPM or upgrading Apache itself.
What is the difference between Apache reload and restart?
A restart stops every Apache process and starts new ones, which briefly drops open connections, usually for a second or two. A reload keeps the parent process running, re-reads the configuration, and swaps workers over gradually, so no connections are lost. On modern systemd distributions, reload is the same as Apache's graceful restart. Use reload for configuration changes. Use a full restart when workers are stuck, memory is leaking, or you've changed modules or the Apache package.
Why won't Apache start after a restart?
The most common causes are a syntax error in a config file, another process holding port 80 or 443, a missing SSL certificate file, the server running out of memory, or SELinux blocking a custom port. Run sudo journalctl -u apache2 -n 50 (or -u httpd) and read the last lines, which almost always name the file and line at fault. Fix that single issue, run configtest to confirm it passes, then start the service again.
Do I need to restart Apache after installing an SSL certificate?
You need to reload it, not fully restart it. Apache reads certificate files only when it loads its configuration, so a new or renewed certificate isn't served until you run sudo systemctl reload apache2 or sudo systemctl reload httpd. Certbot's Apache plugin reloads the server for you at renewal, and on cPanel servers AutoSSL does the same. If the old certificate still appears after reloading, check that the vhost points to the new certificate path.
How often should I restart Apache?
You shouldn't need to restart Apache on a schedule at all. A healthy server can run for months between restarts, reloading only when configuration changes. According to Hostaccent's support team, which resolves 20 to 30 client issues every day, servers that "need" a weekly restart almost always hide an underlying problem, such as too many workers for the available RAM or a leaking module. Fix that root cause, and routine restarts stop being necessary.












Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.