Коротко — такого “застывания” на фиксированном размере (порядка 33 KB) обычно не просто баг wget-а: либо в пути у вас есть какое‑то межсетевое оборудование (прозрачный прокси / NAT / DPI / балансировщик), которое обрывает или «тупит» поток после определённого объёма/паттерна, либо сервер/стек TCP взаимодействуют с этим оборудованием так, что оно начинает неправильно парсить/буферизовать поток и отрубает его. Ниже — возможные причины и практические шаги по диагностике и обходу.
Возможные причины
- Middlebox/DPI/прозрачный прокси:
- фильтрация/блокировка по домену/SNI/IP, либо сигнатуры DPI (контент/заголовки) — обрыв после начала передачи;
- buggy прокси/кеш, который не умеет корректно работать с chunked/Sendfile/large TCP windows и обрывает соединение после заполнения внутреннего буфера (~32 KB — распространённый размер буфера);
- Проблема с TCP стеком / опциями:
- MSS/PMTU или некорректное клэмпирование MSS на промежуточном устройстве (обрыв при определённой последовательности сегментов);
- взаимодействие sendfile/zero-copy (на сервере) с каким‑то NAT/прокси, из‑за чего middlebox неправильно видит сегменты и рвёт соединение;
- Неполадки/политики провайдера:
- лимитирование/тасование трафика для отдельных подсетей хостинга;
- баг в DPI/прокси провайдера, который “узнаёт” именно ваш хост по признаку (IP, заголовки сервера, порядок заголовков, тип контента);
- Серверная конфигурация:
- неверные заголовки (нет Content-Length для статики), chunked без правильного окончания, proxy_buffering в nginx, поведение upstream.
Что проверить прямо сейчас (порядок по эффективности)
1. Снять pcaps одновременно на клиенте и на сервере:
- на сервере: sudo tcpdump -i any host CLIENT_IP and port 80 -w server.pcap
- на клиенте: sudo tcpdump -i any host SERVER_IP and port 80 -w client.pcap
Это покажет: доходят ли пакеты от сервера до клиента и/или где именно обрыв, есть ли RST/ICMP/FIN или просто перестали приходить пакеты.
2. Посмотреть HTTP‑заголовки/поведение:
- curl -v --http1.1 http://site/path/to/file > /dev/null
- wget -S http://...
Обратите внимание на Content-Length, Transfer-Encoding: chunked, Connection, и на то, посылает ли nginx весь файл (серверный access.log покажет bytes_sent и статус).
3. Проверить повторную загрузку / резюме:
- curl -r 0-40000 http://... (попробовать запросить диапазон beyond 33KB). Если range работает и можно докачать «хвост», то это подсказка в пользу прокси/буфера.
4. Отключить sendfile/tcp_nopush/tcp_nodelay в nginx и перезапустить:
В nginx.conf:
sendfile off;
tcp_nopush off;
tcp_nodelay on;
Затем проверить поведение. У многих провайдеров/балансировщиков встречаются баги с sendfile: они видят не те сегменты и обрывают.
5. Включить iptables MSS clamp (если проблема с MSS/PMTU):
- sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Или временно снизить MSS вручную/на интерфейсе, чтобы проверить.
6. Проверить логи nginx и системные логи:
- access.log (bytes_sent, request_time)
- error.log (обрывы, write errors)
- dmesg / kernel log — может быть информация о NIC или offload‑ошибках.
7. Попробовать обойти провайдера/среду:
- попробовать тот же wget через VPN/tor/мобильную сеть того же клиента — если через VPN работает, значит проблема в сети провайдера;
- поставить сайт за CDN (Cloudflare) — если через CDN всё ок, это рабочий обход и одновременно протестирует, виновата ли сеть/маршрут;
- попробовать другой порт (например 8080 или 8443) — иногда провайдеры фильтруют только 80/443.
Почему именно ваш сайт?
- Любой DPI/прокси работает по сигнатурам/базам: IP/ASN, SNI/Host, заголовки Server, необычный порядок заголовков, Transfer-Encoding chunked, либо исторические жалобы на IP — всё это может сделать ваш трафик “подозрительным”.
- Некоторые прокси некорректно обрабатывают chunked ответы или нативный sendfile (нулевые копии) и отрубают поток по достижении их внутреннего буфера (типично ~32 KB).
- Также возможно, что в вашей подсети хоста есть несоответствие MTU/MSS, и на определённой длине соединение перестаёт корректно догоняться.
Что ещё можно сделать/собрать для жалобы в поддержку провайдера
- Два pcap-файла (сервер и клиента) с привязкой по времени (UTC). В pcap должны быть видны TCP sequence/ack: это самый убедительный доказ.
- Логи nginx для соответствующего времени (access + error).
- Traceroute/mtr от клиента до сервера, tracepath для PMTU.
- Описание воспроизводимости: время, ISP, версия wget/curl, URL, поведение при VPN/CDN.
С этими артефактами техподдержка сможет искать проблему на своём оборудовании.
Короткие быстрые изменения, которые часто помогают
- sendfile off; tcp_nopush off; tcp_nodelay on;
- iptables --clamp-mss-to-pmtu;
- обеспечить корректный Content-Length (для статических файлов nginx делает это автоматически) и по возможности избегать chunked, если это возможно;
- временно поставить сайт за CDN.
Если хотите, могу:
- подсказать точные команды tcpdump/curl/wget для съёмки и диагностики;
- посмотреть пример заголовков/лога (вставьте curl -I output и вывод wget -S / curl -v);
- помочь составить письмо в техподдержку провайдера с описанием и вложениями.
Резюме: наиболее вероятны buggy middlebox/прокси (DPI) или взаимодействие sendfile/TSO с ними. Первые шаги — собрать pcap с обеих сторон, временно выключить sendfile в nginx и попробовать clamp MSS. Если после этого поведение не изменится, присылайте pcap/логи — помогу анализировать.