How to properly configure nginx+php and correct nginx URL rewriting

Source: Internet
Author: User

For many people, configuring nginx+php is no different than searching for a tutorial and then copying and pasting. It seems that there is no problem, unfortunately in fact, a lot of information on the network itself in disrepair, flawed, if everyone superficial understanding, blindly copy paste, sooner or later, will pay the price.

Let's say we implement a front-end controller with PHP, or the straightforward point is the unified Portal: Send PHP requests to the same file, and then parse "request_uri" in this file to implement the route.

At this time many tutorials will teach you to configure nginx+php:

server {    listen;    server_name foo.com;    Root/path;    Location/{        index index.html index.htm index.php;        if (!-e $request _filename) {            rewrite./index.php last;        }    }    Location ~ \.php$ {        include fastcgi_params;        Fastcgi_param Script_filename/path$fastcgi_script_name;        Fastcgi_pass 127.0.0.1:9000;        Fastcgi_index index.php;    }}

There are a lot of mistakes, or at least a bad taste, you can see a few.

...

We need to understand the Nginx configuration file in the inheritance of the directive: Nginx configuration file is divided into a lot of pieces, the common from the outside to the inside in turn is "http", "server", " location"and so on, the default inheritance is from the outside to the inside, that is, the inner block will automatically get the value of the outer block as the default (with exceptions, see Reference).

Reference: Understanding the NGINX CONFIGURATION inheritance MODEL

...

Let's start with the "index" command, which is defined in the "location" in the problem configuration:

Location/{    index index.html index.htm index.php;}

Once the future needs to join the new "location", there is bound to be a duplicate definition of the "index" directive, this is because multiple "location" is a peer relationship, there is no inheritance, it should be defined in "server" "index", with the help of inheritance relations, " The index"directive can take effect in all"location".

Reference: Nginx Pitfalls

...

Next look at the "if" directive, saying that it is the most misunderstood nginx command:

if (!-e $request _filename) {    rewrite./index.php last;}

Many people like to use "if" instructions to do a series of checks, but this is actually the responsibility of the "try_files" Directive:

Try_files $uri $uri//index.php;

In addition, beginners tend to assume that the "if" directive is a kernel-level instruction, but in fact it is part of the rewrite module, and the Nginx configuration is actually declarative rather than procedural, so when it is mixed with non-rewrite module instructions, the result may not be what you want.

Reference: Ifisevil and how Nginx "location if" works

...

Here's a look at the "fastcgi_params" configuration file:

Include Fastcgi_params;

Nginx has two copies of the fastcgi configuration files, respectively, "fastcgi_params" and "fastcgi.conf", they are not much different, the only difference is that the latter is more than the former definition of a row of "script_filename":

Fastcgi_param script_filename $document _root$fastcgi_script_name;

Note: There is no/between the $document _root and $fastcgi _script_name.

Originally Nginx only "fastcgi_params", later found that many people in the definition of "script_filename" use hard-coded way, so in order to standardize the use of the introduction of "fastcgi.conf".

However, this raises the question of why it is necessary to introduce a new configuration file instead of modifying the old one. This is because the "fastcgi_param" instruction is an array type, and the same as the normal instruction: The inner layer replaces the outer layers, and the ordinary instruction is different: when used in the same class multiple times, is added instead of replaced. In other words, if you define two "script_filename" at the same level, then they will be sent to the backend, which may cause some potential problems, and in order to avoid such situations, a new configuration file is introduced.

Reference: Fastcgi_params VERSUS FASTCGI. Conf–nginx CONFIG History

...

In addition, we need to consider a security issue: PHP may use the wrong file type as a php file when PHP "cgi.fix_pathinfo" is turned on. If Nginx and PHP are installed on the same server, then the simplest solution is to use the "try_files" command to do a filter:

Try_files $uri = 404;

Reference: Nginx file type Error parsing vulnerability

...

According to the previous analysis, given a modified version, is not a lot more refreshing than the beginning version:

server {Listen 80;    server_name foo.com;    Root/path;    Index index.html index.htm index.php; Location/{
# The  correct wording of the URL rewrite here is modified to the following line instead of #  if (!-e $request _filename) {#      rewrite./index.php last;#  }Try_ Files $uri $uri//index.php$is_args$args; #这里后面的 $is _args$args is to get the URL parameter, do not get to omit
}
Location ~ \.php$ {                                  try_files $uri =404; #这里加入这一行, the page to prevent error is parsed by PHP                                  include fastcgi.conf;                                  Fastcgi_pass 127.0.0.1:9000;            }}

In fact, there are some flaws, mainly "try_files" and "fastcgi_split_path_info" is not compatible, although it can be solved, but the scheme is more ugly, specifically not much to say, interested can refer to the problem description.

Add: Because "location" has already made the limit, so "fastcgi_index" is not really necessary.

...

Hope that everyone will not copy paste, if it is not changed, then please copy and paste this article.

How to properly configure nginx+php and correct nginx URL rewriting

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.