サイトアイコン アラコキからの Raspberry Pi 電子工作

nginx – wordpress エラーログの解析と対策

Webサーバー サイトの運用
nginx アドバンスド設定
nginx の エラーログ と エラー別対策事例
 
nginx エラーログを見ると、多種多様なエラーメッセージが多く出ている。
 
nginx 設定ファイの構成。
 
以下、nginx - wordpress 環境におけるエラーログの解析と、その対策をまとめた。
 
 

 

スポンサー リンク

 

 
 
 
 
 
1. 稼働環境とエラーログの解析
 
稼働環境とエラーログの解析。
 
 
nginx によるリバースプロキシサーバーの下、バックエンドには nginx によるWebサーバーを3台配置し、ドメイン別のWordPressを稼働させている。
 
「SSH」経由の「Tera Term」で、それぞれのサーバーの【error.log】を解析。
 
 
 
2. エラーログの場所と表示方法
 
エラーログの場所は、「nginx.conf」の最初の位置で設定している。(「warn」レベルより上を記録。)
user  nginx;
worker_processes auto;
worker_rlimit_nofile 100000;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections 1024;
    multi_accept on;
    use epoll;
}
 
エラーログには「どのレベル」からのエラーを記録するかを、8段階で指定することができる。
emerg :サーバが稼動できないほどの重大なエラー
alert :critよりも重大なエラー
crit :重大なエラー
error エラー
warn :警告
notice :通知メッセージ
info :サーバ情報
debug :デバック用の情報
 
上記レベルは、上から順に重大レベルとなっており、例えば「error」を設定した場合は、「error」より上の「crit」「alert」「emerg」のエラーの全てが記録される。
 

 
エラーログの内容を参照するには、いくつかのコマンドがある。
①.sudo nano /var/log/nginx/error.log
②.sudo vi /var/log/nginx/error.log
③.sudo cat /var/log/nginx/error.log
④.sudo tail -f -n 3 /var/log/nginx/error.log
  (数字は、表示する件数)
 
 
nano エディターでの表示例
 
sudo nano /var/log/nginx/error.log。
 
nano は折り返し表示がされないので、画面の横幅分しか表示されない。画面を右に拡張すれば、その分表示されるようになる。
 
折り返し表示を行うには、「nanorc」を編集する。
sudo nano /etc/nanorc

## Enable soft line wrapping (AKA full-line display).
# set softwrap ← のコメントを外す。
 
set softwrap」に変更すると、折り返して全体が表示される。
 

 
vim エディターでの表示例
 
sudo vi /var/log/nginx/error.log。
 
折り返して全体が表示される。
 

 
cat コマンドでの表示例
 
sudo cat /var/log/nginx/error.log。
 
折り返して全体が表示される。
 

 
tail コマンドでの表示例
 
sudo tail -f -n 3 /var/log/nginx/error.log。
 
折り返して全体が表示される。見たい行数だけが表示されるのが便利で良い。
tail -n 行数 ファイル名
 
 
 
3. nginx の設定ノウハウ
 
nginx.conf】と【default.conf】は、nginx のインストール時点で、デフォルトのファイルが作成される。
 
default.conf】には、『/usr/share/nginx/html 』がデフォルトの公開ディレクトリとして設定されている。
 
デフォルトの【default.conf】を残したままにすると、
[error] 545#545: *27120 open() "/usr/share/nginx/html/cgi-bin/kerbynet" failed (2: No such file or directory)
というエラーが出るので、リネームするか削除する。
 

 

