web-dev-qa-db-ja.com

アップストリームからのレスポンスヘッドの読み取り中に、アップストリームが大きくすぎるヘッダーを送信した

私はこれらの種類のエラーを受けています：

2014/05/24 11:49:06 [エラー] 8376＃0：* 54031アップストリームがアップストリームからのレスポンスヘッダを読んでいるときに大きすぎるヘッダを送信しました、クライアント：107.21.193.210、サーバ：aamjanata.com、リクエスト： "GET/the-洗脳クロニクルグジャラート政府によるスポンサー/ /％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-グジャラート政府によるスポンサー/、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by- gujarat-govern//、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/ 、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https： /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https:/aamjanata.com/t he-brainwash-chroniclesによるグジャラート政府による支援/、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-クロニクル政府によるグジャラート政府/、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored- by-gujarat-govern /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https：//aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat -government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/、 ％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /、％20https：/ aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https:/aamjanata.com/the-brainwash-chロニクルスポンサードグジャラート政府/、％20ht

いつも同じです。 URLがカンマ区切りで何度も繰り返されました。何が原因なのかわからない。誰か考えがありますか？

更新日：別のエラー：

http request count is zero while sending response to client

これが設定です。無関係なことが他にもありますが、この部分は追加/編集されました

fastcgi_cache_path /var/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$Host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;
    # Upstream to abstract backend connection(s) for PHP.
    upstream php {
            #this should match value of "listen" directive in php-fpm pool
            server unix:/var/run/php5-fpm.sock;
    }

