Linuxを使用した経験はありますが、nginxを使用した経験はありません。私は、アプリケーションサーバーの負荷分散オプションの研究を任されています。

私はapt-getを使用してnginxをインストールしましたが、すべてうまくいきました。

いくつか質問があります。

サイトで使用可能なフォルダーとconf.dフォルダーの違いは何ですか。これらのフォルダーは両方とも、nginxのデフォルト構成セットアップに含まれていました。チュートリアルでは両方を使用します。それらは何のためにあり、ベストプラクティスは何ですか？

サイト対応フォルダーは何に使用されますか？どうやって使うの？

デフォルト設定はwww-dataユーザーを参照しますか？そのユーザーを作成する必要がありますか？そのユーザーにnginxを実行するための最適な許可を与えるにはどうすればよいですか？

sites- *フォルダはによって管理されているnginx_ensiteとnginx_dissite。これを検索で見つけるApache httpdユーザーの場合、同等の値はa2ensite/ a2dissiteです。

このsites-availableフォルダーは、現在有効になっているかどうかにかかわらず、すべてのvhost設定を保存するためのものです。

このsites-enabledフォルダーには、サイトで使用可能なフォルダー内のファイルへのシンボリックリンクが含まれています。これにより、シンボリックリンクを削除して仮想ホストを選択的に無効にできます。

conf.d仕事をしますが、何かを無効にする必要がある場合は、フォルダから何かを移動、削除、または変更する必要があります。sites- *フォルダーの抽象化により、物事が少し整理され、個別のサポートスクリプトで管理できます。

（あなたが私のようではなく、スクリプトについて知らずにシンボリックリンクを直接管理したばかりの多くのdebian管理者の1人でない限り...）

これまでの回答に加えて、最も重要なのはディレクトリの呼び出し方法ではなく（非常に便利な規則ですが）、実際に何を入れるかですnginx.conf。設定例：

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

ここで使用される唯一のディレクティブはincludeであるため、eg conf.d/との間に内部的な違いはありませんsites-enabled/。

上記のドキュメントから：

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

したがって、元の質問に答えるには、内部的な違いはありません。他の回答からのアドバイスを覚えて、できる限り最善の方法で使用できます。そして、「正しい」答えを選ぶことを忘れないでください。

通常、sites-enabledフォルダーは仮想ホストの定義にconf.d使用され、グローバルサーバーの構成に使用されます。複数のWebサイト（つまり、仮想ホスト）をサポートしている場合、それぞれが独自のファイルを取得するので、ファイルを出し入れするsites-enabled（またはシンボリックリンクを作成および削除する）ことで、簡単に有効化および無効化できます。より良いアイデア）。

使用するconf.dモジュールのロード、ログファイル、および単一の仮想ホストに固有ではない他のもののようなもののために。

デフォルト設定はwww-dataユーザーを参照しますか？そのユーザーを作成する必要がありますか？

非rootユーザーとしてnginxを実行する必要があります。これは場合によっては名前www-dataが付けられますが、好きな名前を付けることができます。

そのユーザーにnginxを実行するための最適な許可を与えるにはどうすればよいですか？

私はこの質問に対する答えが確かではありません（現時点ではnginxを実行していません）が、Apacheのようなものであれば、www-dataユーザーは静的ファイルへの読み取り権限のみが必要です（およびディレクトリで読み取り+実行）提供していること、またはCGIスクリプトなどのアクセス許可を読み取り/実行し、それ以外のアクセス許可はありません。

どうしたの？

以来、あなたは、DebianやUbuntuのを使用している必要があり悪 sites-available / sites-enabledロジックはで使用されていないのnginxの上流のパッケージからhttp://nginx.org/packages/。

いずれの場合も、両方の標準includeディレクティブを使用して、構成規則として実装されます/etc/nginx/nginx.conf。

ここでの抜粋です/etc/nginx/nginx.confnginx.orgからのnginxの公式上流のパッケージからは：

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/nginx.confDebian / Ubuntuの抜粋は次のとおりです。

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

そのため、NGINXの観点から見ると、唯一の違いは、ファイルがよりconf.d早く処理されることです。したがって、互いに静かに競合する構成がある場合、の構成がの構成conf.dより優先されsites-enabledます。

ベストプラクティスはですconf.d。

を使用する必要があり/etc/nginx/conf.dます。これは標準の規則であり、どこでも動作するはずです。

サイトを無効にする必要がある場合は、ファイル名を.confサフィックスがなくなるように名前を変更するだけで、非常に簡単でわかりやすく、エラーが発生しません。

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

または、サイトを有効にするための反対：

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

避けてくださいsites-available＆sites-enabledすべてのコストで。

sites-available/ を使用する理由はまったくありませんsites-enabled。

• 一部の人々はスクリプトに言及nginx_ensiteしnginx_dissiteました-これらのスクリプトの名前はこの大惨事の残りの部分よりもさらに悪いです-しかしこれらのスクリプトはどこにも見つかりませんnginx-Debian（そしておそらくUbuntuでも）にもパッケージにはありません、独自のパッケージに含まれていない、さらに、2つのディレクトリ間でファイルを移動および/またはリンクするために、非標準のサードパーティスクリプト全体が本当に必要ですか？

• スクリプトを使用していない場合（実際、上記のように賢い選択です）、サイトをどのように管理するかという問題が発生します。

  • からsites-availableへのシンボリックリンクを作成しますsites-enabledか？
  • ファイルをコピーしますか？
  • ファイルを移動しますか？
  • の場所でファイルを編集しますsites-enabledか？

上記は、数人または数人がシステムの管理を開始するまで、またはあなたが迅速な決定を下すまで、数ヶ月または数年後にそれを忘れるまで、取り組むべきいくつかの小さな問題のように見えるかもしれません...

これにより、次のことが可能になります。

• からファイルを削除しても安全sites-enabledですか？ソフトリンクですか？ハードリンク？または、構成の唯一のコピー？構成地獄の典型的な例。

• どのサイトが無効になっていますか？（有conf.dだけで終わらないファイルのための反転検索を行う、.conf- find /etc/nginx/conf.d -not -name "*.conf"、または使用しますgrep -v。）

だけでなく、上記のすべてが、また、具体的な注意includeのDebian / Ubuntuので使用されるディレクティブを- /etc/nginx/sites-enabled/*-何のファイル名の拡張子が指定されていないsites-enabledためとは異なり、conf.d。

• これが意味する1日すばやくファイルまたは2内を編集することにした場合ということです/etc/nginx/sites-enabled、そしてあなたはemacs、バックアップファイルなどを作成しdefault~、その後、突然、あなたは両方を持っているdefaultし、default~使用ディレクティブを依存し、さえ得られない可能性がある、アクティブな構成として含ま警告が表示され、長時間のデバッグセッションが発生します。（はい、それは私に起こりました;それはハッカソンの間でした、そして私は私のconfがうまくいかなかった理由に完全に戸惑いました。）

したがって、私はそれsites-enabledが純粋な悪であると確信しています！