この記事では主に Nginx の位置マッチングの例を紹介します。チームはフロントエンドとバックエンドを分離しているため、日常業務ではフロントエンドが Nginx とノードのレイヤーを引き継ぎます。 。私はこれまで、位置一致ルールについてあまり知りませんでした。位置がどのように一致するかを理解するために、お役に立てれば幸いです。
location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... } 文法規則は非常に単純で、location キーワード、その後にオプションの修飾子、その後に一致する文字、および中括弧内で実行される操作が続きます。 location关键字，后面跟着可选的修饰符，后面是要匹配的字符，花括号中是要执行的操作。
= 表示精确匹配。只有请求的url路径与后面的字符串完全相等时，才会命中。
~ 表示该规则是使用正则定义的，区分大小写。
~* 表示该规则是使用正则定义的，不区分大小写。
^~ 表示如果该符号后面的字符是最佳匹配，采用该规则，不再进行后续的查找。
对请求的url序列化。例如，对%xx等字符进行解码，去除url中多个相连的/，解析url中的.，..等。这一步是匹配的前置工作。
location有两种表示形式，一种是使用前缀字符，一种是使用正则。如果是正则的话，前面有~或~*修饰符。
具体的匹配过程如下：
首先先检查使用前缀字符定义的location，选择最长匹配的项并记录下来。
如果找到了精确匹配的location，也就是使用了=修饰符的location，结束查找，使用它的配置。
然后按顺序查找使用正则定义的location，如果匹配则停止查找，使用它定义的配置。
如果没有匹配的正则location，则使用前面记录的最长匹配前缀字符location。
基于以上的匹配过程，我们可以得到以下两点启示：
使用正则定义的location在配置文件中出现的顺序很重要。因为找到第一个匹配的正则后，查找就停止了，后面定义的正则就是再匹配也没有机会了。
使用精确匹配可以提高查找的速度。例如经常请求/的话，可以使用=来定义location。
接下来我们以一个例子来具体说明一下匹配过程。
假如我们有下面的一段配置文件：
location = / {
[ configuration A ]
}
location / {
[ configuration B ]
}
location /user/ {
[ configuration C ]
}
location ^~ /images/ {
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
[ configuration E ]
}请求/精准匹配A，不再往下查找。
请求/index.html匹配B。首先查找匹配的前缀字符，找到最长匹配是配置B，接着又按照顺序查找匹配的正则。结果没有找到，因此使用先前标记的最长匹配，即配置B。
请求/user/index.html匹配C。首先找到最长匹配C，由于后面没有匹配的正则，所以使用最长匹配C。
请求/user/1.jpg匹配E。首先进行前缀字符的查找，找到最长匹配项C，继续进行正则查找，找到匹配项E。因此使用E。
请求/images/1.jpg匹配D。首先进行前缀字符的查找，找到最长匹配D。但是，特殊的是它使用了^~修饰符，不再进行接下来的正则的匹配查找，因此使用D。这里，如果没有前面的修饰符，其实最终的匹配是E。大家可以想一想为什么。
请求/documents/about.html匹配B。因为B表示任何以/开头的URL都匹配。在上面的配置中，只有B能满足，所以匹配B。
@用来定义一个命名location。主要用于内部重定向，不能用来处理正常的请求。其用法如下：
location / {
try_files $uri $uri/ @custom
}
location @custom {
# ...do something
}上例中，当尝试访问url找不到对应的文件就重定向到我们自定义的命名location（此处为custom）。
值得注意的是，命名location中不能再嵌套其它的命名location。
/需不需要关于URL尾部的/有三点也需要说明一下。第一点与location配置有关，其他两点无关。
location中的字符有没有/都没有影响。也就是说/user/和/user是一样的。
如果URL结构是https://domain.com/的形式，尾部有没有/都不会造成重定向。因为浏览器在发起请求的时候，默认加上了/。虽然很多浏览器在地址栏里也不会显示/
= は完全一致を意味します。リクエストされた URL パスが次の文字列と正確に等しい場合にのみヒットが発生します。 🎜~ は、ルールが正規表現を使用して定義され、大文字と小文字が区別されることを意味します。 🎜~* は、ルールが通常のルールを使用して定義され、大文字と小文字が区別されないことを意味します。 🎜^~ は、記号の後の文字が最も一致する場合、このルールが使用され、それ以降の検索は実行されないことを意味します。 🎜%xx などの文字をデコードし、URL 内の複数の接続された / を削除し、URL 内の .、 を解析します。 .など。このステップはマッチングのための準備作業です。 🎜🎜location には 2 つの表現形式があり、1 つは接頭辞文字を使用する方法、もう 1 つは正規表現を使用する方法です。通常の場合は、先頭に ~ または ~* 修飾子が付きます。 🎜🎜具体的なマッチングプロセスは次のとおりです: 🎜🎜まず、接頭辞文字を使用して定義された場所を確認し、最も長く一致する項目を選択して記録します。 🎜🎜完全に一致する場所、つまり = 修飾子を使用した場所が見つかった場合は、検索を終了し、その設定を使用します。 🎜🎜次に、正規表現を使用して定義された場所を順番に検索します。一致する場合は、検索を停止し、定義されている設定を使用します。 🎜🎜一致する通常の位置がない場合は、以前に記録された最長一致するプレフィックス文字の位置が使用されます。 🎜🎜上記の照合プロセスに基づいて、次の 2 つの洞察が得られます: 🎜/ を頻繁にリクエストする場合は、= を使用して場所を定義できます。 🎜/ を要求し、それ以上の検索は行わなくなります。 🎜🎜B と一致するように /index.html をリクエストします。まず一致するプレフィックス文字を検索し、最長一致が構成 B であることを見つけてから、一致する通常のルールを順番に検索します。結果が見つからないため、前のタグからの最長一致が使用されます。これが構成 B です。 🎜🎜C と一致するように /user/index.html をリクエストします。最初に最長一致 C を見つけます。後で一致する規則的なパターンがないため、最長一致 C が使用されます。 /user/1.jpg は E と一致します。まず、接頭辞文字を検索して最長一致する項目 C を見つけます。次に、通常の検索を続けて、一致する項目 E を見つけます。そこでEを使います。 🎜🎜リクエスト /images/1.jpg は D と一致します。まず、接頭辞文字を検索し、最長一致 D を見つけます。ただし、特別なのは、^~ 修飾子を使用し、その後の通常の一致検索を実行しないため、D が使用されることです。ここで、以前の修飾子がない場合、最終的な一致は実際には E になります。その理由を考えることができます。 🎜🎜リクエスト /documents/about.html は B と一致します。 B は、/ で始まる URL が一致することを意味するためです。上記の構成では、B のみが満たせるため、B が一致します。 🎜🎜場所の使用法 @name🎜🎜@ は、名前付き場所を定義するために使用されます。主に内部リダイレクトに使用され、通常のリクエストの処理には使用できません。その使用法は次のとおりです: 🎜rrreee🎜 上記の例では、URL にアクセスしようとして対応するファイルが見つからない場合、カスタムの名前付きの場所 (ここではカスタム) にリダイレクトされます。 🎜🎜名前付きの場所は他の名前付きの場所をネストできないことに注意してください。 🎜🎜URL末尾の/は必要ですか?🎜🎜URL末尾の/について説明が必要な点が3つあります。最初の点は場所の構成に関連しており、他の 2 つの点はそれとは関係がありません。 🎜/ が含まれているかどうかは影響しません。つまり、/user/ と /user は同じです。 🎜https://domain.com/ の形式の場合、末尾に / があるかどうかは関係ありません。リダイレクトの原因となります。ブラウザがリクエストを開始すると、デフォルトで / が追加されるためです。ただし、多くのブラウザではアドレス バーに / が表示されません。これは、Baidu にアクセスして確認できます。 🎜 URL の構造が https://domain.com/some-dir/ の場合。末尾の / が欠落すると、リダイレクトが発生します。規則によれば、URL の末尾の / はディレクトリを表し、/ がない場合はファイルを表すためです。したがって、/some-dir/ にアクセスすると、サーバーは自動的にこのディレクトリに移動して、対応するデフォルト ファイルを見つけます。 /some-dir にアクセスすると、サーバーは最初に some-dir ファイルを探します。見つからない場合は、some-dir をディレクトリとして指定し、 <code>/some-dir/ にリダイレクトし、このディレクトリに移動してデフォルトのファイルを見つけます。 Web サイトがこのようになっているかどうかをテストして確認できます。 https://domain.com/some-dir/。尾部如果缺少/将导致重定向。因为根据约定，URL尾部的/表示目录，没有/表示文件。所以访问/some-dir/时，服务器会自动去该目录下找对应的默认文件。如果访问/some-dir的话，服务器会先去找some-dir文件，找不到的话会将some-dir当成目录，重定向到/some-dir/，去该目录下找默认文件。可以去测试一下你的网站是不是这样的。
location的配置有两种形式，前缀字符和正则。查找匹配的时候，先查找前缀字符，选择最长匹配项，再查找正则。正则的优先级高于前缀字符。
正则等查找是按照在配置文件中的顺序进行的。因此正则等顺序很重要，建议越精细的放的越靠前。
使用=精准匹配可以加快查找的顺序，如果根域名经常被访问等话建议使用=
場所の設定には、プレフィックス文字と正規表現の 2 つの形式があります。一致を検索するときは、まず接頭辞文字を検索し、最長一致を選択してから、規則的なパターンを検索します。通常の文字は接頭辞文字よりも優先されます。
通常の検索は設定ファイル内の順序で実行されます。したがって、正規表現の順序は非常に重要であり、より詳細な正規表現を最初に配置することをお勧めします。 正確な一致のために = を使用すると、検索シーケンスが高速化されます。ルート ドメイン名に頻繁にアクセスする場合は、= を使用することをお勧めします。
以上がNginx 位置情報マッチングの共有例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
