Syntax
location [=|~|~*|^~] /uri/ {...}
Rules
= : Indicates exact uri matching (interested students can take a look at the difference between url and uri)
~: Indicates case-sensitive regular matching
~*: Indicates case-insensitive regular matching
! ~ && !~*: Indicates case-sensitive non-matching regular and case-insensitive non-matching regular
/: Universal matching, any request will be matched to the
location matching target
The location matching test only uses the request uri part, not the parameter part. (Reason: There are too many ways to write parameters and cannot be matched accurately)
location matching order
Under the premise of multiple location configurations, the matching order of location (not verified, hey, google Searched above)
1. First match =
2. Secondly match ^~
3. Then follow the order of the configuration file for regular matching,
4. Finally, hand it over to / for general matching
Note:
When a match is successful, the matching will be stopped immediately and the request will be processed according to the current matching rules
Demo example
nginx configuration file is divided into three types from bottom to top Hierarchical structure:
| http block the protocol level
| server block the server level
v location block the requested uri
nginx allows users to define location block and specify a matching pattern (pattern) matches a specific uri. In addition to simple strings (such as file system paths), more complex matching patterns are also allowed.
The basic syntax form of location block is:
location [=|~|~*|^~|@] pattern { ... }
[=|~|~*|^~|@] is called location modifier, which will define how nginx matches the following pattern , and the pattern's most basic attributes (simple string or regular expression).
About location modifier
1. =
This will completely match the specified pattern, and the pattern here is restricted into a simple string, which means regular expressions cannot be used here.
example:
server { server_name jb51.net; location = /abcd { […] } }
Matching situation:
http://jb51.net/abcd # Exactly matches
http://jb51.net/abcd # If running nginx The server system itself is not case-sensitive, such as windows, so it will also match
http://jb51.net/abcd?param1?m2 # Ignore the query string arguments, here is the one after /abcd? param1?m2
http://jb51.net/abcd/ # Does not match because there is a trailing slash at the end, nginx does not consider this situation to be a complete match
http://jb51.net /abcde # Does not match because it is not a complete match
2. (none)
You can not write the location modifier, nginx can still match the pattern. In this case, match those uris starting with the specified pattern. Note that the uri here can only be ordinary strings, and regular expressions cannot be used.
example:
server { server_name website.com; location /abcd { […] } }
Matching situation:
http://jb51.net/abcd # Exactly matches
http://jb51.net/abcd # If running nginx The server system itself is not case-sensitive, such as windows, so it will also match
http://jb51.net/abcd?param1?m2 # Ignore the query string arguments, here is the one after /abcd? param1?m2
http://jb51.net/abcd/ # The trailing slash at the end is also within the matching range
http://jb51.net/abcde # Still matches, because the uri is
3 starting with pattern. ~
This location modifier is case-sensitive, and pattern must be a regular expression
example: server { server_name jb51.net; location ~ ^/abcd$ { […] } }
Matching situation:
http://jb51.net/abcd # Exact match
http://jb51.net/abcd # Does not match, ~ is case sensitive
http://jb51.net/abcd ?param1?m2 # Ignore query string arguments, here is ?param1?m2
after /abcd http://jb51.net/abcd/ # Does not match because there is a backslash at the end (trailing slash), does not match the regular expression^/abcd$
http://jb51.net/abcde #Does not match the regular expression^/abcd$
Note: For some systems that are not case-sensitive, For example, in windows, ~ and ~* do not work. This is mainly due to the operating system.
4. ~*
与 ~ 类似,但这个 location modifier 不区分大小写,pattern 须是正则表达式
example:
server { server_name website.com; location ~* ^/abcd$ { […] } }
匹配情况:
http://jb51.net/abcd # 完全匹配
http://jb51.net/abcd # 匹配,这就是它不区分大小写的特性
http://jb51.net/abcd?param1?m2 # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1?m2
http://jb51.net/abcd/ # 不匹配,因为末尾存在反斜杠(trailing slash),并不匹配正则表达式 ^/abcd$
http://jb51.net/abcde # 不匹配正则表达式 ^/abcd$
5. ^~
匹配情况类似 2. (none) 的情况,以指定匹配模式开头的 uri 被匹配,不同的是,一旦匹配成功,那么 nginx 就停止去寻找其他的 location 块进行匹配了(与 location 匹配顺序有关)
6. @
用于定义一个 location 块,且该块不能被外部 client 所访问,只能被 nginx 内部配置指令所访问,比如 try_files or error_page
演示实例
产生的效果如下:
访问根目录/,匹配到location /
访问除hello.php之外的其它php程序,匹配到location ~ \.php$,并且用php5-fpm去运行
访问hello.php,匹配到location = /hello.php,访问被重定向到好联系官网
The above is the detailed content of How to configure location in Nginx server. For more information, please follow other related articles on the PHP Chinese website!

