Update:There is now a follow up to this post which deals with thedifferences between Nginx and Apache, it is recommended reading if you come from Apache:
Nginx is a fairly simple HTTP server, though there are a few gotchas people need to be aware of before they start using this 8th wonder. The most important is that Nginx is a reverse proxy first and HTTP server second, it does not necessarily have a concept of file, this will change the way we handle our configuration a bit.
The first thing you need to know is that the Nginx configuration file is an inheriting-hierarchy, directives specified in a higher block will filter down to lower blocks as a default value, from this follows that we want to specify things in the top most hierarchy whenever possible. Since directives in top blocks filter down as default values it is still possible to override them in most cases.
There are 3 hierarchies which are usually referred to as blocks. The HTTP-block, the server-block and the location block of which the hierarchy goes like this: http -> server -> location.
Furthermore there are two special locations, an event block and the root which the event block and the http block reside in. Both of these contain only a minor amount of directives. The majority of your time will be spent in the other three blocks.
The blocks have a semantic meaning of sorts. The server block is what in Apache would be considered a virtual host. The location block usually referrers to the URI.
When using the official wiki the context keyword specifies in which block a directive may be used, as mentioned earlier it is usually recommended to specify the directive in the top most block.
Virtual Hosts
To begin with the most interesting directives are server_name and root. The former instruct Nginx to use this server block when the HOST header matches the value and the latter defines what to use as root when looking for files.
This forms the basic of our virtual hosts, an example would be:
server { listen 80; server_name domain.com *.domain.com; rewrite ^ http://www.domain.com$request_uri? permanent; } server { listen 80; server_name www.domain.com; index index.html; root /home/domain.com }
Here we have two virtual hosts. The first one is hit when domain.com or any subdomain of domain.com except for www is sent as the HOST header by the browser. The reason for this is that Nginx will always choose the most specific match, and if visting www.domain.com then this will match the second block precisely.
This also means you can create a default virtual host to catch all domains without a proper match. Thankfully this is as simple as adding the default_server flag to the listen directive. This causes all request without a HOST header or without another vhost matching the HOST header to be sent to this vhost instead. Examples are requests accessing the IP directly or if someone points a random domain at your IP. The server_name _; which you will see mentioned in a lot of guides means nothing and does nothing. It’s just a bogus invalid HOST header that can be used to make sure nothing ever matches it. You should be able to simply not define a server_name.
server { listen 80 default_server; server_name _; index index.html; root /var/www/default }
Locations
If you’re changing over from Apache then this is where you want to pay attention. Nginx typically does not use complicated rewrites – usually we can accomplish the same using a location block.
The most important things to note are that locations, with the exception of named locations, works on the URI without any query parameters and only one location block will ever be run. This is also why I recommend putting directives in the top most block. A root directive defined in location / will not be available in location /images – unless defined in the server block. I trust you see how defining things in the upper most block will prevent code duplication and headaches.
Another important point about locations is that, as with server_name directive, Nginx will use the most specific location block. There are a few rules for how specific various setups will be, thelocation directive wiki entryexplains this very well, so you should read that first.
Let us look at a few examples of how to use a location block. In this example we’ve run a forum on URI /forum/ and have recently moved it to a subdomain. We now need to redirect the old URLs to the new URLs.
server { listen 80 default; server_name www.domain.com; root /home/domain.com # This will match any URI beginning with /forum location /forum { # We capture the URI and redirect it to the subdomain. rewrite forum(.*) http://forum.domain.com$1 permanent; } } server { listen 80; server_name forum.domain.com; index index.php; root /home/domain.com/forum; }
The requests for /forum are now successfully transferred to our new subdomain while requests to files not in /forum will be served from our normal /home/domain.com root.
Handling PHP
PHP – or any backend really ties in well with locations, namely we can define a location block to catch all PHP files.
server { listen 80; server_name forum.domain.com; index index.php; root /home/domain.com/forum; location ~* \.php$ { include fastcgi.conf # I include this in http context, it's just here to show it's required for fastcgi! try_files $uri =404; fastcgi_pass 127.0.0.1:9000; } }
As said previously, Nginx does not care about files but rather locations and this is why I have a try_files directive inside the php block. This location block matches a URI that ends in .php but it does not care if it’s a file or not. Therefore a request for /forum/avatars/user2.jpg/index.php will be matched and sent to PHP, and if PHP is not configured properly PHP will then execute /forum/avatars/user2.jpg when /forum/avatars/user2.jpg/index.php doesn’t exist. This provides a huge security risk. Do note that this is not a bug in Nginx, it’s the intended behaviour and as such will not be “fixed”.
This can also be fixed on the PHP side by setting cgi.fix_pathinfo=0 in the php.ini file.
The end result, though, is that .php files which exist will be passed via fastcgi to our PHP processes running on port 9000.
The Finishing Touch – SEF URLs
This setup works, but all the craze these days is to have search engine friendly URLs for SEO reasons. Usually this involves quite a few rewrites, but with Nginx we can do it with just one line, provided the backend script is written in a sane way.
server { listen 80; server_name forum.domain.com; index index.php; root /home/domain.com/forum; location / { try_files $uri $uri/ /index.php; } location ~* \.php$ { include fastcgi.conf # I include this in http context, it's just here to show it's required for fastcgi! try_files $uri =404; fastcgi_pass 127.0.0.1:9000; } }
Did you notice the change? It’s minimal really. The one try files line means that it will first try accessing the full URI, which means that a static file request will end here. Secondly it will try the full URI plus a slash, thus looking for a directory. Finally, if none of these are found it will send the request to /index.php and perform a new location match, which will of course hit our PHP location and fastcgi_pass the request. PHP will then have the full URI in $_SERVER['PATH_INFO']. Simple, elegant and easy to understand.
Debugging Requests
Nginx is a complicated server at times, thankfully we have an excellent error log available to us to help figure out where things are going wrong. If you check theerror log directive in the wikiyou will notice that it takes a second argument. This will let you define how much information is output by nginx. A value of info will give you sufficient info to debug most issues.
Further Reading
Theofficial nginx wikiis an invaluable resource, a good way to expand your knowledge about Nginx is to read the directives and variables in theCore module. Also see thefull config exampleto get an idea of a more complex configuration file.
No related posts.
相关推荐
nginx 离线安装包nginx 离线安装包
nginx镜像资源nginx镜像资源nginx镜像资源nginx镜像资源nginx镜像资源nginx镜像资源
3.找到D:\nginx\conf下nginx.conf文件用记事本打开 在文段末尾大括号前加上 include proxy.conf;(就是加载刚刚新建的那个文件(注意路径)) 4.进入cmd 进入D盘: d: 进到nginx文件夹下:cd nginx 启动nginx.exe:...
nginx替代apache,nginx替代方案,nginx代替apache与jbos,nginx+jboss结合
Nginx 1.22.0 Linux 版本,解压安装。 Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。其特点是占有内存少,并发能力强,事实上nginx的并发能力在同类型...
Nginx安装包Nginx安装包
亲测好用.nginx-1.13.3,nginx1.13.3不存在信息泄漏漏洞安全稳定nginx版本,不存在漏洞 nginx-1.13.3 nginx1.13.3 安全稳定 nginx版本
nginx.conf nginx-1.20.1.tar.gz 这是关于centos8的nginx 和nginx 的配置https文件
Nginx全能指南是一本介绍Nginx服务器的书,首先,简要介绍Nginx的基本概念和作用,如反向代理、负载均衡等。然后,列举Nginx的优点,如高性能、可扩展性、稳定性等。接着,介绍如何安装和配置Nginx,并提供一些实用...
nginx安装环境及nginx_1.18.0安装包,gcc、g++、pcre、zlib、nginx包
此资源有两个文件,含 nginx-upstream-jvm-route 和 nginx 对应版本,都是tar.gz文件。 安装方法网上很多就不写了,亲测可用。 不用担心版本不匹配造成安装失败,再浪费积分去到处下载尝试的烦恼。 此资源有两个文件...
nginx/Windows-1.23.1 Nginx(发音为“engine X”[9] /ˌɛndʒɪnˈɛks/ EN-jin-EKS),风格化为NGIИX,是一个Web服务器,也可以用作反向代理,负载平衡器,邮件代理和HTTP缓存。该软件由Igor Sysoev创建,并于...
Nginx官网配置.pdf Nginx基本配置.pdf Nginx模块.pdf Nginx指南.pdf 第1章 Nginx简介.pdf 第2章 Nginx服务器的安装与配置.pdf 第3章 Nginx的基本配置与优化.pdf 第4章 Nginx与PHP(FastCGI)的安装、配置与优化.pdf 第...
nginx命令参数用法详细介绍 nginx命令:启动nginx 在Windows上安装好nginx后,我们需要启动nginx服务,启动nginx服务的命令行操作主要有两种方式,即 C:/nginx-0.8.53>nginx.exe 或者 C:/nginx-0.8.53>start ...
nginx1.21.5 nginx.conf配置文件
实战nginx.pdf。主要内容包括:第1章 Nginx简介;第2章Nginx服务器安装与配置;第3章Nginx基本配置与优化;第4章Nginx与PHP;第5章Nginx与JSP、ASP.NET..第6章Nginx http负载均衡和反向代理;第7章Nginx 的rewrite...
官方nginx 镜像不带主动健康,本镜像将 nginx_upstream_check健康检查 打包到了镜像中。
第1章 Nginx简介.pdf第2章 Nginx服务器的安装与配置.pdf第3章 Nginx的基本配置与优化.pdf第4章 Nginx与PHP(FastCGI)的安装、配置与优化.pdf第5章 Nginx与JSP、ASP.NET、Perl的安装与配置.pdf第6章 Nginx HTTP负载...
Nginx入门到实践 Nginx 中间件Nginx入门到实践 Nginx 中间件