HTTP Strict Transport Security (HSTS) protects against HTTP downgrade attacks by forcing browsers to only make secure connections with your domain. Adding NGINX HSTS is similar to and designed to work with SSL redirects. The HSTS header embeds the redirect code within the user’s web browser. The security HTTP header is supported by the most popular web browsers today, including the KaiOS browser.

Implementing the NGINX HSTS header prevents users from overriding invalid or self-signed certificate warnings. Your website will become inaccessible without a valid SSL certificate.

This is the most secure HSTS header with every directive enabled:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Let’s break down each directive of the HSTS header.

max-age: Specifies how long the header will be active in seconds. This is the only required directive. This must be set to “31536000” to be eligible for HSTS preloading.

includeSubDomains: Applies HSTS to all subdomains. If you add this optional directive, you’ll need to ensure any subdomains used for development and staging purposes have valid SSLs installed.

Preload: Authorizes preload listing in web browsers if eligible. By default, the user must visit your website for the browser to save the header for subsequent visits. That means the user is still vulnerable to HTTP downgrade attacks upon the first visit. To account for this, popular browsers ship with a text file containing every domain submitted to “preload” the HSTS header. 

Preloading is a two-step process. First you must add “preload” to your HSTS header. The max-age must comply with current standards as well. Then, you must submit your domain at https://hstspreload.org.

Preloading is most beneficial for larger businesses that have the ability to ensure the domain (and subdomains if applicable) always have a valid SSL. It can take up to six months for a submitted domain to be added to the preload list. It can take even longer to remove it between email inquiries and updates to supported browsers.

Note: You must be on a VPS or Dedicated server to complete the steps in this guide.

Adding NGINX HSTS in SSH

After you log into SSH, edit the NGINX server configuration file for the domain. If you only have one domain on the server, edit the default NGINX configuration file:

sudo nano /etc/nginx/sites-enabled/default

Add the following line directly under the “listen” lines (remove “; preload” if not needed):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Remember, the max-age must be at least 1 year (31536000 seconds) for HSTS preloading.

Here’s an example of the how this might look in your configuration file:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

After you save your changes, restart NGINX:

systemctl restart nginx

Check your server HTTP headers.

curl --head localhost

The HSTS header should display near the bottom.

HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Thu, 09 Dec 2021 16:28:01 GMT
Content-Type: text/html
Content-Length: 10701
Last-Modified: Tue, 03 Aug 2021 14:28:03 GMT
Connection: keep-alive
ETag: "00000000-12ab"
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Accept-Ranges: bytes

If you have to clear system caching and want to double-check from a PC, you can use wget which will follow any redirects automatically:

wget --server-response --spider example.com

Want to learn more about hardening your NGINX web server? Check out our guide on how to hide your NGINX server version.

NGINX can be used as a web server (in lieu of Apache) or proxy server. For those using it as a web server, creating NGINX redirects requires editing server configuration files. This is different from Apache which also checks .htaccess files during web server requests. NGINX doesn’t use .htaccess. Need to know how to redirect HTTP to HTTPS in NGINX? Don’t worry. It’s a simple process, as easy as hiding your NGINX server version. Below we’ll cover how to:

• Create NGINX Redirects
  • Redirect HTTP to HTTPS
  • Redirect to Force www
  • Redirect for a domain
  • Permanent Redirect for a Single File

Create NGINX Redirects

SSH into your NGINX web server as user root. Edit your NGINX configuration file using Nano, Vim, Emacs, etc. We’ll be editing domain configuration files in the sites-enabled directory as it is the easiest method to create NGINX redirects. The file may state default or take the name of the domain.

nano /etc/nginx/sites-enabled/default

vim /etc/nginx/sites-enabled/example.com

Ignoring the comment lines, the default file will resemble the code block below:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
}

Most changes below can all be done within existing code. Just remember to restart NGINX after making changes for them to take effect.

systemctl restart nginx

To save time troubleshooting, negate caching issues by testing changes in a private browsing session.