nginx】の設定場所と、設定の外出し。

 

 
nginx.conf】の「http」ディレクティブで、
include /etc/nginx/conf.d/*.conf;
 
の設定を行った場合、【conf.d】にある「xxx.conf」の全てが自動でが読み込まれるが、これらの設定には「serverディレクティブが必須となる。
 
conf.d】のレベルで、「location」ディレクティブだけの設定を作成すると、『sudo nginx -t』で次のエラーが出る。
 
nginx: [emerg] "location" directive is not allowed here in /etc/nginx/conf.d/xxx.conf:2
nginx: configuration file /etc/nginx/nginx.conf test failed
 
これを回避するには【conf.d】の中に,、サブディレクトリー【sotodasi】を作り、このディレクトリーの中にに「xxx.conf」を作成する。
 
今回「acc-cont.conf」という名前で、エラー対策のアクセス制御を記述する設定を外出しにした。
 
親の conf に、外出し設定を読み込む処理を追記する。
include conf.d/sotodasi/acc-cont.conf;
 

 
[error] 540#540: *25380 open() "/home/yaopi/www/wordpress/js/varien/js.js" failed (2: No such file or directory), client: 192.168.11.104, server: arakan60.com, request: "GET$
 
WordPressの設定として必要な、try_files の1行。
        location / {
                try_files $uri $uri/ /index.php;
        }
↓
               try_files $uri $uri/ /index.php?q=$uri&$args; 
要求されたURIが、ファイルあるいはディレクトリが存在するかをチェックし、存在しない場合は、index.php へリダイレクトという設定。
 
上段の例のように、パラメータなしでも動作するが、明示的に q パラメータと$args を設定しないと、存在しないディレクトリーへのアクセスが多く発生する。 
 
参考:WordPressのパーマリンクと、nginxの設定。
「基本」の場合
try_files $uri $uri/ /index.php?$args;
「カスタム構造 」の場合
try_files $uri $uri/ /index.php?q=$uri&$args;
合体させた記述
try_files $uri $uri/ /index.php?$args /index.php?q=$uri&$args;
 
参考:locationディレクティブのプレフィックス。
 
参考:プレフィックスの使い分け。
 
 
 
4. エラーの種類と対処策
 
connect() failed (113: No route to host) while connecting to upstream
 
原因:バックエンドのWebサーバーにアクセスできない。
 
対処策:バックエンドのWebサーバーを立ち上げる。
 

 
a client request body is buffered to a temporary file /var/cache/nginx/client_temp/
 
原因:アップロードしたファイル等に使ったバッファが、設定しているバッファサイズを超えた。
 
対処策:【nginx.conf】に次の設定を追記する。
client_body_buffer_size 2m;
 

 
[crit] 4023#4023: *150 cache file "/var/cache/nginx/arakan60/0b/d1/d7d3a48a99ff17f0b27004b8c61bd10b" has too long header, client: 38.143.100.10, server: arakan60.com, request: "GET / HTTP/1.1", $
 
原因:cache file has too long header。
 
対処策:【nginx.conf】の設定を次のように変更。(上段:修正前、下段:修正後。)
proxy_buffer_size     32k;
proxy_buffers         100 32k;
proxy_busy_buffers_size 64k;
↓
proxy_buffer_size     64k;
proxy_buffers         100 64k;
proxy_busy_buffers_size 128k;
 

 
[warn] 4265#4265: *37313 an upstream response is buffered to a temporary file /var/cache/nginx/temp/3/96/0000002963 while reading upstream, client: 222.10.228.1, server: arakan60.com, request: "GET /wp-content/uploads/2014.11.11%20miyama-5-2-1.mp4 HTTP/1.1", upstream: "https://192.168.11.106:443/wp-content/uploads/2014.11.11%20miyama-5-2-1.mp4", host: "arakan60.com", referrer: "https://arakoki70.com/"
 
原因:mp4 の動画ファイルで、バッファサイズよりも受信したファイルの容量の方が大きいという「warm」警告が出る。
 
対処策:【proxy_max_temp_file_size】の設定を次のように変更。
proxy_max_temp_file_size 10240m;
↓
proxy_max_temp_file_size 2048m;
↓
proxy_max_temp_file_size 1920m;
↓
proxy_max_temp_file_size 0;
10240mを指定すると、
「"proxy_max_temp_file_size" directive invalid value」エラーになる。

Raspberry Pi が、32bit アーキテクチャなので、指定可能な size は、
Max 2048M or 2G となる。

2048mに変更しても、同じエラーが出る。

1920mを指定すると、設定はOKになるが、「warm」警告は出る。

proxy_max_temp_file_size 0; にすると、警告は止まる。


 [警告]を止めるには
(応答のバッファリングを回避するにはどうすればよいか?)
案A:proxy_bufferingをオフにする
案B:proxy_max_temp_file_sizeを0に設定する
proxy_bufferingディレクティブは警告に直接関係していません。
これをオフにして、バッファリングをまったく停止することもできますが、 これは一般的にはお勧めできません( Comet で必要でない限り)。
[警告]を止めるには、proxy_max_temp_file_sizeを0に設定する必要があります。

 

 
[error] 559#559: *11 open() "/home/yaopi/www/favicon.ico" failed (2: No such file or directory), client: 192.168.11.1,$
 
原因:favicon.ico が無い。
 
対処策:【favicon.ico】をアップロードするか、もしくは、アクセス制御用の「acc-cont.conf」に下記を追記。
 
log_not_found off; エラーログを捨てる
## ファイルが無くてもエラーログを出さない
location ~ /(favicon.ico|apple-touch-icon-*) {
    log_not_found  off;
    access_log  off;
}
上記例には、ついでに次のエラー対策も併せて記述した。 
[error] 558#558: *2902 open() "/home/yaopi/www/apple-touch-icon.png" failed (2: No such file or directory), client: 10$
[error] 558#558: *2901 open() "/home/yaopi/www/apple-touch-icon-precomposed.png" failed (2: No such file or directory)$
 
※:【favicon.ico】をアップロードすると、【apple-touch-icon】のエラーも出なくなる。
 

 
[error] 524#524: *12770 access forbidden by rule, client: 146.185.142.200, server: arakan60.com, request: "POST /wp-login.php HTTP/1.0", host: "arakan60.com"
 
原因:【wp-login.php】に対する「access forbidden by rule」は、【wp-login.php】へのアクセスを制限しているから。
 
対処策:余りにも多くのエラーメッセージが出力されるので、アクセス制御用の「acc-cont.conf」に下記を追記。
#    # WordPress 管理画面へのアクセス制限 その3
        location = /wp-login.php {
                allow 192.168.11.1;
                deny all;

                access_log off;
                error_log off;

                fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include         fastcgi_params;

        }
 

 
[error] 537#537: *50046 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 47.244.120.6, server: arakan60.mydns.jp, request: "GET /xmlrpc.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "arakan60.mydns.jp"
 
原因:【xmlrpc.php】に対するDDoS攻撃、ブルートフォースアタック。
 
対処策:アクセス制御用の「acc-cont.conf」に下記を追記。
#access denyed (xmlrpc.php へのアタック対策)
   location = /xmlrpc.php {
      deny all;
      access_log off;
      error_log off;
   }
 

 
[error] 535#535: *11442 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 195.54.160.21, server: arakan60.mydns.jp, request: "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "arakan60.mydns.jp", referrer: "http://116.222.34.15:80/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php"
 
原因不明:「 FastCGI sent in stderr: "Primary script unknown"」が多数出る。
 
対処策:アクセス制御用の「acc-cont.conf」に下記を追記。
location ^~ /vendor/ {
    log_not_found  off;
}
 

 
[error] 544#544: *4619 FastCGI sent in stderr: "Unable to open primary script: /home/yaopi/www/wordpress /wp-content/plugins/wp-file-manager/lib/files/dWJpwY.php (No such file or directory)" while reading response header from upstream, client: 185.81.157.132, server: arakan60.com, request: "GET /wp-content/plugins/wp-file-manager/lib/files/dWJpwY.$
 
原因不明:【plugins】に関する「 FastCGI sent in stderr: Unable to open primary script」が多数出る。
 
対処策:アクセス制御用の「acc-cont.conf」に下記を追記。
location ^~ /wp-content/plugins/wp-file-manager/ {
    log_not_found  off;
}
 

 
[error] 3900#3900: *9994 "/home/yaopi/www/wordpress/wp-content/uploads/2016/08/地図埋め込み012.jpg/index.htm" is not found (2: No such file or directory), client: 85.1$
 
原因不明: (2: No such file or directory) が多数出る。
 
対処策:アクセス制御用の「acc-cont.conf」に下記を追記。
location ^~ /wp-content/uploads/2016/08/地図埋め込み012.jpg {
    log_not_found  off;
}
 

 
 
 
5. WordPressでの対処策
 
【Facebook】ディレクトリーに、アクセス権限がない。
[error] 539#539: *11841 directory index of "/home/yaopi/www/wordpress/Facebook/" is forbidden, client: 192.168.11.104, server: arakan60.com, request: "GET /Facebook/ HTTP/1.0", $
 
原因:【Facebook】ディレクトリーが、WordPressと同じ階層にある。
 
対処策。
静的HTMLを、WordPressと同じ階層に共存させる
 
【Facebook】ディレクトリーに、「index.php」をコピーして設置する。
 
index.php」を、次のように編集する。(上段:修正前、下段:修正後。)
/** Loads the WordPress Environment and Template */
require __DIR__ . '/wp-blog-header.php';
↓
/** Loads the WordPress Environment and Template */
require __DIR__ . '/./wp-blog-header.php';
 
この状態で、https://ドメイン名/Facebook/にアクセスするとリダイレクトループになってしまうので、function.php に下記を追記する。
remove_filter('template_redirect', 'redirect_canonical');
 
 
参考:
 
以上。
(2020.09.02)
 

 

スポンサー リンク

 

             

 

 

 
モバイルバージョンを終了