「Nginx」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(改行を追加)
(→‎インストール: 情報を更新)
 
(3人の利用者による、間の48版が非表示)
5行目: 5行目:
 
[[ru:Nginx]]
 
[[ru:Nginx]]
 
[[zh-hans:Nginx]]
 
[[zh-hans:Nginx]]
[[Wikipedia:ja:nginx|nginx]] ("エンジンエックス"と発音します)は2005年から Igor Sysoev(ロシア)によって開発されている、フリーでオープンソースかつハイパフォーマンスな HTTP サーバーかつリバースプロクシで、IMAP/POP3 プロクシサーバーとしても機能します。
+
[[Wikipedia:ja:nginx|nginx]] ("エンジンエックス"と発音します)は 2005 年から Igor Sysoev(ロシア)によって開発されている、フリーでオープンソースかつハイパフォーマンスな HTTP サーバーかつリバースプロクシで、IMAP/POP3 プロクシサーバーとしても機能します。Nginx は主に、その安定性・多機能・単純な設定・低リソース消費によって知られています。
   
  +
この記事では nginx の設定方法と、[[#FastCGI]] を使って [[PHP]] と統合する方法を説明します。
Nginx は主に、その安定性・多機能・単純な設定・低リソース消費によって知られています。
 
   
 
== インストール ==
 
== インストール ==
   
[[公式リポジトリ]]から {{Pkg|nginx-mainline}} (最新の機能アップデート、バグ修正が適用された最新版)か {{Pkg|nginx}} (重要な修正のみを適応した安定版) を[[Pacman|インストール]]できます。
+
[[公式リポジトリ]] から {{Pkg|nginx-mainline}} (メインラインブランチ: 最新の機能アップデート修正) か {{Pkg|nginx}} (安定ブランチ: 重要な修正のみを適応) のどちらか [[Pacman|インストール]] できます。
   
  +
メインラインブランチを使用することをお勧めします。安定版ブランチを使う主な理由は、サードパーティ製モジュールとの非互換性や、[https://nginx.org/en/download.html 新機能] の不注意によるバグ導入など、新機能の起こりうる影響を懸念するためです。
{{Note|
 
基本的には[https://www.nginx.com/blog/nginx-1-6-1-7-released/ 最新版の利用が推奨されています]が、
 
* サードパーティ製のモジュールとの互換性
 
* 新規に追加された機能の未知のバグ
 
などによる影響が懸念される場合は、安定版を使用することを検討してください。
 
}}
 
   
  +
{{Note|[[公式リポジトリ]] で利用可能なすべての nginx モジュールは、依存関係として ''nginx'' パッケージ (''nginx-mainline'' ではなく) を必要とします。''nginx'' か ''nginx-mainline'' かを決定する前に、必要なモジュールのリストを確認することをお勧めします。''nginx-mainline'' のモジュールは [[Arch User Repository]] にあります。}}
''Ruby on Rails'' のためにインストールするには、[[Ruby on Rails#Rails パーフェクトセットアップ]]を参照してください。
 
   
セキュリティを向上させるために chroot によるインストールをするには、[[#chroot でインストール]] を参照してください。
+
セキュリティを向上させるために chroot によるインストールをするには、[[nginx#chroot でインストール|chroot でインストール]] を参照してください。
   
 
== サービスの開始 ==
 
== サービスの開始 ==
   
  +
{{ic|nginx.service}} を[[起動/有効化]]します。
Nginx サービスを走らせるには:
 
# systemctl start nginx
 
   
  +
http://127.0.0.1 で提供されるデフォルトのページは、{{ic|/usr/share/nginx/html/index.html}} です。
スタートアップ時に Nginx サービスを起動するには:
 
# systemctl enable nginx
 
 
http://127.0.0.1 にデフォルトで表示されるページは:
 
/usr/share/nginx/html/index.html
 
   
 
== 設定 ==
 
== 設定 ==
39行目: 29行目:
 
nginx における最初の手順は [http://nginx.org/en/docs/beginners_guide.html 公式のビギナーズガイド] で説明されています。{{ic|/etc/nginx/}} にあるファイルを編集することで Nginx の設定ができます。メインの設定ファイルは {{ic|/etc/nginx/nginx.conf}} です。
 
nginx における最初の手順は [http://nginx.org/en/docs/beginners_guide.html 公式のビギナーズガイド] で説明されています。{{ic|/etc/nginx/}} にあるファイルを編集することで Nginx の設定ができます。メインの設定ファイルは {{ic|/etc/nginx/nginx.conf}} です。
   
より詳しい解説はこちら: 公式の [http://nginx.org/en/docs/ ドキュメント] にある [http://wiki.nginx.org/Configuration Nginx Configuration Examples]。
+
より詳しい解説は公式の [http://nginx.org/en/docs/ ドキュメント] にある [http://wiki.nginx.org/Configuration Nginx Configuration Examples] にあります
  +
  +
以下の例は、最も一般的な使用例をカバーしています。ここでは、ドキュメントのデフォルトの場所 ({{ic|/usr/share/nginx/html}}) を使用することを想定しています。そうでない場合は、代わりにあなたのパスを指定してください。
  +
  +
{{Tip|DigitalOcean から [https://nginxconfig.io/ Nginx configuration tool] が提供されています。}}
  +
  +
=== 設定例 ===
  +
  +
{{hc|/etc/nginx/nginx.conf|<nowiki>
  +
user http;
  +
worker_processes auto;
  +
worker_cpu_affinity auto;
  +
  +
events {
  +
multi_accept on;
  +
worker_connections 1024;
  +
}
  +
  +
http {
  +
charset utf-8;
  +
sendfile on;
  +
tcp_nopush on;
  +
tcp_nodelay on;
  +
server_tokens off;
  +
log_not_found off;
  +
types_hash_max_size 4096;
  +
client_max_body_size 16M;
  +
  +
# MIME
  +
include mime.types;
  +
default_type application/octet-stream;
  +
  +
# logging
  +
access_log /var/log/nginx/access.log;
  +
error_log /var/log/nginx/error.log warn;
  +
  +
# load configs
  +
include /etc/nginx/conf.d/*.conf;
  +
include /etc/nginx/sites-enabled/*;
  +
}
  +
</nowiki>}}
   
 
=== 一般設定 ===
 
=== 一般設定 ===
  +
  +
==== プロセス数とコネクション数 ====
   
 
{{ic|worker_processes}} の適当な値を探って下さい。この設定は最終的に nginx が受け入れる接続の数と利用できるプロセスの数を定義します。通常、システムのハードウェアのスレッド数にすると良いでしょう。また、バージョン 1.3.8 と 1.2.5 から {{ic|worker_processes}} には {{ic|auto}} と設定することができ、最適な値を自動的に検出します ([http://nginx.org/en/docs/ngx_core_module.html#worker_processes ソース])。
 
{{ic|worker_processes}} の適当な値を探って下さい。この設定は最終的に nginx が受け入れる接続の数と利用できるプロセスの数を定義します。通常、システムのハードウェアのスレッド数にすると良いでしょう。また、バージョン 1.3.8 と 1.2.5 から {{ic|worker_processes}} には {{ic|auto}} と設定することができ、最適な値を自動的に検出します ([http://nginx.org/en/docs/ngx_core_module.html#worker_processes ソース])。
   
 
nginx が受け入れる最大接続数は {{ic|1=max_clients = worker_processes * worker_connections}} で計算できます。
 
nginx が受け入れる最大接続数は {{ic|1=max_clients = worker_processes * worker_connections}} で計算できます。
  +
  +
==== 別のユーザーで実行する ====
  +
  +
デフォルトでは、{{Pkg|nginx}} はマスタープロセスを {{ic|root}} で、ワーカープロセスを {{ic|http}} ユーザで実行します。ワーカープロセスを別のユーザで実行するには、{{ic|nginx.conf}} の {{ic|user}} ディレクティブを変更します。
  +
  +
{{hc|/etc/nginx/nginx.conf|
  +
user ''user'' [''group''];
  +
}}
  +
  +
group が省略された場合は、''user'' と同じ名前のグループが使用されます。
  +
  +
{{Tip|1=[[systemd]] を使って {{ic|root}} で何もせずに nginx を動かすことも可能です。[[#systemd を使って非特権で動作させる]]を参照してください。}}
   
 
==== サーバーブロック ====
 
==== サーバーブロック ====
   
{{ic|server}} ブロックを使うことで複数のドメインを利用することができます。"バーチャルホスト"とも呼ばれますが、これは [[Apache]] の用語です。{{ic|server}} ブロックの利用方法は [http://wiki.nginx.org/ServerBlockExample Apache] とは異なっています。
+
{{ic|server}} ブロックを使うことで複数のドメインを利用することができます。"バーチャルホスト"とも呼ばれますが、これは [[Apache]] の用語です。{{ic|server}} ブロックの利用方法は [http://wiki.nginx.org/ServerBlockExample Apache] とは異なっています。[https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/ upstream examples] も参照してください
   
 
以下の例では2つのドメインの接続をサーバーが待機します: {{ic|domainname1.dom}} と {{ic|domainname2.dom}}:
 
以下の例では2つのドメインの接続をサーバーが待機します: {{ic|domainname1.dom}} と {{ic|domainname2.dom}}:
80行目: 124行目:
 
127.0.0.1 domainname2.dom
 
127.0.0.1 domainname2.dom
   
==== TLS/SSL ====
+
===== サーバーエントリの管理 =====
  +
SSL を使用するには、{{pkg|openssl}} をインストールする必要があります。
 
  +
異なる {{ic|server}} ブロックを異なるファイルに配置することができます。これにより、特定のサイトを簡単に有効または無効にできます。
  +
  +
次のディレクトリを作成します。
  +
  +
# mkdir /etc/nginx/sites-available
  +
# mkdir /etc/nginx/sites-enabled
  +
  +
{{ic|sites-available}} ディレクトリに、一つ以上のサーバーブロックを含むファイルを作成します。
  +
  +
{{hc|/etc/nginx/sites-available/example.conf|<nowiki>
  +
server {
  +
listen 443 ssl http2;
  +
listen [::]:443 ssl http2;
  +
  +
...
  +
}
  +
</nowiki>}}
  +
  +
{{ic|http}} ブロックの最後に、{{ic|include sites-enabled/*;}} を追加します。
  +
  +
{{hc|/etc/nginx/nginx.conf|<nowiki>
  +
http {
  +
...
  +
include sites-enabled/*;
  +
}
  +
</nowiki>}}
  +
  +
サイトを有効にするには、シンボリックリンクを作成するだけです。
  +
  +
# ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf
  +
  +
サイトを無効にするには、アクティブなシンボリックリンクのリンクを解除します。
  +
  +
# unlink /etc/nginx/sites-enabled/example.conf
  +
  +
{{ic|nginx.service}} を [[リロード]]/[[再起動]] して、サイト設定の変更を有効にします。
  +
  +
==== TLS ====
  +
  +
[[OpenSSL]] は TLS をサポートし、Arch のインストール時にデフォルトでインストールされます。
   
 
{{Tip|
 
{{Tip|
 
* SSL を設定する前に [http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate ngx_http_ssl_module] のドキュメントを読むことを推奨します。
 
* SSL を設定する前に [http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate ngx_http_ssl_module] のドキュメントを読むことを推奨します。
* [[Let’s Encrypt]] は無料の、自動化されたオープンな証明局です。{{Pkg|letsencrypt-nginx}}{{Broken package link|置換パッケージ: {{Pkg|certbot-nginx}}}} をインストールすることで nginx プラグインを利用してコマンドラインから直接 SSL 証明書を作成して自動で設定することがきます。}}
+
* [[Let’s Encrypt]] は無料の、自動化されたオープンな証明局です。コマンドラインおよび自動設定から直接有効な SSL 証明書を要求するプラグインを利用可能です。
  +
* Mozilla には、便利な [[MozillaWiki:Security/Server Side TLS|TLS 記事]] と [https://mozilla.github.io/server-side-tls/ssl-config-generator/ 自動化ツール] があります。より安全な設定を作成するのに役立ちます。
  +
}}
  +
  +
{{Warning|SSL/TLS の実装を計画している場合は、一部のバリエーションと実装は [https://weakdh.org/#affected まだ] [[wikipedia:Transport_Layer_Security# Attacks_against_TLS.2FSSL|攻撃に対して脆弱]] であることを知っておいてください。SSL/TLS 内の現在の脆弱性の詳細と、nginx に適切な変更を適用する方法については、http://disablessl3.com/ および https://weakdh.org/sysadmin.html を参照してください。}}
  +
  +
秘密キーと自己署名証明書を作成します。[[OpenSSL# 証明書署名要求を生成|CSR]] を必要としないほとんどのインストールにはこれで十分です。
   
自己署名証明書を作成してください (キーのサイズや効力の日数は変更できます):
 
 
# mkdir /etc/nginx/ssl
 
# mkdir /etc/nginx/ssl
 
# cd /etc/nginx/ssl
 
# cd /etc/nginx/ssl
# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out cert.key
+
# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 1095
# chmod 600 cert.key
+
# chmod 400 server.key
  +
# chmod 444 server.crt
# openssl req -new -key cert.key -out cert.csr
 
# openssl x509 -req -days 365 -in cert.csr -signkey cert.key -out cert.crt
 
   
  +
{{Note|{{ic|-days}} スイッチはオプションであり、RSA キーサイズは 2048 (デフォルト) まで小さくできます。}}
{{Note|その他の ''openssl'' オプションに関しては、 OpenSSL の [https://www.openssl.org/docs/apps/openssl.html man page] か [https://www.openssl.org/docs/ extensive documentation] を参照してください。}}
 
   
  +
CSR を作成する必要がある場合は、上記の代わりに次の手順に従ってください。
{{Warning|If you plan on implementing SSL/TLS, know that some variations and implementations are [https://weakdh.org/#affected still] [[wikipedia:Transport_Layer_Security#Attacks_against_TLS.2FSSL|vulnerable to attack]]. For details on these current vulnerabilities within SSL/TLS and how to apply appropriate changes to nginx, visit http://disablessl3.com/ and https://weakdh.org/sysadmin.html}}
 
   
  +
# mkdir /etc/nginx/ssl
TLS/SSL を用いる場合の {{ic|nginx.conf}} 設定サンプル:
 
  +
# cd /etc/nginx/ssl
  +
# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key
  +
# chmod 400 server.key
  +
# openssl req -new -sha256 -key server.key -out server.csr
  +
# openssl x509 -req -days 1095 -in server.csr -signkey server.key -out server.crt
   
  +
{{Note|その他の ''openssl'' オプションについては、マニュアル ページ {{man|1ssl|openssl}} を読むか、[https://www.openssl.org/docs/ 豊富なドキュメント] を熟読してください。}}
{{hc|/etc/nginx/nginx.conf|<nowiki>
 
http {
 
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
 
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 
ssl_prefer_server_ciphers on;
 
ssl_session_cache shared:SSL:10m;
 
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
 
add_header X-Frame-Options DENY;
 
add_header X-Content-Type-Options nosniff;
 
ssl_session_tickets off;
 
ssl_stapling on;
 
ssl_stapling_verify on;
 
resolver 8.8.8.8 8.8.4.4 valid=300s; # Google DNS Servers
 
resolver_timeout 5s;
 
}
 
   
  +
TLS を使用した {{ic|/etc/nginx/nginx.conf}} の開始点は、[https://ssl-config.mozilla.org/#server=nginx Mozilla の SSL 設定ジェネレーター] です。
server {
 
#listen 80; # Uncomment to also listen for HTTP requests
 
listen 443 ssl;
 
server_name localhost;
 
   
  +
{{ic|nginx.service}} を[[再起動]] して変更内容を反映させます。
ssl_certificate ssl/server.crt;
 
ssl_certificate_key ssl/server.key;
 
   
  +
==== ユーザーごとのディレクトリ ====
root /usr/share/nginx/html;
 
  +
location / {
 
  +
Apache スタイルの {{ic|~user}} URL をユーザーの {{ic|~/public_html}} ディレクトリに複製するには、次の手順を試してください。(注: 両方のルールを使用する場合、以下では、より具体的な PHP ルールを最初に置く必要があります。)
index index.html index.htm;
 
  +
}
 
  +
{{hc|/etc/nginx/nginx.conf|<nowiki>
  +
...
  +
server {
  +
...
  +
# PHP in user directories, e.g. http://example.com/~user/test.php
  +
location ~ ^/~(.+?)(/.+\.php)$ {
  +
alias /home/$1/public_html$2;
  +
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
  +
fastcgi_index index.php;
  +
include fastcgi.conf;
  +
}
  +
  +
# User directories, e.g. http://example.com/~user/
  +
location ~ ^/~(.+?)(/.*)?$ {
  +
alias /home/$1/public_html$2;
  +
index index.html index.htm;
  +
autoindex on;
  +
}
  +
...
 
}
 
}
  +
...
 
</nowiki>}}
 
</nowiki>}}
   
  +
{{ic|nginx}} を使用した PHP 設定の詳細については、[[nginx#PHP を動かす|PHP を動かす]] を参照してください。
{{Tip|
 
* Mozilla は有用な [https://wiki.mozilla.org/Security/Server_Side_TLS SSL/TLS の記事] を用意しており、[https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx nginx] の設定ガイドラインや、セキュアな設定を助ける [https://mozilla.github.io/server-side-tls/ssl-config-generator/ 自動化ツール] が載っています。
 
* [https://cipherli.st Cipherli.st] には大半のモダンなサーバーに対応する強力な SSL の実装例とチュートリアルが載っています。
 
}}
 
   
{{ic|nginx.service}} を再起動して変更適用します。
+
{{ic|nginx.service}} を [[再起動]] して新しい設定有効にします。
   
 
=== FastCGI ===
 
=== FastCGI ===
287行目: 379行目:
 
{{ic|-f 10}} は生成する子スレッドの数に変更してください。
 
{{ic|-f 10}} は生成する子スレッドの数に変更してください。
   
  +
{{Warning|{{ic|spawn-fcgi}} の {{ic|-M 660}} オプションを使用すると奇妙な動作が発生するため、ExecStartPost 行が必要です。間違ったモードが設定されています。これはバグかもしれません?}}
{{Warning|The ExecStartPost line is required because of strange behaviour I'm seeing when I use the {{ic|-M 660}} option for {{ic|spawn-fcgi}}. The wrong mode is set. This may be a bug?}}
 
   
===== 手順2: Nginx の設定 =====
+
===== nginx の設定 =====
   
  +
{{ic|/etc/nginx}} で、ファイル {{ic|fastcgi_params}} を {{ic|fcgiwrap_params}} にコピーします。{{ic|fcgiwrap_params}} で、{{ic|SCRIPT_NAME}} と {{ic|DOCUMENT_ROOT}} を設定する行をコメント化するか削除します。
CGI ウェブアプリケーションを置くそれぞれの {{Ic|server}} ブロックには以下のような {{Ic|location}} ブロックを記述します:
 
  +
  +
CGI Web アプリケーションを提供する各 {{ic|server}} ブロック内には、次のような {{ic|location}} ブロックが表示されます。
   
 
location ~ \.cgi$ {
 
location ~ \.cgi$ {
root /path/to/server/cgi-bin;
+
include fcgiwrap_params;
  +
fastcgi_param DOCUMENT_ROOT /srv/www/cgi-bin/;
fastcgi_pass unix:/run/fcgiwrap.sock;
 
include fastcgi.conf;
+
fastcgi_param SCRIPT_NAME myscript.cgi;
  +
fastcgi_pass unix:/run/fcgiwrap.sock;
 
}
 
}
   
{{Ic|fcgiwrap}} の'''デフォルト''' (Unix) ソケットは ''/run/fcgiwrap.sock'' です。
+
{{ic|fcgiwrap}} のデフォルトソケットファイル{{ic|/run/fcgiwrap.sock}} です。
  +
  +
{{ic|fastcgi_param SCRIPT_FILENAME /srv/www/cgi-bin/myscript.cgi}} を使用することは、{{ic|DOCUMENT_ROOT}} と {{ic|SCRIPT_NAME}} を設定する代わりのショートカットです。 {{ic|SCRIPT_FILENAME}} を使用する場合は、{{ic|fastcgi_params}} を {{ic|fcgiwrap_params}} にコピーして、{{ic|DOCUMENT_ROOT}} と {{ic|SCRIPT_NAME 行をコメントアウトする必要もありません。}}
  +
  +
{{Warning|SCRIPT_NAME と DOCUMENT_ROOT が使用されている場合、fcgiwrap は nginx に設定されている他の fastcgi_params を ''破棄'' します。他のパラメータ (PATH_INFO など) を Nginx 設定を通じて設定できるようにするには、SCRIPT_FILENAME を使用する必要があります。[https://github.com/gnosek/fcgiwrap/issues/3 GitHub の問題を参照してください]}}
  +
  +
{{ic|502 - bad Gateway}} エラーが繰り返し発生する場合は、CGI アプリケーションが最初に次のコンテンツの MIME タイプをアナウンスするかどうかを確認する必要があります。HTML の場合、これは {{ic|Content-type: text/html}} である必要があります。
  +
  +
403 エラーが発生した場合は、CGI 実行可能ファイルが {{ic|http}} ユーザーによって読み取りおよび実行可能であること、およびすべての親フォルダーが {{ic|http}} ユーザーによって読み取り可能であることを確認してください。
   
 
== chroot でインストール ==
 
== chroot でインストール ==
386行目: 489行目:
 
# cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc}}
 
# cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc}}
 
 
  +
chroot のために制限を付けたユーザー・グループファイルを作成します。これにより chroot にアクセスするのに必要なシステムユーザー・グループが攻撃者に漏洩しなくなります。
Create restricted user/group files for the chroot. This way only the
 
users needed for the chroot to function exist as far as the chroot
 
knows, and none of the system users/groups are leaked to attackers
 
should they gain access to the chroot.
 
   
 
{{hc|$JAIL/etc/group|
 
{{hc|$JAIL/etc/group|
414行目: 514行目:
 
# touch $JAIL/run/nginx.pid
 
# touch $JAIL/run/nginx.pid
   
  +
最後にパーミッションをできるだけ制限的に設定してください。できるかぎり所有者を root にして書き込み不可にします。
Finally make set very restrictive permissions. As much as possible
 
should be owned by root and set unwritable.
 
   
 
# chown -R root:root $JAIL/
 
# chown -R root:root $JAIL/
432行目: 531行目:
 
# chmod +rw $JAIL/run
 
# chmod +rw $JAIL/run
   
  +
サーバーがポート 80 (あるいは 0-1024 のどれかのポート) で待機する場合、chroot した実行ファイルに root 権限がなくてもポートを使えるように権限を与えてください:
If your server will bind port 80 (or any port 0-1024), give the
 
chrooted executable permission to bind these ports without root.
 
   
 
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx
 
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx
439行目: 537行目:
 
=== nginx.service を変更して chroot を起動 ===
 
=== nginx.service を変更して chroot を起動 ===
   
  +
{{ic|nginx.service}} ユニットファイルを編集する前に、ユニットファイルを {{ic|/etc/systemd/system/}} にコピーして {{ic|/usr/lib/systemd/system/}} のファイルよりも優先されるようにすると良いでしょう。nginx をアップグレードしたときにカスタムした ''.service'' ファイルが変更されなくなります。
Before modifying the nginx.service unit file, it may be a good idea to copy it to
 
  +
{{ic|/etc/systemd/system/}} since the unit files there take priority over those in {{ic|/usr/lib/systemd/system/}}.
 
This means upgrading nginx would not modify your custom .service file.
 
 
# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service
 
# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service
   
  +
chroot で nginx を起動するために systemd ユニットを変更して、pid ファイルを chroot に保存します。
The systemd unit must be changed to start up Nginx in the chroot, as
 
  +
the http user, and store the pid file in the chroot
 
  +
{{Note|pid ファイルを chroot ジェイルに保存する必要があるかどうかはわかりません。}}
{{Note|I'm not sure if the pid file needs to be stored in the chroot jail.}}
 
   
 
{{hc|/etc/systemd/system/nginx.service|<nowiki>
 
{{hc|/etc/systemd/system/nginx.service|<nowiki>
464行目: 561行目:
 
WantedBy=multi-user.target</nowiki>}}
 
WantedBy=multi-user.target</nowiki>}}
   
  +
{{Note|pacman を使用して nginx をアップグレードしても、chroot された nginx インストールはアップグレードされません。上記の手順の一部を繰り返して、手動で更新を行う必要があります。リンク先のライブラリも忘れずに更新してください。}}
{{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Do not forget to also update the libraries it links against. }}
 
  +
  +
chroot されていない nginx 環境は取り除いてもかまいません:
   
You can now safely get rid of the non-chrooted nginx installation.
 
 
# pacman -Rsc nginx
 
# pacman -Rsc nginx
   
  +
chroot されていない nginx 環境を削除しない場合、実行中の nginx プロセスが chroot されているプロセスかどうか確認したくなるときがあるかもしれません。{{ic|/proc/''PID''/root}} シンボリックリンクを確認することでチェックできます。
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/{PID}/root}} symmlinks to. If should link to {{ic|/srv/http}} instead of {{ic|/}}.
 
  +
 
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done
 
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done
   
== トラブルシューィング ==
+
== ヒンクニック ==
   
  +
=== systemd を使用したユーザーサービスの実行 ===
=== 設定の確認 ===
 
# nginx -t
 
   
  +
権限のないユーザーが完全に制御して構成できるサーバーインスタンスを実行したい場合は、{{AUR|nginx-user-service}} の使用を検討してください。
結果:
 
   
  +
=== [[systemd]] を使って非特権で動作させる ===
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
 
nginx: configuration file /etc/nginx/nginx.conf test is successful
 
   
  +
{{ic|nginx.service}} の[[ドロップインファイル]]を使用して、{{ic|[Service]}} の下の {{ic|User}} と任意で {{ic|Group}} を設定します。
=== ローカル IP へのアクセスが localhost にリダイレクトされる ===
 
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
  +
[Service]
  +
User=''user''
  +
Group=''group''
  +
}}
   
  +
権限昇格に対してサービスを防御することができます:
Arch Linux [https://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 フォーラム]からの解決法があります。
 
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
  +
[Service]
  +
...
  +
NoNewPrivileges=yes
  +
}}
   
  +
{{Tip|1=制限オプションについて詳しくは [http://www.freedesktop.org/software/systemd/man/systemd.exec.html#User= systemd.exec(5)] を見てください。}}
{{ic|/etc/nginx/nginx.conf}} を開き、"server_name localhost" の前の # を取り除き、以下を付け加えます:
 
server_name_in_redirect off;
 
   
  +
それから {{ic|''user''}} が必要なファイルやポートにアクセスできるようにしてください。以下の項目に従って、nginx を[[起動]]します。
デフォルトでは、nginx は設定にある server_name へのリクエストをすべてリダイレクトします。
 
   
  +
{{Tip|[[#FastCGI|FastCGI サーバー]] でも同じ設定が望ましい場合があります。}}
=== Error: 403 (Permission error) ===
 
   
  +
==== ポート ====
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?
 
  +
Linux はデフォルトでは {{ic|root}} 以外が 1024 以下のポートを使うことができないようになっています。1024 よりも上のポートは使うことができます:
   
  +
{{hc|/etc/nginx/nginx.conf|
If the files are located within a home directory, (e.g. {{ic|/home/arch/public/webapp}}) and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determine this), {{ic|/home/arch}} might be '''chmod 750''', simply {{Ic|chmod}} it to ''751'', and it should work.
 
  +
server {
  +
listen 8080;
  +
}
  +
}}
   
  +
{{Tip|1=nginx にポート 80 あるいは 443 からアクセスできるようにしたい場合、[[ファイアウォール]]を設定して 80 あるいは 443 から nginx が listen しているポートに転送してください。}}
'''If you have changed your document root'''
 
  +
</dd>
  +
<dd>
  +
また、nginx プロセスに CAP_NET_BIND_SERVICE ケイパビリティを付与することで 1024 以下のポートにバインドできるようになります:
   
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
If you are sure that permissions are as they should be, make sure that your document root directory is not empty. Try creating index.html in there.
 
  +
[Service]
  +
...
  +
CapabilityBoundingSet=
  +
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
  +
AmbientCapabilities=
  +
AmbientCapabilities=CAP_NET_BIND_SERVICE
  +
}}
  +
</dd>
   
=== Error: 404 (Pathinfo error) ===
+
==== PID ファイル ====
   
  +
{{Pkg|nginx}} はデフォルトでは {{ic|/run/nginx.pid}} を使います。''user'' が書き込み可能なディレクトリを作成して PID ファイルをそこに配置します。[[systemd#一時ファイル|systemd-tmpfiles]] を使用する例:
いくつかのフレームワーク (thinkphp、cakephp など)や CMS では pathinfo が必要です。
 
   
  +
{{hc|/etc/tmpfiles.d/nginx.conf|2=
1. {{ic|/etc/php/php.ini}} ファイルを開き、次のように付け加えます
 
  +
d /run/nginx 0775 root ''group'' - -
cgi.fix_pathinfo=1
 
  +
}}
2. {{ic|/etc/nginx/nginx.conf}} を開き、次の部分をコメントアウトします
 
   
  +
設定を実行:
location ~ \.php$ {
 
...
 
}
 
   
  +
# systemd-tmpfiles --create
 
   
  +
元の {{ic|nginx.service}} に合わせて PID の値を[[編集]]:
#location ~ \.php$ {
 
#...
 
#}
 
   
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
そして以下を加えます
 
  +
[Service]
location ~ ^(.+\.php)(.*)$ {
 
  +
...
root /srv/http/nginx;
 
  +
PIDFile=/run/nginx/nginx.pid
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
 
  +
ExecStart=
#fastcgi_pass 127.0.0.1:9000; #Un-comment this and comment "fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;" if you are not using php-fpm.
 
  +
ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;'
fastcgi_index index.php;
 
  +
ExecReload=
set $document_root2 $document_root;
 
  +
ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid;'
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }
 
  +
}}
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }
 
  +
</dd>
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }
 
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }
 
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }
 
fastcgi_split_path_info ^(.+\.php)(.*)$;
 
fastcgi_param SCRIPT_FILENAME $document_root2$fastcgi_script_name;
 
fastcgi_param PATH_INFO $fastcgi_path_info;
 
fastcgi_param PATH_TRANSLATED $document_root2$fastcgi_path_info;
 
include fastcgi_params;
 
fastcgi_param DOCUMENT_ROOT $document_root2;
 
}
 
   
  +
==== /var/lib/nginx ====
try_files を使う方法もあります:
 
server {
 
..
 
root /usr/share/nginx/html;
 
index index.php;
 
location / {
 
try_files $uri $uri/ /index.php?$args;
 
}
 
}
 
   
  +
{{Pkg|nginx}} は、デフォルトで一時ファイルを {{ic|/var/lib/nginx}} に保存するようにコンパイルされます。
=== Error: The page you are looking for is temporarily unavailable. Please try again later. ===
 
   
  +
{{Tip|{{ic|$ nginx -V}} を実行して、すべてのコンパイル済みオプションを表示します}}
FastCGI サーバーが動作していないか、ソケットが間違ったパーミッションに設定されています。
 
  +
  +
たとえば、{{ic|StateDirectory}} ({{man|5|systemd.exec}}) を使用して、''ユーザー'' にこのディレクトリへの書き込みアクセス権を与えることができます。
  +
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
  +
[Service]
  +
...
  +
StateDirectory=nginx
  +
}}
  +
  +
==== /var/log/nginx ====
  +
  +
{{Pkg|nginx}} は、デフォルトでアクセスログを {{ic|/var/log/nginx}} に保存するようにコンパイルされます。
  +
  +
たとえば、{{ic|LogsDirectory}} ({{man|5|systemd.exec}}) を使用して、''ユーザー'' にこのディレクトリへの書き込みアクセス権を与えることができます。
  +
  +
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2=
  +
[Service]
  +
...
  +
LogsDirectory=nginx
  +
}}
  +
  +
=== systemd の別のスクリプト ===
  +
  +
純粋な systemd では、chroot + systemd の利点を得ることができます。[http://0pointer.de/blog/projects/changing-roots.html] セット [https://wiki.nginx.org/CoreModule#user ユーザーグループ] と pid に基づいて次のようにします。
  +
  +
{{hc|/etc/nginx/nginx.conf|2=
  +
user http;
  +
pid /run/nginx.pid;
  +
}}
  +
  +
ファイルの絶対パスは {{ic|/srv/http/etc/nginx/nginx.conf}} です。
  +
  +
{{hc|/etc/systemd/system/nginx.service|2=
  +
[Unit]
  +
Description=nginx (Chroot)
  +
After=syslog.target network.target
  +
  +
[Service]
  +
Type=forking
  +
PIDFile=/srv/http/run/nginx.pid
  +
RootDirectory=/srv/http
  +
ExecStartPre=/usr/bin/nginx -t -c /etc/nginx/nginx.conf
  +
ExecStart=/usr/bin/nginx -c /etc/nginx/nginx.conf
  +
ExecReload=/usr/bin/nginx -c /etc/nginx/nginx.conf -s reload
  +
ExecStop=/usr/bin/nginx -c /etc/nginx/nginx.conf -s stop
  +
  +
[Install]
  +
WantedBy=multi-user.target
  +
}}
  +
  +
デフォルトの場所を設定する必要はありません。nginx はデフォルトでロードされます。{{ic| -c /etc/nginx/nginx.conf}} ですが、これは良い考えです。
  +
  +
あるいは、パラメータ {{ic|RootDirectoryStartOnly}} を {{ic|yes}} に設定して chroot として '''only''' {{ic|ExecStart}} を実行することもできます。({{man|5|systemd.service}} を参照) またはマウントポイントが有効になる前、または systemd パス ({{man|5|systemd.path}} を参照) が利用可能になる前に起動します。
  +
  +
{{hc|/etc/systemd/system/nginx.path|2=
  +
[Unit]
  +
Description=nginx (Chroot) path
  +
[Path]
  +
PathExists=/srv/http/site/Public_html
  +
[Install]
  +
WantedBy=default.target
  +
}}
  +
  +
作成された {{ic|nginx.path}} を [[有効化]] し、{{ic|1=WantedBy=default.target}} を {{ic|1=WantedBy=nginx.path}} に変更します|/etc/systemd/system/nginx.service}}
  +
  +
ユニットファイル内の {{ic|PIDFile}} により、systemd がプロセスを監視できるようになります (絶対パスが必要です) 望ましくない場合は、デフォルトのワンショットタイプに変更し、ユニットファイルから参照を削除できます。
  +
  +
=== Nginx Beautifier ===
  +
  +
{{AUR|nginxbeautifier}} は nginx の設定ファイルを整形することができるコマンドラインツールです。
  +
  +
=== より良いヘッダー管理 ===
  +
  +
Nginx のヘッダー管理システムはあまり直感的とは言えません。ヘッダーは特定のコンテキストでしか定義できず、他のヘッダーは無視されます。[https://github.com/openresty/headers-more-nginx-module#more_set_headers headers-more-nginx] モジュールをインストールすることでこの挙動を変更できます。
  +
  +
{{Pkg|nginx-mod-headers-more}} パッケージを[[インストール]]してください。モジュールは {{ic|/usr/lib/nginx/modules}} ディレクトリにインストールされます。
  +
  +
モジュールをロードするには以下をメインの nginx の設定ファイルに追加してください:
  +
  +
{{hc|/etc/nginx/nginx.conf|2=
  +
load_module "/usr/lib/nginx/modules/ngx_http_headers_more_filter_module.so";
  +
...
  +
}}
  +
  +
=== 基本認証 ===
  +
  +
基本認証ではパスワードファイルの作成が必要です。パスワードファイルは、{{Pkg|apache}} パッケージで提供される {{ic|htpasswd}} プログラムを使用するか、{{ic|nginx-passwd}} を提供する {{AUR|nginx_passwd}} を使用して管理できます。詳細は、次のサイトで確認できます。 [https://github.com/gene-git/nginx_passwd github ソース]
  +
  +
== トラブルシューティング ==
  +
  +
=== 設定の確認 ===
  +
  +
{{hc|# nginx -t|
  +
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
  +
nginx: configuration file /etc/nginx/nginx.conf test is successful
  +
}}
  +
  +
=== Error: The page you are looking for is temporarily unavailable. Please try again later. (502 Bad Gateway) ===
  +
  +
これは、FastCGI サーバーが起動していないか、使用されているソケットの権限が間違っているためです。
  +
  +
502 エラーを修正するには、[https://stackoverflow.com/questions/4252368/nginx-502-bad-gateway/16497957#16497957 out thisanswer] を試してください。
  +
  +
Arch Linux では、上記のリンクに記載されている設定ファイルは {{ic|/etc/php/php-fpm.conf}} です。
   
 
=== Error: No input file specified ===
 
=== Error: No input file specified ===
   
  +
1. {{ic|/etc/php/php.ini}} の変数 {{ic|open_basedir}} が {{ic|nginx.conf}} の {{ic|root} 引数に指定した正しいパスを含むことを確認します。(通常は {{ic|/usr/share/nginx/}}) です。PHP の FastCGI サーバとして [https://php-fpm.org/ PHP-FPM] を使用する場合、 {{ic|<nowiki>fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/"</nowiki>;}} を {{ic|location}} ブロックに追加し、{{ic|nginx.conf}} の php ファイル処理用に指定することができます。
おそらくスクリプトのフルパスを含んだ SCRIPT_FILENAME がありません。
 
  +
  +
2. もう 1 つは、{{ic|nginx.conf}} の {{ic|location ~ \.php$}} セクションの {{ic|root}} 引数が間違っていることです。{{ic|root}} が同じサーバー内の {{ic|location /}} と同じディレクトリを指していることを確認してください。または、root をグローバルとして設定し、location セクションで定義しないこともできます。
  +
  +
3. パーミッションの確認:例えば、ユーザー/グループは {{ic|http}} 、ディレクトリは {{ic|755}} 、ファイルは {{ic|644}} です。{{ic|html}} ディレクトリへのパス全体が正しいパーミッションを持っている必要があることを忘れないでください。ディレクトリツリーを一括で変更するには、[[ファイルのパーミッションと属性#まとめて chmod]] を参照してください。
  +
  +
4. おそらくスクリプトのフルパスを含んだ SCRIPT_FILENAME がありません。
 
nginx の設定 (fastcgi_param SCRIPT_FILENAME) が完全でも、このエラーは php が requestd スクリプトをロードできないことを意味しています。これは単純にパーミッションの問題であることが普通で、root で php-cgi を実行するか
 
nginx の設定 (fastcgi_param SCRIPT_FILENAME) が完全でも、このエラーは php が requestd スクリプトをロードできないことを意味しています。これは単純にパーミッションの問題であることが普通で、root で php-cgi を実行するか
 
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi
 
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi
565行目: 776行目:
 
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi
 
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi
   
  +
5. chrooted nginx で php-fpm を実行している場合は、{{ic|chroot}} が {{ic|/etc/php-fpm/php-fpm.d/www.conf}} (または {{ic|/etc/php-fpm/php-fpm.conf}} 古いバージョンで動作している場合)
他の可能性としては、{{ic|nginx.conf}} 内の "location ~ \.php$" セクションの "root" 引数が間違っていることがありえます。"root" が同じサーバーの "location /" と同じディレクトリを示しているか確認してください。もしくは root をグローバルに設定するには、location セクションで定義しないでください。
 
   
  +
=== Warning: Could not build optimal types_hash ===
Also keep in mind that your php script path was defined as {{ic|/srv/http}} by default using the variable "open_basedir" in {{ic|/etc/php/php.ini}}; you can change them if you need.
 
   
  +
{{ic|nginx.service}} を開始すると、プロセスによって次のメッセージが記録される場合があります。
Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.
 
   
  +
[warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
=== Error: FastCGI で空のページが表示される ===
 
   
  +
この警告を修正するには、{{ic|http}} ブロック内のこれらのキーの値を増やします [https://nginx.org/en/docs/http/ngx_http_core_module.html#types_hash_max_size] [https://nginx.org/en/docs/http/server_names.html]:
access.log にエラーが表示されず、コード200が返されるのに以下のような空のページが表示される場合:
 
   
  +
{{hc|/etc/nginx/nginx.conf|
<html>
 
  +
http {
<head></head>
 
  +
types_hash_max_size 4096;
<body></body>
 
  +
server_names_hash_bucket_size 128;
</html>
 
  +
...
  +
}
  +
}}
   
  +
=== 要求されたアドレスを割り当てることができない ===
[http://beutelevision.com/blog2/2013/08/26/nginx-with-php-fpm-generating-blank-page/ Thomas Beutel のブログ] に書かれた解決方法:
 
   
  +
{{ic|nginx.service}} [[ユニットステータス]] からの完全なエラーは次のとおりです。
{{ic|/etc/nginx/nginx.conf}} を編集して php の {{ic|location}} セクションに {{ic|fastcgi_param}} という行を追加:
 
   
  +
[emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address)
location ~ \.php$ {
 
...
 
include fastcgi_params;
 
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 
...
 
}
 
   
  +
nginx ユニットファイルが systemd を使用して {{ic|network.target}} の後に実行するように設定されている場合でも、nginx は、構成されているがどのインターフェイスにもまだ追加されていないアドレスでリッスンしようとする場合があります。 nginx の [[開始]] を手動で実行して、これが当てはまることを確認します (これにより、IP アドレスが適切に設定されていることが示されます) 任意のアドレスをリッスンするように nginx を設定すると、この問題が解決します。ユースケースで特定のアドレスをリッスンする必要がある場合、考えられる解決策の 1 つは、systemd を再構成することです。
php_fpm では PHP ファイルのパスを認識するために以上のように設定する必要があります。
 
  +
  +
設定されたすべてのネットワークデバイスが起動し、IP アドレスが割り当てられた後に nginx を起動するには、{{ic|nginx.service}} 内の {{ic|1=After=}} に {{ic|network-online.target}} を追加し、{{ic|systemd-networkd-wait-online.service}} を [[起動/有効化]] にします。
   
 
== 参照 ==
 
== 参照 ==
  +
* [http://nginx.org/ Nginx 公式サイト]
 
* [http://calomel.org/nginx.html Nginx HowTo]
+
* [[WebDAV#nginx|WebDAV with nginx]]
  +
* [https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ nginx configuration pitfalls]
* [http://wiki.gotux.net/config:nginx Easy Config Files]
 
  +
* [https://calomel.org/nginx.html Very good in-depth 2014 look at nginx security and Reverse Proxying]
* [http://www.tecmint.com/install-nginx-php-mysql-with-mariadb-engine-and-phpmyadmin-in-arch-linux/ Installing LEMP (Nginx, PHP, MySQL with MariaDB engine and PhpMyAdmin) in Arch Linux]
 
  +
* [https://www.tecmint.com/install-nginx-php-mysql-with-mariadb-engine-and-phpmyadmin-in-arch-linux/ Installing LEMP (nginx, PHP, MySQL with MariaDB engine and PhpMyAdmin) in Arch Linux]
  +
* [[Let’s Encrypt|Using SSL certificates generated with Let's Encrypt]]

2023年5月29日 (月) 03:31時点における最新版

nginx ("エンジンエックス"と発音します)は 2005 年から Igor Sysoev(ロシア)によって開発されている、フリーでオープンソースかつハイパフォーマンスな HTTP サーバーかつリバースプロクシで、IMAP/POP3 プロクシサーバーとしても機能します。Nginx は主に、その安定性・多機能・単純な設定・低リソース消費によって知られています。

この記事では nginx の設定方法と、#FastCGI を使って PHP と統合する方法を説明します。

インストール

公式リポジトリ から nginx-mainline (メインラインブランチ: 最新の機能・アップデート・修正) か nginx (安定ブランチ: 重要な修正のみを適応) のどちらかを インストール できます。

メインラインブランチを使用することをお勧めします。安定版ブランチを使う主な理由は、サードパーティ製モジュールとの非互換性や、新機能 の不注意によるバグ導入など、新機能の起こりうる影響を懸念するためです。

ノート: 公式リポジトリ で利用可能なすべての nginx モジュールは、依存関係として nginx パッケージ (nginx-mainline ではなく) を必要とします。nginxnginx-mainline かを決定する前に、必要なモジュールのリストを確認することをお勧めします。nginx-mainline のモジュールは Arch User Repository にあります。

セキュリティを向上させるために chroot によるインストールをするには、chroot でインストール を参照してください。

サービスの開始

nginx.service起動/有効化します。

http://127.0.0.1 で提供されるデフォルトのページは、/usr/share/nginx/html/index.html です。

設定

nginx における最初の手順は 公式のビギナーズガイド で説明されています。/etc/nginx/ にあるファイルを編集することで Nginx の設定ができます。メインの設定ファイルは /etc/nginx/nginx.conf です。

より詳しい解説は、公式の ドキュメント にある Nginx Configuration Examples にあります。

以下の例は、最も一般的な使用例をカバーしています。ここでは、ドキュメントのデフォルトの場所 (/usr/share/nginx/html) を使用することを想定しています。そうでない場合は、代わりにあなたのパスを指定してください。

ヒント: DigitalOcean から Nginx configuration tool が提供されています。

設定例

/etc/nginx/nginx.conf
user http;
worker_processes auto;
worker_cpu_affinity auto;

events {
    multi_accept on;
    worker_connections 1024;
}

http {
    charset utf-8;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    server_tokens off;
    log_not_found off;
    types_hash_max_size 4096;
    client_max_body_size 16M;

    # MIME
    include mime.types;
    default_type application/octet-stream;

    # logging
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log warn;

    # load configs
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

一般設定

プロセス数とコネクション数

worker_processes の適当な値を探って下さい。この設定は最終的に nginx が受け入れる接続の数と利用できるプロセスの数を定義します。通常、システムのハードウェアのスレッド数にすると良いでしょう。また、バージョン 1.3.8 と 1.2.5 から worker_processes には auto と設定することができ、最適な値を自動的に検出します (ソース)。

nginx が受け入れる最大接続数は max_clients = worker_processes * worker_connections で計算できます。

別のユーザーで実行する

デフォルトでは、nginx はマスタープロセスを root で、ワーカープロセスを http ユーザで実行します。ワーカープロセスを別のユーザで実行するには、nginx.confuser ディレクティブを変更します。

/etc/nginx/nginx.conf
user user [group];

group が省略された場合は、user と同じ名前のグループが使用されます。

ヒント: systemd を使って root で何もせずに nginx を動かすことも可能です。#systemd を使って非特権で動作させるを参照してください。

サーバーブロック

server ブロックを使うことで複数のドメインを利用することができます。"バーチャルホスト"とも呼ばれますが、これは Apache の用語です。server ブロックの利用方法は Apache とは異なっています。upstream examples も参照してください。

以下の例では2つのドメインの接続をサーバーが待機します: domainname1.domdomainname2.dom:

/etc/nginx/nginx.conf
...
server {
        listen 80;
        server_name domainname1.dom;
        root /usr/share/nginx/domainname1.dom/html;
        location / {
           index index.php index.html index.htm;
        }
}

server {
        listen 80;
        server_name domainname2.dom;
        root /usr/share/nginx/domainname2.dom/html;
        ...
}
...
}

nginx.service再起動して変更を適用します。

クライアントからの接続時にこれらのドメイン名を解決するには、BINDdnsmasq などのDNSサーバーを設定する必要があります。

ローカルマシンでバーチャルホストをテストするには、/etc/hosts ファイルにバーチャルネームを追加してください:

127.0.0.1 domainname1.dom 
127.0.0.1 domainname2.dom
サーバーエントリの管理

異なる server ブロックを異なるファイルに配置することができます。これにより、特定のサイトを簡単に有効または無効にできます。

次のディレクトリを作成します。

# mkdir /etc/nginx/sites-available
# mkdir /etc/nginx/sites-enabled

sites-available ディレクトリに、一つ以上のサーバーブロックを含むファイルを作成します。

/etc/nginx/sites-available/example.conf
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ...
}

http ブロックの最後に、include sites-enabled/*; を追加します。

/etc/nginx/nginx.conf
http {
    ...
    include sites-enabled/*;
}

サイトを有効にするには、シンボリックリンクを作成するだけです。

# ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf

サイトを無効にするには、アクティブなシンボリックリンクのリンクを解除します。

# unlink /etc/nginx/sites-enabled/example.conf

nginx.serviceリロード/再起動 して、サイト設定の変更を有効にします。

TLS

OpenSSL は TLS をサポートし、Arch のインストール時にデフォルトでインストールされます。

ヒント:
  • SSL を設定する前に ngx_http_ssl_module のドキュメントを読むことを推奨します。
  • Let’s Encrypt は無料の、自動化されたオープンな証明局です。コマンドラインおよび自動設定から直接有効な SSL 証明書を要求するプラグインを利用可能です。
  • Mozilla には、便利な TLS 記事自動化ツール があります。より安全な設定を作成するのに役立ちます。
警告: SSL/TLS の実装を計画している場合は、一部のバリエーションと実装は まだ 攻撃に対して脆弱 であることを知っておいてください。SSL/TLS 内の現在の脆弱性の詳細と、nginx に適切な変更を適用する方法については、http://disablessl3.com/ および https://weakdh.org/sysadmin.html を参照してください。

秘密キーと自己署名証明書を作成します。CSR を必要としないほとんどのインストールにはこれで十分です。

# mkdir /etc/nginx/ssl
# cd /etc/nginx/ssl
# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 1095
# chmod 400 server.key
# chmod 444 server.crt
ノート: -days スイッチはオプションであり、RSA キーサイズは 2048 (デフォルト) まで小さくできます。

CSR を作成する必要がある場合は、上記の代わりに次の手順に従ってください。

# mkdir /etc/nginx/ssl
# cd /etc/nginx/ssl
# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key
# chmod 400 server.key
# openssl req -new -sha256 -key server.key -out server.csr
# openssl x509 -req -days 1095 -in server.csr -signkey server.key -out server.crt
ノート: その他の openssl オプションについては、マニュアル ページ openssl(1ssl) を読むか、豊富なドキュメント を熟読してください。

TLS を使用した /etc/nginx/nginx.conf の開始点は、Mozilla の SSL 設定ジェネレーター です。

nginx.service再起動 して変更内容を反映させます。

ユーザーごとのディレクトリ

Apache スタイルの ~user URL をユーザーの ~/public_html ディレクトリに複製するには、次の手順を試してください。(注: 両方のルールを使用する場合、以下では、より具体的な PHP ルールを最初に置く必要があります。)

/etc/nginx/nginx.conf
...
server {
    ...
    # PHP in user directories, e.g. http://example.com/~user/test.php
    location ~ ^/~(.+?)(/.+\.php)$ {
        alias          /home/$1/public_html$2;
        fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
        fastcgi_index  index.php;
        include        fastcgi.conf;
    }

    # User directories, e.g. http://example.com/~user/
    location ~ ^/~(.+?)(/.*)?$ {
        alias     /home/$1/public_html$2;
        index     index.html index.htm;
        autoindex on;
    }
    ...
}
...

nginx を使用した PHP 設定の詳細については、PHP を動かす を参照してください。

nginx.service再起動 して新しい設定を有効にします。

FastCGI

FastCGI、または FCGI はウェブサーバーでインタラクティブなプログラムを動作させるためのプロトコルです。FastCGI は Common Gateway Interface (CGI) の変種で、ウェブサーバーと CGI プログラムのオーバーヘッドを減らすよう設計されていて、サーバーはより多くのウェブページのリクエストを一度に捌くことができます。

Nginx には FastCGI が組み込まれており多くの外部ツールが動きます、例えば Perl、PHPPython など。これらを使うためにはまず FastCGI サーバーを動かす必要があります。

PHP を動かす

PHP のために FastCGI サーバーを動かす方法は複数あります。ここでは推奨方法として php-fpm を使う方法を記載しています。

手順1: PHP の設定

php をインストールしてください。/etc/php/php.ini の中にある open_basedir に PHP ファイルが含まれているベースディレクトリを (/srv/http//usr/share/webapps/ のような感じで)指定しなくてはなりません:

open_basedir = /usr/share/webapps/:/srv/http/:/home/:/tmp/:/usr/share/pear/

そうしたら必要なモジュールを設定しましょう。例えば sqlite3 を使うなら php-sqlite をインストールして、/etc/php/php.ini の次の行をアンコメントして有効にします:

extension=sqlite3.so
ノート: chroot 環境で nginx を動かしている場合 (chroot は /srv/nginx-jail で、ウェブページは /srv/nginx-jail/www) です。/etc/php/php-fpm.conf ファイルを編集して chroot /srv/nginx-jaillisten = /srv/nginx-jail/run/php-fpm/php-fpm.sock ディレクティブを pool セクション (デフォルトは [www]) の中に記述する必要があります。ソケットファイルのディレクトリが存在しない場合は作成してください。
MariaDB

MariaDB で説明されているようにして MySQL/MariaDB を設定してください。

/etc/php/php.ini の以下の行の 少なくともどれか一つ をアンコメント:

extension=pdo_mysql.so
extension=mysqli.so
警告: PHP 5.5 から、mysql.so廃止 されログファイルにエラーが表示されます。

ウェブスクリプトのために最小権限の MySQL ユーザーを追加することができます。また、/etc/mysql/my.cnf を編集して skip-networking 行をアンコメントすると MySQL サーバーはローカルホストからしかアクセスできなくなります。変更を適用するには MySQL を再起動する必要があります。

ヒント: データベースを利用するために phpMyAdmin, Adminer, mysql-workbench などのツールをインストールしても良いでしょう。
手順2: php-fpm

php-fpm をインストールします:

# pacman -S php-fpm

設定ファイルは /etc/php/php-fpm.conf です。

サービスを動かします:

# systemctl start php-fpm

php-fpm をスタートアップ時に有効にします:

# systemctl enable php-fpm.service
手順3: Nginx の設定

それぞれの server ブロックの中の location ブロックに PHP アプリケーションを次のように記述します:

location ~ \.php$ {
     fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
     fastcgi_index  index.php;
     include        fastcgi.conf;
}

/etc/nginx/php.conf を作って設定をそこに書く場合、このファイルを server ブロックに入れて下さい。

server = {
    ...
    include  php.conf;
    ...
}

.html や .htm ファイルを PHP として処理したい場合は、以下のようにしてください:

location ~ \.(php|html|htm)$ {
     fastcgi_pass  unix:/run/php-fpm/php-fpm.sock;
     fastcgi_index  index.php;
     include        fastcgi.conf;
}

拡張子が .php でないファイルを php-fpm で動かすことを /etc/php/php-fpm.conf で有効にする必要があります:

security.limit_extensions = .php .html .htm

設定を変えた後は php-fpm デーモンを再起動してください。

# systemctl restart php-fpm
ノート: fastcgi_pass 引数に注意を払って下さい、FastCGI サーバーの設定ファイルで定義された TCP や Unix ソケットでなくてはなりません。デフォルトの php-fpm (Unix) ソケットは
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;

デフォルトの代わりに、通常の TCP ソケットを使うこともできます

fastcgi_pass 127.0.0.1:9000;
ただし Unix ドメインソケットの方が高速です。

Nginx のための FastCGI 設定がある fastcgi.conffastcgi_params が含まれていますが、後者は使われなくなりました。これらのファイルは Nginx をインストールしたときに作られます。

最後に、Nginx が動作している場合は再起動してください:

# systemctl restart nginx

FastCGI をテストしたい場合は、/usr/share/nginx/html/index.php を次の内容で作成して

<?php
  phpinfo();
?> 

ブラウザで http://127.0.0.1/index.php を開いて下さい。

以下は実際の設定例です。例の中では root パスは server の下に直接指定されており (デフォルト設定のように) location の中には置いていません。

server {
    listen 80;
    server_name localhost;
    root /usr/share/nginx/html;
    location / {
        index index.html index.htm index.php;
    }

    location ~ \.php$ {
        #fastcgi_pass 127.0.0.1:9000; (depending on your php-fpm socket configuration)
        fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        include fastcgi.conf;
    }
}

CGI を動かす

この実装は CGI アプリケーションに必要です。

手順1: fcgiwrap

fcgiwrap をインストールしてください。 設定ファイルは /usr/lib/systemd/system/fcgiwrap.socket です。 systemdfcgiwrap.socket を有効化・起動します。

この systemd ユニットファイルは現在 ArchLinux のタスクページで議論されています。思い通りに動くか確認するためにユニットファイルを自分で検査すると良いでしょう。

マルチワーカースレッド

複数のワーカースレッドを生成したい場合は、multiwatchAUR を使用するのが推奨されています。これはクラッシュした子スレッドの再起動の面倒をみてくれます。multiwatch は systemd が作成したソケットを管理できないため、unix ソケットを作成するには spawn-fcgi を使う必要がありますが、ユニットファイルから直接実行した場合は fcgiwrap には問題が生じません。

/usr/lib/systemd/system/fcgiwrap.service から /etc/systemd/system/fcgiwrap.service にユニットファイルをコピーして (存在する場合は fcgiwrap.socket ユニットも)、ExecStart 行を必要に応じて修正してください。以下は multiwatchAUR を使用するユニットファイルです。fcgiwrap.socket が実行中だったり有効になっていないことを確認してください、このユニットと衝突してしまうからです:

/etc/systemd/system/fcgiwrap.service
[Unit]
Description=Simple CGI Server
After=nss-user-lookup.target

[Service]
ExecStartPre=/bin/rm -f /run/fcgiwrap.socket
ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap
ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock
PrivateTmp=true
Restart=on-failure

[Install]
WantedBy=multi-user.target

-f 10 は生成する子スレッドの数に変更してください。

警告: spawn-fcgi-M 660 オプションを使用すると奇妙な動作が発生するため、ExecStartPost 行が必要です。間違ったモードが設定されています。これはバグかもしれません?
nginx の設定

/etc/nginx で、ファイル fastcgi_paramsfcgiwrap_params にコピーします。fcgiwrap_params で、SCRIPT_NAMEDOCUMENT_ROOT を設定する行をコメント化するか削除します。

CGI Web アプリケーションを提供する各 server ブロック内には、次のような location ブロックが表示されます。

location ~ \.cgi$ {
     include       fcgiwrap_params;
     fastcgi_param DOCUMENT_ROOT /srv/www/cgi-bin/;
     fastcgi_param SCRIPT_NAME   myscript.cgi;
     fastcgi_pass  unix:/run/fcgiwrap.sock;
}

fcgiwrap のデフォルトのソケットファイルは /run/fcgiwrap.sock です。

fastcgi_param SCRIPT_FILENAME /srv/www/cgi-bin/myscript.cgi を使用することは、DOCUMENT_ROOTSCRIPT_NAME を設定する代わりのショートカットです。 SCRIPT_FILENAME を使用する場合は、fastcgi_paramsfcgiwrap_params にコピーして、DOCUMENT_ROOTSCRIPT_NAME 行をコメントアウトする必要もありません。

警告: SCRIPT_NAME と DOCUMENT_ROOT が使用されている場合、fcgiwrap は nginx に設定されている他の fastcgi_params を 破棄 します。他のパラメータ (PATH_INFO など) を Nginx 設定を通じて設定できるようにするには、SCRIPT_FILENAME を使用する必要があります。GitHub の問題を参照してください

502 - bad Gateway エラーが繰り返し発生する場合は、CGI アプリケーションが最初に次のコンテンツの MIME タイプをアナウンスするかどうかを確認する必要があります。HTML の場合、これは Content-type: text/html である必要があります。

403 エラーが発生した場合は、CGI 実行可能ファイルが http ユーザーによって読み取りおよび実行可能であること、およびすべての親フォルダーが http ユーザーによって読み取り可能であることを確認してください。

chroot でインストール

chroot に Nginx をインストールすることでセキュリティレイヤーを追加することができます。セキュリティを最大限に高めるために、Nginx サーバーを動かすのに必要なファイルだけを入れて、全てのファイルは出来る限り最小限の権限にします。例えば、なるべく root が所有するようにして、/usr/bin などのディレクトリは読み書きできないようにするなど。

Arch はデフォルトでサーバーを実行するための http ユーザーとグループが設定されています。chroot は /srv/http で動作させます。

この牢獄を作るための perl スクリプトが jail.pl gist にあります。このスクリプトを使用するか、またはこの記事の指示に従って作成するか選ぶことができます。スクリプトは root で実行してください。変更を適用する前に行をアンコメントする必要があります。

必要なデバイスを作成

Nginx には /dev/null, /dev/random, /dev/urandom が必要です。これらを chroot にインストールするために /dev/ フォルダを作成してデバイスを mknod で追加します。chroot が危険になったときでも、攻撃者が /dev/sda1 などの重要なデバイスにアクセスするには chroot から脱出しなくてはならないようにするために、/dev/ を全てマウントはしません。

ヒント: mknod の引数については man mknodls -l /dev/{null,random,urandom} を見て下さい。
# export JAIL=/srv/http
# mkdir $JAIL/dev
# mknod -m 0666 $JAIL/dev/null c 1 3
# mknod -m 0666 $JAIL/dev/random c 1 8
# mknod -m 0444 $JAIL/dev/urandom c 1 9

必要なフォルダを作成

Nginx を適切に実行するためにはたくさんのファイルが必要になります。それらをコピーする前に、ファイルを保存するためのフォルダを作成してください。ここでは Nginx のドキュメントルートが /srv/http/www であると仮定します。

# mkdir -p $JAIL/etc/nginx/logs
# mkdir -p $JAIL/usr/{lib,bin}
# mkdir -p $JAIL/usr/share/nginx
# mkdir -p $JAIL/var/{log,lib}/nginx
# mkdir -p $JAIL/www/cgi-bin
# mkdir -p $JAIL/{run,tmp}
# cd $JAIL; ln -s usr/lib lib 
ノート: 64ビットのカーネルを使っている場合 usr/liblib64usr/lib64 のシンボリックリンクを作成する必要があります: cd $JAIL; ln -s usr/lib lib64cd $JAIL/usr; ln -s lib lib64

そして $JAIL/tmp$JAIL/run を tmpfs でマウントします。攻撃者が RAM を全て喰いつくせないようにサイズを制限すると良いでしょう。

# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M'
# mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'

再起動してもマウントが維持されるように、以下のエントリを /etc/fstab に追加します:

/etc/fstab
 tmpfs   /srv/http/run   tmpfs   rw,noexec,relatime,size=1024k   0       0
 tmpfs   /srv/http/tmp   tmpfs   rw,noexec,relatime,size=102400k 0       0

chroot に移住

まず平易なファイルをコピーします。

# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx
# cp -r /usr/share/nginx/html/* $JAIL/www
# cp /usr/bin/nginx $JAIL/usr/bin/
# cp -r /var/lib/nginx $JAIL/var/lib/nginx

そして必要なライブラリをコピーします。ldd を使ってライブラリを確認して適当な場所にコピーして下さい。ハードリンクよりはコピーが推奨されます。攻撃者が書き込み権限を得たときに本当のシステムファイルが破壊されたり改変される可能性があるためです。

$ ldd /usr/bin/nginx
   linux-vdso.so.1 (0x00007fffc41fe000)
   libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000)
   libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000)
   libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000)
   libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000)
   libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000)
   libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000)
   libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000)
   libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000)
   libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000)
   libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000)
   libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000)
   libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000)
   /lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib

/usr/lib の中にあるファイルについては次のワンライナーが使えます:

# cp $(ldd /usr/bin/nginx | grep /usr/lib | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib
ノート: linux-vdso.so をコピーしないでください – 実際のライブラリではなく /usr/lib には存在しません。64ビット環境の場合 ld-linux-x86-64.so/lib64 にあるように表示されます。

必要なライブラリとシステムファイル以外のファイルをコピーします。

# cp /usr/lib/libnss_* $JAIL/usr/lib
# cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc

chroot のために制限を付けたユーザー・グループファイルを作成します。これにより chroot にアクセスするのに必要なシステムユーザー・グループが攻撃者に漏洩しなくなります。

$JAIL/etc/group
http:x:33:
nobody:x:99:
$JAIL/etc/passwd
http:x:33:33:http:/:/bin/false
nobody:x:99:99:nobody:/:/bin/false
$JAIL/etc/shadow
http:x:14871::::::
nobody:x:14871::::::
$JAIL/etc/gshadow
http:::
nobody:::
# touch $JAIL/etc/shells
# touch $JAIL/run/nginx.pid

最後にパーミッションをできるだけ制限的に設定してください。できるかぎり所有者を root にして書き込み不可にします。

# chown -R root:root $JAIL/
 
# chown -R http:http $JAIL/www
# chown -R http:http $JAIL/etc/nginx
# chown -R http:http $JAIL/var/{log,lib}/nginx
# chown http:http $JAIL/run/nginx.pid
 
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod -rw
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod +x
# find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs sudo chmod -x
# find $JAIL/usr/bin -type f -print | xargs sudo chmod ug+rx
# find $JAIL/ -group http -user http -print | xargs sudo chmod o-rwx
# chmod +rw $JAIL/tmp
# chmod +rw $JAIL/run

サーバーがポート 80 (あるいは 0-1024 のどれかのポート) で待機する場合、chroot した実行ファイルに root 権限がなくてもポートを使えるように権限を与えてください:

# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx

nginx.service を変更して chroot を起動

nginx.service ユニットファイルを編集する前に、ユニットファイルを /etc/systemd/system/ にコピーして /usr/lib/systemd/system/ のファイルよりも優先されるようにすると良いでしょう。nginx をアップグレードしたときにカスタムした .service ファイルが変更されなくなります。

# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service

chroot で nginx を起動するために systemd ユニットを変更して、pid ファイルを chroot に保存します。

ノート: pid ファイルを chroot ジェイルに保存する必要があるかどうかはわかりません。
/etc/systemd/system/nginx.service
 [Unit]
 Description=A high performance web server and a reverse proxy server
 After=syslog.target network.target
 
 [Service]
 Type=forking
 PIDFile=/srv/http/run/nginx.pid
 ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;'
 ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;'
 ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload
 ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit
 
 [Install]
 WantedBy=multi-user.target
ノート: pacman を使用して nginx をアップグレードしても、chroot された nginx インストールはアップグレードされません。上記の手順の一部を繰り返して、手動で更新を行う必要があります。リンク先のライブラリも忘れずに更新してください。

chroot されていない nginx 環境は取り除いてもかまいません:

# pacman -Rsc nginx

chroot されていない nginx 環境を削除しない場合、実行中の nginx プロセスが chroot されているプロセスかどうか確認したくなるときがあるかもしれません。/proc/PID/root シンボリックリンクを確認することでチェックできます。

# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done

ヒントとテクニック

systemd を使用したユーザーサービスの実行

権限のないユーザーが完全に制御して構成できるサーバーインスタンスを実行したい場合は、nginx-user-serviceAUR の使用を検討してください。

systemd を使って非特権で動作させる

nginx.serviceドロップインファイルを使用して、[Service] の下の User と任意で Group を設定します。

/etc/systemd/system/nginx.service.d/user.conf
[Service]
User=user
Group=group

権限昇格に対してサービスを防御することができます:

/etc/systemd/system/nginx.service.d/user.conf
[Service]
...
NoNewPrivileges=yes
ヒント: 制限オプションについて詳しくは systemd.exec(5) を見てください。

それから user が必要なファイルやポートにアクセスできるようにしてください。以下の項目に従って、nginx を起動します。

ヒント: FastCGI サーバー でも同じ設定が望ましい場合があります。

ポート

Linux はデフォルトでは root 以外が 1024 以下のポートを使うことができないようになっています。1024 よりも上のポートは使うことができます:

/etc/nginx/nginx.conf
server {
        listen 8080;
}
ヒント: nginx にポート 80 あるいは 443 からアクセスできるようにしたい場合、ファイアウォールを設定して 80 あるいは 443 から nginx が listen しているポートに転送してください。
また、nginx プロセスに CAP_NET_BIND_SERVICE ケイパビリティを付与することで 1024 以下のポートにバインドできるようになります:
/etc/systemd/system/nginx.service.d/user.conf
[Service]
...
CapabilityBoundingSet=
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=
AmbientCapabilities=CAP_NET_BIND_SERVICE

PID ファイル

nginx はデフォルトでは /run/nginx.pid を使います。user が書き込み可能なディレクトリを作成して PID ファイルをそこに配置します。systemd-tmpfiles を使用する例:

/etc/tmpfiles.d/nginx.conf
d /run/nginx 0775 root group - -

設定を実行:

# systemd-tmpfiles --create

元の nginx.service に合わせて PID の値を編集:

/etc/systemd/system/nginx.service.d/user.conf
[Service]
...
PIDFile=/run/nginx/nginx.pid
ExecStart=
ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' 
ExecReload=
ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid;'

/var/lib/nginx

nginx は、デフォルトで一時ファイルを /var/lib/nginx に保存するようにコンパイルされます。

ヒント: $ nginx -V を実行して、すべてのコンパイル済みオプションを表示します

たとえば、StateDirectory (systemd.exec(5)) を使用して、ユーザー にこのディレクトリへの書き込みアクセス権を与えることができます。

/etc/systemd/system/nginx.service.d/user.conf
[Service]
...
StateDirectory=nginx

/var/log/nginx

nginx は、デフォルトでアクセスログを /var/log/nginx に保存するようにコンパイルされます。

たとえば、LogsDirectory (systemd.exec(5)) を使用して、ユーザー にこのディレクトリへの書き込みアクセス権を与えることができます。

/etc/systemd/system/nginx.service.d/user.conf
[Service]
...
LogsDirectory=nginx

systemd の別のスクリプト

純粋な systemd では、chroot + systemd の利点を得ることができます。[1] セット ユーザーグループ と pid に基づいて次のようにします。

/etc/nginx/nginx.conf
user http;
pid /run/nginx.pid;

ファイルの絶対パスは /srv/http/etc/nginx/nginx.conf です。

/etc/systemd/system/nginx.service
[Unit]
Description=nginx (Chroot)
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/srv/http/run/nginx.pid
RootDirectory=/srv/http
ExecStartPre=/usr/bin/nginx -t -c /etc/nginx/nginx.conf
ExecStart=/usr/bin/nginx -c /etc/nginx/nginx.conf
ExecReload=/usr/bin/nginx -c /etc/nginx/nginx.conf -s reload
ExecStop=/usr/bin/nginx -c /etc/nginx/nginx.conf -s stop

[Install]
WantedBy=multi-user.target

デフォルトの場所を設定する必要はありません。nginx はデフォルトでロードされます。 -c /etc/nginx/nginx.conf ですが、これは良い考えです。

あるいは、パラメータ RootDirectoryStartOnlyyes に設定して chroot として only ExecStart を実行することもできます。(systemd.service(5) を参照) またはマウントポイントが有効になる前、または systemd パス (systemd.path(5) を参照) が利用可能になる前に起動します。

/etc/systemd/system/nginx.path
[Unit]
Description=nginx (Chroot) path
[Path]
PathExists=/srv/http/site/Public_html
[Install]
WantedBy=default.target

作成された nginx.path有効化 し、WantedBy=default.targetWantedBy=nginx.path に変更します|/etc/systemd/system/nginx.service}}

ユニットファイル内の PIDFile により、systemd がプロセスを監視できるようになります (絶対パスが必要です) 望ましくない場合は、デフォルトのワンショットタイプに変更し、ユニットファイルから参照を削除できます。

Nginx Beautifier

nginxbeautifierAUR は nginx の設定ファイルを整形することができるコマンドラインツールです。

より良いヘッダー管理

Nginx のヘッダー管理システムはあまり直感的とは言えません。ヘッダーは特定のコンテキストでしか定義できず、他のヘッダーは無視されます。headers-more-nginx モジュールをインストールすることでこの挙動を変更できます。

nginx-mod-headers-more パッケージをインストールしてください。モジュールは /usr/lib/nginx/modules ディレクトリにインストールされます。

モジュールをロードするには以下をメインの nginx の設定ファイルに追加してください:

/etc/nginx/nginx.conf
load_module "/usr/lib/nginx/modules/ngx_http_headers_more_filter_module.so";
...

基本認証

基本認証ではパスワードファイルの作成が必要です。パスワードファイルは、apache パッケージで提供される htpasswd プログラムを使用するか、nginx-passwd を提供する nginx_passwdAUR を使用して管理できます。詳細は、次のサイトで確認できます。 github ソース

トラブルシューティング

設定の確認

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Error: The page you are looking for is temporarily unavailable. Please try again later. (502 Bad Gateway)

これは、FastCGI サーバーが起動していないか、使用されているソケットの権限が間違っているためです。

502 エラーを修正するには、out thisanswer を試してください。

Arch Linux では、上記のリンクに記載されている設定ファイルは /etc/php/php-fpm.conf です。

Error: No input file specified

1. /etc/php/php.ini の変数 open_basedirnginx.conf の {{ic|root} 引数に指定した正しいパスを含むことを確認します。(通常は /usr/share/nginx/) です。PHP の FastCGI サーバとして PHP-FPM を使用する場合、 fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";location ブロックに追加し、nginx.conf の php ファイル処理用に指定することができます。

2. もう 1 つは、nginx.conflocation ~ \.php$ セクションの root 引数が間違っていることです。root が同じサーバー内の location / と同じディレクトリを指していることを確認してください。または、root をグローバルとして設定し、location セクションで定義しないこともできます。

3. パーミッションの確認:例えば、ユーザー/グループは http 、ディレクトリは 755 、ファイルは 644 です。html ディレクトリへのパス全体が正しいパーミッションを持っている必要があることを忘れないでください。ディレクトリツリーを一括で変更するには、ファイルのパーミッションと属性#まとめて chmod を参照してください。

4. おそらくスクリプトのフルパスを含んだ SCRIPT_FILENAME がありません。 nginx の設定 (fastcgi_param SCRIPT_FILENAME) が完全でも、このエラーは php が requestd スクリプトをロードできないことを意味しています。これは単純にパーミッションの問題であることが普通で、root で php-cgi を実行するか

# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi

php-cgi を起動するグループとユーザーを作成する必要があります。例えば:

# groupadd www
# useradd -g www www
# chmod +w /srv/www/nginx/html
# chown -R www:www /srv/www/nginx/html
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi

5. chrooted nginx で php-fpm を実行している場合は、chroot/etc/php-fpm/php-fpm.d/www.conf (または /etc/php-fpm/php-fpm.conf 古いバージョンで動作している場合)

Warning: Could not build optimal types_hash

nginx.service を開始すると、プロセスによって次のメッセージが記録される場合があります。

[warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size

この警告を修正するには、http ブロック内のこれらのキーの値を増やします [2] [3]:

/etc/nginx/nginx.conf
http {
    types_hash_max_size 4096;
    server_names_hash_bucket_size 128;
    ...
}

要求されたアドレスを割り当てることができない

nginx.service ユニットステータス からの完全なエラーは次のとおりです。

[emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address)

nginx ユニットファイルが systemd を使用して network.target の後に実行するように設定されている場合でも、nginx は、構成されているがどのインターフェイスにもまだ追加されていないアドレスでリッスンしようとする場合があります。 nginx の 開始 を手動で実行して、これが当てはまることを確認します (これにより、IP アドレスが適切に設定されていることが示されます) 任意のアドレスをリッスンするように nginx を設定すると、この問題が解決します。ユースケースで特定のアドレスをリッスンする必要がある場合、考えられる解決策の 1 つは、systemd を再構成することです。

設定されたすべてのネットワークデバイスが起動し、IP アドレスが割り当てられた後に nginx を起動するには、nginx.service 内の After=network-online.target を追加し、systemd-networkd-wait-online.service起動/有効化 にします。

参照