ERR_CONNECTION_RESET: причини і виправлення

Що означає ERR_CONNECTION_RESET

На відміну від ERR_CONNECTION_REFUSED, яка виникає ще до того, як пішли якісь дані, скидання трапляється вже після успішного TCP-рукостискання, коли з'єднання вже обмінювалося даними. Щось на шляху, чи одна з кінцевих точок сама, тоді надсилає пакет RST, що завершує з'єднання без звичайної послідовності закриття. Браузер не може сказати, чи RST прийшов від сервера, проміжного пристрою на кшталт брандмауера чи балансувальника навантаження, чи власного мережевого стека клієнта, тож повідомлення лишається загальним незалежно від причини.

Звичайне TCP-закриття включає обмін FIN в обидва боки, що дає кожній стороні завершити відправку того, що вона вже поставила в чергу. RST повністю пропускає це: усе, що було в польоті, відкидається, а будь-які дані, які сервер уже почав писати, але клієнт ще не отримав, втрачаються. Саме тому скидання посеред завантаження великого файлу чи довгої відповіді API часто лишає видимо обірваний результат, а не чистий збій до того, як хоч щось завантажилося.

Як з'являється помилка

Chrome показує "This site can't be reached ... ERR_CONNECTION_RESET" посеред завантаження, іноді вже після того, як частина сторінки відрендерилася. curl повідомляє про це прямо:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

На боці сервера nginx логує відповідний рядок для тієї самої події: readv() failed (104: Connection reset by peer) while reading upstream. Скидання, що стабільно трапляється на однаковій кількості байтів чи однаковій кількості секунд у запиті, вказує на ліміт розміру чи тайм-ауту десь на шляху, а не на випадковий мережевий збій.

Що спричиняє ERR_CONNECTION_RESET

• Брандмауер, IDS чи WAF обриває з'єднання посеред потоку. Правило, що спрацьовує посеред запиту чи відповіді, а не в момент з'єднання, дає скидання замість негайної відмови.
• Проблеми MTU чи фрагментації пакетів. Шлях із меншим MTU, ніж очікує будь-яка з кінцевих точок, може пошкодити великі пакети, і деякі неправильно налаштовані роутери відповідають скиданням з'єднання замість правильної фрагментації.
• Перевірка TLS антивірусним ПЗ чи корпоративним проксі. Перехоплення, що провалюється посеред рукостискання чи відповіді, часто скидає з'єднання замість того, щоб провалитися коректно.
• Робочий процес сервера падає посеред запиту. Помилка застосунку, вбивство через нестачу пам'яті чи перезапуск воркера під час деплою - усе це лишає відкрите з'єднання, якому вже нема кому відповісти.
• Невідповідність тайм-ауту keep-alive між клієнтом і сервером чи проксі. Якщо тайм-аут простою балансувальника навантаження коротший за той, що на бекенді, він може скинути з'єднання, яке бекенд усе ще вважає активним.
• Втручання провайдера чи формування трафіку. Деякі провайдери скидають довготривалі чи високопропускні з'єднання, особливо для стрімінгу чи великих завантажень, як форму керування трафіком.

Як зрозуміти, хто винен

Перевірте той самий запит з другої мережі, наприклад із мобільного інтернету замість офісного Wi-Fi. Якщо там усе працює, з'єднання перехоплює локальний брандмауер, антивірус чи проксі. Якщо скидання трапляється однаково скрізь, причина на боці сервера чи в правилі WAF перед ним. HTTP-перевірка, запущена з кількох локацій одночасно, показує, чи скидання універсальне, чи обмежене однією мережею, без потреби в другому пристрої для тестування.

Як виправити ERR_CONNECTION_RESET

Якщо ви відвідувач

1. Перезавантажте роутер чи модем. Застряглий запис у NAT-таблиці чи застарілий стан з'єднання на побутових роутерах - поширена, легко усувна причина.
2. Вимкніть будь-який VPN чи проксі і перезавантажте. Якщо скидання припиняється, VPN чи проксі перехоплює чи неправильно обробляє з'єднання.
3. Вимкніть сканування HTTPS у своєму антивірусі, зазвичай у розділі "web protection" чи "SSL/TLS scanning", і повторіть спробу. Якщо це допомагає, додайте сайт до списку винятків, а не залишайте сканування вимкненим.
4. Перевірте на незвично низьке налаштування MTU, якщо ви на VPN чи мобільній точці доступу; невелике зниження на клієнті може вирішити скидання, пов'язані з фрагментацією.

