2つの異なるサーバーでホストされている2つのRoR Webアプリケーションがあります。 1つの特定のページの場合、要求は2番目のアプリケーションから提供されます。残りのページでは、リクエストはメインアプリケーションから提供されます。メインアプリケーションのNginx設定
location /customer/help/ {
proxy_pass http://second-application:3020/help_and_support/;
}
location /assets/ {
proxy_pass http://second-application:3020/assets/;
}
これは昨日までうまくいきました。さて、/customer/help/
ページが正しく読み込まれていません。 Firefoxでは空白のページが表示され、Chromeでは部分的に読み込まれてコンソールにエラーが表示されます
net::ERR_INCOMPLETE_CHUNKED_ENCODING
デバッグ後、API経由で送信された画像データに問題がある可能性があることがわかりました。 2つ目のアプリはAPIを呼び出して画像を取得し、ページに表示します
<% url_with_binary_data = "data:image/" + "jpeg" + ";base64," + u.photo_url.to_s %>
<%= image_tag(url_with_binary_data, :class => "userpic") %>
画像を取得するためのAPIコード
photo_url: Base64.encode64(u.photo.file.read).gsub("\n", '')
Nginxワーカーを実行しているユーザーがディレクトリ/var/lib/nginx
を所有しているかどうかを確認できます。
Nginxに対して大きすぎる応答を与えると、このディレクトリを使用して一時ファイルの作業ディレクトリとして書き込むことを学びました。ワーカープロセスがアクセスできない場合、Nginxは転送が完了する前に終了するため、エラーINCOMPLETE_CHUNKED_ENCODINGが発生します。
AWSでのこの問題にぶつかり、いくつかのproxy_bufferディレクティブをサイト構成ファイルに追加すると問題が修正されることがわかりました。
server {
...
location / {
...
proxy_buffers 8 1024k;
proxy_buffer_size 1024k;
}
}
私にとって、このソリューションはDfKimerが推奨するものでしたが、/var/lib/nginx
ではなく/var/cache/nginx
でした。
私にとっての解決策はproxy_max_temp_file_size
プロキシされたサーバーが/var/lib/nginx
に書き込めない場合、ファイルのアクセス許可やそのディレクトリの所有権を操作する必要はありません。コンテキストに応じてnginxのキャッシュディレクトリを変更できます。
proxy_temp_path /home/emre/projects/frontend/nginx_temp 1 2;
http
、server
、またはlocation
nginx.conf
ファイルのコンテキスト内。
チェック http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_temp_path
phpおよびnginx Webサーバー用の100%動作するソリューション
問題=> net :: ERR_INCOMPLETE_CHUNKED_ENCODING nginx
Step1:/etc/php/7.2/fpm/pool.dを開きます[私の場合、php 7.2を使用している場合は、phpフォルダーを選択します]
Step2:pool.dフォルダー内のwww.confファイルを編集します
私の場合は次のようになります=>
[inet]
user = www-data
group = www-data
listen = 127.0.0.1:9999
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 5
pm.status_path = /status
ping.path = /ping
request_terminate_timeout = 10s
request_slowlog_timeout = 10s
;
; Log files
;
access.log = /var/log/php-fpm/php-fpm.log
slowlog = /var/log/php-fpm/slow.log
Step:request_terminate_timeout = 10sの値を変更します(いつでも好きなときに)
request_terminate_timeout = 300s
Step4:php-fpmを保存して再起動します(私の場合、php7.2を使用しているので、cmdはそうなります)
Sudo service php7.2-fpm restart
これでスクリプトを実行できます動作しますそして0秒後に終了します
次に、もう1行構文を追加しますfastcgi_read_timeout 300; nginx.confファイルまたはWebサイトの.confファイル[ここにコードがあります]
user www-data;
worker_processes 1;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/conf-enabled/*.conf;
include /etc/nginx/sites-enabled/*.conf;
}
fastcgi_read_timeout 300;を追加すると、次のようになります
user www-data;
worker_processes 1;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/conf-enabled/*.conf;
include /etc/nginx/sites-enabled/*.conf;
fastcgi_read_timeout 300;
}
ここでnginxをリロードし、次のコマンドでphp-fpmを再起動します
Sudo service php7.2-fpm reload
Sudo service nginx reload
注:コードスニペットが実行され、テストされました。私の回答で問題を解決できない場合はお知らせください。
サーバーのメモリがいっぱいのため、このエラーが発生しました。これが将来の誰にも役立つことを願っています。
proxy_set_header接続キープアライブ。
完全な構成
server {
listen 0000; #//port give by your need
server_name aa.com;
proxy_buffers 16 4k;
proxy_buffer_size 2k;
#charset koi8-r;
#access_log logs/Host.access.log main;
location ~ ^/hello/{
proxy_buffering off;
proxy_pass http://127.0.0.1:1111; #//port give by your need
proxy_redirect off;
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Connection keep-alive;
}