NGINX is more suitable for handling high concurrent connections, while Apache is more suitable for scenarios where complex configurations and module extensions are required. 1.NGINX is known for its high performance and low resource consumption, and is suitable for high concurrency. 2.Apache is known for its stability and rich module extensions, which are suitable for complex configuration needs.

NGINXUnit improves application flexibility and performance with its dynamic configuration and high-performance architecture. 1. Dynamic configuration allows the application configuration to be adjusted without restarting the server. 2. High performance is reflected in event-driven and non-blocking architectures and multi-process models, and can efficiently handle concurrent connections and utilize multi-core CPUs.

NGINX and Apache are both powerful web servers, each with unique advantages and disadvantages in terms of performance, scalability and efficiency. 1) NGINX performs well when handling static content and reverse proxying, suitable for high concurrency scenarios. 2) Apache performs better when processing dynamic content and is suitable for projects that require rich module support. The selection of a server should be decided based on project requirements and scenarios.

NGINX is suitable for handling high concurrent requests, while Apache is suitable for scenarios where complex configurations and functional extensions are required. 1.NGINX adopts an event-driven, non-blocking architecture, and is suitable for high concurrency environments. 2. Apache adopts process or thread model to provide a rich module ecosystem that is suitable for complex configuration needs.

NGINX can be used to improve website performance, security, and scalability. 1) As a reverse proxy and load balancer, NGINX can optimize back-end services and share traffic. 2) Through event-driven and asynchronous architecture, NGINX efficiently handles high concurrent connections. 3) Configuration files allow flexible definition of rules, such as static file service and load balancing. 4) Optimization suggestions include enabling Gzip compression, using cache and tuning the worker process.

NGINXUnit supports multiple programming languages and is implemented through modular design. 1. Loading language module: Load the corresponding module according to the configuration file. 2. Application startup: Execute application code when the calling language runs. 3. Request processing: forward the request to the application instance. 4. Response return: Return the processed response to the client.

NGINX and Apache have their own advantages and disadvantages and are suitable for different scenarios. 1.NGINX is suitable for high concurrency and low resource consumption scenarios. 2. Apache is suitable for scenarios where complex configurations and rich modules are required. By comparing their core features, performance differences, and best practices, you can help you choose the server software that best suits your needs.

Question: How to start Nginx? Answer: Install Nginx Startup Nginx Verification Nginx Is Nginx Started Explore other startup options Automatically start Nginx


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

MinGW - Minimalist GNU for Windows
This project is in the process of being migrated to osdn.net/projects/mingw, you can continue to follow us there. MinGW: A native Windows port of the GNU Compiler Collection (GCC), freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality. All MinGW software can run on 64-bit Windows platforms.

SublimeText3 English version
Recommended: Win version, supports code prompts!

SublimeText3 Chinese version
Chinese version, very easy to use

VSCode Windows 64-bit Download
A free and powerful IDE editor launched by Microsoft

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software