Configuring virtual hosts is easy. Simply create a separate server directive for each virtual host:
server { listen 80; server_name www.domain1.com, domain1.com; root /usr/share/nginx/domain1; access_log /var/log/nginx/domain1.access.log main; location / { … }}
server { listen 80; server_name www.domain2.com, domain2.com; root /usr/share/nginx/domain2; access_log /var/log/nginx/domain2.access.log main; location / { … }}
To enable HTTP authentication, you need to create a password file with the htpasswd command:
On Fedora and CentOS:
# htpasswd -c /etc/nginx/mypassfile <username>
On Ubuntu:
$ sudo htpasswd -c /etc/nginx/mypassfile <username>
Then add the auth type and specify the password file under a location directive like this:
location /private { auth_basic "Password Protected"; auth_basic_user_file /etc/nginx/mypassfile;}
That will require a password to access the /private directory under the document root.
You can also limit access by IP address, like so:
location /private { allow 192.168.23.10; allow 10.0.1.0/24; deny all;}
That configuration would permit host 192.168.23.10 and subnet 10.0.1.0/24 to access the /private directory, but deny requests from any other IP addresses.
SSL support requires the creation of SSL keys and certificates, which is outside the scope of this document. However, you will find sample SSL configurations in the default nginx config files. They function like so:
server { listen 443; root html; index index.html index.htm; ssl on; ssl_certificate cert.pem; ssl_certificate_key cert.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / { try_files $uri $uri/ /index.html; }}
This is a standard server directive, but it contains the ssl on instruction, which will enable SSL for this instance. It also specifies TCP port 443, the standard SSL port. The files cert.key and cert.pem constitute the key and certificate needed to use SSL. You can create those yourself with OpenSSL and use unsigned certificates, or you can create a request to send to a certificate authority for a global certificate, then reference those files here.
If you’ve used Apache, you may have configured URL rewrites with mod_rewrite. In Nginx, those rewrites are built right into the configuration, like so:
server { listen 80; server_name www.example.com, example.com; root /var/www/html; rewrite_log off; rewrite ^/orig(.*) /new$1 break;…}
This directive will rewrite a URL for http://www.example.com/orig/etc to http://www.example.com/new/etc, then stop processing. You can add other rewrites in this stanza that would be used if the rules above do not match. Also, note that you can configure the rewrite_log directive to log rewrite attempts, which is useful when trying to construct rewrite rules.
Although dedicated load balancers such as HAProxy are better tuned for the job, Nginx can fulfill this role too with minimal configuration. Here’s an example:
http { upstream webservers { server web1.example.com; server web2.example.com; server web3.example.com; } server { listen 80; location / { proxy_pass http://webservers; } }}
In this configuration, we define an upstream collection of servers (web1.example.com and so on), then set a proxy_pass directive that rotates through them. Thus, requests coming into Nginx will be passed along to those servers in a round-robin fashion. We can also configure least_conn and ip_hash or apply specific weights to those servers in order to more finely control the load balancing.
Nginx is a very fast and capable Web server that requires little configuration to get running out of the box. Under the right workload, it can provide faster service with lighter resource requirements than Apache, especially for static files.
You can find much more information on Nginx at wiki.nginx.org.
