常連

### 実現したいこと
HSTSの脆弱性(RFC 6797 HTTP Strict Transport Security)を是正したい。
curlコマンドの結果にHSTSヘッダーが表示されるようにしたい。

### 発生している問題・分からないこと
(RHEL8)
以下の設定をnginx.confに追加したのですが、
curlコマンドの結果にHSTSのヘッダーがありません。何が問題なのか分かる方がいたら教えていただけないでしょうか。よろしくお願い致します。

【nginx.confに追加した設定】

server {
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

listen 443 ssl;
server_name *.xxxxx; ← curlコマンドで指定するドメイン

ssl_certificate /etc/nginx/ssl/ssl.crt/portal.crt;
ssl_certificate_key /etc/nginx/ssl/ssl.key/portal.key;
}

server {
listen 80;
server_name *.xxxxx; ← curlコマンドで指定するドメイン
return 301 https://$host$request_uri;
}

※nginx -t で文法エラーがないことを確認し、systemctl restart nginxを実行

【curlコマンドの結果】
# curl -I https://xxxxxx
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 May 2025 09:02:09 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
X-Content-Type-Options: nosniff
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate
X-Content-Type-Options: nosniff
Content-Language: ja
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)



### 該当のソースコード

```
特になし
```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [ ] ソースコードを自分なりに変更した
- [ ] 知人に聞いた
- [x] その他

##### 上記の詳細・結果
AIに質問してnginx.confを変更しましたが上手くいきませんでした。

### 補足
特になし

HSTSの脆弱性を是正したい

### 実現したいこと

https://teratail.com/questions/l3g3sgik9io99q
の続きのようなもの。
↑の質問では一番の問題が解決してベストアンサーつけたので改めて。

メインドメインで公開済みのHPのサブディレクトリとして、
WordPressで作ったホームページにアクセスさせたい(URLはそのまま)

### 前提
ConoHa , Kusanagi9 , nginx

メインドメインのHPはphp、
サブディレクトリに置きたいWordpressはKusanagiManagerで作成済みのプロビジョン
(仮のサブドメインで作成)

作業担当者の知識不足のため、WordPress作成して自前でDB接続というのができないため、
WordPressページを作成するのにKusanagiManagerを使用している。

あるもの
・メインドメインのHP(PHP)
・サブドメインで作ったWordPress(Wordpress,KusanagiManager)

やりたいころ
(メインドメイン)/(サブディレクトリ)/
にアクセスしたらURLは(メインドメイン)/(サブディレクトリ)/のまま
(サブドメイン)のメインページが表示されるようにしたい

### 試したこと

試したこと1
↑の質問と回答を踏まえ、

    location /(サブディレクトリ名)/ {
    	alias /home/kusanagi/(プロビジョン名)/DocumentRoot/;
        index index.php;
        try_files $uri $uri/ /index.php?$args;
        location ~ \.php$ {
        	rewrite ^/(サブディレクトリ名)/(.*\.php)$ /$1 break;
                include conf.d/fastcgi.inc;
        }
    }
とした。
404や403といったものは返ってこなくなったが、
(サブドメイン)/(サブディレクトリ)/
の中身が返ってくる。(ダミーデータ入れて確認済み)


試したこと2
include conf.d/fastcgi.inc;
をincludeせずに中身をフルパス指定にして書き換えた
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f /home/kusanagi/(プロビジョン名)/DocumentRoot$fastcgi_script_name) {
		return 404;
	}
fastcgi_pass (IP):(Port?);
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/kusanagi/(プロビジョン名)/DocumentRoot$fastcgi_script_name;
fastcgi_param HTTP_HOST $host;
include fastcgi_params;
fastcgi_buffers 256 128k;
fastcgi_buffer_size 128k;
fastcgi_intercept_errors on;
fastcgi_read_timeout 120s;

が、動作に変わりはなかった




### 補足情報（FW/ツールのバージョンなど）

質問やコメントに応じて随時追記


メインドメインHPのサブディレクトリにWordPressで作ったページを置きたい

### 実現したいこと
メインドメインで公開済みのHPのサブディレクトリに、
WordPressで作ったホームページにアクセスさせたい
ただし、リダイレクトでない(URLはそのまま)

### 前提
ConoHa , Kusanagi9 , nginx

