Различия

Показаны различия между двумя версиями страницы.

Посмотреть различия двумя колонкамивнутри текста Go

Ссылка на это сравнение

Предыдущая версия справа и слеваПредыдущая версия 2024/11/04 14:21 dx 2024/11/04 14:09 dx 2022/07/19 17:59 dx 2022/04/15 22:04 dx 2021/08/17 01:03 dx 2021/06/24 02:08 dx 2021/05/27 01:54 dx 2021/05/17 17:38 dx 2021/05/17 17:18 dx 2021/05/17 17:14 dx 2021/05/17 17:06 dx 2021/05/16 21:11 dx 2020/04/03 15:07 внешнее изменениеGo Следующая версия		Предыдущая версия 2024/11/04 14:21 dx 2024/11/04 14:09 dx 2022/07/19 17:59 dx 2022/04/15 22:04 dx 2021/08/17 01:03 dx 2021/06/24 02:08 dx 2021/05/27 01:54 dx 2021/05/17 17:38 dx 2021/05/17 17:18 dx 2021/05/17 17:14 dx 2021/05/17 17:06 dx 2021/05/16 21:11 dx 2020/04/03 15:07 внешнее изменениеGo
linux:nginx:nginx_error [2021/05/17 17:14] – dx		linux:nginx:nginx_error [2024/11/04 14:21] (текущий) – dx
Строка 1:		Строка 1:
		+	====== nginx: коллекция ошибок ======
		+	==== http2 deprecated ====
		+
		+	Ошибка **nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in etc/nginx/nginx.conf :15**
		+
		+	Заменить
		+
		+	<code bash>listen 443 ssl http2;</code>
		+
		+	На
		+
		+	<code bash>
		+	listen 443 ssl;
		+	http2 on;
		+	</code>
		+
		+	Заменить быстро везде
		+
		+	<code bash>sed -i 's/listen 443 ssl http2;/listen 443 ssl;\nhttp2 on;/g' *</code>
		+
		+	==== could not allocate new session in ssl session shared cache le_nginx_ssl while ssl handshaking ====
		+
		+	https://trac.nginx.org/nginx/ticket/621
		+
		+	//For now you may use smaller session timeouts and/or a larger shared memory zone. This way sessions will expire and will be removed from the cache before the cache will be overflowed, and no errors will happen.//
		+
		+	т.е. **ssl_session_cache** и **ssl_session_timeout**
		+
		+	<code bash>
		+	ssl_session_cache   shared:le_nginx_SSL:64m;
		+	ssl_session_timeout 1800m;
		+	</code>
		+
		+	==== Skipping acquire of configured file 'nginx/binary-i386/Packages' ====
		+
		+	**Ошибка**
		+
		+	<code>
		+	Skipping acquire of configured file 'nginx/binary-i386/Packages' as repository 'http://nginx.org/packages/ubuntu focal InRelease' doesn't support architecture 'i386'
		+	</code>
		+
		+	**Решение**
		+
		+	Заменить
		+
		+	<code>
		+	deb http://nginx.org/packages/ubuntu/ focal nginx
		+	deb-src http://nginx.org/packages/ubuntu/ focal nginx
		+	</code>
		+
		+	На
		+
		+	<code>
		+	deb [arch=amd64] http://nginx.org/packages/ubuntu/ focal nginx
		+	deb-src http://nginx.org/packages/ubuntu/ focal nginx
		+	</code>
		+
		+	==== upstream timed out (110: Connection timed out) while reading response header from upstream ====
		+
		+	для apache
		+	<code>
		+	proxy_connect_timeout 300;
		+	proxy_send_timeout 300;
		+	proxy_read_timeout 300;
		+	</code>
		+
		+	для fpm
		+
		+	<code>
		+	fastcgi_connect_timeout 60;
		+	fastcgi_send_timeout 180;
		+	fastcgi_read_timeout 180;
		+	</code>
		+
		+	FIXME
		+
		+	==== sock failed (11: Resource temporarily unavailable) while connecting to upstream ====
		+
		+	Ошибка: connect() to unix:/var/www/php-fpm/www.sock failed (11: Resource temporarily unavailable) while connecting to upstream
		+
		+	Браузер возвращает **502 Bad Gateway**.
		+
		+	nginx работает с php через сокеты. Проблема в дефолтных лимитах
		+
		+	* net.core.somaxconn = 128 (ограничение на количество открытых соединений к файловым сокетам)
		+	* net.core.netdev_max_backlog = 200 (ограничение на количество ожидающих запросов открытия соединений к файловым сокетам)
		+
		+	Посмотреть текущие значения можно так
		+
		+	<code>
		+	cat /proc/sys/net/core/somaxconn
		+	cat /proc/sys/net/core/netdev_max_backlog
		+	</code>
		+
		+	Решение: добавить в ''sysctl.conf''
		+
		+	<code>
		+	net.core.somaxconn = 65535
		+	net.core.netdev_max_backlog = 65535
		+	</code>
		+
		+	Высокие значения указаны лишь для примера и лучше использовать подходящие под конкретную систему.
		+
		+	К сожалению это не помогло.
		+
		+	Понадобилась еще одна настройки в fpm пуле
		+
		+	<code>listen.backlog = 65535</code>
		+
		+	или установить unlimited
		+
		+	<code>listen.backlog = -1</code>
		+
		+	FIXME изучить дополнительно / [[https://otus.ru/nest/post/348/|технические детали]] на otus.ru
		+
		+	==== fastcgi_intercept_errors ====
		+
		+	https://ornix.livejournal.com/55738.html
		+
		+	==== nginx: [warn] 4096 worker_connections exceed open file resource limit: 1024 ====
		+
		+	OKGOOGLE. Проверим текущие soft/hard лимиты файловых дескрипторов и открытых файлов для master процесса nginx
		+
		+	<code>
		+	# cat /proc/$(cat /var/run/nginx.pid)/limits|grep open.files
		+	Max open files            1024                4096                files
		+	</code>
		+
		+	Далее (подсмотрел на stackoverflow кажется) проверим для дочерних процессов (worker)
		+
		+	<code>
		+	# ps --ppid $(cat /var/run/nginx.pid) -o %p|sed '1d'|xargs -I{} cat /proc/{}/limits|grep open.files
		+	Max open files            1024                4096                files
		+	Max open files            1024                4096                files
		+	Max open files            1024                4096                files
		+	Max open files            1024                4096                files
		+	</code>
		+
		+	Добавить в ''/etc/security/limits.conf''
		+	16384
		+	<code>
		+	nginx soft nofile 16384
		+	nginx hard nofile 16384
		+	</code>
		+
		+	В ''nginx.conf'' установить
		+	* worker_processes 4;
		+	* worker_connections 4096;
		+	* worker_rlimit_nofile 16384;
		+
		+	<code>
		+	for pid in `pidof nginx`; do echo "$(< /proc/$pid/cmdline)"; egrep 'files|Limit' /proc/$pid/limits; echo "Currently open files: $(ls -1 /proc/$pid/fd | wc -l)"; echo; done
		+	</code>
		+
		+	upd FIXME
		+
		+	в centos7 ''/etc/systemd/system/nginx.service.d'' добавить conf
		+
		+	<code>
		+	[Service]
		+	LimitNOFILE=16384
		+	</code>
		+
		+	==== could not build the server_names_hash ====
		+
		+	[[http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_names_hash_bucket_size|server_names_hash_bucket_size]]
		+
		+	Ошибка
		+
		+	<code>
		+	could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32
		+	</code>
		+
		+	Просто сделай больше LOL
		+
		+	<code>
		+	http {
		+
		+	...snip...
		+	server_names_hash_bucket_size 64;
		+	...snip...
		+
		+	}
		+	</code>
		+
		+	==== 413 Request Entity Too Larget ====
		+
		+	Ошибка появляется при загрузке файлов больше 1 мегабайта. Одна из причин — это дефолтные настройки nginx, а точнее параметра **client_max_body_size**, который по умолчанию равен 1m
		+
		+	Директива **client_max_body_size** задаёт максимально допустимый размер тела запроса клиента, указываемый в строке "Content-Length" в заголовке запроса. Если размер больше заданного, то клиенту возвращается ошибка "Request Entity Too Large" (413). Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку.
		+
		+	Подробнее в документации[[http://nginx.org/ru/docs/http/ngx_http_core_module.html#client_max_body_size|client_max_body_size]]
		+
		+	Решение\\
		+	Изменить размер **client_max_body_size**
		+
		+	==== upstream sent too big header while reading response header from upstream, client ====
		+
		+	Что такое [[http://wiki.nginx.org/NginxHttpProxyModule#proxy_buffer_size|proxy_buffer_size]] и [[http://wiki.nginx.org/NginxHttpProxyModule#proxy_buffers|proxy_buffers]].
		+
		+	Исправляется добавлением двух последних строк в конфиг Nginx:
		+
		+	<code>
		+	http {
		+	include /etc/nginx/mime.types;
		+	default_type application/octet-stream;
		+
		+	proxy_buffers 8 16k;
		+	proxy_buffer_size 32k;
		+	</code>
		+
		+	А если по-русски, то **proxy_buffer_size** предназначен для хранения, прочтенного с бэкэнда хидера:
		+
		+	<code>
		+	proxy_buffer_size and fastgci_buffer_size set buffer to read the whole of
		+	response header from backend or fastcgi server.
		+	</code>
		+
		+	То есть, если Вы уже выставили 32к, а ошибка все равно появляется, то нужно тюнить дальше.\\
		+	Если же просто увеличить 32к до 64к, то можно получить вот такую ошибку:
		+
		+	<code>
		+	Restarting nginx: [emerg]: "proxy_busy_buffers_size" must be less than the size of all
		+	"proxy_buffers" minus one buffer in /etc/nginx/nginx.conf:34017
		+	</code>
		+
		+	Итого, если указанных в самом верху настроек мало, корректируем так:
		+
		+	<code>
		+	proxy_buffers 8 32k;
		+	proxy_buffer_size 64k;
		+	</code>
		+
		+	И еще. fastcgi paramaters that appear to be currently working
		+
		+	<code>
		+	fastcgi_connect_timeout 60;
		+	fastcgi_send_timeout 180;
		+	fastcgi_read_timeout 180;
		+	fastcgi_buffer_size 128k;
		+	fastcgi_buffers 4 256k;
		+	fastcgi_busy_buffers_size 256k;
		+	fastcgi_temp_file_write_size 256k;
		+	fastcgi_intercept_errors on
		+	</code>
		+
		+	* http://forum.nginx.org/read.php?2,188352
		+	* http://phpsuxx.blogspot.com/2009/11/upstream-sent-too-big-header-while.html
		+	* http://blog.rackcorp.com/?p=14
		+
		+	==== Ошибки 404/403 apache+nginx HTTP/1.0 HTTP/1.1 ====
		+
		+	//Небольшая заметка на тему косяка в апаче (это всё-таки он игнорирует то, что ему передали HTTP/1.0, и отдаёт с HTTP/1.1)//
		+
		+	В качестве обхода проблемы (особенно если используется не Apache) по идее также должна помочь установка nginx >= 1.1.4 или **chunked_transfer_encoding off**.
		+
		+	http://habrahabr.ru/blogs/nginx/135662/
		+
		+	==== 414 Request URI Too Large ====
		+
		+	**nginx** via https://ruhighload.com/post/414+Request+URI+Too+Large
		+
		+	''large_client_header_buffers 4 16k''
		+
		+	//Здесь 16k байт и будет желаемым размером URL-адреса, а 4 — количеством желаемых буферов//
		+
		+	Большой URL, в основном из-за плохого дизайна приложения.
		+
		+	FIXME **apache**
		+
		+	Увеличиваем размер для [[http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline|limit request line]] и [[http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize|limit request field size]].
		+
		+	<code>
		+	LimitRequestLine      102400
		+	LimitRequestFieldSize 102400
		+	</code>
		+
		+	==== 504 SSL_do_handshake() failed  ====
		+
		+	via http://dragonflybsd.blogspot.com/2012/04/nginx-504-ssldohandshake-failed.html
		+
		+	При проксировании https даже без сертификатов (чисто прокси) при реальной работе ловили
		+	<code>SSL_do_handshake() failed (SSL: error:1408C095:SSL routines:SSL3_GET_FINISHED:digest check failed) while SSL handshaking to upstream</code>
		+
		+	и 502 Bad Gateway.
		+
		+	Как ни странно, гугл дал всего 4 страницы, из которой только 1 была [[http://mailman.nginx.org/pipermail/nginx/2010-October/023224.html|с решением]]:
		+	<code>proxy_ssl_session_reuse off;</code>
		+
		+	Помогло. Непонятно, что это было и почему... Проверять можно было через openssl s_client -connect www.test.com:81 -state -ssl3 -no_ssl2 -no_tls1 в несколько потоков.
		+
		+	==== 400 Bad Request Request Header Or Cookie Too Large ====
		+
		+	Самое просто решение - почистить куки. Если же сервер наш, можно подкрутить настройки серверов:
		+
		+	для nginx [[http://wiki.nginx.org/HttpCoreModule#large_client_header_buffers|это]]
		+	<code>large_client_header_buffers 4 8k;</code>
		+
		+	Можно выставить например 16к, но дальше будет ошибка
		+	<code>Your browser sent a request that this server could not understand.
		+	Size of a request header field exceeds server limit.</code>
		+
		+	Потому что надо увеличить эти же значения и для apache
		+	<code>LimitRequestFieldSize 8190</code>
		+
		+	Можно выставить
		+	<code>LimitRequestFieldSize 16380</code>
		+
		+	[[http://dragonflybsd.blogspot.ru/2012/08/400-bad-request-request-header-or.html|via]]
		+
		+	==== could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32 ====
		+
		+	<code>server_names_hash_bucket_size 64;</code>
		+
		+	{{tag>linux nginx php php-fpm}}