Различия

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

--- linux:nginx:nginx_error [2024/11/04 14:09] – 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''
+<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}}