Ошибки тайм-аута передачи файлов: причины и решения

Ошибки тайм-аута при передаче файлов возникают из одного из четырёх мест: HTTP-запрос клиента слишком долго ждал ответа сервера (обычно 30–120 секунд), сервер слишком долго ждал данных от клиента (типично при медленных загрузках), промежуточный прокси или балансировщик нагрузки разорвал соединение (по умолчанию AWS ALB — 60 секунд), или ОС завершила простаивающее TCP-соединение. 504 Gateway Timeout означает, что балансировщик нагрузки не смог достучаться до источника. 408 Request Timeout — сервер устал ждать ваших данных. ERR_CONNECTION_TIMED_OUT — TCP-рукопожатие так и не завершилось. У каждой ошибки — своё решение.

Определяйте тип тайм-аута по коду ошибки

Разные тайм-ауты требуют разных подходов:

• 504 Gateway Timeout: промежуточный прокси или балансировщик нагрузки завершил ожидание. Проблема на стороне сервиса, обычно временная. Повторите попытку или смените регион.
• 408 Request Timeout: сервер прекратил ждать данные от клиента. Загрузка зависла в середине запроса.
• 524 (Cloudflare): источник не ответил в течение 100 секунд. Проблема на стороне сервиса.
• 502 Bad Gateway: прокси получил некорректный ответ от источника. Сбой сервиса или деплой в процессе.
• ERR_CONNECTION_TIMED_OUT: TCP-соединение с сервером не установлено. Проблема в сети или брандмауэре.
• ERR_NETWORK_CHANGED: сеть сменилась в процессе соединения. Переход между точками Wi-Fi или отключение VPN.

Вкладка «Сеть» в DevTools показывает точный ответ, тайминг и код состояния. Сделайте скриншот до того, как что-либо закроете.

Wi-Fi разрывает длительные загрузки при переключении точек

Чипы Wi-Fi в ноутбуках автоматически переключаются между диапазонами и точками доступа. Каждое переключение обрывает текущее TCP-соединение. Потоковые загрузки падают немедленно; загрузки по частям выживают, если сервис повторяет попытку для каждого фрагмента отдельно.

Решение: подключайтесь через Ethernet для загрузок от 2 ГБ. Если это невозможно, отключите band-steering на роутере (переключите в режим «только 5 ГГц» для SSID ноутбука) и оставайтесь в одной комнате. На macOS отключите «Auto-Join» для всех SSID, кроме основного, чтобы ноутбук не искал более сильный сигнал в процессе загрузки.

Тайм-ауты балансировщика нагрузки на стороне сервиса

AWS Application Load Balancer по умолчанию задаёт тайм-аут простоя в 60 секунд. Nginx по умолчанию имеет proxy_read_timeout — 60 секунд. Сервисы, не настроившие эти параметры должным образом, разрывают загрузки при кратком простое (во время шифрования, медленного чтения с диска) на отметке 60 секунд.

Если вы видите 504-ошибки на конкретном сервисе — это, как правило, неверно настроенный балансировщик нагрузки на их стороне. Со стороны клиента ничего нельзя сделать, кроме повторной попытки. Загрузчики по частям справляются с этим прозрачно, повторяя сбойный фрагмент; потоковые загрузчики полностью падают и требуют начать заново.

Тайм-ауты корпоративного прокси

Zscaler, Blue Coat, Palo Alto и другие корпоративные прокси устанавливают собственные тайм-ауты — обычно 30 секунд до 5 минут простоя. Если загрузка делает что-то, что прокси воспринимает как простой (пауза шифрования, задержка повтора фрагмента) — прокси разрывает соединение.

Диагностируйте, загрузив файл вне корпоративной сети (через хотспот телефона). Если тайм-ауты исчезают — виноват прокси. Попросите IT добавить домен сервиса в белый список и исключить его из инспекции. Альтернатива — личная сеть или VPN-туннель домой.

TCP keepalive на уровне ОС

Linux по умолчанию отправляет TCP keepalive-пакеты только после 2 часов простоя — что бесполезно для передачи файлов. macOS и Windows имеют похожие настройки по умолчанию. При очень длинных загрузках через нестабильные сети некоторые сервисы реализуют keepalive на уровне приложения через WebSocket ping-фреймы или периодические пустые фрагменты. Если сервис этого не делает, длинные загрузки через NAT-брандмауэр (стандартный тайм-аут UDP-сессии для большинства домашних роутеров — 5 минут) могут прерваться при истечении записи NAT.

