The first thing to understand about Apache on a cPanel server is that its main configuration file is not yours to edit. It is generated.
cPanel builds it from templates plus the current account data, and rebuilds it whenever an account is created or modified, or the panel updates. Anything you typed into it directly is gone at that point, usually days later and with no connection in your mind between the change and its disappearance.
The Include Editor
In WHM, Service Configuration → Apache Configuration → Include Editor.
Includes are fragments that the rebuild reads and preserves. They come in scopes:
Pre-Main. Before the main configuration.
Pre-VirtualHost and Post-VirtualHost. Before or after the per-domain sections, applying to the whole server.
Pre- and Post-VirtualHost for one specific host. Scoped to a single domain, which is the option to use when the change is for one customer rather than everyone.
Post-VirtualHost is the usual choice for server-wide additions, because it comes last and therefore wins.
Test, then restart
This is the part that separates a routine change from an outage.
httpd -t
If it prints Syntax OK, restart. If it prints an error, fix it first: the error names the file and line, and it is nearly always a missing closing tag or a directive that is not valid in that scope.
Restarting with a broken configuration stops Apache, and Apache serves every site on the server. One typo becomes an outage for everyone. There is no version of this rule that can be skipped because the change was small.
What belongs here, and what does not
Server-wide includes are for things that genuinely apply to everyone: a security header you have decided all sites should send, a global rule, a module directive.
What does not belong here is anything specific to one site. That belongs in the account's own .htaccess, where the customer can see it, change it, and where it does not become a thing you must remember about the server. For that side, see .htaccess rules worth knowing.
The test: would a new administrator understand why this is here? A global include with no comment explaining who asked for it and why is a future mystery.
Global configuration settings
Beside the Include Editor, WHM exposes Apache's global settings as a form, timeouts, keep-alive behaviour, the server signature, and the limits on how many requests can be handled at once.
Two are worth attention.
Keep-alive lets a browser reuse one connection for several files, which materially speeds up page loads. It should be on, with a short timeout; a long one holds connections open doing nothing.
The server signature and tokens control how much Apache announces about itself in responses and on error pages. Reducing it to the product name only is a small, free reduction in what a scanner learns for nothing.
When Apache will not start
If a restart fails, the error log names the reason on the last lines. Read it before changing anything else. The temptation to revert several things at once is how a simple fault becomes an unclear one.
If a recent include is the cause, removing it and rebuilding is the fastest route back:
/scripts/rebuildhttpdconf && httpd -t && systemctl restart httpd
Service status and server health explains confirming everything came back, and EasyApache walks through the separate job of changing which modules and PHP versions exist in the first place.
Confirm the change survived the next rebuild
The whole point of the include mechanism is that it survives regeneration, and confirming that is a five second check nobody performs.
/scripts/rebuildhttpdconf 2>/dev/null | tail -2 grep -c 'Include.*userdata' /etc/apache2/conf/httpd.conf 2>/dev/null apachectl -t
Rebuild deliberately, immediately after making the change, rather than discovering weeks later that it was lost when an account was created.
Anything typed directly into the generated file disappears at that moment. The include directories exist precisely so a change can survive, and the test is whether it is still there after a rebuild you triggered on purpose.
Read the effective configuration, not the file
Settings arrive from several files at once, and what applies is not always what any single file says.
apachectl -S 2>/dev/null | head -20 apachectl -t -D DUMP_INCLUDES 2>/dev/null | head -20 httpd -M 2>/dev/null | head
The virtual host summary shows which configuration answers for each name and which file defined it, which resolves the common confusion where a site behaves as though it belongs to a different configuration.
Check the loaded module list too. A directive that produces no error and no effect is usually one whose module is not loaded, and the configuration test passes because the syntax is valid regardless.
Reload rather than restart where you can
A restart drops every connection in progress. A reload applies the new configuration to new requests and lets existing ones finish.
apachectl -t && apachectl graceful systemctl reload httpd 2>/dev/null || systemctl reload apache2
Test the configuration first, every time. A graceful reload with a broken configuration leaves the old one running, which is safe. A restart with a broken configuration stops the server and does not start it again.
That difference is the whole reason to reload on a live machine, and it is the step people skip when the change seems small.
Know where each site's configuration comes from
An account with several domains has several virtual hosts, and a setting applied to the wrong one is invisible until somebody notices the wrong site behaving oddly.
apachectl -S 2>/dev/null | grep -A1 'port 443' ls /etc/apache2/conf.d/userdata/ssl/2_4/username/ 2>/dev/null
The summary names the file and line that defined each virtual host, which resolves the confusion directly rather than by reading configuration files in order.
Include files exist per user and per domain, and a change placed at the user level applies to all of that user's domains. Where the intention was one site, the file has to be the domain specific one.