Да, я извиняюсь что неуточнил. Ротировать логи я умею, но хотелось бы иметь возможность как-то разделить нормальные error_log-и и этот флуд, а так как у флуда уровень [crit] повысить уровень непомогает. Рассматривал как вариант вписать в https-ный виртуальный хост отдельный error_log или даже отправить еuо в /dev/null, но и это не лучший вариант - при норм работе HTTPS тоже бывают ошибки о которых бы полезно было знать. Вобщем логи - вещь вторая. Самое главное это пропадание сервиса, причем пропадает сервис только на 443 порту, а на 80ом все продолжает работать шустро и быстро, без всяких проблем. Сокеты незаканчиваються точно, процессор тоже как здесь упомянули незагружен. Есть подозрения что заканчиваеться место в каком то разделяемом буффере, а конкретно я смотрю на ssl_session_cache - у меня он был выставлен в 5мб, чего согласно доке должно хватить на примерно 20000 коннектов. Я несчитал точно, но допускаю возможность что в какой-то момент кол-во хостов учавствующих в ддосе растет до указанной цифры (может не одновременно а последовательно) и в результате место в буфере кончаеться чт ои приводе в отказу в обслуживании. Кроме того нестоит забывать о висящих при этом в состоянии CLOSE_WAIT сокетов - это ж не с проста. Предпологаю (неуверен - в исходниках не копался еще) что перед инициализацией шифрования резервируеться место в этом буффере, а после ошибки инициализации и закрытию сокета зарезервированная область не освобождаеться и висит там до таймаута.