nginx-client_max_body_size는 영향을 미치지 않습니다

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 사이트에서 성공적으로 작동하고 있습니다 (마침내 & rjha94의 제안에 따라).그들의 제안에 약간의 설명을 추가하면 누군가에게 도움이 될 것이라고 생각했습니다. 우선 모든 3 개의 개별 정의 블록 (서버, 위치 및 http)에 증가 된 업로드 지시문을 포함 시켰는지 확인하십시오. 각각 별도의 줄 항목이 있어야합니다. 결과는 다음과 같습니다 (여기서 ...는 정의 블록의 다른 줄을 나타냄).

http {
    ...
    client_max_body_size 200M;
}    

(ISPconfig3 설정에서이 블록은 /etc/nginx/nginx.conf 파일에 있습니다)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(ISPconfig3 설정에서이 블록들은 /etc/nginx/conf.d/default.conf 파일에 있습니다)또한 서버의 php.ini 파일이 이러한 NGINX 설정과 일치하는지 확인하십시오. 필자의 경우 php.ini의 File_Uploads 섹션의 설정을 다음과 같이 변경했습니다.

upload_max_filesize = 200M

참고 : ISPconfig 3 설정을 관리하는 경우 (

완벽한 서버에

따라 CentOS 6.3에 설정이 있음 ) 여러 항목으로이 항목을 관리해야합니다. 구성이 단계별 설정의 구성과 유사하면 수정해야 할 NGINX conf 파일은 다음 위치에 있습니다.

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

내 php.ini 파일은 다음 위치에 있습니다.

/etc/php.ini

nginx.conf 파일에서 http {} 블록을 계속 간과했습니다. 이것을 간과하면 업로드를 1M 기본 제한으로 제한하는 효과가있었습니다. 연관된 변경을 수행 한 후에는 NGINX 및 PHP FastCGI Process Manager (PHP-FPM) 서비스를 다시 시작해야합니다. 위의 구성에서 다음 명령을 사용합니다.

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

---

현재

2016년 3월

, 나는 (그것이 중요하지 않는 것이, 파이썬 요청에서) HTTPS를 통해 POST의 JSON하려고이 문제에 달렸다.비결은

"client_max_body_size 200M;"입니다. 두 개 이상의 장소에서 http {}와server {}

:

1.

 

http

디렉토리

• 일반적으로 /etc/nginx/nginx.conf

2.

 

server

호스트 의 디렉토리.

• apt-get을 통해 설치 한 데비안 / 우분투 사용자 (및 기본적으로 /etc/nginx/sites-available/mysite.comvgins 와 함께 nginx를 설치하는 다른 배포판 패키지 관리자)의 경우 vhost가없는 사용자의 경우 아마도 nginx.conf이거나 동일한 디렉토리에있을 것입니다.

3.

2

location /

와 같은 위치에 있는 디렉토리

• 보다 구체적 일 수는 /있지만 전혀 작동하지 않으면 이것을 적용 /한 다음 작동이 더 구체적 일 것을 권장 합니다.

기억

- 당신은 SSL이있는 경우, 즉 SSL에 대한 위의를 설정해야하는 것

server

하고

location

도 어디든지 그 (이상적으로 동일 할 수있다

2

). 클라이언트가 http에 업로드하려고 시도하고 클라이언트가 https에 301'd를 얻으려고하면 파일이 http 서버에 비해 너무 커서 리디렉션하기 전에 nginx가 실제로 연결을 끊어 버린다는 것을 알았습니다. 에서

모두

.최근 의견에 따르면 최신 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

)을 가져와 하나씩 죽이거나 (

kill -9 12345

) 다음 명령을 사용하여 수행 할 수 있습니다.

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

---

위치 {} 블록이 아닌 http {} 블록 내에서 client_max_body_size 지시문을 설정하고 있는지 확인하십시오. http {} 블록 안에 설정했으며 작동합니다.

---

Someone correct me if this is bad, but I like to lock everything down as much as possible, and if you've only got one target for uploads (as it usually the case), then just target your changes to that one file. This works for me on the Ubuntu nginx-extras mainline 1.7+ package:

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

---

Assuming you have already set the client_max_body_size and various PHP settings (upload_max_filesize / post_max_size , etc) in the other answers, then restarted or reloaded NGINX and PHP without any result, run this...

nginx -T

This will give you any unresolved errors in your NGINX configs. In my case, I struggled with the 413 error for a whole day before I realized there were some other unresolved SSL errors in the NGINX config (wrong pathing for certs) that needed to be corrected. Once I fixed the unresolved issues I got from 'nginx -T', reloaded NGINX, and EUREKA!! That fixed it.

---

I'm setting up a dev server to play with that mirrors our outdated live one, I used The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot and ISPConfig 3)

After experiencing the same issue, I came across this post and nothing was working. I changed the value in every recommended file (nginx.conf, ispconfig.vhost, /sites-available/default, etc.)

Finally, changing client_max_body_size in my /etc/nginx/sites-available/apps.vhost and restarting nginx is what did the trick. Hopefully it helps someone else.

---

I meet the same problem, but I found it nothing to do with nginx. I am using nodejs as backend server, use nginx as a reverse proxy, 413 code is triggered by node server. node use koa parse the body. koa limit the urlencoded length.

formLimit: limit of the urlencoded body. If the body ends up being larger than this limit, a 413 error code is returned. Default is 56kb.

set formLimit to bigger can solve this problem.

---

I had a similar problem recently and found out, that client_max_body_size 0; can solve such an issue. This will set client_max_body_size to no limit. But the best practice is to improve your code, so there is no need to increase this limit.

---

Had the same issue that the client_max_body_size directive was ignored.

My silly error was, that I put a file inside /etc/nginx/conf.d which did not end with .conf. Nginx will not load these by default.

---

If you are using windows version nginx, you can try to kill all nginx process and restart it to see. I encountered same issue In my environment, but resolved it with this solution.

참고URL : https://stackoverflow.com/questions/2056124/nginx-client-max-body-size-has-no-effect