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

ssl_session_cache   shared:le_nginx_SSL:64m;
ssl_session_timeout 1800m;

Ошибка

Skipping acquire of configured file 'nginx/binary-i386/Packages' as repository 'http://nginx.org/packages/ubuntu focal InRelease' doesn't support architecture 'i386'

Решение

Заменить

deb http://nginx.org/packages/ubuntu/ focal nginx
deb-src http://nginx.org/packages/ubuntu/ focal nginx

На

deb [arch=amd64] http://nginx.org/packages/ubuntu/ focal nginx
deb-src http://nginx.org/packages/ubuntu/ focal nginx

для apache

proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;

для fpm

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;

Ошибка: 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 (ограничение на количество ожидающих запросов открытия соединений к файловым сокетам)

Посмотреть текущие значения можно так

cat /proc/sys/net/core/somaxconn
cat /proc/sys/net/core/netdev_max_backlog

Решение: добавить в sysctl.conf

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535

Высокие значения указаны лишь для примера и лучше использовать подходящие под конкретную систему.

К сожалению это не помогло.

Понадобилась еще одна настройки в fpm пуле

listen.backlog = 65535

или установить unlimited

listen.backlog = -1

изучить дополнительно / технические детали на otus.ru

https://ornix.livejournal.com/55738.html

OKGOOGLE. Проверим текущие soft/hard лимиты файловых дескрипторов и открытых файлов для master процесса nginx

# cat /proc/$(cat /var/run/nginx.pid)/limits|grep open.files
Max open files            1024                4096                files   

Далее (подсмотрел на stackoverflow кажется) проверим для дочерних процессов (worker)

# 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  

Добавить в /etc/security/limits.conf 16384

nginx soft nofile 16384
nginx hard nofile 16384

В nginx.conf установить

• worker_processes 4;
• worker_connections 4096;
• worker_rlimit_nofile 16384;

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

upd

в centos7 /etc/systemd/system/nginx.service.d добавить conf

[Service] 
LimitNOFILE=16384

server_names_hash_bucket_size

Ошибка

could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Просто сделай больше

    http {

    ...snip...
    server_names_hash_bucket_size 64;
    ...snip...

    }

Ошибка появляется при загрузке файлов больше 1 мегабайта. Одна из причин — это дефолтные настройки nginx, а точнее параметра client_max_body_size, который по умолчанию равен 1m

Директива client_max_body_size задаёт максимально допустимый размер тела запроса клиента, указываемый в строке "Content-Length" в заголовке запроса. Если размер больше заданного, то клиенту возвращается ошибка "Request Entity Too Large" (413). Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку.

Подробнее в документацииclient_max_body_size

Решение
Изменить размер client_max_body_size

Что такое proxy_buffer_size и proxy_buffers.

Исправляется добавлением двух последних строк в конфиг Nginx:

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

proxy_buffers 8 16k;
proxy_buffer_size 32k;

А если по-русски, то proxy_buffer_size предназначен для хранения, прочтенного с бэкэнда хидера:

proxy_buffer_size and fastgci_buffer_size set buffer to read the whole of
response header from backend or fastcgi server.

То есть, если Вы уже выставили 32к, а ошибка все равно появляется, то нужно тюнить дальше.
Если же просто увеличить 32к до 64к, то можно получить вот такую ошибку:

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

Итого, если указанных в самом верху настроек мало, корректируем так:

proxy_buffers 8 32k;
proxy_buffer_size 64k;

И еще. fastcgi paramaters that appear to be currently working

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

• 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

Небольшая заметка на тему косяка в апаче (это всё-таки он игнорирует то, что ему передали HTTP/1.0, и отдаёт с HTTP/1.1)

В качестве обхода проблемы (особенно если используется не Apache) по идее также должна помочь установка nginx >= 1.1.4 или chunked_transfer_encoding off.

http://habrahabr.ru/blogs/nginx/135662/

nginx via https://ruhighload.com/post/414+Request+URI+Too+Large

large_client_header_buffers 4 16k

Здесь 16k байт и будет желаемым размером URL-адреса, а 4 — количеством желаемых буферов

Большой URL, в основном из-за плохого дизайна приложения.

apache

Увеличиваем размер для limit request line и limit request field size.

LimitRequestLine      102400
LimitRequestFieldSize 102400

via http://dragonflybsd.blogspot.com/2012/04/nginx-504-ssldohandshake-failed.html

При проксировании https даже без сертификатов (чисто прокси) при реальной работе ловили

SSL_do_handshake() failed (SSL: error:1408C095:SSL routines:SSL3_GET_FINISHED:digest check failed) while SSL handshaking to upstream

и 502 Bad Gateway.

Как ни странно, гугл дал всего 4 страницы, из которой только 1 была с решением:

proxy_ssl_session_reuse off;

Помогло. Непонятно, что это было и почему… Проверять можно было через openssl s_client -connect www.test.com:81 -state -ssl3 -no_ssl2 -no_tls1 в несколько потоков.

Самое просто решение - почистить куки. Если же сервер наш, можно подкрутить настройки серверов:

для nginx это

large_client_header_buffers 4 8k;

Можно выставить например 16к, но дальше будет ошибка

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Потому что надо увеличить эти же значения и для apache

LimitRequestFieldSize 8190

Можно выставить

LimitRequestFieldSize 16380

via

server_names_hash_bucket_size 64;