メインドメインのHPはphp、
サブディレクトリに置きたいWordpressはKusanagiManagerで作成済みのプロビジョン
(仮のサブドメインで作成)

作業担当者の知識不足のため、WordPress作成して自前でDB接続というのができないため、
WordPressページを作成するのにKusanagiManagerを使用している。

メインドメインのconfファイルでlocationをいじったりいろいろしているがうまくいかない。

ファイル構造
/home/(メインドメイン)/
/home/kusanagi/(プロビジョン名？)/DocumentRoot/index.php他
/home/(サブディレクトリ名)(テスト用)/index.php(ダミーデータ)

### 試したこと
メインドメインのlocationに、
    location /(サブディレクトリ名)/ {
    	root /home;
	   index index.php;
        try_files $uri $uri/ /index.php?$args;
        location ~ \.php$$ {
		include conf.d/fastcgi.inc;
        }
    }
を追加したときはダミーデータのindex.phpに正常にアクセスできた。

/home/kusanagi/(略)/DocumentRoot/index.phpにつなごうとしたところ404になった。
    location /(サブディレクトリ名)/ {
    	alias /home/kusanagi/(プロビジョン名？)/DocumentRoot/;
	index index.php;
        try_files $uri $uri/ /index.php?$args;
        location ~ \.php$ {
		include conf.d/fastcgi.inc;
        }
    }
にしても404が返ってくる

(chatGPTに言われるがままに)試したが、たいてい404か403が帰ってきた


### 追記
回答いただいた内容をもとに

    location /(サブディレクトリ名)/ {
    	alias /home/kusanagi/(プロビジョン名？)/DocumentRoot/;
	index index.php;
        try_files $uri $uri/ /index.php?$args;
        location ~ \.php$ {
		include conf.d/fastcgi.inc;
                rewrite /(サブディレクトリ名)/(.*)$ /$1 break;
        }
    }
としたところ、
目的のページ(kusanagiManagerで作成したwp)の一階層下
(おそらくプロビジョンのサブドメイン名.index.php/(サブディレクトリ名)/)
が返ってくるようになった。
(ページに設定したヘッダー・フッターと、「表示するページが見つからなかった」ページが返ってくるようになった)
あとはメインドメイン/(サブディレクトリ)/がサブドメインWPのindex.phpが返ってくるようにしたい



メインドメインHPのサブディレクトリにWordPressで作ったページをぶらさげたい

nginxをインストールしたので、「systemctl start nginx.service」とコマンドを入力して起動させたら、
起動に失敗しましたとエラーが表示されました。
そこで、「systemctl status nginx.service」で確認をしたところ以下のような内容でした。

nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled)
   Active: failed (Result: exit-code) since Sat 2016-09-24 19:40:49 BST; 17s ago
     Docs: http://nginx.org/en/docs/
  Process: 12709 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)
  Process: 12707 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)

Sep 24 19:40:47 localhost.localdomain nginx[12707]: nginx: configuration file /etc/nginx/nginx.conf...ful
Sep 24 19:40:47 localhost.localdomain nginx[12709]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98:...se)
Sep 24 19:40:47 localhost.localdomain nginx[12709]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98:...se)
Sep 24 19:40:48 localhost.localdomain nginx[12709]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98:...se)
Sep 24 19:40:48 localhost.localdomain nginx[12709]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98:...se)
Sep 24 19:40:49 localhost.localdomain nginx[12709]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98:...se)
Sep 24 19:40:49 localhost.localdomain nginx[12709]: nginx: [emerg] still could not bind()
Sep 24 19:40:49 localhost.localdomain systemd[1]: nginx.service: control process exited, code=exite...s=1
Sep 24 19:40:49 localhost.localdomain systemd[1]: Failed to start nginx - high performance web server.
Sep 24 19:40:49 localhost.localdomain systemd[1]: Unit nginx.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

これを読むと、「Failed to start nginx - high performance web server」とあったので、
検索してみたのですが、該当する記事が見つからず、わかりませんでした。

何が原因で起きたのでしょうか？

なお、開発環境は以下の通りです。
OS：CentOS7.1(vagrant)
vagrant:1.8.4
nginx:1.11.4
nginxはパッケージからのインストールになります。

nginxを起動したら、起動に失敗しました。

###前提・実現したいこと
Webのサーバーサイド(APIなど)の開発を行っていて502エラーが発生するようになってしまいました。