Redirect HTTP to HTTPS

To force encrypted connections, add the following to a new line under server_name _;:

return 301 https://$host$request_uri;

You can install a free domain-validated SSL certificate with Certbot.

Redirect to Force www

Deciding to explicitly use “www” or not for your website improves search engine optimization (SEO). First, add the following above the existing server { line:

server {
        listen       80;
        server_name  www.domain.com;
}

If you want to force HTTPS, add this line above the closing } bracket:

return 301 https://www.domain.com$request_uri;

Finally, add the following to a new line under server_name _;:

return 301 http://www.domain.com$request_uri;

Redirect a Domain to Another Domain

This is useful when migrating your website to a newer domain or subdomain (e.g. /blog or /forum). Add the following to a new line under server_name _;:

return 301 https://newdomain.com$request_uri;

Permanent Redirect for a Single File

To redirect a single page or file URL, add the following to a new line under server_name _;:

rewrite ^/page1.html$ /page2.html permanent;

Learn more from our Cloud Server Hosting Product Guide.

See the image for an example of how this may appear:

If your new Nextcloud installation resembles this, the issue may be related to your NGINX cPanel Cache Manager settings.

Note: the cPanel Cache Manager is only available on our WordPress Hosting, Managed VPS Hosting, and Dedicated server hosting plans.

Our customized NGINX static content acceleration ignores .htaccess rules and serves data directly from the file system. This can create issues in Nextcloud and other content management systems (CMSs) that depend on .htaccess rules to serve content correctly.

Below we cover how to use Nextcloud on your NGINX server.

Per our Terms of Service, Nextcloud should only be installed on our top VPS hosting or higher. Contact our Live Support directly with questions regarding this.

Modify cPanel Cache Manager for Nextcloud

1. Log into cPanel
2. Select the Cache Manager
3. Select the Nextcloud domain or parent domain from the drop-down menu
4. Select the Options tab
5. Select Show Advanced Options at the bottom for more settings
6. Under Accelerate Static Content, select Disable
7. Save Changes
8. If you refresh Nextcloud (F5 or Ctrl+R), the application should look normal now

Remember, storing files online is risky by default. After you get Nextcloud working, consider some of these free Nextcloud apps:

• Antivirus for files uses ClamAV (available on Cloud and managed VPS/Dedicated servers) to scan uploaded files to protect your server from malware by deleting or logging suspicious files. See our guide on How to Install and configure ClamAV plugin for cPanel.
• Brute-force settings protects against rainbow table password attacks and white-lists specified IP addresses from being blocked
• Two-factor authentication (2FA) plugins using different mobile applications and methods are available in the Nextcloud app store
• Password policy is pre-installed to allow you to set minimum strength requirements for user passwords
• Passwords is a password manager application within Nextcloud for users that are always on the go

If you have any issues with Nextcloud on NGINX, let us know in our Community Support Center.

In this article, we will outline how to install the popular NGINX web server software on your VPS or Dedicated Hosting account. Installing this software allows your web server to cache content and increase server performance. This ultimately translates into faster websites and better experiences for end users. The installation process requires both root WHM and SSH access and is only recommended for users with familiarity with Command Line Interfaces (CLI). As this process requires root-level access, it can only be performed on VPS or Dedicated Hosting accounts.

Topics Include:

• Changing Listening Ports
• Installing NGINX

Changing Listening Ports

1. First, log into WHM as the root user.
2. Next, click the Tweak Settings link in the Server Configuration section.
3. On the Tweak Settings page click the “>” to scroll, then click the System tab when you see it.
4. Scroll down to the Apache non-SSL IP/port options and select the box to change ports. Since we want to set the listening ports to 8080 for InMotion servers, enter the following:
   
   0.0.0.0:8080
   
5. Navigate to the Apache SSL port setting and select the box to change the ports. Since InMotion uses port 8443 enter the following:
   
   0.0.0.0:8443
   
6. Scroll down to the bottom of the page and click the Save button to open the listening ports.

