Сервер Minio за Nginx выдает ошибку 104 сброс соединения со стороны пира.

Вопрос или проблема

У меня есть экземпляр Minio, настроенный за Nginx. Каждый раз, когда я синхронизирую большие папки с помощью rclone, я получаю ошибку 104: сброс соединения со стороны пира по какой-то причине. Я отслеживал tcpdump, чтобы убедиться, что это не ошибка Nginx, и, похоже, это не так. Minio отправляет сбросы соединения.

Вывод tcpdump с моего ПК до nginx:

12:45:56.037558 IP mypc.lan.50299 > myserver.lan.https: Flags [P.], seq 210758:211258, ack 271369, win 513, length 500
12:45:56.037567 IP myserver.lan.https > mypc.lan.50299: Flags [.], ack 211258, win 4014, length 0
12:45:56.041378 IP myserver.lan.https > mypc.lan.50294: Flags [P.], seq 304261:304440, ack 231696, win 6722, length 179
12:45:56.073311 IP myserver.lan.https > mypc.lan.50297: Flags [P.], seq 315796:315975, ack 250662, win 4042, length 179
12:45:56.092129 IP mypc.lan.50297 > myserver.lan.https: Flags [P.], seq 250662:251204, ack 315975, win 513, length 542
12:45:56.092148 IP myserver.lan.https > mypc.lan.50297: Flags [.], ack 251204, win 4052, length 0
12:45:56.097786 IP mypc.lan.50294 > myserver.lan.https: Flags [.], ack 304440, win 511, length 0
12:45:56.113142 IP mypc.lan.50294 > myserver.lan.https: Flags [P.], seq 231696:232196, ack 304440, win 511, length 500
12:45:56.113152 IP myserver.lan.https > mypc.lan.50294: Flags [.], ack 232196, win 6742, length 0
12:45:56.121592 IP myserver.lan.https > mypc.lan.50293: Flags [P.], seq 354178:354357, ack 282451, win 4629, length 179
12:45:56.174268 IP mypc.lan.50293 > myserver.lan.https: Flags [.], ack 354357, win 513, length 0
12:45:56.179362 IP myserver.lan.https > mypc.lan.50296: Flags [P.], seq 269665:270001, ack 211252, win 3463, length 336

И соответствующий вывод tcpdump на loopback между nginx и minio:

12:45:56.092237 IP localhost.40782 > localhost.cslistener: Flags [.], ack 1, win 512, options [nop,nop,TS val 4256686849 ecr 4256686849], length 0
12:45:56.092256 IP localhost.40782 > localhost.cslistener: Flags [P.], seq 1:599, ack 1, win 512, options [nop,nop,TS val 4256686849 ecr 4256686849], length 598
12:45:56.092264 IP localhost.cslistener > localhost.40782: Flags [.], ack 599, win 507, options [nop,nop,TS val 4256686849 ecr 4256686849], length 0
12:45:56.113223 IP localhost.40786 > localhost.cslistener: Flags [S], seq 1989401545, win 65495, options [mss 65495,sackOK,TS val 4256686870 ecr 0,nop,wscale 7], length 0
12:45:56.113231 IP localhost.cslistener > localhost.40786: Flags [S.], seq 2441514866, ack 1989401546, win 65483, options [mss 65495,sackOK,TS val 4256686870 ecr 4256686870,nop,wscale 7], length 0
12:45:56.113237 IP localhost.40786 > localhost.cslistener: Flags [.], ack 1, win 512, options [nop,nop,TS val 4256686870 ecr 4256686870], length 0
12:45:56.113253 IP localhost.40786 > localhost.cslistener: Flags [P.], seq 1:557, ack 1, win 512, options [nop,nop,TS val 4256686870 ecr 4256686870], length 556
12:45:56.113256 IP localhost.cslistener > localhost.40786: Flags [.], ack 557, win 508, options [nop,nop,TS val 4256686870 ecr 4256686870], length 0
12:45:56.121528 IP localhost.cslistener > localhost.40026: Flags [R.], seq 1, ack 557, win 512, options [nop,nop,TS val 4256686878 ecr 4256686639], length 0
12:45:56.179288 IP localhost.cslistener > localhost.40766: Flags [R.], seq 1, ack 653, win 512, options [nop,nop,TS val 4256686936 ecr 4256686696], length 0

Тем не менее, если я открою порт 9000 и синхронизирую ту же большую папку напрямую, все еще используя rclone, этой ошибки у меня совсем нет. Вот вывод tcpdump без ошибок:

12:44:00.253537 IP myserver.lan.cslistenedomacica.r > mypc.lan.49493: Flags [P.], seq 993647:994206, ack 681899, win 9686, length 559
12:44:00.253622 IP mypc.lan.49496 > myserver.lan.cslistener: Flags [P.], seq 530108:530599, ack 991128, win 513, length 491
12:44:00.254002 IP myserver.lan.cslistener > mypc.lan.49488: Flags [P.], seq 1007299:1007860, ack 690855, win 9674, length 561
12:44:00.254018 IP myserver.lan.cslistener > mypc.lan.49496: Flags [P.], seq 991128:991690, ack 530599, win 9662, length 562
12:44:00.254031 IP myserver.lan.cslistener > mypc.lan.49487: Flags [P.], seq 1039391:1039932, ack 653371, win 9709, length 541

Я не понимаю, что отличается между двумя процессами.

Я также добавляю конфигурацию сайта nginx, если кто-то сможет заметить какие-либо проблемы здесь:

