nginx - client_max_body_size không có hiệu lực

nginx cứ nói client intended to send too large body. Googling và RTM chỉ cho tôi client_max_body_size. Tôi đặt nó thành200m trong nginx.confcũng như trong vhost confNginx, khởi động lại một vài lần nhưng tôi vẫn nhận được thông báo lỗi.

Tôi đã bỏ qua một cái gì đó? Các phụ trợ là php-fpm( max_post_sizevà max_upload_file_sizeđược thiết lập cho phù hợp).

Theo tài liệu nginx , bạn có thể đặt client_max_body_size 20m (hoặc bất kỳ giá trị nào bạn cần) trong ngữ cảnh sau:

context: http, server, location

Cuối cùng, các video tải lên lớn của NGINX đang hoạt động thành công trên các trang web WordPress được lưu trữ (theo đề xuất từ ​​nembleton & rjha94)

Tôi nghĩ rằng nó có thể hữu ích cho ai đó, nếu tôi thêm một chút làm rõ vào các đề xuất của họ. Để bắt đầu, hãy chắc chắn rằng bạn đã bao gồm chỉ thị tải lên tăng lên của mình trong TẤT CẢ BA khối định nghĩa riêng biệt (máy chủ, vị trí & http). Mỗi nên có một mục nhập riêng. Kết quả sẽ giống như thế này (trong đó ... phản ánh các dòng khác trong khối định nghĩa):

http {
    ...
    client_max_body_size 200M;
}    

(trong thiết lập ISPconfig 3 của tôi, khối này nằm trong tệp /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(trong thiết lập ISPconfig 3 của tôi, các khối này nằm trong tệp /etc/nginx/conf.d/default.conf)

Ngoài ra, hãy chắc chắn rằng tệp php.ini của máy chủ của bạn phù hợp với các cài đặt NGINX này. Trong trường hợp của tôi, tôi đã thay đổi cài đặt trong phần File_Uploads của php.ini để đọc:

upload_max_filesize = 200M

Lưu ý: nếu bạn đang quản lý thiết lập ISPconfig 3 (thiết lập của tôi là trên CentOS 6.3, theo Máy chủ hoàn hảo ), bạn sẽ cần quản lý các mục này trong một số tệp riêng biệt. Nếu cấu hình của bạn tương tự như trong thiết lập từng bước, các tệp conf NGINX bạn cần sửa đổi được đặt ở đây:

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

Tệp php.ini của tôi được đặt ở đây:

/etc/php.ini

Tôi tiếp tục bỏ qua khối http {} trong tệp nginx.conf. Rõ ràng, nhìn ra điều này có tác dụng giới hạn tải lên đến giới hạn mặc định 1M. Sau khi thực hiện các thay đổi liên quan, bạn cũng sẽ muốn chắc chắn khởi động lại các dịch vụ NGINX và PHP FastCGI Process Manager (PHP-FPM) của bạn. Trên cấu hình trên, tôi sử dụng các lệnh sau:

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

Tính đến tháng 3 năm 2016 , tôi gặp phải vấn đề này khi cố gắng POST json qua https (từ các yêu cầu python, không phải là vấn đề).

Mẹo nhỏ là đặt "client_max_body_size 200M;" ở ít nhất hai nơi http {}vàserver {} :

1. các httpthư mục

• Điển hình trong /etc/nginx/nginx.conf

2. các serverthư mục trong vhost của bạn.

• Đối với người dùng Debian / Ubuntu đã cài đặt qua apt-get (và các trình quản lý gói phân phối khác cài đặt nginx với vhost theo mặc định), đó là /etc/nginx/sites-available/mysite.com, đối với những người không có vhost, có thể đó là nginx.conf hoặc trong cùng thư mục với nó.

3. các location /thư mục trong cùng một vị trí như 2.

• Bạn có thể cụ thể hơn /, nhưng nếu nó không hoạt động, tôi khuyên bạn nên áp dụng điều này /và sau đó một khi nó hoạt động cụ thể hơn.

Hãy nhớ rằng - nếu bạn có SSL, điều đó sẽ yêu cầu bạn đặt ở trên cho SSL servervà locationbất cứ nơi nào có thể (lý tưởng giống như 2. ). Tôi thấy rằng nếu khách hàng của bạn cố tải lên trên http và bạn mong họ nhận được 301'd thành https, nginx sẽ thực sự hủy kết nối trước khi chuyển hướng do tệp quá lớn đối với máy chủ http, vì vậy nó phải trong cả hai .

Các ý kiến ​​gần đây cho thấy có vấn đề với SSL này với các phiên bản nginx mới hơn, nhưng tôi đang ở phiên bản 1.4.6 và mọi thứ đều tốt :)

