====== 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}}