前回のブログでは、「コンフィギュレーションとのnginxの最適化について話をする、2.5節では、位置モジュールは、ほとんどのnginxのに使用されて言及し、そして最も重要なモジュール、ロード・バランシング」ように、プロキシ、仮想ドメインを逆にして、それ関連。
まず、最初に私にメッセージを送った同僚を見ることができます
あなたは静的ファイルを照合する際に「auto_dish」を「/」、およびアクセスをマッチさせたい一般的なケースでは、動的なリソースへの直接アクセス。一見何の問題、近い見たりのわずか予感を感じ、無知な力を見て。一方では約2場所の順序と一致し、一方のディレクトリ・パスの原因です。
唯一の場所の位置の長手方向調整を達成したい後、(使用される別の構成の効果を示す以下)優れOK auto_dishのルートディレクトリへのパスを変更します。
それでは、私たちは、静的を追加することにより、サーバー名の下に、スタティックアクセス静的リソースを実行することができます。
(ああ、これは非常に基本的である、と恥ずかし)
ここでは、場所の試合の下でルールの包括的な理解を開始します。
1)位置の構文規則
location [=|~|~*|^~] /uri/ {
·····
}
その後、場所後に意味のルールに一致します
= 开头表示精确匹配
^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可。nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格)
~ 开头表示区分大小写的正则匹配
~* 开头表示不区分大小写的正则匹配
!~ 区分大小写不匹配的正则
!~* 不区分大小写不匹配的正则
/ 通用匹配,任何请求都会匹配到
我々は、の順と一致する場所プロビジョニング、複数のを持っている場合:
オーダーファイルが続くマッチング「^〜」、続いまずマッチングは、「=」、正の試合、そして最後に「/」汎用的な試合です。
マッチング停止したとき、一致の成功があった場合、現在のルールによる処理要求が一致しました。
今同時に、以下に示すようなマッチング規則があります
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/login 将匹配规则B,http://localhost/register 则匹配规则H
访问 http://localhost/static/a.html 将匹配规则C
访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而 http://localhost/static/c.png 则优先匹配到规则C
访问 http://localhost/a.PNG 则匹配规则E,而不会匹配规则D,因为规则E不区分大小写
访问 http://localhost/a.xhtml 不会匹配规则F和规则G,http://localhost/a.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到,所以想想看实际应用中哪里会用到
访问 http://localhost/category/id/1111 则最终匹配到规则H,因为以上规则都不匹配,这个时候应该是nginx转发请求给后端应用服务器,比如FastCGI(php),tomcat(jsp),nginx作为方向代理服务器存在
したがって、実用的な用途では、少なくとも3つのマッチングルールの必要性は、以下のように定義されます。
# 直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。
# 这里是直接转发给后端应用服务器了,也可以是一个静态首页
# 第一个必选规则
location = / {
proxy_pass http://localhost: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://localhost:8080/ }
2)書き換え文法
last – 基本上都用这个 Flag
break – 中止 Rewirte,不在继续匹配
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301
2.1発現を決定するために使用することができます
-f 和 !-f 用来判断是否存在文件
-d 和 !-d 用来判断是否存在目录
-e 和 !-e 用来判断是否存在文件或目录
-x 和 !-x 用来判断文件是否可执行
グローバル変数が決定される2.2を使用してもよいです
例:http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php $document_uri:/test1/test2/test.php $document_root:D:\nginx/html $request_filename:D:\nginx/html/test1/test2/test.php
3)文法をリダイレクト
server {
listen 80;
server_name start.igrow.cn;
index index.html index.php; root html; if ($http_host !~ “^star\.igrow\.cn$" { rewrite ^(.*) http://star.igrow.cn$1 redirect; } }
4)抗ホットリンク
location ~* \.(gif|jpg|swf)$ {
valid_referers none blocked start.igrow.cn sta.igrow.cn; if ($invalid_referer) { rewrite ^/ http://$host/logo.png; } }
5)ファイルの種類に応じて、有効期限を設定します
location ~* \.(js|css|jpg|jpeg|gif|png|swf)$ {
if (-f $request_filename) {
expires 1h; break; } }
6)ディレクトリへのアクセスを禁止
location ~* \.(txt|doc)${
root /data/www/wwwroot/linuxtone/test;
deny all;
}
レポート:グローバル変数が用意されています
$args
$content_length
$content_type
$document_root
$document_uri $host $http_user_agent $http_cookie $limit_rate $request_body_file $request_method $remote_addr $remote_port $remote_user $request_filename $request_uri $query_string $scheme $server_protocol $server_addr $server_name $server_port $uri
参考資料
1. nginxの分離の静的および動的リソースアクセスエントリ
2. 場所のnginxの詳細構成(ロケーションマッチング順)
3. 静的および動的リソースの分離の使用は、nginxの、静的および動的なリソースを処理しましたか
からの振替
孤立ダイナミックアクセス権を持つ静的リソースのnginxの構成 - blackfoxyaパーソナルスペース - OSCHINA https://my.oschina.net/u/3314358/blog/1920380