Якщо ви керуєте сайтом

1. Перевірте логи застосунку й системи на предмет збою чи вбивства через нестачу пам'яті приблизно в момент скидання. Робочий процес, що падає посеред запиту, - одна з найпоширеніших причин.
2. Перегляньте правила WAF та IDS і їхні логи. Правило, що скидає з'єднання, які збігаються з певними навантаженнями чи частотою, може виглядати ідентично до випадкового мережевого збою, доки ви не перевірите саме лог безпеки.
3. Узгодьте тайм-аути keep-alive по всьому стеку. На nginx встановіть тайм-аут із боку проксі рівним чи більшим за власний тайм-аут бекенда:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Невідповідність тут - часта причина скидань під навантаженням, коли фронтенд закриває з'єднання, яке бекенд усе ще очікує використати.
4. Слідкуйте за повідомленнями про скидання upstream у лозі зворотного проксі, на кшталт upstream prematurely closed connection while reading response header from upstream, що прямо вказує на застосунок бекенда, а не на мережу.
5. Перезавантажуйте після будь-якої зміни, а не редагуйте на льоту: nginx -t && systemctl reload nginx перевіряє конфігурацію, перш ніж вона набуде чинності.

Як запобігти ERR_CONNECTION_RESET

Скидання, що з'являється лише під навантаженням, чи лише для великих відповідей, рідко проявляється під час швидкої ручної перевірки, оскільки залежить від порогів часу чи розміру, яких один запит може не досягти. Постійний HTTP-моніторинг, що перевіряє код статусу й вміст тіла за розкладом із понад 300 контрольних точок у 158 містах, ловить періодичний патерн скидань, який одноразовий тест пропустить, і сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами, щойно це почнеться.

Пов'язані помилки

• ERR_CONNECTION_REFUSED трапляється, коли з'єднання взагалі не встановлюється.
• ERR_CONNECTION_TIMED_OUT трапляється, коли на спробу з'єднання взагалі ніхто не відповідає.
• This site can't be reached охоплює весь набір помилок з'єднання, які Chrome об'єднує під одним заголовком.

Часті запитання

Чи означає ERR_CONNECTION_RESET, що мене зламали?

Ні. Це майже завжди вказує на мережевий пристрій, правило брандмауера, перехоплення антивірусом чи збій на боці сервера, а не на атаку на ваш пристрій.

Чому це трапляється лише з великими завантаженнями файлів?

Великі передачі частіше натрапляють на невідповідність MTU, тайм-аут проксі чи ліміт розміру, налаштований на брандмауері чи балансувальнику навантаження, - усе це може завершити з'єднання посеред потоку, тоді як малий запит устиг би завершитися до того, як спрацює тригер.

Чи може мій власний антивірус це спричинити?

Так. Функції сканування HTTPS, що перехоплюють і повторно шифрують TLS-трафік, іноді провалюються на конкретних сайтах чи великих відповідях і скидають з'єднання замість того, щоб пропустити його.

Чи скидання гірше за тайм-аут?

Не за своєю природою. Скидання означає, що щось активно завершило з'єднання, що часто легше діагностувати, ніж тайм-аут, де нічого не відбувається і ви не можете сказати, чи пакет узагалі прийшов.

Чому скидання трапляється в одному й тому самому місці щоразу?

Стабільна кількість байтів чи час до скидання зазвичай вказує на фіксований ліміт, наприклад тайм-аут проксі, максимальний розмір відповіді чи налаштування keep-alive, а не на випадковий збій.

Чи може мобільний оператор скидати мої з'єднання?

Деякі оператори справді скидають довготривалі з'єднання як частину керування мережею, особливо на перевантажених вежах чи для високопропускних передач на кшталт відеострімінгу. Якщо той самий запит стабільно працює через Wi-Fi, але скидається на мобільному інтернеті, втручання на рівні оператора - розумне пояснення.