Directadmin Docs

Customizing NGINX/APACHE

per-domain nginx=1 (disable proxy) for nginx-only processing with Nginx reverse proxy

If you're running with custombuild options.conf setting:

webserver=nginx_apache

where apache is behind an nginx proxy, then by default all domains are listed in both the User nginx.conf and httpd.conf. All connections run through the nginx.conf, and some requests are passed through to apache as needed, while static files are processed by nginx.

This feature lets you shut off the proxy part, just for 1 domain, such that the domain is procssed 100% by nginx, without using apache at all. PHP is still enabled for the nginx-only domain (must use php-fpm just like standalone nginx).

To enable this for a given domain, add:

nginx=1

to the domain's config in:

/usr/local/directadmin/data/users/FRED/domains/DOMAIN.COM.conf

and issue a rewrite: /usr/local/directadmin/custombuild/build rewrite_confs

Relative CMD_* calls and JSON

To view the state of a domain:

CMD_ADDITIONAL_DOMAINS?action=view&domain=testdomain%2Ecom&ipp=50&json=yes&redirect=yes

Which is a dump of the domain.com.conf file, and will include this if enabled:

nginx=1

Additionally, HAS_PER_DOMAIN_NGINX=yes will be shown if this value is allowed to be controlled.

To save the setting:

CMD_DOMAIN
method: POST
action=modify
domain=testdomain.com
form_version=1.1
...
nginx=1

Which is to be saved along with all other settings (php, cgi, etc), OR you can save just this item:

method: POST
action=modify
domain=testdomain.com
only_affect=nginx
nginx=1

Disabling is the same as enabling, except pass either:

nginx=0

or simply omit the nginx variable entirely, as it is a checkbox and the absence is the equivalent to 'off'.

Relative skin changes

The following skin file:

/usr/local/directadmin/data/skins/enhanced/user/modify_domain.html

Now contains the following after php:

|*if HAS_PER_DOMAIN_NGINX="yes"|
        <tr>
            <td>|LANG_NGINX_ONLY|</td>
            <td align=center><input type="checkbox" name="nginx" value="1" |NGINX_CHECKED|></td>
            <td>|LANG_NGINX_ONLY_DESC|</td>
        </tr>
|*endif|

Relative Language pack changes

The file:

/usr/local/directadmin/data/skins/enhanced/lang/en/user/modify_domain.html

Now contains the following:

LANG_NGINX_ONLY=Nginx-Only
LANG_NGINX_ONLY_DESC=Use only Nginx. Proxy to apache is disabled.

Global custom include templates for Apache/Nginx

This feature will let you insert global custom values into the CUSTOM and CUSTOM# variables in the Apache/Nginx templates. You can think of this as a virtual_host2.conf subset template, that is only used if it exists, and gets inserted into the CUSTOM tokens for all VirtualHosts.

It would be handy if you want add code to all VirtualHosts, but don't want to create new templates, and don't want to add it to each domain's Custom Httpd Config.

Add the new custom template token files to the data/templates/custom folder, matching the token name you want, with a .pre or .post suffix e.g.,

/usr/local/directadmin/data/templates/custom/cust_httpd.CUSTOM.3.pre/usr/local/directadmin/data/templates/custom/cust_httpd.CUSTOM.post/usr/local/directadmin/data/templates/custom/cust_httpd.CUSTOM.2.post/usr/local/directadmin/data/templates/custom/cust_nginx.CUSTOM.post

with the Apache/Nginx code that you want to be inserted to the given token.

The prefix is either cust_httpd. or cust_nginx. to determine which server type the token is for.

Where .pre means that your code would be added before any CUSTOM/CUSTOM.# values set in:

Admin Level -> Custom Httpd Config -> domain.com -> CUSTOM

or .post means it would be added after any Custom Httpd Config data.

You can use tokens as desired.

If you're not sure if you should use pre or post, keep in mind that tokens can be set in Custom Httpd Config, so you could then read them if they're set and alter the behavior of your CUSTOM.post using if-then-else statements.

