nginx-client_max_body_sizeは効果がない

nginxは言い続けますclient intended to send too large body。グーグルとRTMが私を指摘しましたclient_max_body_size。私はそれを設定する200mにはnginx.conf、同様のようにvhost conf、再起動Nginxは数回、私はまだエラーメッセージが出ています。

見落としましたか？バックエンドはphp-fpm（max_post_sizeそしてmax_upload_file_sizeそれに応じて設定されます）です。

nginxのドキュメントに従って、client_max_body_size 20m（または必要な任意の値）を次のコンテキストで設定できます。

context: http, server, location

NGINXの大規模なアップロードが、ホストされたWordPressサイトで正常に機能するようになりました（nembletonとrjha94からの提案による）

私は彼らの提案に少し説明を加えれば、それは誰かのために役立つかもしれないと思いました。まず、アップロードディレクティブを3つすべての定義ブロック（サーバー、場所、http）に含めていることを確認してください。それぞれに個別の行エントリが必要です。結果は次のようになります（...は定義ブロック内の他の行を反映しています）。

http {
    ...
    client_max_body_size 200M;
}    

（私のISPconfig 3設定では、このブロックは/etc/nginx/nginx.confファイルにあります）

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

（私のISPconfig 3設定では、これらのブロックは/etc/nginx/conf.d/default.confファイルにあります）

また、サーバーのphp.iniファイルがこれらのNGINX設定と一致していることを確認してください。私の場合、php.iniのFile_Uploadsセクションの設定を次のように変更しました。

upload_max_filesize = 200M

注：ISPconfig 3セットアップを管理している場合（私のセットアップは、CentOS 6.3で、Perfect Serverに従って）、これらのエントリをいくつかの個別のファイルで管理する必要があります。構成が段階的なセットアップの構成に似ている場合、変更する必要があるNGINX confファイルは次の場所にあります。

/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf 

私のphp.iniファイルはここにありました：

/etc/php.ini

nginx.confファイルのhttp {}ブロックを見落とし続けました。どうやら、これを見落とすと、アップロードをデフォルトの1Mに制限する効果がありました。関連する変更を行った後、NGINXおよびPHP FastCGIプロセスマネージャー（PHP-FPM）サービスを必ず再起動する必要もあります。上記の構成では、次のコマンドを使用します。

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart

のとして2016年3月、私は（それが重要ではないことを、Pythonの要求から）HTTPS上でPOST JSONにしようと、この問題に遭遇しました。

トリックは「client_max_body_size 200M;」http {}server {}を置くことです。少なくとも2つの場所 と：

1.httpディレクトリ

• 通常は /etc/nginx/nginx.conf

2.server vhost内のディレクトリ。

• apt-get（およびデフォルトでvginを使用してnginxをインストールする他のディストリビューションパッケージマネージャー）を介してインストールしたDebian / Ubuntuユーザーの場合、vhosts /etc/nginx/sites-available/mysite.comを持たないユーザーの場合は、おそらくnginx.confまたはそれと同じディレクトリにあります。

3. 2location /と同じ場所にあるディレクトリ

• より具体的にすることもできます/が、まったく機能しない場合は、これを適用してから/、その機能をより具体的にすることをお勧めします。

覚えておいてください -あなたはSSLを使用している場合、それはSSLのために上に設定する必要でしょうserverし、locationあまりにも、どこそれは（のように理想的に同じであってもよい2）。クライアントがhttpでアップロードを試み、それらがhttpsに301されることを期待している場合、nginxはファイルがhttpサーバーに対して大きすぎるため、リダイレクトの前に実際に接続をドロップするため、で両方。

最近のコメントは、新しいnginxバージョンのSSLでこれに問題があることを示唆していますが、私は1.4.6を使用しており、すべてが良好です:)

次の変更を適用する必要があります。