Installing NGINX

1. First, connect to your server as the root user via SSH.
2. Once logged in, run the following command:
   
   yum -y install imh-ultrastack-ded
   
3. You will see the following message, type ‘y’, then press the enter key.
   
   Install 1 Package
Total download size: 484 k
Installed size: 1.3 M
Is this ok [y/d/N]: y
   
   The software has been installed successfully when you see a message such as this:
   
   Installed:
imh-nginx.x86_64 0:1.13.3-2.el7
Complete!

Congratulations, you have now installed NGINX!

More Resources

To take full advantage of everything NGINX has to offer, please see the following resources:

• Install cPanel Cache Manager
• NGINX Education Channel

Banner grabbing is the act of scanning websites to find server information including services and open ports. This technique is used during vulnerability assessments. Hiding your NGINX server version from scanning tools makes it harder for hackers to know what vulnerabilities can be exploited on your server.

Below we’ll cover how VPS and dedicated server administrators can view server header info and hide your NGINX server version.

Log into SSH or WebHost Manager (WHM) Terminal (if managing a cPanel server) as root before continuing.

View and Hide NGINX Server Header Information

You can use the following terminal command to check your current server information.

curl --head yourdomain.com

You can also view this information with online tools such as https://securityheaders.com and https://observatory.mozilla.org. However, you’ll still need to access the terminal to make necessary changes to your server.

In a default configuration, the first two lines of results will display the HTTP protocol, HTTP status code (200, 301, 302, etc.) for the info returned, and server version info. For example:

HTTP/2 200
server: nginx/1.16.7

We’ll remove that version number to make it just a little harder for cyber attackers to infect your server.

1. Edit the NGINX configuration file:

   nano /etc/nginx/nginx.conf

2. Under the # HTTP Options and ## lines, add a new line:

   server_tokens off;

3. Save changes: Ctrl + x.
4. Check your NGINX server information:

   curl --head yourdomain.com

Note that these changes may take up to a few hours to reflect in header information, depending on system caching settings.

There are many other ways to configure your NGINX web server for better website security. Check out our Support Center for more articles about advanced NGINX configuration.

Learn more about how to secure your server with our Managed Hosting team and Launch Assist today.

Most of the steps in this article require root-level SSH access to your server and assume basic familiarity with Linux system administration. Check out some of the following articles if you need a refresher:

• Obtaining root access
• How to login via SSH
• Editing files with Nano

Adding custom NGINX directives

It may be desirable to add custom NGINX configuration directives — either to change a global configuration option, or only for a specific domain. Both options will be covered here. However, it should also be noted that in many cases, changing the NGINX configuration is not required (and may not be desirable). For example, you may come across a tutorial that provides a list of NGINX rewrites that can be added to your configuration for a certain WordPress plugin. In most cases, this should actually be done in the Apache configuration (such as in an .htaccess file). Many tutorials that pertain to NGINX assume that Apache is not running “behind” NGINX, so the directives do make sense in those cases. However, if the necessary functionality can only be provided by NGINX, then follow along with the steps below.

Using per-domain includes

It is possible to add custom NGINX directives in the server{} block of the NGINX configuration for a specific domain on your server. For example, this includes adding additional location{} blocks, or defining redirects or rewrites (rewrite).

First, open up /opt/ngxconf/config.yaml with a text editor, such as vim or Nano:

 nano /opt/ngxconf/config.yaml

Change the option allow_user_includes from false to true, then save and exit (in Nano, press Control+X, then Y to confirm saving).

Once this option has been enabled, include files can be created for each domain that requires custom directives. For example, if your user exampl5 owns the domain example.com, then the include file would be created at /home/exampl5/.imh/nginx/example_com.inc.conf. Use an editor such as vim or Nano to edit the file.

Once the include files are created, you’ll need to force-rebuild the NGINX configuration:

 ngxconf -Rrd --force