Global pre/post per-file before each Apache/Nginx CUSTOMX token

Very similar to the feature mentioned earlier, this variation does the same thing, but not for all templates, but rather for the specific template that is named.

All are located inside this directory:

/usr/local/directadmin/data/templates/custom/

And include:

virtual_host2.conf.CUSTOM.prenginx_server.conf.CUSTOM.4.postvirtual_host2_secure_sub.conf.CUSTOM.1.pre etc.

Where the format is:

<templatename>.<tokenname>.<pre|post>

Note these per-template token files are included before the "Global custom include templates for Apache/Nginx" files, which are still included, if both exist.

ALSO at the start/end of the entire httpd.conf or nginx.conf file, unrelated to any VirtualHost or CUSTOM token:

/usr/local/directadmin/data/templates/custom/cust_httpd.pre/usr/local/directadmin/data/templates/custom/cust_httpd.post/usr/local/directadmin/data/templates/custom/cust_nginx.pre/usr/local/directadmin/data/templates/custom/cust_nginx.post

which shows up just after the comments, before the user_virtual_host.conf, and at the very end of the .conf files. Note that these start/end .conf templates do not share the token files like per-domains do, so you cannot pass variables around in the same way. However, like all Apache/Nginx templates, they run as root, and they have embedded scripting abilities, so you can read or write data to disk, even a database, and control things that way.

Global pre/post file before each apache/nginx template

For the main domain http/https/subomain templates, you can now create custom template files that will be tokenized and inserted outside of the VirtualHost/server{} entry.

For example, if you want code before all main virtual_host2.conf templates, create:

/usr/local/directadmin/data/templates/custom/virtual_host2.conf.pre

with the code you want, and it will show up before all VirtualHosts from that given template.

This can be repeated for other template files:

nginx_server_secure_sub.confnginx_server_secure.confvirtual_host2_secure_sub.confvirtual_host2_secure.confnginx_server_secure.confnginx_server.confvirtual_host2_secure.confvirtual_host2.conf

How to install the Pagespeed module

Mod_pagespeed is an open-source Apache HTTP Server (or Nginx) module, which automatically applies chosen filters to pages and associated assets such as stylesheets, JavaScript, and HTML files, as well as to images and website cache requirements.

A major advantage of this module is that it does not require modifications to existing content or workflow, meaning that all internal optimizations and changes to files are made on the server side, presenting modified files directly to the user. Each of 40+ filters correspond to one of Google's web performance best practices rules.

If nginx_apache reverse proxy is used, one could install the Pagespeed module for Nginx only. To do so, follow the guide from the "Nginx > Customizing NGINX" section.

How to enable brotli compression

  1. Extract brotli under any path you prefer. In this case I chose to to extract it in the base of the custombuild directory.
cd /usr/local/directadmin/custombuild
mkdir brotli
git clone https://github.com/google/ngx_brotli.git brotli
cd brotli && git submodule update --init && cd ..
  1. Add a custom add-module directive.
mkdir -p custom/nginx_reverse
cp -p ./configure/nginx_reverse/configure.nginx custom/nginx_reverse/

Add the following somewhere before the last configuration line in custom/nginx_reverse/configure.nginx.

"--add-module=/usr/local/directadmin/custombuild/brotli" \

make sure to substitute /usr/local/directadmin/custombuild/brotli with whatever path it's been extracted under.

  1. rebuild nginx_apache
./build nginx_apache

This should have compiled nginx with the brotli module.

You can configure brotli by modifying /etc/nginx/nginx-includes.conf. Refer to the documentation found hereopen in new window.

  1. To test that the configuration was successful, add the following to /etc/nginx/nginx-includes.conf:
brotli on;
brotli_static on;

Restart nginx.

service nginx restart

curl one of your domains (exampledomain.com in this example).

curl -kL -I -H 'Accept-Encoding: br' http://exampledomain.com 2>&1 | grep -i encoding

If successful, the following output should be returned:

Content-Encoding: br
Last Updated: