Install Nginx on Ubuntu 16.04

Nginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy and HTTP cache. With all these qualities it makes a definite competitor for Apache. To install Nginx follow our straightforward tutorial.

Pre-Flight Check

  • Logged into an as root and are working on an Ubuntu 16.04 LTS server powered by Liquid Web! If using a different user with admin privileges use sudo before each command.

Step 1: Update Apt-Get

As always, we update and upgrade our package manager.

apt-get update && apt-get upgrade

Step 2: Install Nginx

One simple command to install Nginx is all that is needed:

apt-get -y install nginx

Step 3: Verify Nginx Installation

When correctly installed Nginx’s default file will appear in /var/www/html as index.nginx-debian.html . If you see the Apache default page rename index.html file. Much like Apache, by default, the port for Nginx is port 80, which means that if you already have your A record set for your server’s hostname you can visit the IP to verify the installation of Nginx. Run the following command to get the IP of your server if you don’t have it at hand.

ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'

Take the IP given by the previous command and visit via HTTP. (http://xxx.xxx.xxx.xxx) You will be greeted with a similar screen, verifying the installation of Nginx!

Nginx Default Page

Note
Nginx, by default, does not execute PHP scripts and must be configured to do so.

If you already have Apache established to port 80, you may find the Apache default page when visiting your host IP, but you can change this port to make way for Nginx to take over port 80. Change Apache’s port by visiting the Apache port configuration file:

vim /etc/apache2/ports.conf

Change “Listen 80” to any other open port number, for our example we will use port 8090.

Listen 8090

Restart Apache for the changes to be recognized:

service apache2 restart

All things Apache can now be seen using your IP in the replacement of the x’s. For example http://xxx.xxx.xxx.xxx:8090

Configuring NGINX for Managed WordPress

Running a WordPress site can be incredibly simple and used right out of the box, but you may need to customize or add specific files in order to get the most out of your site. Our Managed WordPress customers can include custom NGINX configurations for individual sites because we know that adding simple redirects or adjusting browser cache settings are actions that many of our Managed WordPress users do on a regular basis. Read on to learn how you can use this functionality for your own site.

On the Managed WordPress platform, custom configuration files are read from the NGINX folder within the site’s home directory. Any file ending with .conf will be read into NGINX on reload or restart, so a file called ~/nginx/user.conf.sample is provided as a placeholder.

While you can create and edit these files, it is necessary that you reach out to our Managed WordPress Support team to reload the NGINX configuration. This will allow us to test the file configuration and confirm that there are no errors or warnings. Because your site performance and uptime is important, the Managed WordPress support team will manually review files to check for potentially irregular and harmful configurations.

Although the primary use of this feature is for configuring redirects at the NGINX level. you may also set custom browser cache expiration times for static files. Any configurations beyond those described below are considered beyond scope support.

An example of simple redirects:

# Simple redirect to an individual page
location /example-redirect-123 {
add_header X-Redirect-By "Yoast SEO Premium";
return 301 /example-redirect;
}

# Rewrite all urls under an old path to a new path
location /category/old-category {
rewrite ^/category/old-category/(.*)$ /category/new-category/$1 permanent;
}

An example of adjusting browser cache settings:

# Reduces js and css cache times to a single day instead of the MWP default of 1 year.
location ~* \.(?:css|js)$ {
expires 24h;
access_log off;
add_header Cache-Control "public";
}

If you are looking to block access to a specific directory, you can complete this request by using the following command:

rewrite ^/wp-content/private_directory/(.*) /last;

Where “private_directory” is the directory you wish to block access to.

Configuring NGINX

  1. Log into the site via SSH.:ssh/sftp credential section in Managed WordPress portal highlighted
  2. Navigate to the NGINX directory located in the home directory.
    s150@default:~$ pwd
    /home/s150
    s150@default:~$ cd nginx
    s150@default:~ngingx$ ls
    user.conf.sample
    s150@default:~/nginx$
  3. Next, create a file ending in .conf:
    s150@default:~/nginx$ touch redirects.conf
    s150@default:~ngingx$ ls
    redirects.conf user.conf.sample
    s150@default:~/nginx$

    In this example, we are using redirects.conf, but you can name it anything you’d like, just make sure you remember the file name.
  4. Then modify the file with the configuration changes:
    s150@default:~/nginx$ vi redirects.conf
    s150@default:~ngingx$ cat redirects.conf
    # Limited to directives valid in the server block context
    # All files ending in '.conf' in this directory will be loaded
    # Please contact support to have them reload the nginx config files
    # for changes to go into effect.# Configure redirects
    #
    loacation /example-redirect-123 {
    add_header X-Redirect-By "Yoast SEO Premium";
    return 301 /example-redirect;
    }
    s150@default:~/nginx$
  5. Lastly, contact support to request review and reload of the config. You can easily reach our Managed WordPress support team by opening a chat or ticket through your Managed WordPress portal, or by calling our team at 1(833)845-4527 or 1(517)322-0434.

How To Boost Web Server Performance with Nginx and Apache

Apache is the most commonly used web server software on the Internet, and for good reason.

Its long history, general reliability, thorough documentation and active support community have helped it grow to include support for nearly anything a web developer can think to throw at it. But Apache’s universal support has not come without some trade-offs.

Why Apache Alone May Not Meet Your Needs

Apache excels at serving web pages, but its resource requirements (particularly memory) increase as it’s given more to do, thanks to the way Apache manages processes. Apache’s process management is governed by its Multi-Processing Module (MPM). The most common are prefork, worker, and event.

Each time a new request comes in, Apache creates a new process to handle it.

  • In prefork mode, each process contains a single thread (the code which runs inside of a process).
  • In worker mode, each process can contain multiple threads, each handling a single connection.
  • In event mode, each process can contain multiple threads, but each is able to handle more than one connection at a time.

Regardless of the MPM, new processes still are being created to handle new incoming requests (although worker creates fewer than prefork, and event creates fewer than worker).

As requests keep coming in and new processes are created to handle them, CPU and memory usage continue to increase. That drives up load, slows the server down, and ultimately (should the amount of incoming requests far exceed the server’s capabilities) could cause it to become unresponsive. With Apache, scaling up typically requires adding RAM or CPU cores to cope with greatly increased traffic.

And that’s the essential problem Nginx aims to solve: Scalability.

Unlike Apache, Nginx does not create new processes to handle incoming requests. It runs with a set number of processes, typically only one per CPU core, and each of its few processes uses a single thread to handle many requests (potentially thousands) at the same time.

Because of this, Nginx’s resource requirements don’t tend to increase with incoming requests as do Apache’s. And thanks to its small footprint, it’s also able to do the job considerably faster.

One Server’s Weakness Is Another’s Strength

While Nginx’s processes management can be much more efficient and it can serve pages at lightning speed, it’s important to note that the potential performance gains with Nginx are most dramatic when serving static content.

That’s because, unlike Apache’s all-in-one approach, Nginx can serve only static content natively (html, images, javascript and css, etc.). To keep it as lightweight as possible, Nginx relies on separate applications such as PHP FastCGI Process Manager (FPM), Tomcat, or Apache to serve dynamic content.

Unless your site is mostly comprised of static pages, you may decide that there’s not a tremendous amount to be gained by switching from Apache to Nginx outright, given that you’d still need to rely on another application to serve the dynamic content.

And that’s the beauty of using the more-powerful Apache and the more-nimble Nginx together.

In terms of resource usage, Apache doesn’t really care what type of content it’s serving. Processes are created and threads are spun off based only on the number of incoming requests. That makes it somewhat less than ideal for serving extremely large amounts of small, static resources.

By allowing Nginx to serve the static content and pass requests for dynamic content to Apache, you can (for a small amount of overhead up front) effectively eliminate the drain on resources that otherwise would have been caused by having Apache serve all that static content.

Meanwhile, Nginx is caching as it serves, making future requests that much faster still.

This setup, in which Nginx listens on the standard web port (typically 80) and transparently passes requests to the appropriate server, is called a reverse proxy configuration.

Depending on your site’s composition and the number of static resources served, you could find that pairing Nginx and Apache can yield dramatic results.

Considerations

  • Apache, assuming it already is installed and running, would need to be configured to run on another port.
  • After switching the Apache port, sites on the server would not be accessible at their normal URLs until Nginx is installed, properly configured, and running.
  • Nginx handles virtual hosts (vhosts) differently than Apache, and each existing virtual host entry would need to be recreated for Nginx.
  • Some control panel software, such as cPanel/WHM, does not officially support Nginx (although WHM/cPanel plugins are available).
  • The installation, configuration, troubleshooting and maintenance of Nginx is not supported by Liquid Web on any platform; do not attempt to install any software or modify any configuration files unless you have fully researched the process and know how to address any potential issues that may arise.

Find More Information in Our Knowledge Base

 

How to Install Nginx on Ubuntu 15.04

nginx is a free, open source, high-performance web server. Need HTTP and HTTPS but don’t want to run Apache? Then nginx may be your next go-to, at least for Linux.

Pre-Flight Check

  • These instructions are intended specifically for installing nginx on Ubuntu 15.04.
  • I’ll be working from a Liquid Web Self Managed Ubuntu 15.04 server, and I’ll be logged in as root.

Continue reading “How to Install Nginx on Ubuntu 15.04”

How to Install Nginx on Ubuntu 14.04 LTS

nginx is a free, open source, high-performance web server. Need HTTP and HTTPS but don’t want to run Apache? Then nginx may be your next go-to, at least for Linux.

Pre-Flight Check

  • These instructions are intended specifically for installing nginx on Ubuntu 14.04 LTS.
  • I’ll be working from a Liquid Web Self Managed Ubuntu 14.04 server, and I’ll be logged in as root.

Continue reading “How to Install Nginx on Ubuntu 14.04 LTS”