Как исправить ошибку 104

Разбор ошибки 104 и методы её исправления

Ошибка 104 (Connection reset by peer) — это распространённая сетевая ошибка, возникающая на транспортном уровне (чаще всего по протоколу TCP). Она означает, что существующее сетевое соединение было неожиданно разорвано удалённой стороной («пиром»). В контексте тестирования и эксплуатации ПО это критическая ошибка, требующая детального анализа.

Основные причины возникновения ошибки 104

• Серверная сторона разрывает соединение: Сервер может закрыть сокет из-за таймаута, ошибки в приложении (например, необработанное исключение), перезагрузки службы или политики безопасности (например, фаервол).
• Проблемы с сетевой инфраструктурой: Промежуточное оборудование (маршрутизаторы, фаерволы, балансировщики нагрузки) может принудительно разорвать соединение из-за правил фильтрации, таймаутов неактивности (keep-alive) или перегрузки.
• Клиентское приложение: Клиент может некорректно обрабатывать данные, вызывая аварийное завершение работы сетевого стека.
• Аппаратные проблемы: Нестабильное сетевое оборудование или физический обрыв связи.

Пошаговая стратегия диагностики и исправления для QA Engineer

Как QA Engineer, вы должны не просто «исправить» ошибку (это часто задача разработки или администрирования), а исследовать, локализовать и воспроизвести проблему, предоставив детальный отчёт.

1. Анализ контекста и сбор логов

Первым делом определите, в каких условиях возникает ошибка.

• Когда? При старте соединения, во время передачи данных, при длительной неактивности?
• На какой стороне? В логах клиента или сервера?
• Стабильность воспроизведения? Постоянно или эпизодически?

Соберите логи с обеих сторон соединения. Для веб-приложений используйте инструменты разработчика (F12) -> Вкладка Network. Ищите статус (failed) net::ERR_CONNECTION_RESET.

Пример анализа в командной строке (может помочь DevOps):

# Проверка доступности порта (базовая диагностика)
nc -zv example.com 443
# Просмотр сетевых соединений (Linux/Mac)
netstat -an | grep <PORT>
# или
ss -tnp | grep <PORT>
# Трассировка маршрута (выявление проблем на участке сети)
traceroute example.com

2. Воспроизведение и изоляция проблемы

Попытайтесь воспроизвести ошибку в контролируемых условиях.

• Изменение среды: Проверьте работу в другой сети (например, мобильный интернет), отключив локальный фаервол/антивирус.
• Использование снифферов: Инструменты вроде Wireshark или tcpdump позволяют захватывать сетевые пакеты и увидеть, кто именно инициирует разрыв (пакет RST).

  # Пример захвата пакетов на конкретном порту
  sudo tcpdump -i any port 8080 -w connection_issue.pcap
  

• Нагрузочное тестирование: Если ошибка проявляется под нагрузкой, используйте JMeter, k6 или wrk для моделирования сценария.

  // Пример скрипта для k6, создающего нагрузку
  import http from 'k6/http';
  export default function () {
    const res = http.get('http://test-server:8080/api/data');
    if (res.status !== 200) {
      console.error(`Ошибка: ${res.status}`);
    }
  }
  

3. Проверка конфигурации и таймаутов

Частая причина — несовпадение настроек таймаутов на клиенте и сервере.

• Увеличение таймаутов соединения: В конфигурации сервера (например, Nginx, Apache) или клиентской библиотеки.

  # Пример для Nginx
  http {
      proxy_connect_timeout 75s;
      proxy_send_timeout 600s;
      proxy_read_timeout 600s;
      keepalive_timeout 75s;
  }
  

• Проверка Keep-Alive: Убедитесь, что заголовки Keep-Alive корректно обрабатываются.

4. Глубокий анализ приложения

• Исключения на сервере: Изучите логи серверного приложения (Java, Python, Node.js и т.д.) на предмет ошибок, предшествующих разрыву.
• Исчерпание ресурсов: Возможно, сервер исчерпал лимиты на количество открытых файлов/сокетов или память.
• Поведение при высокой нагрузке: Может возникать race condition или блокировка, приводящая к аварийному закрытию соединения.

Что предоставить в отчёте об ошибке (Bug Report)

Как QA, ваша главная задача — качественный репорт. Он должен включать:

1. Чёткий заголовок: "Connection reset by peer (Error 104) при загрузке файла >100MB через API /upload".
2. Шаги воспроизведения: Максимально детальные.
3. Окружение: ОС, версия браузера/клиента, версия серверного ПО, сетевая конфигурация.
4. Логи и скриншоты: Фрагменты логов с обеих сторон (обязательно замаскировав конфиденциальные данные), вывод консоли разработчика, дампы из Wireshark.
5. Частота и серьёзность: Насколько часто проявляется (%, например, 8 из 10 попыток) и влияние на бизнес-процесс (блокирующая/критическая).
6. Результаты первичного анализа: Ваши наблюдения (например, "Ошибка возникает ровно через 30 секунд неактивности, что совпадает с настройкой фаервола IPTables на тестовом стенде").

Таким образом, «исправление» ошибки 104 начинается с её глубокого исследования. Роль QA — стать «следопытом», который находит первопричину, собирает неопровержимые доказательства и ставит точный «диагноз» для команды разработки и эксплуатации.