Apache Modules (a2enmod)

Apache is built from a small core plus a large collection of optional pieces called modules. A module is a self-contained chunk of code that teaches Apache to do one extra thing — rewrite URLs, speak HTTPS, forward requests to another app, compress responses, and so on. This modular design means your server only loads what you actually need, which keeps it lean and a little more secure. On Ubuntu you do not edit cryptic config lines to turn modules on and off — you run two friendly helper commands, a2enmod (Apache 2 enable module) and a2dismod (Apache 2 disable module).

Why Apache uses modules

When you install Apache on Ubuntu, only a basic set of modules is active. Everything else ships pre-installed on disk but stays disabled until you switch it on. The benefit is twofold:

• Smaller attack surface — code that is not loaded cannot be exploited. Leaving unused modules off is a genuine security win.
• Less memory and faster startup — Apache only initialises what is enabled.

A module usually exists as a shared library file (ending in .so, for “shared object”) under /usr/lib/apache2/modules/, paired with a small .load config snippet under /etc/apache2/mods-available/. Some modules also have a .conf file there holding their default settings.

How a2enmod actually works

On Ubuntu, enabling a module is just clever symlinking (a symlink is a shortcut that points to another file). The mods-available/ directory holds every module Apache knows about. The mods-enabled/ directory holds symlinks to the ones that are switched on. Apache only reads mods-enabled/.

• a2enmod <name> creates a symlink from mods-enabled/ to the file in mods-available/.
• a2dismod <name> deletes that symlink.

Neither command takes effect until you reload Apache, because the running server has already read its config into memory.

# See which modules are available and which are enabled
ls /etc/apache2/mods-available/
apache2ctl -M

Output:

Loaded Modules:
 core_module (static)
 so_module (static)
 mpm_event_module (shared)
 authz_core_module (shared)
 dir_module (shared)
 mime_module (shared)

The (static) modules are baked into the Apache binary and cannot be disabled. The (shared) ones are the ones you control with a2enmod/a2dismod.

Enabling the modules you will actually need

Here are the four modules most people enable first, with the exact commands.

# URL rewriting (needed for .htaccess RewriteRule, pretty URLs, redirects)
sudo a2enmod rewrite

# Reverse proxy support (forward requests to a Node/Python app)
sudo a2enmod proxy proxy_http

# HTTPS / TLS support
sudo a2enmod ssl

# Set or remove HTTP response headers (security headers, caching)
sudo a2enmod headers

# Apply the changes
sudo systemctl reload apache2

Output:

Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2

Tip: a2enmod suggests a full restart, but reload is almost always enough and does not drop existing connections. Use sudo systemctl reload apache2 for config and module changes. Only restart if a reload reports an error or the module specifically requires it.

Always test the config before reloading so a typo cannot take your site down:

sudo apache2ctl configtest

Output:

Syntax OK

Commonly needed modules

Module	What it does	When to enable it
rewrite	Rewrites and redirects URLs (the engine behind .htaccess rules)	Pretty URLs, force HTTPS, single-page-app routing
ssl	Adds HTTPS / TLS so traffic is encrypted	Any site facing the public internet
proxy + proxy_http	Forwards requests to another server or app	Putting Apache in front of a Node, Python, or Java app
headers	Adds or removes HTTP headers	Security headers, cache-control, CORS
deflate	Gzip-compresses responses to save bandwidth	Almost always, for HTML/CSS/JS
expires	Sets cache expiry headers on static files	Speeding up repeat visits
http2	Enables the faster HTTP/2 protocol	Modern sites already on HTTPS
status	Exposes a live server-status page	Debugging and monitoring (lock it down!)

The rewrite module is what makes .htaccess rules work — see the dedicated .htaccess page below for the rule syntax. The proxy family is what turns Apache into a reverse proxy (a server that sits in front of your app and forwards requests to it); the Apache reverse-proxy page covers that setup in full.

Disabling a module you do not need

If you enabled something for testing, or a default module is unused, turn it off. For example, Apache’s CGI module is rarely needed on a modern site:

sudo a2dismod cgi
sudo systemctl reload apache2

Output:

Module cgi disabled.
To activate the new configuration, you need to run:
  systemctl restart apache2

Be careful: some modules depend on others. If you try to disable a module that another one needs, a2dismod will warn you and may refuse. For instance, disabling proxy while proxy_http is still on is blocked because proxy_http cannot work without it. Disable the dependent module first.

Security gotcha: Never enable status or info modules on a public server without restricting access. The server-status page leaks request details and internal IPs. If you do need it, wrap it in a <Location> block that limits access to 127.0.0.1 (localhost) and your own admin IP only.

Verifying a module is loaded

After reloading, confirm the module is really active rather than just symlinked:

apache2ctl -M | grep rewrite

Output:

 rewrite_module (shared)

If it shows up here, Apache has loaded it and the related features (like RewriteRule directives) will now work.

Best practices

• Enable only the modules a site genuinely uses — every disabled module is one fewer thing to patch and secure.
• Always run sudo apache2ctl configtest before reloading so a syntax error never reaches production.
• Prefer sudo systemctl reload apache2 over restart for module changes to avoid dropping live connections.
• Disable default modules you do not need (such as cgi, status, autoindex) on internet-facing servers.
• Respect module dependencies — disable dependent modules (like proxy_http) before their parents (proxy).
• Document which modules you enabled and why, so future-you knows what is safe to remove.

Related Topics

• .htaccess files
• Apache as a reverse proxy
• Apache virtual hosts
• Installing Apache
• What is Apache?