If you receive a validation error, then run nginx -t to re-validate the configuration, which should report the line that’s causing the error. Then either fix or remove the code from the include file to resolve the problem, and re-run ngxconf -Rrd --force to rebuild again.

Changing global options

If a global NGINX configuration option needs to be changed or added, this can be accomplished by either editing the file at /etc/nginx/nginx.conf (not recommended), or by creating a new file in /etc/nginx/conf.d. For example:

 nano /etc/nginx/conf.d/custom.conf

This should open up Nano and allow you to add custom directives or configuration values. The configuration options should be intended for use inside of the http{} context — double-check the NGINX documentation for the directive you’re attempting to use to confirm this.

Once you have finished adding custom directives, be sure to test the configuration, then reload NGINX:

 nginx -t service nginx reload

If nginx -t reports an error, then re-open your file and fix any problems before continuing. After fixing, re-check again with nginx -t, then proceed with reloading if validation is successful.

Setting global defaults & overrides

It is possible to define default Cache Manager settings, which will be applied to all domains on the server. This can be handy for PCI compliance, as well as ensuring the cache settings are the same across all domains, without having to manually make these changes for each user. Please note that only one of the options below should be used — they should not be used together.

Setting global defaults

Open /opt/ngxconf/config.yaml with vim or Nano, then enable the following option flag. If the key does not exist, then create it:

 apply_user_default_config: true

Next, create a new file at /opt/ngxconf/defaults.yaml, then populate it with the values you would like to set as defaults for all users. Below is an example that shows how to disable TLSv1 and TLSv1.1, then set a default cache time of 60 minutes.

 --- cache_time_default: 3600 enable_tlsv1: false enable_tlsv1_1: false

Keep in mind that these settings will only be applied when a default configuration is generated. After the defaults have been generated, the user can still modify the values of these options later on. To reset all user configs to defaults, run the following command:

 # WARNING: Running this command will reset any user-chosen configuration options for ALL domains # to the defaults you have set in defaults.yaml (SSL-related options will still be automatically generated) ngxconf -Rrd --defaults --force

Setting global overrides

Open /opt/ngxconf/config.yaml with vim or Nano, then enable the following option flag. If the key does not exist, then create it:

 user_default_override_local: true

Next, create a new file at /opt/ngxconf/defaults.yaml, then populate it with the values you would like to override for all users. Below is an example that shows how to disable TLSv1 and TLSv1.1, then set a default cache time of 60 minutes.

 --- cache_time_default: 3600 enable_tlsv1: false enable_tlsv1_1: false

After making the necessary changes, rebuild the configuration for all users:

 ngxconf -Rrd --force

Available configuration options

Below is a list of all possible configuration values that can be used when creating a default or override configuration. These are the same values that are modified when a change is made in the Cache Manager Plugin in cPanel for a particular domain.

• pass_all – Passes all requests and responses through to Apache, unchanged. This creates a simple stub server{} block that passes everything to Apache. No other options (with the exception of SSL/TLS) will be taken into consideration if enabled. (default: false)
• error_page – Specify a custom user-created page to display if the server encounters a 503 (Service Unavailable) or 504 (Gateway Timeout) error (default: ‘/50x.html’ or server default)
• proxy_proto – Protocol to use when requesting a page from the origin Apache server; this can be set to https to prevent redirect loops in certain applications (default: http; possible values: http, https)

Cache options

• cache_time_default – Default cache TTL if the origin does not supply an X-Accel-Expires header. X-Accel info (default: 60)
• cache_time_modsec – Cache TTL for ModSecurity hits that return a 406 status code (default: 0)
• cache_time_404 – Cache TTL for hits that return a ‘404 Not Found’ status code (default: 10)
• cache_lock_enable – Enable cache locking; this ensures that only one request is sent to the origin Apache server, even if multiple request that page at the exact same time (default: True)
• cache_convert_head – Convert HEAD requests to GET requests for the purposes of caching (default: true)
• cache_honor_cc – When enabled, Cache-Control headers are honored. This is disabled by default, since many CMSes set this value to zero (default: false)
• cache_honor_expires – When enabled, Expires headers are honored. This is disabled by default, since many CMSes set this value to a time in the past (default: false)
• cache_honor_cookies – When enabled, Set-Cookie headers from the server are honored. This should be left enabled in most cases. (default: true)
• cache_bypass_paths[] – List of URIs which will always bypass the cache (default: see below)
• bypass_cookies[] – List of strings to match in the Request cookies which will trigger a cache bypass. This is important to ensure that logged in users’ pages are not being cached and shown to other visitors. The default setting should work with most WordPress sites, but may need to be updated for certain plugins, or if using a CMS other than WordPress