現在複数台のサーバーでサービス動かしており
流れとしては以下のような感じです。

1. ユーザーがUserのGETのリクエストを飛ばす
1.   UserサーバーがGET処理を実行
1.   UserサーバーのGET処理の中でInfoのGETを実行
1.       InfoサーバーでGET処理を実行
1.       InfoサーバーのGET処理の中でDataのGETを実行
1.         DataサーバーでGET処理を実行
1.         DataサーバーからInfoサーバーにレスポンスを返す
1.       Infoサーバーがレスポンスを受け取りデータを整形
1.       InfoサーバーからUserサーバーにレスポンスを返す
1.   Userサーバーがレスポンスを受け取りデータを整形
1.   Userサーバーがユーザーにレスポンスを返す
1. ユーザーがレスポンスを受け取る


502エラーが発生する原因は
infoサーバー内ででているConnection refusedエラーが原因だと思っています。

これを解決する方法を探しています。


###発生している問題・エラーメッセージ

userサーバーで起きているエラー
```
urllib.error.HTTPError: HTTP Error 502: Bad Gateway
```

infoサーバーで起きているエラー
「InfoサーバーのGET処理の中でDataのGETを実行する」
このタイミングでエラーが発生します。
```
urllib.error.URLError: <urlopen error [Errno 111] Connection refused>
```

###設定周りの情報


gunicornの設定です。
関係ありそうな部分だけ抜粋しました。

```
workers = multiprocessing.cpu_count() * 2 + 1
worker_class = 'sync'
worker_connections = 1000
max_requests = 0
timeout = 30
keepalive = 2
```

nginxの.confではアクセス数やレスポンスまでの時間制限などの設定は行っていないです。

### 試したこと

Connection refusedは必ず発生するわけではありませんでした。
頻度としては7回に1回ほどエラーが出ます。
発生しない場合は取得したかった内容が取得できています。

###補足情報(言語/FW/ツール等のバージョンなど)
取得しているデータは文字列で半角英数字記号で500字ほど。
json形式で取得します。
成否問わずレスポンスは0.5秒かからず返ってきます。

環境情報
EC2インスタンス
Linux
nginx
Python3
gunicorn

RDSインスタンス
MySQL

APIの取得の確認は主にChromeで行っています。

### 追記、試したこと1
gunicornの設定の下記2つを変更しての動作を確認してみました。
変更したところインスタンスを作成してから
約1時間ほどで適当に百数回以上GETを試しましたが502エラーは発生しませんでした。
しかし、時間がたってからGETを行ったところ502が発生。
以降発生するのは変わりませんが頻度は少しだけ減ったように感じます。
（1/7から1/10くらいに変化）

```
timeout = 30 -> 3000
keepalive = 2 -> 20
```

### 追記

nginxのキャッシュが溜まっているとかそういう面について調べましたが
キャッシュは作られていませんでした。（設定もしてないです）

また現在サーバーの再起動や何やらは切ってある状態で試しているため
もし停止したら停止しっぱなしになります。

### 追記2

Dockerで同じような状況を作って試してみました。
DockerでMySQLサーバーを立てて、
CentOSのサーバーを立てて、
AWSのEC2インスタンスとRDSインスタンスと同じ内容を詰め込んで
Docker内でやり取りさせてみました。

そして、502エラーが発生するまで無限ループを行うようスクリプトを準備し
それを12個ほどcmdから実行しています。
現在30分ほど経ちましたが今のところ502エラーは発生していません。
AWSでも同じことをして試してみます。

### 追記3：メモリが怪しそうです
free コマンドでメモリの使用量を確認したところ以下のように表示されました。
また、GETを繰り返すたびにMem-usedの値が上がっていくのが確認できました。
Mem-cachedはすぐには上がりませんでしたがココらへんについてもう少し深く調査してみようと思います。

```
[ec2-user@ip-172-31-29-13 ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:           995        871        123          0         32        682
-/+ buffers/cache:        157        838
Swap:            0          0          0
```

### 追記4：メモリに負荷をかけてリクエストの結果

stress コマンドでメモリに負荷をかけて
```
stress --vm 2 --vm-bytes 400M --timeout 10m
```

10のプロセスから各1000回づつ、10/sでリクエストの送信を行っている状態での
vmstatコマンドの結果です。