Bạn cần áp dụng các thay đổi sau:

1. Cập nhật php.ini(Tìm đúng tệp ini từ phpinfo();) và tăng post_max_sizevà upload_max_filesizekích thước bạn muốn:

   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. Cập nhật nginx cài đặt cho trang web của bạn và add client_max_body_sizegiá trị trong bạn location, httphoặc serverbối cảnh.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Khởi động lại NginX và PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

LƯU Ý: Đôi khi (Trong trường hợp của tôi hầu như mọi lúc), bạn cần phải giết php-fpmtiến trình nếu nó không được làm mới bằng lệnh dịch vụ đúng cách. Để làm điều đó, bạn có thể lấy danh sách các tiến trình ( ps -elf | grep php-fpm) và giết từng cái một ( kill -9 12345) hoặc sử dụng lệnh sau để làm điều đó cho bạn:

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

Vui lòng xem nếu bạn đang đặt lệnh client_max_body_size bên trong khối http {} chứ không phải bên trong khối vị trí {}. Tôi đã đặt nó bên trong khối http {} và nó hoạt động

Ai đó sửa tôi nếu điều này là xấu, nhưng tôi muốn khóa mọi thứ càng nhiều càng tốt và nếu bạn chỉ có một mục tiêu để tải lên (như thường lệ), thì hãy nhắm mục tiêu thay đổi của bạn vào một tệp đó. Điều này hoạt động với tôi trên gói chính 1.7+ của Ubuntu nginx-bổ sung:

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

Tôi đã có một vấn đề tương tự gần đây và phát hiện ra, điều đó client_max_body_size 0;có thể giải quyết vấn đề như vậy. Điều này sẽ đặt client_max_body_size thành không giới hạn. Nhưng thực tiễn tốt nhất là cải thiện mã của bạn, vì vậy không cần phải tăng giới hạn này.

Giả sử bạn đã đặt client_max_body_size và các cài đặt PHP khác nhau (upload_max_filesize / post_max_size, v.v.) trong các câu trả lời khác, sau đó khởi động lại hoặc tải lại NGINX và PHP mà không có kết quả nào, hãy chạy ...

nginx -T

Điều này sẽ cung cấp cho bạn bất kỳ lỗi nào chưa được giải quyết trong cấu hình NGINX của bạn. Trong trường hợp của tôi, tôi đã vật lộn với lỗi 413 trong cả một ngày trước khi tôi nhận ra có một số lỗi SSL chưa được giải quyết khác trong cấu hình NGINX (đường dẫn sai cho certs) cần được sửa. Khi tôi đã khắc phục các sự cố chưa được giải quyết, tôi đã nhận được từ 'nginx -T', đã tải lại NGINX và EUREKA !! Điều đó đã sửa nó.

Tôi đang thiết lập một máy chủ dev để chơi với cái máy phản chiếu lỗi thời đó, tôi đã sử dụng Máy chủ hoàn hảo - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot và ISPConfig 3)

Sau khi trải qua vấn đề tương tự, tôi đã xem qua bài đăng này và không có gì là làm việc. Tôi đã thay đổi giá trị trong mỗi tệp được đề xuất (nginx.conf, ispconfig.vhost, / site-Available / default, v.v.)

Cuối cùng, thay đổi nginx client_max_body_sizecủa tôi /etc/nginx/sites-available/apps.vhostvà khởi động lại là những gì đã làm. Hy vọng nó sẽ giúp người khác.

Tôi gặp vấn đề tương tự, nhưng tôi thấy nó không liên quan gì đến nginx. Tôi đang sử dụng nodejs làm máy chủ phụ trợ, sử dụng nginx làm proxy ngược, mã 413 được kích hoạt bởi máy chủ nút. nút sử dụng koa phân tích cơ thể. koa giới hạn độ dài urlencoding.

formLimit: giới hạn của phần thân được mã hóa. Nếu phần thân kết thúc lớn hơn giới hạn này, mã lỗi 413 được trả về. Mặc định là 56kb.

đặt formLimit thành lớn hơn có thể giải quyết vấn đề này.

Có cùng một vấn đề rằng client_max_body_size chỉ thị đã bị bỏ qua.

Lỗi ngớ ngẩn của tôi là, tôi đã đặt một tập tin bên trong /etc/nginx/conf.dmà không kết thúc .conf. Nginx sẽ không tải chúng theo mặc định.

Nếu bạn đang sử dụng phiên bản nginx của windows, bạn có thể thử hủy tất cả quá trình nginx và khởi động lại để xem. Tôi gặp phải vấn đề tương tự Trong môi trường của tôi, nhưng đã giải quyết nó bằng giải pháp này.