server {
  server_name что-то;

  set $test 0;
  if ( $host != "что-то" ) {
    set $test 1;
  }
  if ( $host != "что-то" ) {
    set $test 1$test;
  }
  if ( $test = 11 ) {
    return 444;
  }

  # Разрешить специальные символы в заголовках
  ignore_invalid_headers off;
  # Разрешить загрузку файлов любого размера.
  # Установите значение, такое как 1000m; чтобы ограничить размер файла до определенного значения
  client_max_body_size 0;
  # Отключить буферизацию
  proxy_buffering off;
  proxy_request_buffering off;

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_connect_timeout 300;
    # По умолчанию HTTP/1, keepalive только включен в HTTP/1.1
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    chunked_transfer_encoding off;

    proxy_pass http://127.0.0.1:9000;
  }

  location /ui/ {
    rewrite ^/ui/(.*) /$1 break;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-NginX-Proxy true;

    # Это необходимо для передачи правильного IP для хеширования
    real_ip_header X-Real-IP;

    proxy_connect_timeout 300;

    # Для поддержки веб-сокетов в версиях MinIO, выпущенных после января 2023
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    chunked_transfer_encoding off;

    proxy_pass http://127.0.0.1:9091;

  }


    listen [::]:443 ssl ipv6only=on; # управляется Certbot
    listen 443 ssl; # управляется Certbot
    ssl_certificate /etc/letsencrypt/live/что-то/fullchain.pem; # управляется Certbot
    ssl_certificate_key /etc/letsencrypt/live/что-то/privkey.pem; # управляется Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # управляется Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # управляется Certbot

    ssl_verify_depth 2;
    ssl_verify_client on;
    ssl_client_certificate /etc/ssl/certs/ca.crt;

}

server {
    if ($host =что-то) {
        return 301 https://$host$request_uri;
    } # управляется Certbot


    if ($host = что-то) {
        return 301 https://$host$request_uri;
    } # управляется Certbot



  listen 80;
  listen [::]:80;
  server_name что-то;
    return 404; # управляется Certbot

}

У меня такая же проблема, и оказывается, проблема в том, что брандмауэр Checkpoint обнаружил уязвимость CVE и блокирует соединение.

Ответ или решение

Ошибка 104 Connection Reset by Peer в MinIO за Nginx: Подробный Анализ и Решение

Ошибка "104 Connection Reset by Peer", возникающая при использовании MinIO за прокси-сервером Nginx, может вызывать затруднения как для начинающих, так и для опытных администраторов. Данная проблема заключается в том, что MinIO сбрасывает соединение, когда происходит синхронизация крупных папок с использованием rclone. Разберёмся в отдельных аспектах и возможных причинах этой ошибки.

Анализ Проблемы

В вашем случае TCP-дампы показывают, что данные отправляются от вашей машины (клиента) к Nginx и обратно, однако Nginx не становится источником сброса соединения. Вместо этого, MinIO, работающий на локальном сервере, инициирует сброс соединения.

1. Сцепление Прокси и MinIO

В конфигурации Nginx имеются параметры, которые могут влиять на производительность и стабильность соединения:

  • proxy_buffering off и proxy_request_buffering off – данные настройки отключают буферизацию, что может отрицательно сказаться на обработке больших объемов данных. Чтобы избежать сбросов, вы можете попробовать установить данные параметры в on.

  • Размеры загружаемых данных: Указание client_max_body_size 0 позволяет загружать файлы любого размера, однако если размер слишком велик, возможно, лучше установить разумный лимит (например, 1000m). В некоторых случаях слишком большие запросы могут вызывать тайм-ауты.

  • Параметры подключения: Конфигурация proxy_connect_timeout 300 указывает время ожидания на соединение. Возможно, вам потребуется увеличить его значении, если у MinIO есть латентность или проблемы с производительностью.

2. Разница в Работе через Порт 9000

При прямом обращении к MinIO по порту 9000 не возникает сброса соединения. Это указывает на то, что проблема действительно в Nginx или в том, как Nginx обрабатывает запросы к MinIO. Прямое подключение позволяет избежать дополнительных нюансов, связанных с проксированием, таких как тайм-ауты или превышение лимитов.

Возможные Решения

  1. Тестирование Производительности
    Необходимо проанализировать производительность и лимиты MinIO. Параметры конфигурации могут быть настроены в зависимости от окружения, в котором работает MinIO. Следует просмотреть документацию MinIO и убедиться, что настройки соответствуют объему ваших данных.

  2. Настройка Nginx
    Попробуйте изменить параметры конфигурации Nginx, включая:

    • Включение proxy_buffering и proxy_request_buffering.
    • Увеличение client_max_body_size до более разумного значения.
    • Настройка проблем с тайм-аутами и соединениями.

    Например:

    client_max_body_size 1000m;  # Ограничение на 1 ГБ
    proxy_buffering on;            # Включить буферизацию
    proxy_request_buffering on;    # Включить буферизацию запросов
  3. Проверка Брандмауэра
    Также стоит обратиться к настройкам брандмауэра (например, Checkpoint firewall), так как они могут блокировать соединения, исходя из политик безопасности, что и результатирует в сбросах соединений. Проверьте настройки брандмауэра для исключений или создания правил, позволяющих соединения с MinIO.

  4. Логи и Мониторинг
    Включите детальное логирование и мониторинг как на стороне Nginx, так и MinIO, чтобы увидеть, что происходит в момент возникновения ошибки. Это может предоставить ясные подсказки о том, что выполняется неправильно.

Заключение

Приведенные указания помогут сузить круг возможных причин возникновения ошибки "104 Connection Reset by Peer" при использовании MinIO за Nginx. Проблема, скорее всего, кроется в конфигурации прокси или сетевых настройках, поэтому её решение потребует внимательного анализа и тестирования. Помните, что каждая инфраструктура уникальна, и некоторые изменения могут потребовать дополнительных настроек для достижения оптимальной производительности.

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

Оцените материал
Добавить комментарий

Капча загружается...