そしてサーバーブロック内で：set $ skip_cache 0;

    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
            set $skip_cache 1;
    }
    if ($query_string != "") {
            set $skip_cache 1;
    }

    # Don't cache uris containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
            set $skip_cache 1;
    }

    # Don't use the cache for logged in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
            set $skip_cache 1;
    }

    location / {
            # This is cool because no php is touched for static content.
            # include the "?$args" part so non-default permalinks doesn't break when using query string
            try_files $uri $uri/ /index.php?$args;
    }


    location ~ \.php$ {
            try_files $uri /index.php;
            include fastcgi_params;
            fastcgi_pass php;
            fastcgi_read_timeout 3000;

            fastcgi_cache_bypass $skip_cache;
            fastcgi_no_cache $skip_cache;

            fastcgi_cache WORDPRESS;
            fastcgi_cache_valid  60m;
    }

    location ~ /purge(/.*) {
        fastcgi_cache_purge WORDPRESS "$scheme$request_method$Host$1";
    }`
nginxphp
197
Vidyut

以下をconfファイルに追加してください。

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;
339
Neo

Nginxがプロキシ/リバースプロキシとして動作している場合

つまり、ngx_http_proxy_moduleのユーザーのために

fastcgiモジュールに加えて、proxyモジュールはリクエストヘッダも一時バッファに保存します。

そのため、proxy_buffer_sizeとproxy_buffersを増やすか、完全に無効にする必要があるかもしれません（ nginxのドキュメント を読んでください）。

プロキシバッファリング設定の例

http {
  proxy_buffer_size   128k;
  proxy_buffers   4 256k;
  proxy_busy_buffers_size   256k;
}

プロキシバッファを無効にする例（ロングポーリングサーバーに推奨）

http {
  proxy_buffering off;
}

詳細については、 Nginxプロキシモジュールのドキュメント を参照してください。

109
amd

upstream sent too big header while reading response header from upstreamはnginxの「見ているものが好きではない」という一般的な言い方です。

  1. 上流のサーバースレッドがクラッシュしました
  2. 上流サーバーが無効なヘッダーを送り返しました
  3. STDERRから返送されたNotice/Warningsがバッファをオーバーフローさせ、それとSTDOUTの両方がクローズされました

3：メッセージの上にあるエラーログを見てください。メッセージの前にログが記録されてストリーミングされていますか？ PHP message: PHP Notice: Undefined index:ループのログファイルからの抜粋例：

2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
... // 20 lines of same
PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undef
2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "ta_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Firstname

下から3行目で、バッファの制限に達し、壊れて、次のスレッドがそれを上書きしていることがわかります。その後、Nginxは接続を閉じて、クライアントに戻ります502。

2：リクエストごとに送信されたすべてのヘッダーをログに記録し、それらを確認し、それらが規格に準拠していることを確認します。 ..）。 getallheaders関数呼び出しは通常、抽象化されたコード状況で役に立ちます phpすべてのヘッダを取得

例が含まれます：

<?php
//expire cookie
setcookie ( 'bookmark', '', strtotime('2012-01-01 00:00:00') );
// nginx will refuse this header response, too far past to accept
....
?>

この：

<?php
header('Content-type: image/jpg');
?>

<?php   //a space was injected into the output above this line
header('Content-length: ' . filesize('image.jpg') );
echo file_get_contents('image.jpg');
// error! the response is now 1-byte longer than header!!
?>

1：スレッドが正しいエンドポイントに到達していて、完了前に終了していないことを確認するために、スクリプトログを検証または作成します。

21
ppostma1

Pleskインストラクション

Plesk 12では、リバースプロキシとしてnginxを実行していました（これがデフォルトです）。そのため、nginxもプロキシとして実行されているため、現在のトップアンサーは機能しません。

私はSubscriptions | [subscription domain] | Websites & Domains (tab) | [Virtual Host domain] | Web Server Settingsに行きました。

それから、そのページの一番下で、あなたがここで上の2つの答えの組み合わせになるように設定した追加のnginxディレクティブを設定できます。

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;
9
icc97

Symfonyフレームワークを使用している場合：Nginxの設定を変更する前に、まずChromePHPを無効にしてください。

1 - app/config/config_dev.ymlを開きます

2 - これらの行をコメントする

#chromephp:
    #type:   chromephp
    #level:  info

ChromePHPは、X-ChromePhp-Dataヘッダーにjsonエンコードされたデバッグ情報をパックします。これは、fastcgiを使用したnginxのデフォルト設定には大きすぎます。

出典： https://github.com/symfony/symfony/issues/8413#issuecomment-20412848

5
Lucas Bustamante

私たちは、これを経験している私たちの1つのサーバーがfpmの設定を破壊し、通常ディスクに記録されるphpエラー/警告/通知がFCGIソケット経由で送信されていることに気づきました。ヘッダの一部がバッファチャンクにまたがって分割されると、構文解析のバグがあるようです。

そのため、php_admin_value[error_log]を実際に書き込み可能なものに設定し、php-fpmを再起動するだけで問題を解決できます。

小さいスクリプトで問題を再現できます。

<?php
for ($i = 0; $i<$_GET['iterations']; $i++)
    error_log(str_pad("a", $_GET['size'], "a"));
echo "got here\n";

バッファを増やすと、502は攻撃されにくくなりましたが不可能ではありませんでした。

bash-4.1# for it in {30..200..3}; do for size in {100..250..3}; do echo "size=$size iterations=$it $(curl -sv "http://localhost/debug.php?size=$size&iterations=$it" 2>&1 | egrep '^< HTTP')"; done; done | grep 502 | head
size=121 iterations=30 < HTTP/1.1 502 Bad Gateway
size=109 iterations=33 < HTTP/1.1 502 Bad Gateway
size=232 iterations=33 < HTTP/1.1 502 Bad Gateway
size=241 iterations=48 < HTTP/1.1 502 Bad Gateway
size=145 iterations=51 < HTTP/1.1 502 Bad Gateway
size=226 iterations=51 < HTTP/1.1 502 Bad Gateway
size=190 iterations=60 < HTTP/1.1 502 Bad Gateway
size=115 iterations=63 < HTTP/1.1 502 Bad Gateway
size=109 iterations=66 < HTTP/1.1 502 Bad Gateway
size=163 iterations=69 < HTTP/1.1 502 Bad Gateway
[... there would be more here, but I piped through head ...]

fastcgi_buffers 16 16k; fastcgi_buffer_size 32k;：

bash-4.1# for it in {30..200..3}; do for size in {100..250..3}; do echo "size=$size iterations=$it $(curl -sv "http://localhost/debug.php?size=$size&iterations=$it" 2>&1 | egrep '^< HTTP')"; done; done | grep 502 | head
size=223 iterations=69 < HTTP/1.1 502 Bad Gateway
size=184 iterations=165 < HTTP/1.1 502 Bad Gateway
size=151 iterations=198 < HTTP/1.1 502 Bad Gateway

だから私は正しい答えだと思います：それはディスクにエラーを記録するようにあなたのfpmの設定を修正する。

2
lyte