Server options

• fast_sending – Sets the postpone_output value to 0 for current server block; this is typically not a good idea if gzip is also enabled (default: false)
• gzip – Compress response via gzip, using the specified level; 0 = disabled (default: 3)
• accel_static_content – Bypass Apache to directly serve static content. The server block will use the try_files directive in a location block with a set of specific file extensions (default: true)
• static_content_paths[] – List of URIs which should be served directly by NGINX (default: [‘/wp-content/uploads’])
• force_passthru[] – List of URIs which should always be forwarded to Apache (default: [])
• Rate-limiting ratelimit – Sets the number of requests per minute allowed to login or other rate-limited URIs; set to 0 to disable (default: 15)
• ratelimit_paths[] – List of URIs which should be rate-limited

SSL/TLS options

• enable_hsts – If enabled, send a Strict-Transport-Security header (default: false)
• enable_http2 – Enable http/2 (default: true, if an SSL is installed)
• force_https – If enabled, all traffic is redirected to https:// (default: false)
• allow_compat_ciphers – If enabled, export and deprecated ciphers and protocols will be enabled. By default, these will be disabled. (default: false)
• enable_tlsv1 – Enable TLSv1 support (default: true)
• enable_tlsv1_1 – Enable TLSv1.1 support (default: true)
• set_default – Set the current domain as the default. This option adds the default_server option to the NGINX listen directive for this server{} block. This means that this block will be served if the client directly visits an IP address, or their browser does not support SNI (default: false)

Using Node.js, Python, or Tomcat/Java applications with NGINX

One of the major benefits of using a VPS or Dedicated Server is the ability to run your own custom software or services. The steps below will provide a general overview of how to configure NGINX to work with your Node.js, Python, or Java application.

Overriding the default Apache/PHP setup

First, we need to prevent the NGINX configuration tool (ngxconf) from building a configuration for the domain in question. To do this, use vim or Nano to modify the Cache Manager configuration, located at /home/$USER/.imh/nginx/$DOMAIN.yml. For example, if your user exampl5 owns the domain example.com, then the configuration file would be created at /home/exampl5/.imh/nginx/example_com.yml.

 nano /home/exampl5/.imh/nginx/example_com.yml

With the file open, add a new line at the top, with the following content:

 _exclude: true

Creating the new config file

Next, we need to create a new configuration file for your domain. Use a text editor again to create a file in /etc/nginx/conf.d. Example:

 nano /etc/nginx/conf.d/example_com.conf

