タグ: Nginx

  • 新しくインストールしたUbuntuでNginxが起動しない

    新しくUbuntuをインストールして、NginxやPHPをインストールした。Nginxを起動させようとしたところ、エラーで起動せず。

    zen@dev:/etc/nginx/sites-available$ sudo service nginx start
    Job for nginx.service failed because the control process exited with error code.
    See "systemctl status nginx.service" and "journalctl -xe" for details.
    zen@dev:/etc/nginx/sites-available$
    zen@dev:/etc/nginx/sites-available$ sudo systemctl status nginx.service
    ● nginx.service - A high performance web server and a reverse proxy server
         Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:>
         Active: failed (Result: exit-code) since Wed 2021-11-17 16:13:11 JST; 2min>
           Docs: man:nginx(8)
        Process: 294747 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_pro>
        Process: 294758 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; >
    Nov 17 16:13:08 dev systemd[1]: Starting A high performance web serve>
    Nov 17 16:13:08 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
    Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
    Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
    Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
    Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
    Nov 17 16:13:11 dev nginx[294758]: nginx: [emerg] still could not bin>
    Nov 17 16:13:11 dev systemd[1]: nginx.service: Control process exited>
    Nov 17 16:13:11 dev systemd[1]: nginx.service: Failed with result 'ex>
    Nov 17 16:13:11 dev systemd[1]: Failed to start A high performance we>
    zen@dev:/etc/nginx/sites-available$

    エラーを見ると、ポートのバインドに失敗している。もしやと思って調べると、Apacheがいて、ポート80で起動していた。Apacheを終了させると、無事にNginxを起動させることができた。

    aptでいろいろとインストールしていると、いつのまにかapache がいて邪魔をする。初歩的なミスだけど、よくやらかす。

  • Nginx上のPHPのページにアクセスすると「File not found.」と表示される

    NginxにPHPを動作させるための設定をいれたのだが、アクセスすると、「File not found.」と表示されて、PHPの処理がされない。Nginxのエラーログを見てみると、下記の表示があった。

    FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream,

    Nginxの「/etc/nginx/sites-available/default」のPHPに関連する設定は、下記のように設定していた。

         # pass PHP scripts to FastCGI server 
            # 
            location ~ \.php$ { 
                        include snippets/fastcgi-php.conf; 
            # 
            #       # With php-fpm (or other unix sockets): 
                    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
            #       # With php-cgi (or other tcp sockets): 
            #       fastcgi_pass 127.0.0.1:9000; 
                    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
            }

    上記を、次のように修正したところ、正常にPHPの処理が行われた。

         # pass PHP scripts to FastCGI server 
            # 
            location ~ \.php$ { 
                     root     /var/www/html; 
                     include snippets/fastcgi-php.conf; 
            # 
            #       # With php-fpm (or other unix sockets): 
                    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
            #       # With php-cgi (or other tcp sockets): 
            #       fastcgi_pass 127.0.0.1:9000; 
                    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
                    include fastcgi_params; 
            }

    そもそものエラーが、ファイルの場所がわからないということなので、「root  path」でドキュメントルートを指定したことにより、正常に処理ができるようになった。Nginxの設定は、何回やっても難解でどこからしらで躓く。

  • Nginxでファイルアップロードで「413 Request Entity Too Large」が表示される

    Nginx上で、Wordpressを動作させるために、PHP-FPMやMariaDBを設定して「動作した」と思ったら、アップロードで、下記のエラーが表示された。

    413 Request Entity Too Large

    アップロードしたファイルは1MBちょっとのファイルなのだが。これを調べていくと、PHP側のアップロードサイズとポストサイズは問題なかった。Nginx側は、サイズ指定されていないようなので、デフォルトのサイズだった。このNginxのデフォルトサイズが問題で、デフォルトだと、1mしかない。これが原因なので、Nginxのパラメータを書き換える。

    https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

    `/etc/nginx/sites-available/default` を編集し、「server {}」のところに、「client_max_body_size 30m;」を追加し、最大サイズを30mにした。

    # Default server configuration 
    # 
    server { 
            #listen 80 default_server; 
            #listen [::]:80 default_server; 
            listen 443 ssl default_server; 
            listen [::]:443 ssl default_server; 
            #listen 443 ssl; 
            ssl_certificate /etc/nginx/conf.d/server.crt; 
            ssl_certificate_key /etc/nginx/conf.d/server.key; 
            client_max_body_size 30m;

    あとは、Nginxを再起動するか、Nginxでコンフィグをリロードする。

    `sudo service nginx reload` でコンフィグのリロードか、` sudo service nginx restart` で再起動する。これでエラーがでなければOK。

  • リバースプロキシを使ったWordPressのアクセスでハマる

    リバースプロキシの後ろにWordpressをおいて、リバースプロキシ経由でアクセスさせようとしたところ、ハマった。いろいろと試しているが、現在進行系で格闘中だ。

    事象としては、

    • インストール時に、Wordpressのホスト名が「127.0.0.1:8080」で登録されてしまい、ログインしようとすると、127.0.0.1にアクセスしようとしてしまい、アクセスできず。
    • 上記の問題は、DBを直接書き換えることで対処するが、トップページにアクセスすると、「127.0.0.1」にリダイレクトされる。
    • WordPressのCSSの一部と、画像が表示されない

    という具合だ。前がNginxで、後ろがApache2.4。WordpressをCDNで配信するときの設定も試したが、うまく行かず。たぶん、根本的に何かが欠けていると思われる。簡単と思っていたけれど、思わぬところでハマるものだ。最初から考え直し。

  • PHPのバージョンアップしたら、Nginxが起動しなくなった

    Ubuntu 18.04で、PHPをPHP7.2からPHP7.4にアップデートしたところ、作業後にOSを再起動したら、Nginxが起動しなくなった。原因を調べて対処したので、メモを残す。

    Nginxのステータスを確認したところ。

    ubuntu@ip-10-0-0-122:/etc/nginx$ sudo service nginx status
    ● nginx.service - A high performance web server and a reverse proxy server
       Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
       Active: failed (Result: exit-code) since Wed 2020-10-14 22:35:23 PDT; 5s ago
         Docs: man:nginx(8)
      Process: 1296 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
    Oct 14 22:35:23 ip-10-0-0-122 systemd[1]: Starting A high performance web server and a reverse proxy server...
    Oct 14 22:35:23 ip-10-0-0-122 nginx[1296]: nginx: [emerg] "try_files" directive is duplicate in /etc/nginx/sites-enabled
    Oct 14 22:35:23 ip-10-0-0-122 nginx[1296]: nginx: configuration file /etc/nginx/nginx.conf test failed
    Oct 14 22:35:23 ip-10-0-0-122 systemd[1]: nginx.service: Control process exited, code=exited status=1
    Oct 14 22:35:23 ip-10-0-0-122 systemd[1]: nginx.service: Failed with result 'exit-code'.
    Oct 14 22:35:23 ip-10-0-0-122 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
    ubuntu@ip-10-0-0-122:/etc/nginx$
    

    PHP7.4にアップデートしたタイミングで、Apacheがインストールされて、これが自動起動しており、Nginxと、ポート80の使用が競合して、Nginxが落ちていた。apache2の自動起動を停止する。

    sudo systemctl disable apache2
    

    それでも、まだ、Nginxの起動でエラーになる。ログを見ると、コンフィグの問題のようなので、configtestを実施し、見事にエラーになる。

    ubuntu@ip-10-0-0-122:/etc/nginx/sites-available$ sudo service nginx configtest
     * Testing nginx configuration                                                                                   [fail]
    ubuntu@ip-10-0-0-122:/etc/nginx/sites-available$
    

    Nginxのコンフィグのdefaultで、php7.2-fpmの部分を、php7.4-fpmのsockに書き換え。

    その後、Nginxの起動を試すが失敗。Nginxのコンフィグチェックを行って、エラーになっている行を特定。

    sudo nginx -t
    nginx: [emerg] "try_files" directive is duplicate in /etc/nginx/sites-enabled/default:77
    nginx: configuration file /etc/nginx/nginx.conf test failed
    

    “try_files” がダブっているというので、場所を確認して、変更した。なぜ、急にエラーになったのか、はあるが、とりあえず、スルー。修正後は、Nginxが無事に起動した。

    最初のStatusのログをみると、最初から”try_files ”が問題って書いてあった。おちついて、見る必要あり。

  • Nginxに中間CA証明書をインストールするときの注意

    Nginxは、サーバ証明書を1つしか設定できない。そのため、中間CA証明書を指定しなければならない場合は、1つのファイルに複数の証明書を記述する。

    このとき、中間CA証明書は、サーバ証明書の後に、中間CA証明書を指定する。中間CA証明書を最初に記述すると、エラーになるので、注意が必要。

  • NginxでWordPressのパーマリンクが動かず、Apacheに変えた

    WordPress用のサーバ構築があったので、フロントのウェブサーバをNginxで設定した。PHPの動作や、Wordpressの初期設定までは、問題なし。Wordpressのパーマリンク設定をデフォルトから、変更したところ、404エラーに。Nginxなので、「.htaccess」でのrewrite設定が効かないので、Nginxの設定を変えて対応していが、いろいろと試しても動かない。いつまでも時間をかけてられないので、パーマリンクの問題で、Apache2.4系に変更した。Apache2.4だと、かなりあっさりと動作した。

    どこか時間を見つけて、Nginx + PHP + WordPressのパーマリンクの設定を検証しなくては。公式サイトの手順でもダメだったから、なんでだろう。たぶん、途中の設定とかがよくないのだろうな。やり直したら、さくっと動作するとか、そういうパターンだろう。

  • AWSのELBでWordPressを使うと”ERR_TOO_MANY_REDIRECTS”がでる

    AWSで、WordpressとSSLを使うためにELB(Elastic Load Balancer)を設定したのだが、アクセスすると、”ERR_TOO_MANY_REDIRECTS” が表示される。

    調べてみると、Wordpress+SSL+ELBの組み合わせで発生しているとのこと。Amazonの公式ページの内容も試してみたが、効果なし。

    https://aws.amazon.com/jp/premiumsupport/knowledge-center/redirect-http-https-elb/

    Nginxを使ったので、その設定を試したが効果なし。

    WordPressの設定で回避できることがわかったので、その設定を実施。

    “wp-config.php” の「wp-settings.php」の読み込み前に設定を追加。これで、アクセスしたところ、見事に成功。このとき、Nginxの設定は元に戻した状態で実施しても問題なかったので、Nginxの設定ではなく、Wordpress側の設定で回避できる問題だったようだ。

    /** Absolute path to the WordPress directory. */
    if ( ! defined( 'ABSPATH' ) ) {
            define( 'ABSPATH', dirname( __FILE__ ) . '/' );
    }
    
    /** 追加した設定 **/
    if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
        $_SERVER['HTTPS'] = 'on';
        $_ENV['HTTPS'] = 'on';
    }
    
    
    /** Sets up WordPress vars and included files. */
    require_once( ABSPATH . 'wp-settings.php' );
    

    参考: https://qiita.com/katzueno/items/ec4cb5997eb8a066fefc

  • Nginx-fullをインストールしたときに設定されているオプション

    ubuntu 18.04.02で、Nginx-fullをインストールしたときにインストールされているオプション。

    “–with-http_ssl_module” と “–with-http_v2_module” がついているので、SSL化もHTTP/2化もすんなりとできる。

    zen:/var/log$ nginx -V
    nginx version: nginx/1.14.0 (Ubuntu)
    built with OpenSSL 1.1.0g  2 Nov 2017
    TLS SNI support enabled
    configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-FIJPpj/nginx-1.14.0=. 
    -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' 
    --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx 
    --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log 
    --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid 
    --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body 
    --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy 
    --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug 
    --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module 
    --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module 
    --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module 
    --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module 
    --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module 
    --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module 
    --add-dynamic-module=/build/nginx-FIJPpj/nginx-1.14.0/debian/modules/http-auth-pam 
    --add-dynamic-module=/build/nginx-FIJPpj/nginx-1.14.0/debian/modules/http-dav-ext 
    --add-dynamic-module=/build/nginx-FIJPpj/nginx-1.14.0/debian/modules/http-echo 
    --add-dynamic-module=/build/nginx-FIJPpj/nginx-1.14.0/debian/modules/http-upstream-fair 
    --add-dynamic-module=/build/nginx-FIJPpj/nginx-1.14.0/debian/modules/http-subs-filter
    
  • ウェブサーバのSSL設定のコンフィグを生成してくれるジェネレータ

    ウェブサーバのSSL設定のコンフィグを生成してくれるジェネレータを、Mozillaが公開している。 NginxもApacheもAWS ELBも生成してくれるので、便利。証明書のパスなどは自分で書き換える必要があるが、ベースになるコンフィグを作ってくれるので、楽。

    もちろん、必要に応じてチューニングは必要だが、ベースは重要。