1. 更新php.ini（から正しいiniファイルを検索phpinfo();）しpost_max_size、upload_max_filesize必要なサイズに増やします。

   sed -i "s/post_max_size =.*/post_max_size = 200M/g" /etc/php5/fpm/php.ini
   sed -i "s/upload_max_filesize =.*/upload_max_filesize = 200M/g" /etc/php5/fpm/php.ini```
   

2. あなたのウェブサイトおよび追加の更新nginxの設定client_max_body_sizeあなたの値location、httpまたはserverコンテキスト。

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. NginXとPHP-FPMを再起動します。

   service nginx restart
   service php5-fpm restart
   

注：php-fpmサービスコマンドで適切に更新されなかった場合、いつか（私の場合はほぼ毎回）プロセスを強制終了する必要があります。これを行うには、プロセスのリストを取得し（ps -elf | grep php-fpm）、1つずつ削除する（kill -9 12345）か、次のコマンドを使用して実行します。

ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9

http_}ブロック内でclient_max_body_sizeディレクティブを設定していて、場所{}ブロック内ではないかどうかを確認してください。私はそれをhttp {}ブロック内に設定し、それは動作します

これが悪い場合は誰かが私を修正しますが、私はできるだけすべてをロックダウンしたいと思います。アップロードのターゲットが1つしかない場合（通常の場合）、変更をその1つのファイルにターゲットします。これは、Ubuntu nginx-extras mainline 1.7+パッケージで私のために動作します：

location = /upload.php {
    client_max_body_size 102M;
    fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
    (...)
}

最近同様の問題があり、そのような問題client_max_body_size 0;を解決できることがわかりました。これにより、client_max_body_sizeが無制限に設定されます。ただし、ベストプラクティスはコードを改善することです。そのため、この制限を増やす必要はありません。

他の回答ですでにclient_max_body_sizeとさまざまなPHP設定（upload_max_filesize / post_max_sizeなど）を設定し、結果なしでNGINXとPHPを再起動または再ロードしたと仮定して、これを実行します...

nginx -T

これにより、NGINX構成で未解決のエラーが発生します。私の場合、修正が必要なNGINX構成（証明書の誤ったパス）に他の未解決のSSLエラーがいくつかあることに気づく前に、丸1日の間413エラーと格闘しました。「nginx -T」から得られた未解決の問題を修正したら、NGINX、およびEUREKAを再ロードしました!! それで直った。

私は古いライブサーバーをミラーリングするために開発サーバーをセットアップしています。PerfectServer-Ubuntu 14.04（nginx、BIND、MySQL、PHP、Postfix、Dovecot、ISPConfig 3）を使用しました。

同じ問題が発生した後、私はこの投稿に出くわし、何も機能しませんでした。すべての推奨ファイル（nginx.conf、ispconfig.vhost、/ sites-available / defaultなど）の値を変更しました

最後に、client_max_body_size私の中で変更して/etc/nginx/sites-available/apps.vhostnginxを再起動することがトリックをしたものです。うまくいけば、それは他の誰かを助けます。

同じ問題に遭遇しましたが、nginxとは何の関係もありませんでした。nodejsをバックエンドサーバーとして使用し、nginxをリバースプロキシとして使用しています。413コードはノードサーバーによってトリガーされます。node use koa本体を解析します。koaはurlencodedの長さを制限します。

formLimit：URLエンコードされた本体の制限。ボディがこの制限より大きくなると、413エラーコードが返されます。デフォルトは56kbです。

formLimitをより大きく設定すると、この問題を解決できます。

client_max_body_size指令が無視されたのと同じ問題があった。

私の愚かなエラーは、/etc/nginx/conf.d末尾がでないファイルを中に入れたことでした.conf。Nginxはデフォルトではこれらをロードしません。

Windowsバージョンのnginxを使用している場合は、すべてのnginxプロセスを強制終了してから再起動して確認できます。私の環境で同じ問題が発生しましたが、このソリューションで解決しました。