Ошибка Nginx recv () не удалась (104: соединение сброшено узлом)

Так как пару дней назад я получаю некоторые ошибки на моем сервере. Я использую CentOS 6.5 с Parallels 12.0.18, сервер Apache для обслуживания динамического контента и Nginx в качестве прокси для обслуживания статического контента.

Сначала я получил следующую ошибку:

[error] 29951#0: *5138862 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 89.7.24.108, server: , request: "GET /page/2/ HTTP/1.1", upstream: "http://ip:7080/page/2/", host: "domain.es", referrer: "http://domain.es/"

Затем я изменил некоторые настройки, например, увеличил MaxClients в моем файле «httpd.conf», и эти строки в моем файле /etc/nginx/conf.d/timeout.conf:

proxy_connect_timeout       600;
proxy_send_timeout          600;
proxy_read_timeout          600;
send_timeout                600;

Казалось, все работает нормально, пока я снова не получил те же ошибки вместе с новой:

[error] 15228#0: *130292 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 89.130.25.154, server: domain.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:7080/", host: "domain.com"

У меня два разных сайта на одном сервере. Вот почему вы видите там два разных хоста.

Вот проблема: когда я получил эти ошибки, я получил «502 Bad Gateway», и сервер стал настолько медленным, что я даже не могу войти в систему с помощью SSH-терминала. Я могу исправить это только временно, сбросив службу httpd.

Я знаю, что есть и другие темы, похожие на эту, но все, что я нашел, это проблемы с PHP-FPM, которые я не использую.

Вот мой файл конфигурации Nginx: user nginx; рабочие_процессы 16;

error_log  /var/log/nginx/error.log;

events {
    worker_connections  1024;
}

http {
server_names_hash_max_size 2048;
server_names_hash_bucket_size 512;

server_tokens off;

include    mime.types;
default_type  application/octet-stream;

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout  10;

# Gzip on
gzip on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_buffers 4 32k;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;
gzip_disable "MSIE [1-6]\.";

# Other configurations
ignore_invalid_headers on;
client_max_body_size    8m;
client_header_timeout  3m;
client_body_timeout 3m;
#send_timeout     3m;
connection_pool_size  256;
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
request_pool_size  4k;
output_buffers   4 32k;
postpone_output  1460;

# Cache most accessed static files
open_file_cache          max=10000 inactive=10m;
open_file_cache_valid    2m;
open_file_cache_min_uses 1;
open_file_cache_errors   on;

# virtual hosts includes
include "/etc/nginx/conf.d/*.conf";
}

Вот мой файл виртуального хоста Nginx: server { listen ip:80 default_server;

server_name domain.es;
server_name www.domain.es;
server_name ipv4.domain.es;

client_max_body_size 128m;

root "/var/www/vhosts/domain.es/httpdocs";
access_log "/var/www/vhosts/system/domain.es/logs/proxy_access_log";
error_log "/var/www/vhosts/system/domain.es/logs/proxy_error_log";

if ($host ~* ^www.domain.es$) {
    rewrite ^(.*)$ http://domain.es$1 permanent;
}

location / {
    proxy_pass http://82.194.74.41:7080;
    proxy_set_header Host             $host;
    proxy_set_header X-Real-IP        $remote_addr;
    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    access_log off;
}

location @fallback {
    proxy_pass http://ip:7080;
    proxy_set_header Host             $host;
    proxy_set_header X-Real-IP        $remote_addr;
    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    access_log off;
}

location ~ ^/plesk-stat/ {
    proxy_pass http://ip:7080;
    proxy_set_header Host             $host;
    proxy_set_header X-Real-IP        $remote_addr;
    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    access_log off;
}

location ~ ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|swf|tar|tgz|txt|wav|xls|xlsx|zip))$ {
    access_log off;
    expires 7d;
    add_header Cache-Control public;

 try_files $uri @fallback;
}

include "/var/www/vhosts/system/domain.es/conf/vhost_nginx.conf";
}

И некоторые из переменных конфигурации, которые я использую с Apache (httpd.conf):

<IfModule prefork.c>
StartServers      14
MinSpareServers    8
MaxSpareServers   14
ServerLimit      1000
MaxClients       1000
MaxRequestsPerChild  2000
</IfModule>

Заранее большое спасибо!


person Shupyrg    schedule 04.08.2014    source источник


Ответы (3)


В моем случае отсутствует расширение php, после того, как я его отключил, оно восстановилось! Проверьте /var/log/messages, чтобы увидеть, есть ли segfault.

person youly    schedule 20.06.2016

Кажется, ваш Apache более занят, чем ваш Nginx. Когда Nginx получает некоторые запросы, но Apache не может их обработать, вы получаете сообщение «502 Bad Gateway», что означает, что Apache отказался работать для Nginx.

Попробуйте уменьшить «worker_connections» и «worker_processes» в Nginx и увеличить «MaxClients», «ServerLimit».

Убедитесь, что worker_connections * worker_processes ‹ MaxClients ‹ ServerLimit

person Yang Yuan    schedule 04.08.2014
comment
Я уменьшил worker_processes до 2 и worker_connections до 512. Кроме того, увеличил MaxClients и ServerLimit до 1200. Это снова произошло, я даже не могу подключиться к серверу через терминал. Спасибо за Ваш ответ. - person Shupyrg; 05.08.2014
comment
Вы не можете подключиться к серверу, потому что, вероятно, не хватает памяти. Вы увеличили количество одновременных клиентов, что означает, что apache будет обрабатывать больше запросов одновременно, что приводит к более высокому использованию памяти php или чем-либо еще, генерирующим ваш динамический контент. единственное решение imho - увеличивать или уменьшать масштаб. (Увеличьте память сервера или добавьте серверы в свою ферму.) - person fholzer; 29.05.2015

В случае, который я недавно видел, эта ошибка регистрировалась для 95% запросов, но и веб-сервер, и сервер приложений почти не работали, и было открыто всего несколько подключений. Остальные 5% оказались успешными.

Оказалось, что наши дружелюбные сетевые коллеги настроили IPS-устройство между веб-сервером и сервером приложений, и оно начало цепляться и сбрасывать соединения, когда трафик увеличивался, потому что думал, что происходит атака грубой силы. Ложноположительный результат. Так что ничего общего с Nginx или Apache, но перенастройка IPS устранила проблему.

person shonky linux user    schedule 30.05.2019