NGINX Setup and Configuration Tips

NGINX is a popular open source web server used to support websites and applications. In the annual State of Open Source Report, it is always among the technologies listed as the most business-critical. 

In this blog, we cover the basics of NGINX setup and installation, recommended best practices for NGINX configuration, plus other tips and resources to help teams find long-term success with NGINX. 

What Is NGINX?

NGINX is a fast and compact modular TCP/UDP server with HTTP, forward proxy, reverse proxy, load balancer capabilities. It was created by Igor Sysoev and publicly released in 2004. NGINX is free open source software, under the terms of the 2-clause BSD license. 

As a web server, NGINX is highly regarded and used by more than 350 million websites. Companies like Netflix and Dropbox rely on it to deliver content securely and quickly to millions of customers worldwide. 

NGINX Setup and Installation

NGINX can be installed from a pre-built RPM or DEB packages or built from source. Building from source allows for more flexibility in versions and modules.

Building from source with the required modules offers tailored functionality, which decreases the attack surface and granular choice of required modules for the server to perform its role. For example, to include TLS 1.3, HTTP/3, and QUIC support or image manipulation modules.

NGINX Configuration

NGINX configuration is a series of directives that control the modules. The directives are placed in a context, with the events and http directives residing in the main context. The server in http, and location in server context. Many other directives are context- and module-specific.

NGINX configuration supports many variables for dynamic configuration.

The NGINX Configuration File

By default, NGINX uses the /etc/NGINX/NGINX.conf file and conf.d sub-directories. Or additionally defined by the include directive.

The configuration file path can be altered and specified during the NGINX build process using ./configure --conf-path=PATH

To see all the currently loaded configuration files and directives, you can run the NGINX -T command.

NGINX Proxy Configuration

NGINX includes proxy server modules, which allow it to receive requests and forward on to the next node, returning the returned content. Beyond the simple use case, this can be used for TLS termination or HTTP protocol switching, as well as separate content to be loaded from different locations or servers.

The proxy_pass directive is used to forward the requests received on the listen port and location URI.

The proxy module offers a large number of directives to configure behavior, caches, and headers. You can see examples from NGINX here. 

NGINX Fast CGI Configuration

NGINX is able to route requests to FastCGI servers running any number of backend frameworks and applications.

Thefastcgi_pass directive is used to pass incoming client requests to the downstream application.

A common technique used together with the FastCGI processing is to split responses between dynamic and static content (image files). A more advanced performance tuning technique, depending on the FastCGI application, is dynamic content microcaching.

Examples for dynamic content caching include articles that don’t change often, RSS feeds, slow moving counters, date information, and help content.

The FastCGI microcaching is declared using the fastcgi_cache_path directive and path. You can learn more about FastCGI microcaching from NGINX here. 

NGINX MIME Type Configuration

The mime.types config file maps the common content types to extensions. Without including the mime.types configuration or defining the content type, the returned content type will be text/plain. This would break CSS, JS, etc.

Pre-Built Configuration Templates and Examples

Template and examples can be used as a quick starting point to begin configuration iteration, implementation, and testing. NGINX provides the following: 

• Example 1
• Example 2

The NGINX Configuration Validator

NGINX includes a configuration file validation command NGINX -t. 

You can also print the currently loaded configuration using NGINX -T. (NOTE: The first one has a lowercase “t” while the second uses a capital “T”.)

After changing a configuration file, the new configuration can be hot reloaded by the worker processes with the NGINX -s reload command.

Need NGINX Support? 

Our open source experts have years of experience working with NGINX. We can help. 

Talk to an Expert

NGINX Configuration Best Practices

There are several best practices that we recommend: 

Logging

Logging allows for troubleshooting, monitoring, and server observability. You'll be able to use metrics such as $request_time, $upstream_connect_time, $upstream_header_time, $upstream_response_time to HTTP codes, and more.

Depending on your risk profile, centralized logs can also provide anomaly analysis or historical graphs across applications. 

Start Minimal

Configuration can either be developed from scratch in an iterative process or a known good configuration can be copied from examples and an organization’s SDLC repository. If the configuration file is not already part of a maturity process, then it can be added to it.

Focus on Security 

In addition to the well documented OWASP web service security guidelines, we recommend not neglecting host Mandatory Access Control such as SELinux or AppArmor. This applies to Linux Operating Systems.

When using TLS, it is recommended to build NGINX with the latest version of OpenSSL, opt for the latest TLS protocol version(s) and enable thessl_prefer_server_ciphers directive. Configure a list of known good ciphers that are compatible with the expected client applications or libraries.

Document Along the Way

Change and version control for known secure configuration should include confidentiality and availability. Settings which seem more secure in terms of hardening may cause more CPU load and a drop in server performance. This is where an iteration can be rolled back or revised.

This enables configuration maturity as a process, from ad hoc, consistent/reproducible, metered, and improved.

Other NGINX Configuration Best Practices to Consider

In addition to the common web server and proxy server use cases, NGINX can be used for HTTP protocol switching or TLS termination.

With the development of QUIC and HTTP/3 protocols, NGINX can be used as a protocol switch. For example, taking advantage of the QUIC and HTTP/3 protocols on one network segment and switching to or from HTTP 1.1 for compatibility.

Final Thoughts

NGINX is a fast, resource-efficient web and proxy server with many modules. That said, it may not meet every possible need out of the box, and in complex use cases may require (Regex, LUA) scripting. In such cases, Apache HTTP and its modules may be a simpler way to achieve the required results. 

Working With NGINX? 

OpenLogic NGINX experts are ready to provide technical support and professional services to help you deploy and manage NGINX in your organization. 

Talk to an Expert

Additional Resources

• Blog - NGINX vs. HAProxy
• Blog - NGINX Performance Tuning: Top 5 Tips 
• Blog - Web Server Security Best Practices 
• Blog - Web Server vs. Application Server: What's the Difference?
• Blog - Tomcat vs. NGINX
• Blog - Apache vs. NGINX
• On-Demand Webinar - The State of Open Source Web App Development 
• Course - NGINX Training
• Guide - Open Source in the Enterprise