```
2017/01/26 11:05:25 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
2017/01/26 11:05:25  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
2017/01/26 11:05:25  2  0      0 291484   4024  18948    0    0    10    25   77   85  1  1 98  0  0	
2017/01/26 11:05:26  2  0      0 266260   4032  18940    0    0     0    48  265  298 13 87  0  0  0	
2017/01/26 11:05:27  2  0      0 261168   4032  18940    0    0     0     0  251  258 16 84  0  0  0	
2017/01/26 11:05:28  3  0      0 179840   4044  20852    0    0  1940     0 1979 1332 32 68  0  0  0	

...省略
```

メモリに負荷をかけていない状態ではcpu の id に余裕がありましたが、
負荷をかけた状態では上記のようになっています。

### 仕様について追記

nginxを起動後、gunicornを起動させて
その状態でずっと稼働しっぱなしにして動かしています。

そして、問題の502が起きるのは、しばらくアクセスを繰り返した後に発生し始めること
アクセスするたびにメモリが減っていく様子が確認できたことからそこら辺に原因があるかもしれないと思っています。

### 現在の状況

InfoサーバーやDataサーバーから取得するデータ量を減少させたて、
タイムアウトまでの時間を伸ばすことでほぼ502エラーが出ないことが確認できました。
一応以前は502エラーが発生していた時以上にはアクセスを繰り返してもエラーは発生しませんでした。
例としては 10プロセスから 10/s で 各1千回リクエストを飛ばすと行ったことをしましたが
エラーは発生せずに終えることができました。

また、UserサーバーからInfoサーバーにリクエストを飛ばした際に
正常な結果が得られるまでリクエストを飛ばすことで、無理やり押し通すことが出来るのも確認しました。
（これはコメントアウトした状態で検証しています。）


ただ、どちらも対処療法の領域をでておらず、
原因の特定に至っていないためまだ調査中と言った感じです。

### ワーカープロセスについて
今回のことで初めて調べたのであっているかわかりませんがご了承ください。
nginx,gunicorn共にすべてのサーバーで同じ設定を行っています。
サーバーのスペックも同スペックで作成しています。

まずこちらのサイトを参考にCPUや最大プロセス数を調べたところ
http://www.crystalsnowman.com/?p=344

CPU : 1
最大プロセス数 ： 1024

とわかりました。
また、nginxにはワーカープロセスについての設定を行って無い状態でした。

gunicornでは以下の設定は行っていました。
``
workers = multiprocessing.cpu_count() * 2 + 1
worker_class = 'sync'
worker_connections = 1000
max_requests = 0
``

以下は動いているnginxとgunicornのプロセスを確認したものです。
```
[ec2-user@ip-xxx-xx-xx-xx ~]$ ps aux |grep nginx |grep -v grep
root     17576  0.0  0.1  58088  1080 ?        Ss   11:58   0:00 nginx: master process nginx
ec2-user 17578  0.0  0.4  58600  4756 ?        S    11:58   0:00 nginx: worker process
[ec2-user@ip-xxx-xx-xx-xx ~]$ ps aux |grep gunicorn |grep -v grep
ec2-user 17614  0.0  2.1 202156 22332 ?        S    11:58   0:01 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
ec2-user 17646  0.4  2.5 223292 25996 ?        S    11:58   0:44 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
ec2-user 17647  0.3  2.5 223296 26000 ?        S    11:58   0:38 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
ec2-user 17648  0.4  2.5 223248 26004 ?        S    11:58   0:41 /home/ec2-user/.pyenv/versions/3.5.2/bin/python3.5 /home/ec2-user/.pyenv/versions/3.5.2/bin/gunicorn run:app --config guniconf.py
```

Connection refused エラーの検証と原因の特定方法

# nginxがrailsサーバーに接続してません

nginxが急に接続できなくなり、We're sorry, but something went wrong.が表示されました。
現在 `failed (111: Connection refused) while connecting to upstream`というエラーが発生してしまい、ウェブサイトにアクセスできなくなりました。
以下が、`nignx.error.log`の内容です。

```error
 while connecting to upstream, client: 10.0.1.171, server: www.sumigokochi2020.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/www/rails/rails_app/tmp/sockets/puma.sock:/", host: "10.0.0.222"
2020/12/03 12:22:24 [error] 3277#0: *439 connect() to unix:/var/www/rails/rails_app/tmp/sockets/puma.sock failed (111: Connection refused) while connecting to upstream, client: 10.0.0.196, server: www.sumigokochi2020.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/www/rails/rails_app/tmp/sockets/puma.sock:/", host: "10.0.0.222"
```

