How to correctly Configure Nginx + PHP and correct nginxURL rewriting

Source: Internet
Author: User
How to correctly Configure Nginx + PHP and correct nginxURL rewriting for many people, to Configure Nginx & #43; PHP is simply to search for a tutorial and copy and paste it. It sounds like & #20284; it's almost no problem. Unfortunately, in fact, many materials on the network have been out of repair for years, and they are full of loopholes. if you don't want to solve it, just copy and paste it, sooner or later, the cost will be paid. Suppose we use PHP to implement a front-end controller, or simply put, it is a unified portal: correct Nginx + PHP configuration and correct nginx URL rewriting

For many people, to Configure Nginx + PHP, simply search for a tutorial and copy and paste it. It seems that there is no problem. Unfortunately, in fact, many materials on the network have been out of repair for a long time. if you just copy and paste them, you will pay a price one day later.

Suppose we use PHP to implement a front-end controller, or simply put, it is a unified portal: Send all PHP requests to the same file, and then implement routing by parsing "REQUEST_URI" in this file.

At this time, many tutorials will teach you how to configure Nginx + PHP in this way:

server {    listen 80;    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 many errors, or at least bad ones. you can see a few.

...

It is necessary to first understand the inheritance of commands in the Nginx configuration file: The Nginx configuration file is divided into multiple modules, the common types of inheritance are http, server, and location. the default inheritance relationship is from outside to inside, that is to say, the internal block automatically obtains the value of the external block as the default value (for exceptions, see the reference ).

Reference: UNDERSTANDING THE NGINX CONFIGURATION INHERITANCE MODEL

...

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

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

If you need to add a new "location" in the future, the "index" command will be repeatedly defined. this is because multiple "locations" are in a hierarchical relationship and there is no inheritance, in this case, define "index" in "server". with the inheritance relationship, the "index" command takes effect in all "locations.

Reference: Nginx Pitfalls

...

Next, let's take a look at the "if" command, which is the most misunderstood Nginx command:

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

Many people prefer to use the "if" command for a series of checks, but this is actually the responsibility of the "try_files" command:

try_files $uri $uri/ /index.php;

In addition, beginners often think that the "if" command is a kernel-level command, but it is actually part of the rewrite module, and Nginx configuration is actually declarative, instead of procedural, when it is mixed with the commands of the non-rewrite module, the results may not be as expected.

Refer to: ifisedevil and How nginx "location if" works

...

Let's take a look at the "fastcgi_params" configuration file:

include fastcgi_params;

Nginx has two fastcgi configuration files: "fastcgi_params" and "fastcgi. conf. The only difference is that the latter has a line of "SCRIPT_FILENAME" more than the former:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Note: There is no/between $ document_root and $ fastcgi_script_name /.

Originally, Nginx only had "fastcgi_params". later, it was found that many people used hard encoding when defining "SCRIPT_FILENAME". Therefore, "fastcgi. conf" was introduced for standard usage 」.

In this case, the question is: why should we introduce a new configuration file instead of modifying the old configuration file? This is because the "fastcgi_param" command is of the array type, which is the same as the common command: the inside layer replaces the outer layer; and the common command is different: when it is used multiple times at the same level, is New rather than replacement. In other words, if two "SCRIPT_FILENAME" statements are defined at the same level, they are all sent to the backend, which may cause some potential problems. to avoid such problems, A new configuration file is introduced.

Reference: FASTCGI_PARAMS versus fastcgi. CONF-NGINX CONFIG HISTORY

...

In addition, we also need to consider a security issue: when "cgi. fix_pathinfo" is enabled in PHP, PHP may parse the wrong file type as a PHP file. If Nginx and PHP are installed on the same server, the simplest solution is to use the "try_files" command for filtering:

try_files $uri =404;

Reference: Nginx file type error parsing vulnerability

...

According to the previous analysis, a modified version is provided, which is much easier than the previous version:

Server {listen 80; server_name foo.com; root/path; index index.html index.htm index. php; location /{
# Modify the correct syntax of some URL rewriting comments here to replace the following line # if (! -E $ request_filename) {# rewrite. /index. php last ;#} try_files $ uri // index. php $ is_args $ args; # $ is_args $ args is used to obtain URL parameters.
}
Location ~ \. Php $ {try_files $ uri = 404; # add this line here to prevent the error page from being parsed by PHP: include fastcgi. conf; fastcgi_pass 127.0.0.1: 9000 ;}}

In fact, there are still some flaws, mainly because "try_files" and "fastcgi_split_path_info" are not compatible enough. although they can be solved, the solution is ugly and I will not talk about them much. if you are interested, refer to the problem description.

Note: Because "location" has been defined, "fastcgi_index" is not necessary.

...

I hope you will not copy or paste it any more. if you cannot change it, copy and paste this article.

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.