Причины ошибки и способы решения - connect() to unix:/run/php-fpm/www.sock failed (Resource temporarily unavailable) while connecting to upstream)

Ошибка "connect() to unix:/run/php-fpm/www.sock failed (11: Resource temporarily unavailable) while connecting to upstream" возникает, когда Nginx не может установить соединение с PHP-FPM через Unix domain socket. Это может быть вызвано несколькими причинами. Вот некоторые из них и способы решения проблемы:

1. PHP-FPM не запущен: Проверьте, что процесс PHP-FPM работает и слушает на правильном Unix domain socket. Вы можете выполнить команду для проверки состояния PHP-FPM:

#bash
sudo systemctl status php-fpm

#bash 
sudo systemctl start php-fpm

2. Неправильный путь к Unix domain socket: Убедитесь, что путь к Unix domain socket, указанный в настройках PHP-FPM, совпадает с тем, который использует Nginx для соединения. Проверьте настройки PHP-FPM в файле конфигурации /etc/php/{версия PHP}/fpm/pool.d/www.conf и убедитесь, что параметр listen указывает на правильный путь к socket.

3. Ошибки разрешения прав доступа: Проверьте права доступа к Unix domain socket. Обычно PHP-FPM работает с правами пользователя www-data (или другого пользователя www-data), а Nginx работает также от имени этого же пользователя. Убедитесь, что оба процесса имеют доступ к Unix domain socket.

4. Недостаток ресурсов: Ошибка "Resource temporarily unavailable" может быть вызвана недостатком ресурсов, таких как файловые дескрипторы или процессы. Убедитесь, что система не достигла лимита на количество открытых файлов или процессов. Вы можете проверить текущие значения лимитов с помощью команды ulimit -a.

Значение по умолчанию 128 = соединения через каждый файловый сокет. Во время теста высокой нагрузки или производительности в журнале Nginx появится такая проблема:

*1 connect() to
unix:/run/php/php8.0-fpm.sock failed (11: Resource temporarily unavailable)

Убедитесь, что ограничения операционной системы позволяют использовать указанное выше значение.

Запустите:

sysctl net.core.somaxconn

Если отображает значение 128, попробуйте ег увеличить.

Меняем лимиты — в файле /etc/sysctl.conf меняем или добавляем эти строки:

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

Применяем параметры

$ sudo sysctl -p

и перезапускаем сервер.

Если перезагрузить нельзя, то перезапускаем php-fpm:

$ sudo service php8.0-fpm restart

и web-сервер nginx:

$ sudo service nginx restart

Это может быть следствием DoS/DDoS атаки

Как вариант можно на разные домены поставить разные хосты (домены) разные сокеты разных пхп.

или увеличить количество соединений на один сокет. или добавить защиту от Дос атак.

читайте подробнее ниже о сособах борьбы с этим злом.

5. Конфликт портов: Если у вас используется TCP-порт вместо Unix domain socket для связи Nginx с PHP-FPM, убедитесь, что не происходит конфликта портов. Убедитесь, что PHP-FPM слушает на правильном порту и в конфигурации Nginx указан правильный адрес и порт для соединения с PHP-FPM.

6. Проблемы с сетевыми правами: Если у вас есть специфические настройки безопасности или прокси, убедитесь, что они не блокируют соединение между Nginx и PHP-FPM.

Если после проверки указанных выше причин проблема не устраняется, рекомендуется дополнительно изучить журналы ошибок Nginx (/var/log/nginx/error.log) и PHP-FPM (/var/log/php-fpm.log) для получения более подробной информации о возникшей ошибке. Это поможет уточнить проблему и найти специфическое решение для вашей конфигурации

Если это всеже dos атака то можно

• 1) заблокировать пачки ип адресов.
• 2) выдавать статическую страницу с вставкой жс и динамичекую страницу
• 3) регулировать и ограничить количество запросов в единицу времени

1) заблокировать пачки ип адресов.

Для этого в нжин файл в секцию сервер добавьте эти ип адреса, например