`rails s -e production`を実行すると以下の結果が得られます。

```
=> Booting Puma
=> Rails 6.0.3.4 application starting in production 
=> Run `rails server --help` for more startup options
Puma starting in single mode...
* Version 4.3.6 (ruby 2.7.2-p137), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: production
* Listening on unix:///var/www/rails/rails_app/tmp/sockets/puma.sock
Use Ctrl-C to stop
```
`error.log`の
```
connect() to unix:/var/www/rails/rails_app/tmp/sockets/puma.sock
```
と`rails s -e production`実行結果の

```
* Listening on unix:///var/www/rails/rails_app/tmp/sockets/puma.sock
```

のListening先とconnect先が違うことがエラーの原因なのではないかと考えているのですが、どなたかわかる人がいました、教えて頂きたいです。
**rails**の`production.log`が一切更新されてないので、**Nginx**の問題かなとは考えています。
##　本番環境

* AWS EC2 Linux
* Rails 6.0.3
* Nginx  

***Nginx.conf***file
```nginx/conf:nginx

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
    # server{}欄を変更して,httpでアクセスされたものをhttpsにリダイレクトさせる
    server {
        listen       80;
        listen       [::]:80;
        server_name  www.sumigokochi2020.com;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }	
}
```
nginx/conf.d/rails_app.conf
```
# log directory
error_log  /var/www/rails/rails_app/log/nginx.error.log; #自分のアプリケーション名に変更
access_log /var/www/rails/rails_app/log/nginx.access.log; #自分のアプリケーション名に変更
# max body size
client_max_body_size 2G;
upstream app_server {
  # for UNIX domain socket setups
  server unix:/var/www/rails/rails_app/tmp/sockets/puma.sock fail_timeout=0; #自分のアプリケーション名に変更
}
server {
  listen 80;
  server_name www.sumigokochi2020.com; #自分のElasticIP
  # nginx so in:creasing this is generally safe...
  keepalive_timeout 5;
  # path for static files
  root /var/www/rails/rails_app/public; #自分のアプリケーション名に変更
  # page cache loading
  try_files $uri/index.html $uri.html $uri @app;
  location @app {
    # HTTP headers
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://app_server;
  }
  # Rails error pages
  error_page 500 502 503 504 /500.html;
  location = /500.html {
    root /var/www/rails/rails_app/public; #自分のアプリケーション名に変更
  }
}
```

nginxで(111: Connection refused）が出て、アクセスできないです。

nginxのドキュメントルートを確認したいのですが、その方法が分かりません。

/etc/nginx/nginx.conf を確認したのですが、
ドキュメントルートに関する記述は見当たりませんでした。

ブラウザからローカルホストにアクセスしたところ、404 Not Foundと表示されるので
どこかの場所を参照していると思うのですが、そのpathを知りたいのです。
pathが記載されているログファイルや、確認できるコマンドなど、
ドキュメントルートを知る方法がございましたら、ご教示いただきたく思います。

当方の環境は、Ubuntu 14.04 で nginx 1.4.6 です。
どうか宜しくお願いいたします。

nginxのドキュメントルートを知る方法について

nginxをリバースプロキシとして使うテストをしています。
nginx.confを下記のように書いたのですが、下記のようなエラーが出てしまいます。
locationディレクティブをどのように書けばnginxを起動できますでしょうか。

```nginx.conf

```user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
  worker_connections  1024;
}


http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;

  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';

  access_log  /var/log/nginx/access.log  main;

  sendfile        on;
#tcp_nopush     on; 

  keepalive_timeout  65; 

#gzip  on; 

  include /etc/nginx/conf.d/*.conf;
                             location ~ \.php$ {
                             root           /var/www;
                             fastcgi_pass   127.0.0.1:9000;
                             fastcgi_index  index.php;
                             fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                             include        fastcgi_params;
                             }
}



nginx -t
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2015/08/16 16:26:29 [warn] 10838#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2015/08/16 16:26:29 [emerg] 10838#0: "location" directive is not allowed here in /etc/nginx/nginx.conf:32
nginx: configuration file /etc/nginx/nginx.conf test failed

```