web-dev-qa-db-ja.com

サーバーの応答が途中で切れる

Json応答を返すREST API。

...route_short_name":"135","route_long_name":"Secte // end of response

返されるJSON文字列に応じて、カットオフポイントの位置が変化し続けるため、エンコードの問題ではないと確信しています。カットオフが発生する特定の応答サイズも見つかりませんでした（65kbがカットオフにならないのに対し、40kbsはカットオフになります）。

カットオフが発生したときの応答ヘッダーを見る：

{
    "Cache-Control" = "must-revalidate, private, max-age=0";
    Connection = "keep-alive";
    "Content-Type" = "application/json; charset=utf-8";
    Date = "Fri, 11 May 2012 19:58:36 GMT";
    Etag = "\"f36e55529c131f9c043b01e965e5f291\"";
    Server = "nginx/1.0.14";
    "Transfer-Encoding" = Identity;
    "X-Rack-Cache" = miss;
    "X-Runtime" = "0.739158";
    "X-UA-Compatible" = "IE=Edge,chrome=1";
}

ベルも鳴らしません。誰でも？

jsonrestresponse
36
samvermette

私は同じ問題を抱えていました：

NginxはFastCGIバックエンドからのいくつかの応答を遮断しました。たとえば、PhpMyAdminから適切なSQLバックアップを生成できませんでした。私はログをチェックし、これを見つけました：

2012/10/15 02:28:14 [crit] 16443＃0：* 14534527 open（） "/ usr/local/nginx/fastcgi_temp/4/81/0000004814"はアップストリーム、クライアントの読み取り中に失敗しました（13：許可が拒否されました） ：*、サーバー：、リクエスト： "POST /HTTP/1.1"、アップストリーム： "fastcgi：//127.0。 0.1：9000 "、ホスト：" "、リファラー：" http：//*/server_export.php？token = ** "

修正するために私がしなければならなかったことは、/usr/local/nginx/fastcgi_tempフォルダ、およびclient_body_temp。

修正済み！

どうもありがとうsamvermette、あなたの質問と回答は私を正しい方向に導いてくれました。

32
Clement Nedelcu

私のnginx error.logファイルを検索し、次を見つけました：

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

Nginxのプロキシが応答コンテンツ（thinで渡された）をファイルに保存しようとしたようです。応答サイズがproxy_buffers（64ビットプラットフォームではデフォルトで64kb）を超えた場合にのみそうします。そのため、最終的にはバグwasリクエストレスポンスサイズに接続されました。

proxy_bufferingを更新したり、ファイル許可の問題を修正したりする代わりに、nginxの設定ファイルでproxy_buffersをoffに設定して、問題の修正を終了しました。

まだnginxのバッファの目的がわからない。誰かがそれを追加できれば幸いです。バッファリングを完全に無効にすることは悪い考えですか？

30
samvermette

サーバーからの応答を切断する際にも同様の問題がありました。

応答header('Content-type: application/json');を返す前にjsonヘッダーを追加したときにのみ発生しました

私の場合、gzipが問題を引き起こしました。

gzip_typesでnginx.confを指定し、リストにapplication/jsonを追加してからgzipをオンにすることで解決しました。

gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;
gzip on;
11
Dralac

質問と素晴らしい回答をありがとう、私は多くの時間を節約しました。結局、クレメントとサムの答えは私の問題を解決するのに役立ちましたので、クレジットは彼らに行きます。

トピックについて少し読んだ後、proxy_bufferingを無効にすることはお勧めできません。クライアント（システムのユーザー）のインターネット接続が悪い場合、サーバーが停止する可能性があるためです。 。

この議論 を理解するのに非常に役立つことがわかりました。フランシス・デーリーの例は私にとって非常に明確でした。

おそらく、完全なプロセスを一連のプロセスと考える方が簡単です。

webブラウザーは1 MB/sリンクを介してnginxと通信します。 nginxは、100 MB/sリンクを介してアップストリームサーバーと通信します。アップストリームサーバーは100 MBのコンテンツをnginxに返します。 nginxは100 MBのコンテンツをWebブラウザーに返します。

Proxy_bufferingをオンにすると、nginxは100 MB全体を保持できるため、nginx-upstream接続は1秒後に閉じられ、nginxはWebブラウザーにコンテンツを送信するのに100秒費やすことができます。

Proxy_bufferingをオフにすると、nginxは、nginxがWebブラウザーに送信できるのと同じレートでアップストリームからのみコンテンツを取得できます。

Webブラウザーは違いを気にしません。コンテンツ全体を取得するのに100秒かかります。

nginxは違いをあまり気にしません。コンテンツをブラウザにフィードするのにまだ100秒かかりますが、アップストリームへの接続をさらに99秒間開いたままにする必要があります。

上流は違いを気にします。1秒かかったものは実際には100秒かかります。余分な99秒間、そのアップストリームサーバーは他の要求を処理していません。

通常：nginx-upstreamリンクはbrowser-nginxリンクよりも高速です。そして、上流はnginxよりも「重い」。そのため、アップストリームが処理をできるだけ早く終了するのが賢明です。

2
Vlad

Inodeを使い果たした可能性があり、これによりNginXがfastcgi_tempディレクトリを適切に使用できなくなります。

df -iそして、0％のiノードが空いている場合、それは問題です。

find /tmp -mtime 10（10日より古い）で、ディスクがいっぱいになっている可能性があるものを確認します。

または、ファイルが多すぎる別のディレクトリです。たとえば、/ home/www-data/example.comに移動して、ファイルをカウントします。

find . -print | wc -l

2
PJ Brunet

同様の問題がありました。これは、SO = LINGERが有効になっているRESTサーバー（DropWizard）が原因で発生しました。切り捨てられました。

1
Chris Kannon

私もこの問題を抱えていました-JSONクライアント側の解析に障害があり、応答が切断されているか、さらに悪化しています。応答が古く、ランダムなメモリバッファから読み取られました。

いくつかのガイドを読んだ後、 NginxからPOSTを介して静的コンテンツを提供 および Nginx：POSTを使用する場合の「405 Not Allowed」の修正_静的な配信 シンプルなJSONファイルを提供するようにnginxを設定しようとしています。

私の場合、以下を使用する必要がありました。

max_ranges 0;

nginxが応答ヘッダーにAccept-Ranges: bytesを追加するときにブラウザが面白いアイデアを取得しないように）および

sendfile off;

静的ファイルを提供するプロキシのserverブロック内。見つかったlocationファイルを最終的に提供するJSONブロックに追加しても役に立ちませんでした。

静的JSONsを提供するためのもう1つのヒントは、応答タイプを忘れないことです。

charset_types application/json;
default_type application/json;
charset utf-8;

他の検索ではフォルダーのアクセス許可の問題が発生しました– nginxは動的ページの最後を切り取ってキャッシュする またはプロキシのバッファリングの問題– nginxを介してチャンク化されたリクエストを取得する 。

0
Dr1Ku