In this example, we have Node.js listening on port 7000, so we will add a proxy_pass https://127.0.0.1:7000; directive to pass the traffic to our application. Below is a very basic configuration that should be modified to suit your needs:

 server {      listen 80;     server_name example.com www.example.com;      location / {         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header Host $http_host;         proxy_set_header X-Forwarded-Proto $scheme;         proxy_pass https://127.0.0.1:7000;     } }

To add HTTPS support, add the following block to your configuration file (in addition to the one above):

 server {      listen 443 ssl http2;     server_name example.com www.example.com;      ssl on;     ssl_certificate /var/nginx/certs/example-com.pem;     ssl_certificate_key /var/nginx/certs/example-com.key;      ssl_prefer_server_ciphers on;      ssl_session_cache shared:SSL:10m;     ssl_session_timeout 10m;     ssl_buffer_size 8k;       ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;     ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256';     ssl_dhparam /var/nginx/dhparams.pem;      location / {         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header Host $http_host;         proxy_set_header X-Forwarded-Proto $scheme;         proxy_pass https://127.0.0.1:7000;     } }

Remember to update the port number for proxy_pass to match your application, as well as the path to the SSL certificate and key. If you’re unsure of the path to your domain’s SSL certificate and key, you can check with the following command:

 grep ^ssl_certificate /home/USER/.imh/nginx/*.yml

Finally, rebuild the configuration:

 ngxconf -Rrd --force

If all went well, you should now be able to visit your domain and see the results of your configuration. Some applications may require additional configuration to pass through static files. In those cases, please follow the application recommendations, which are typically provided in their documentation.

Troubleshooting

If you receive a validation error when running ngxconf, then double-check your configuration file for errors. Use nginx -t to validation the configuration — it should report any problems, and display exactly which line in the configuration is the source of the error. After resolving the problem, reload NGINX by running:

 service nginx reload

If you receive a 502 Bad Gateway error, then double-check that your application is running and that the port number is correct. The NGINX error log should have further details — check the last few lines by running:

 tail -10 /var/log/nginx/error.log

If you run into a problem that you can’t seem to resolve, please don’t hesitate to reach out to our Support Team for assistance. Our Managed Hosting team is also experienced in performing custom server setups and can assist you in integrating external applications with your NGINX configuration.

In this tutorial:

NGINX Traffic Flow NGINX Logs Troubleshoot NGINX Additional Notes

In this tutorial, we will show you how to manage NGINX on your server. We will explain how the traffic flows, provide information on where relevant files and logs are located. Then, we will provide some NGINX troubleshooting steps and additional notes.

NGINX Traffic Flow

NGINX listens on port 80 and port 443 and relays requests back to Apache when it doesn’t have something cached. Apache builds your website and gives NGINX the HTML, etc. Then, NGINX gives it back to you and keeps a copy in cache in case someone else asks for it.

NGINX File/Log Locations

Your NGINX access logs and error logs are located here:

/var/log/nginx/

Troubleshooting NGINX

• Make sure you have changed the listening ports.
• It’s important to make sure that domains that are added in Apache/cPanel are also added in nginx’s configuration, which should happen by default if you’re using all of our packages
• It can be useful to disable NGINX caching to see if any website errors are being cached or if there’s something going on with the cache.

Additional Notes

It is important to know that restarting NGINX does not clear the NGINX cache. NGINX stores its cache in memory, but it also uses files to store the cache and the files have to be deleted. If you have a WordPress stack, you can use the Cache Manager in cPanel to clear the NGINX cache.

In this tutorial:

Change Listening Ports Install NGINX

If you no longer want NGINX on your server, you can easily remove the package to un-install it. In this tutorial we will walk you through removing NGINX from your cPanel server. First, you will have to change the listening ports back to the default settings in WHM. Then we will show you how to un-install NGINX from your server via SSH.

Change Listening Ports

1. Log into WHM as the ‘root’ user.
2. Click the Tweak Settings link in the Server Configuration section.
3. On the Tweak Settings page click the right arrow to scroll, then click the System tab when you see it.
4. Scroll down to the Apache non-SSL IP/port options and select the following default option:

    0.0.0.0:80 default
5. Navigate to the Apache SSL port setting and select the following option:

   0.0.0.0:443 default
6. Scroll down to the bottom of the page and click the Save button to open the listening ports.

Un-Installing NGINX

1. Connect to your server as the ‘root” user via SSH.
2. Run the following command to install NGINX.

   yum remove imh-nginx

3. You will see the following message, type ‘y‘ for yes then click the enter key.

   Remove 1 Package (+2 Dependent packages)
   
   Installed size: 3.7 M
   Is this ok [y/N]: y
   

   The NGINX package will then be removed. You are finished when you see a Complete! message such as this:

   Removed:
         imh-nginx.x86_64 0:1.13.3-2.el7
   
   Dependency Removed:
         imh-cpanel-cache-manager.noarch 0:1.0-3.el7 imh-ngxconf.noarch 0:0.9.10-1.el7
   
   Complete!

Congratulations, now you know how to un-install NGINX from your server!

Nginx (pronounced “Engine-X”) is an open source, high-performance Hypertext Transfer Protocol (HTTP) server. In technical terms, it is an event-driven asynchronous server. This means the method by which Nginx handles processes (required for loading web content, for example) is driven by conditions and delegated to alternative server resources to bear the load accordingly. Nginx is typically used to exploit higher performance from minimal resources, for example, on a VPS platform.

Nginx is versatile, in that it can be installed to replace Apache as the HTTP server. Because of its flexibility and lightweight design, it can also be installed along side Apache. In this manner, Nginx would be referred to as a reverse proxy.

How does Nginx compare to Apache?

On our servers, Apache is the default HTTP server that is configured for handling PHP processes to serve web content. In its default configuration, Apache is designed as a process-based architecture. This means that Apache forks (or threads) each process that is needed to serve web content.

Nginx alternatively scales these processes to help decrease the amount of CPU, RAM, and other server resources utilized, thus improving the load time. For instance, if one connection requests the same content as another, rather than processing those requests individually, Nginx analyzes and delegates accordingly. Both connections receive the same results of content loaded.

Although Apache and Nginx performance can both be similar in comparing load handling for small sites, Nginx’s architecture, by design, is more efficient for heavier sites. However, the benefits of Nginx can be experienced with simple web applications, like WordPress. A common configuration that is implemented to improve the handling of a high load, is to setup Nginx as a reverse proxy.

What is a Reverse Proxy?

A Reverse Proxy is a type of configuration in which a proxy server off loads a request to another web server (or multiple servers) to execute processes. When the results of the request are received by the proxy, it is then returned to the client. This kind of proxy results in the ability to cache dynamic content without having to continuously rely on the server’s resources for each request to load the same content. This results in a reduction of resources (like CPU, RAM, I/O) utilized and thus improves the performance of your site.

How Does a Reverse Proxy Work?

Putting this all together, typically server administrators will combine the use of Apache and Nginx as a reverse proxy to decrease the server resources needed to load a site’s content. Depending on Nginx’s configuration, when requests are made, it will first check to see if the processes have already been completed.

If the results of the requests do not exist, then Nginx will provide the requests to Apache for processing. Apache will handle the requests (forking/threading the requests) and then return the results to Nginx to serve to the client. If configured, it will also keep the results of the requests cached. This allows Nginx to quickly retrieve and serve them to any other connections that are requesting the same content.

If the results of the requests already exist, then Nginx will quickly retrieve and serve the cached content. Nginx may also be configured to analyze the cached version and update it with changes accordingly. Therefore eliminating the need for Apache to do anything for repeated visits/connections, even as content is updated.

Does Nginx work with WordPress hosting?

Nginx can be configured to handle your WordPress site so that your visitors will be able to see your site’s updated content and not just an outdated cached version. Included with your WordPress-optimized server is the cPanel plugin, Cache Manager. For more information on how you can simply leverage Nginx’s caching resources, review our article on the Cache Manager for cPanel.

Common Commands

Stop Command

Let’s say we wanted to stop Nginx right away without finishing the current worker processes. We would use the “stop” command like this:

Reload Command

Keep in mind, if you edit the configuration file for Nginx it will not be used or applied until the reload command is invoked or you restart Nginx. To force a reload of Nginx, run the command:

Once the reload command is ran a signal is sent to the master process. It then checks the syntax of the new configuration file and attempts to apply it. If this is successful, the master process will start new child processes using the new configuration. Old child processes still running will be sent a command to end the current process and restart using the new configuration.

If the new configuration is found to be invalid, the master process will roll back changes and will continue to use the old configuration. This is a great feature as you’ll never be able to stop the current configuration and replace it with an invalid one.