Nginx Log Analysis--Path matching Chapter

After the Nginx configuration, it is possible that the Web page will not be properly accessed. If it is a path-matching problem, it can be resolved by its error log.

The Nginx error log is configured in nginx.conf:

Error_log  logs/error.log Debug;

The above declaration generates a error.log in the logs directory under the Nginx installation directory, with a logging level of debug (most detailed) level. Note that the Nginx configuration is a hierarchical system (see Nginx Profile resolution), so if the declaration is under an HTTP node, it is valid for all HTTP requests, and if all requests to the server are valid under the server node, if at the location node, Only the request for the location is valid. When making a path-matching error analysis, at least configure to the server node or above, but not to the location. Otherwise, once because of conf file writing error and a location should match without matching, there will be no log output, can not play the role of debugging.

Suppose Http://www.lotus-scent.com/blog/index.php/web technology/Layout and optimization/nginx error log analysis-path matching/Unable to request to the page, analysis as follows:

Download the sample Log

Nginx's processing of the above requests begins at line No. 974 of the log, where the keyword is "HTTP request lines". Note that the URL for this line of output is the encoded address, and the next 975 lines output the decoded address:/blog/index.php/web copernicium € link? JavaScript Laos bian harm Wan 撻 獙 backward javascript-siphoning ″ 潡 to donate Ms. Clever  siphoning ″/". Because the address contains Chinese, it is displayed as garbled.

Line No. 976, Nginx continues processing the request, resolving that the request does not have an HTTP args. For request "Get/blog?user=aaron", "User=aaron" is output here.

Next to line 989, nginx the analysis of the HTTP header for the request ends. The key word here is "HTTP header done".

Next Nginx handles address matching, noting that 988 rows of rewrite phase 0 output. As can be seen from the log output, Nginx has tested 5 location blocks and finally processed the request using the configuration of the/blog block:

2011/09/19 23:54:54 [Debug] 27343#0: *417 test Location: "/"
2011/09/19 23:54:54 [Debug] 27343#0: *417 test Location: "Develop"
2011/09/19 23:54:54 [Debug] 27343#0: *417 test Location: "CKEditor"
2011/09/19 23:54:54 [Debug] 27343#0: *417 test Location: "Blog"
2011/09/19 23:54:54 [Debug] 27343#0: *417 test Location: ~ "/blog/.*\. (?: ico|css|js|gif|jpe?g|png) $ "
2011/09/19 23:54:54 [Debug] 27343#0: *417 using Configuration "/blog"

Note the keyword here "using Configuration".

Proceed from line No. 999 to rewrite phase phase 2nd, which is handled in the configuration "/blog" Block:

Line 1001th, get the URI raw string:/usr/www/blog/index.php/web copernicium € link? javascript Laos € backward bian harmful raccoon 撻 獙 javascript-siphoning ″ 潡 Ms. Clever donate  siphoning ″ Lyon/"

Line 1003th, the row should be to check whether the URI directly corresponds to a file on the server. 1004-line lookup failed, directly into the 1005-line rewrite match. Match the on regular expression "^/blog/index.php/(. +) $", and get the child match "web copernicium € link" javascript Laos € backward bian harmful raccoon 撻 獙 javascript-siphoning ″ 潡 Ms. Clever to donate  siphoning ″ Lyon/". The next step is to call/blog/index.php?q=$1 based on the information that has been obtained, thus entering the next round of internal address redirection. Note that there is a break statement in the IF statement block, indicating that the following processing is skipped after execution.

1013 line into the third round of address redirection, the URI of this round request is "/blog/index.php?q= ...". 1020 line display match on/blog configuration. Note that the configuration was matched in the previous round, but this round is matched again with a different parameter invocation.

1027 lines, where the result is false, meaning that/usr/www/blog/index.php is a file that exists on the server. So the entire if block is skipped and goes directly to the fastcgi section. Line 1041 starts to get query_string,request_method,script_name and other fastcgi parameters, and finally to the PHP engine processing to generate the page, returned to the client. The first few lines of 1120 should be the log output of the Nginx when the HTTP message response is populated from PHP after the output is obtained. Running to it also means that Nginx's processing of the HTTP request basically ends.