こんにちは、ハブラビテスさん！
Elasticwebでは、 Nginxを密かに擁護しており、おそらく、Apacheと.htaccessをそれぞれサポートしていない数少ないホスティング会社の1つです。 この点で、それらの多数のヒット。 サポートは、Nginxの構成ファイルの作成を支援することに関連しています。 そのため、最も人気のあるCMS / CMF / PHPフレームワーク用
の有用なスニペットの
コレクションと既製のNging構成の コレクションを収集することにしました。
準備ができた構成：
Nginxコマンド
Nginxの実行中に基本的な操作を実行するための基本的なコマンド。
- nginx -V -Nginxのバージョン、コンパイルされた構成パラメーター、インストールされているモジュールを確認します。
- nginx -t-構成ファイルをテストし、その場所を確認します。
- nginx -s reload -Nginxを再起動せずに構成ファイルを再起動します。
PHPのロケーションブロック
WebサイトにPHP、FPM、またはCGIをすばやく簡単にインストールするためのシンプルなテンプレート。
location ~ \.php$ { try_files $uri =404; client_max_body_size 64m; client_body_buffer_size 128k; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/path/to/php.sock; }
書き換えとリダイレクト
強制www
リモートサーバー
を特定する
正しい方法は、
wwwを使用しないドメイン
ごとに 、
wwwからリダイレクトすること
です 。
server { listen 80; server_name example.org; return 301 $scheme://www.example.org$request_uri; } server { listen 80; server_name www.example.org; ... }
HTTPSでも機能します。ノーノーフォース
リモートサーバーを特定する正しい方法は、c
wwwドメインから取得し、
wwwなしでリダイレクトすること
です 。
server { listen 80; server_name example.org; } server { listen 80; server_name www.example.org; return 301 $scheme://example.org$request_uri; }
HTTPSを強制する
HTTPからHTTPSに転送する方法：
server { listen 80; return 301 https://$host$request_uri; } server { listen 443 ssl;
末尾のスラッシュを強制
この行は、URLにピリオドまたはパラメーターがない場合にのみ、各URLの末尾にスラッシュ
/を追加します。 つまり、
example.com /
index.phpまたは
example.com/do?some=123の後、スラッシュは配信されません。
rewrite ^([^.\?]*[^/])$ $1/ permanent;
ページにリダイレクト
server { location = /oldpage.html { return 301 http://example.org/newpage.html; } }
サイトにリダイレクト
server { server_name old-site.com return 301 $scheme://new-site.com$request_uri; }
URIの特定のパスにリダイレクトする
location /old-site { rewrite ^/old-site/(.*) http://example.org/new-site/$1 permanent; }
性能
キャッシング
ブラウザが静的コンテンツをキャッシュすることを永続的に許可します。 Nginxは、ExpiresとCache-Controlの両方のヘッダーを設定します。
location /static { root /data; expires max; }
次のように、ブラウザのキャッシュを無効にすることができます（たとえば、リクエストを追跡するため）。
location = /empty.gif { empty_gif; expires -1; }
Gzip圧縮
gzip on; gzip_buffers 16 8k; gzip_comp_level 6; gzip_http_version 1.1; gzip_min_length 256; gzip_proxied any; gzip_vary on; gzip_types text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml text/javascript application/javascript application/x-javascript text/x-json application/json application/x-web-app-manifest+json text/css text/plain text/x-component font/opentype application/x-font-ttf application/vnd.ms-fontobject image/x-icon; gzip_disable "msie6";
ファイルキャッシュ
Nginxを介して多数の静的ファイルをキャッシュした場合、これらのファイルのメタデータをキャッシュすると遅延時間が節約されます。
open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
SSLキャッシュ
SSLキャッシングを有効にすると、SSLセッションを再開し、SSL / TLSプロトコルへの次の呼び出しの時間を短縮できます。
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
アップストリームサポート
アップストリーム接続を使用したキャッシュのアクティブ化：
upstream backend { server 127.0.0.1:8080; keepalive 32; } server { ... location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; } }
モニタリング
デフォルトでは、
スタブステータスモジュールは構築されません。その構成は、構成パラメーターwith-http_stub_status_moduleを使用して有効にし、次を使用してアクティブにする必要があります。
location /status { stub_status on; access_log off; }
この設定により、リクエストとクライアント接続の合計数（受け入れ済み、処理済み、アクティブ）のステータスをプレーンテキスト形式で受け取ることができます。
Luameterを使用すると、Nginxからより有益なステータスを取得できます。これは、インストールがやや難しく、Nginx Luaモジュールが必要です。 これにより、さまざまな構成グループの次のメトリックがJSON形式で提供されます。
- リクエスト/レスポンスの総数。
- ステータスコード別にグループ化された応答の総数：1xx、2xx、3xx、4xx、5xx。
- クライアントに送受信された合計バイト数。
- 最小、最大、中央値、遅延などを推定するための中間期間
- 負荷の監視と予測を容易にするためのクエリの平均数。
- など...
Luameterダッシュボードの例 。
また、
ngxtopは統計の収集に最適です。
安全性
基本認証の有効化
まず、パスワードを作成し、プレーンテキストファイルに保存する必要があります。
:
次に、保護するサーバー/ロケーションブロックのニトロ設定を設定します。
auth_basic "This is Protected"; auth_basic_user_file /path/to/password-file;
ローカルアクセスのみを開く
location /local { allow 127.0.0.1; deny all; ... }
SSL設定の保護
その他
完了後のサブクエリ
アドオン内またはその処理後にリクエストを別のバックエンド
に転送する必要がある場合があります。 最初のケースは、ユーザーがファイルをダウンロードした後にAPIを呼び出して、完了したダウンロードの数を追跡することです。 2番目のケースは、可能な限り迅速に（おそらく空の.gifを使用して）返したいリクエストを追跡し、対応するエントリをバックグラウンドで作成することです。
post_actionを使用すると、サブクエリを定義でき、現在のリクエストの終了時に拒否されますが、両方のオプションに
最適なソリューションです。
location = /empty.gif { empty_gif; expires -1; post_action @track; } location @track { internal; proxy_pass http://tracking-backend; }
ソース間のリソースの分配
サーバーへのクロスドメイン要求の最も簡単で最も有名な方法：
location ~* .(eot|ttf|woff) { add_header Access-Control-Allow-Origin *; }
ソース
ご清聴ありがとうございました！