deny 93.91.115.16;
deny 45.152.188.241; 

#или заблокируйте все кроме своего ип

allow 1.1.1.1;
deny all;

Получить список всех подозрительных ип легко из логов с помощью регулярых выражений (потом нужно разрешить посиковивки иливооще снять ограничения).

#распарсить ip
grep -oE '(^| )((25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])(\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])){3})($| )' /var/www/site.com/logs/nginxaccess.log | sort | uniq

#добавить deny  и точку с запятой 
sed -i 's/^/deny /; s/$/;/' /var/www/site.com/logs/nginxaccess.log

Добавляем этот список через инклуде в nginx, перезапускаем

server {
   #return 401; -можем временно включить

    server_name    intellect.icu;
    root           /var/www/intellect.icu/;
    index          index.php;

#    error_log /var/www/intellect.icu/logs/nginxerror.log; - временно отключаем
    access_log /var/www/intellect.icu/logs/nginxaccess.log;

include /etc/nginx/blockips.conf; 
...

2) выдавать статическую страницу с вставкой жс и динамичекую страницу

Если все запросы дрос атаки выполнятся с разных ип адресов но на один урл например индекс то можно попосбовать добвить выдачу разных страниц для главной других, Для настройки Nginx так, чтобы он отдавал статическую страницу index.html для индексного запроса (запроса на корневой URL) и обрабатывал все остальные URL через файл index.php, вы можете использовать два отдельных location блока в конфигурации Nginx. Вот как это можно сделать:

server {
    listen 80;
    server_name example.com;

    # Корневой каталог вашего веб-сайта
    root /path/to/your/website;

    location = / {
        # Обработка индексного запроса
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location / {
        # Обработка всех остальных URL через index.php
        index index.php;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        # Настройки обработки PHP файлов (FastCGI, PHP-FPM и т. д.)
    }

    # Другие настройки сервера
}

3) регулировать и ограничить количество запросов в единицу времени

Чтобы регугировать количество запростов в единицу времени Nginx можно использовать модуль ngx_http_limit_req

Так же можно попробовать сделать ограничение скорости обработки запросов в nginx с помощью встроенного модуля ngx_http_limit_req.

в файл конфигурационный файл Nginx. Обычно это файл /etc/nginx/nginx.conf добавьте

   limit_req_zone $binary_remote_addr zone=limit_by_ip:10m rate=2r/m;
   limit_req_zone $request_uri zone=limit_by_url:10m rate=5r/s;

Далее, в блоке server, к которому хотите применить ограничение, добавьте следующую директиву limit_req:

server {
    # ... Другие настройки nginx...

    location / {
        # Применяем ограничение из зон "limit_by_ip и limit_by_url"
        limit_req zone=limit_by_ip;
        limit_req zone=limit_by_url;

        #если нужно применить паарметры burst или nodelay

        limit_req zone=limit_by_url burst=5 nodelay;
        # Другие директивы обработки запросов
    }

    # ... Другие настройки nginx...
}​

В приведенном выше примере мы создали зону ограничения с именем "limit_by_ip" и объемом 10 МБайт. Мы установили ограничение до 2х запросов в секунду (rate=2r/s) для каждого уникального IP-адреса ($binary_remote_addr). И зону ограничения с именем "limit_by_url" и объемом 10 МБайт с ограничением до 5-ти запросов в секунду (rate=5r/s) для каждого уникального урл ($request_uri ).

При этом NGINX будет использовать алгоритм «дырявое ведро» (leaky bucket). Для NGINX 300r/m и 5r/s одинаковы: он будет пропускать один запрос каждые 0,2 с. В данном случае NGINX каждые 0,2 секунды будет устанавливать флаг, разрешающий прием запроса. Когда приходит подходящий для этой зоны запрос, NGINX снимает флаг и обрабатывает запрос. Если приходит очередной запрос, а таймер, считающий время между пакетами, еще не сработал, запрос будет отклонен с HTTP кодом состояния 503. Если время истекло, а флаг уже установлен в разрешающее прием значение, никаких действий предприниматься не будет.