Обновление токена VPN-сессии

Некоторые VPN-клиенты обновляют токены сессии каждые 5–15 минут. На клиентах с багами обновление на полсекунды прерывает базовый TCP-туннель. Длинные загрузки при этом падают.

Платные VPN (Mullvad, ProtonVPN Plus, IVPN) обрабатывают это корректно. Бесплатные — часто нет. Если вы видите стабильные тайм-ауты примерно на 10-й минуте — подозревайте обновление VPN. Отключите VPN на время загрузки, если сервис уже использует сквозное шифрование TLS 1.3.

Переключение сотовых вышек

Мобильный интернет переключается между вышками в движении. Каждое переключение либо (а) сохраняет IP через управление мобильностью (прозрачно), либо (б) назначает новый IP (соединение рвётся). На LTE большинство переключений прозрачны. На 5G, особенно mmWave, переходы на sub-6 или LTE-fallback могут менять IP и убивать соединения.

Если вы загружаете файл из движущегося транспорта через мобильный интернет — ожидайте обрывов. Загрузчики по частям с возобновлением справляются с этим хорошо; потоковые — нет.

Тайм-ауты mod_security и WAF

Если сервис находится за Web Application Firewall (Cloudflare WAF, AWS WAF, ModSecurity), WAF может расценить длинную загрузку как подозрительную и разорвать её. Симптомы: загрузки небольших файлов проходят, а на определённом пороге (часто 1 ГБ или 10 ГБ в зависимости от настройки WAF) возникают ответы 403 или 502.

Со стороны клиента исправить это невозможно. Сообщите сервису. Правильно настроенный WAF допускает загрузку по частям без срабатывания правил.

Тайм-ауты браузера

Браузеры тоже имеют тайм-ауты запросов, хотя для загрузок они обычно щедрые. Chrome и Firefox не устанавливают ограничений по времени для XHR и fetch по умолчанию, но могут прерывать простаивающие соединения после 5 минут в некоторых конфигурациях. Service Workers могут перехватывать и расширять тайм-ауты.

Если собственный JavaScript сервиса устанавливает xhr.timeout = 30000 (30 секунд) на фрагмент, медленные фрагменты будут падать. Это баг на стороне сервиса — сообщите о нём.

Антивирус, инспектирующий HTTPS-трафик

Windows Defender с включённой «инспекцией HTTPS», Norton, Bitdefender и подобные перехватывают HTTPS-соединения (MITM) для проверки содержимого. При крупных загрузках сама проверка добавляет задержку, способную превысить серверные тайм-ауты.

Временно отключите инспекцию HTTPS (не весь антивирус, только HTTPS-сканирование) на время крупных загрузок. Если загрузки проходят — добавьте домен сервиса передачи в список исключений антивируса навсегда.

Логика повтора и экспоненциальное ожидание

Хорошо написанные клиенты передачи повторяют сбойные фрагменты с экспоненциальным ожиданием: 1 секунда, затем 2, затем 4, затем 8. Кратковременный сбой сети устраняется прозрачно. Клиенты без логики повтора падают на первой же ошибке.

Если вы используете сервис без автоматического повтора, тайм-ауты будут случаться чаще. Выбирайте клиент или сервис, берущий обработку повторов на себя.

Просто повторите через 15 минут

Некоторые тайм-ауты временны: сбой на узле Cloudflare, деплой сервиса, перегруженный транзитный канал. Повторите попытку через 15 минут, прежде чем идти на следующий уровень. Если снова не получается — смените сеть, чтобы изолировать: проблема в вашей стороне или в сервисе.

Выбирайте сервис с устойчивым механизмом повтора

Для больших файлов через нестабильные сети нужен сервис с повтором на уровне фрагментов, возобновляемым состоянием сессии и без агрессивных серверных тайм-аутов. HexaTransfer использует параллельную загрузку по частям с повтором каждого фрагмента и клиентским шифрованием AES-256-GCM, поэтому загрузка 10 ГБ через нестабильное соединение повторяет проблемные фрагменты прозрачно, не прерывая всю передачу из-за единственного сбоя.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.