下部セグメントファイルサーバNginx.conf、場所のURIを設定し、マッピング結果のルールを打ちます。

構文規則

文法規則：場所[= |〜|〜* | ^〜| @] / / URI {...}

=：ルーチンの完全一致
^〜：一般的にディレクトリを一致させるために使用される正規の文字が一致し、最長一致の原則、
〜：ケース・センシティブのマッチング正準
〜*：通常の大文字と小文字を区別しないマッチ
！〜と〜* :!一致は大文字と小文字が区別され、大文字と小文字を区別しない正規の不一致ではありませんでした
/：通配符

マッチの優先順位

ロケーションマッチングは、少し複雑なルールを最優先のいくつかの公式大会を投稿しました：

次のように要約すると、ディレクティブがチェックされる順序は次のとおりです。

正確にクエリに一致=接頭辞ディレクティブ。見つかった場合は、停止を検索します。

従来の文字列、最初の最長一致を持つすべての残りのディレクティブ。この試合はストップを検索、^〜接頭辞を使用した場合。

設定ファイルの定義のために正規表現、。

＃3は、一致が得られた場合、その結果が使用されます。エルス＃2からの一致が使用されます。

貧しい翻訳：

完全一致「=」プレフィックスモード、ヒットは最終結果として返された場合、
従来の文字列パターンに残っているのは、最長一致の原則に合致します。ヒット、そしてマッチング「^〜」プレフィックスを使用した場合、結果はそうでない場合は、通常のマッチングのステップ3に進み、マッチングの最終結果として返されます。
プロファイルで定義された順序でNが一致するため、それは物理的な場所に定期的な順序を設定ファイルを強調留意されたいです。
ルール3が一致する場合、結果が使用されています。それ以外の場合は、ルール2の結果。

この公式の説明は消化に良くない、更なる説明の必要性は、私たちは、最初の2つのエラーを回避する必要があります。

1、マッチングシーケンスの位置は、「最初に正常に一致する、定期的に一致します」。
訂正：この誤解の理由は次のとおりです。いくつかの構成では、通常の試合は通常の試合を上書きします。マッチングシーケンスの実際の場所は、実際には「通常最初に一致し、その後正規、通常のヒットが正規ヒットによって覆われていてもよい一致」です。

2、オーダー実行ロジックの場所は、編集の場所とは何の関係もありません。
訂正：この文は、すべての権利、「一般的な場所」ルールに一致することで、「最大の接頭辞」とではありませんので、「通常の位置」は本当に順序を編集する場所とは何の関係もありません。しかし、「定期的な場所」に一致する限り、ルール「シーケンシャル一致を照合し、後ろ第一ストップ一致「と、」通常位置「と」通常位置「マッチングのシーケンスが通常の位置に一致するようにされた後、」「検討は、通常の位置に一致します。時にはあなたは、「定期的な場所」と一致して続行する必要はありません、「定期的な場所」と一致し続ける必要があり、試合は「通常の位置」を終えた後、つまり、「配慮」は「可能」な手段であることに注意してください。どちらの場合も正規位置に一致するように継続する、不要：1）場合、通常の前に指定された場所「^〜」または「=」、特定のセクション内の一般的な位置が一致したらnginxのに伝え、定期的なマッチングを継続する必要がない; 2）ときに正常場所は正確に厳密ではなく、最大プレフィックス一致、それ以上のマッチング定期的に一致します。

それを要約すると：「正規譲歩厳密に正確な位置が一致するの一般的な場所の結果と一致する。しかし、場所をカバーする最大の共通のプレフィックス一致結果、」
「nginxのマッチングルールが説明の場所」、このブログは非常に詳細な分析が一致規則を示して作られました

三つのカテゴリーに簡略化マッチングの場所覚えやすい：通常の場所の内側に一致する、共通の内部の位置が一致し、普通の場所は、通常の場所と一致します。ルールを分割した後、以下の個人を受け続けます。

優先順位は、一般的な場所と一致して、定期的な場所にマッチします
「=」または「^〜」構文とマッチが成功するを使用して通常の位置は、最終的な結果としてマッチし、その後、現在のリターンヒットを停止します
完全一致は、その後、最終的な結果として、現在のヒットが返された場合と、第1条、一般的な位置最長プレフィックス一致の原則を次のように、それ以外の場合は定期的に試合を続行しない場合は、通常の試合を取って、定期的に試合をヒットしない場合は、そうでありません通常の試合結果をカバーする定期的な試合
内部の一般的な場所の試合は、最適なソリューションを選択し、設定ファイルを編集するために、場所を気にしません。
設定ファイルの編集中に一致するシーケンス内の場所の位置についての定期的なケア、限り定期的な場所に一致するように、場所はもはや後の順序で編集を検討していません
しかし、最大プレフィックスはの一般的な場所と一致してカバーし、定期的な場所は密接に正確に譲歩の一般的な位置の結果と一致一致します

メモリと併せて理解実施例（実施例転送：https://www.cnblogs.com/sign-ptk/p/6723048.htmlを
）：

location = / {  
   #规则A  
}  
location = /login {  
   #规则B  
}  
location ^~ /static/ {  
   #规则C  
}  
location ~ \.(gif|jpg|png|js|css)$ {  
   #规则D  
}  
location ~* \.png$ {  
   #规则E  
}  
location !~ \.xhtml$ {  
   #规则F  
}  
location !~* \.xhtml$ {  
   #规则G  
}  
location / {  
   #规则H  
}

以下のような効果があります。

などのルートディレクトリ/へのアクセス、のhttp：// localhost /を一致するルールA
訪問にhttp：// localhostの/ログインがルールBと一致しますが、HTTP：// localhost /を登録マッチングルールH
訪問のhttpを：//localhost/static/a.htmlマッチングルールC
アクセスHTTP：//localhost/a.gif、HTTP：//localhost/b.jpgマッチングルールDとEのルールが、優先Dの順番のルール、Eがルールを動作しない、とのhttp：// localhost /を静的/ C .pngを Cと一致するように、優先ルールを
訪問//localhost/a.PNGます：httpルールは大文字と小文字を区別しませんので、マッチングルールなし、D、EをマッチングルールEを。
訪問のhttpを：//localhost/a.xhtml規則や規制F G、一致していないHTTPを：//localhost/a.XHTMLそれは大文字と小文字を区別しませんので、ルールGと一致していません。ルールF、Gは、除外ルールに属しているが、一致する一致ルールを満たして、それが使用される実用的なアプリケーションについて考えていません。
訪問にhttp：// localhostの/カテゴリ/ ID / 1111 その後、決勝戦は、上記のルールが一致しないため、今回はそのようにFastCGI（PHP）、tomcatの（JSPとして、バックエンド・アプリケーション・サーバーに要求を転送nginxのする必要があり、Hを支配します）、 nginxのは、リバースプロキシサーバが存在します。

以下のように実際の使用は、通常、少なくとも3のマッチングルールが定義されています。

#直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。  
#这里是直接转发给后端应用服务器了，也可以是一个静态首页  
# 第一个必选规则  
location = / {  
    proxy_pass http://tomcat:8080/index  
}  
   
# 第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项  
# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用  
location ^~ /static/ {  
    root /webroot/static/;  
}  
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {  
    root /webroot/res/;  
}  
   
#第三个规则就是通用规则，用来转发动态请求到后端应用服务器  
#非静态文件请求就默认是动态请求，自己根据实际把握  
#毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了  
location / {  
    proxy_pass http://tomcat:8080/  
}

nginxの位置マッチングルールは、詳細（3）

構文規則

マッチの優先順位

おすすめ