Сначала коротко о главном. Когда Telegram показывает «Connected», это значит только одно: TCP-сессия установлена. Это не говорит ни о скорости, ни о стабильности, ни о том, где физически находится сервер. Медленный прокси при живом коннекте — это не «магия», не «плохой Telegram», а конкретная комбинация факторов, которые можно проверить.
Вот чек-лист. Пройдите по пунктам сверху вниз.
Проверьте, не oversubscribed ли сервер
Действие: посмотрите на количество пользователей на прокси. Если у вас доступ к панели оператора или к открытой статистике (например, на странице проекта free-mtproto-proxies — там публикуются свежие прокси с метаданными), оцените соотношение активных сессий к полосе. Для MTProto-прокси нормой считается 100–200 одновременных клиентов на 1 Гбит/с. Если на одном IPv4 сидят 500+ человек и все качают медиа — очередь на отправку растёт.
Почему так: скрытый пул прокси (например, https://github.com/dubblebyte/free-mtproto-proxies собирает их автоматически) часто включает адреса, купленные для массового использования. Один канал в 1 Гбит/с делится между всеми. При 300 одновременных пользователях загрузка — это гонка за слоты TCP, и латентность на пустом месте вырастает до 300–500 мс, даже если пинг до сервера 20 мс.
Тонкость: не всегда видно. Если прокси закрытый и статистику не отдаёт — косвенный признак oversubscription: скорость падает ровно в часы пик (вечером по часовому поясу сервера), а ночью «всё летает».
Замерьте реальную латентность, а не «скорость подключения»
Действие: откройте Настройки → Данные и память → Служба прокси в Telegram. Посмотрите «Ответ сервера» — это время полного цикла запрос-ответ. Не путайте с TCP handshake. Для медийного чата адекватно 150–200 мс. Если видите 800 мс+ при пустом чате — дело в маршруте или стеке, а не в полосе.
Команда для точного замера: с Linux/macOS используйте curl -x socks5://proxy_ip:port https://t.me -o /dev/null -s -w '%{time_total}\n' — это даст общее время с учётом TLS. Но учтите: MTProto-прокси работает как SOCKS-прокси внутри Telegram, и curl не покажет поведение MTProto-стека. Для честного замера используйте Telegram с логированием: включите --log=network в десктопной версии и посмотрите реальные RTT в логах.
Ищите проблемы с TCP window collapse
Действие: скачайте файл через прокси (отправьте себе большой архив в «Избранное») и наблюдайте за прогрессом. Если скорость падает ступенчато: 10 МБ/с → 2 МБ/с → 300 КБ/с за 30 секунд — это классика.
Почему так: MTProto-прокси — это по сути TCP-релей. Пакет теряется (потеря 0.5–1% по маршруту до сервера — норма для транзитных каналов). TCP ReC’s windows size уменьшается вдвое при каждой потере. При длинной сессии, если сервер не поддерживает window scaling (или ваш клиент не договаривается о нём), размер окна может деградировать до нескольких МБ, и пропускная способность падает в 10–20 раз при той же латентности.
Как проверить: посмотрите в логах cwnd (congestion window). В Telegram это не отдаётся напрямую, но косвенно: если пинг к прокси стабильный, а скорость падает — это почти всегда сжатие окна из-за потерь. Фиксируется не «скоростью соединения», а только долгим тестом передачи.
Учитывайте географию маршрута
Действие: узнайте IP прокси (например, через whois или страницу статуса). Определите страну хостинга. Теперь посчитайте сквозной маршрут: клиент → GCC (Катар) → Финляндия → Амстердам. Хоть ping до Amsterdam 120 мс из Москвы, но с TCP-буферизацией и потерями на стыках — реальный RTT до Telegram-сервера может быть 600 мс.
Почему так: MTProto-прокси не обязан быть близко к Telegram-дата-центру. Операторы часто ставят прокси на дешёвые VPS в Люксембурге или Болгарии. Два сетевых хопа с потерей 2% каждый — и вы получаете «работающий» пинг 250 мс, но медиа-загрузку со скоростью 150 КБ/с.
Быстрый тест: сравните пинг до прокси (ping с ICMP, если разрешено) с пингом до 149.154.167.50 (стандартный DC4 Telegram). Если разница больше 100 мс — проблема в пути между прокси и Telegram.
Измеряйте не «скорость», а время до первого байта (TTFB)
Действие: в настройках Telegram включите «Информация о прокси» (пункт доступен в Android-версии). Там показывается время установки соединения и время отклика. Если соединение стабильно «зелёное», но простои между загрузкой в 2–3 секунды: TTFB > 1 секунды. Это типично для прокси с перегруженным диском tmpfs или медленной записью логов.
Команда: time curl -x socks5h://proxy:1080 https://core.telegram.org -o /dev/null — посмотрите time_starttransfer. Если он > 800 мс при локальной скорости — сервер медленно обрабатывает запрос, а не сеть.
Проверьте порт и протокол
Действие: покопайте в сниффере: запустите tcpdump -i eth0 host <proxy_ip> во время передачи файла. Смотрите на размер SYN-пакета и MSS. Стандартный MTProto-прокси использует порт TCP, но некоторые операторы поднимают Fake-TLS (порт 443). Проблема: если клиент TLS-обёртку не договаривается о MTU — происходит фрагментация. Видите в tcpdump кучу [F] флагов и < 1400 байт в payload — это и есть TCP segment size mismatch. Обычно лечится только сменой прокси или явным выбором другой версии протокола в настройках Telegram.
Настройте буфер чтения (если вы оператор)
Если вы сами запускаете прокси (на базе mtprotoproxy или Erlang-реализации), проверьте настройку tcp_buf_size. Дефолтное значение в некоторых реализациях — 64 КБ. При высокой латентности (RTT > 100 мс) это ограничивает пропускную способность формулой bandwidth ≈ window / RTT: 64 КБ / 0.1 с = 640 КБ/с. Это ровно та скорость, которую многие видят на «живых» прокси.
Не спешите менять прокси — сначала исключите клиентскую часть
Когда всё перечисленное выше проверено и ничего не «виновато», посмотрите на свой Wi-Fi. 2.4 ГГц с загруженной сетью — это потеря 10–20% пакетов через роутер. Для TCP это смерть: каждые 100 пакетов с потерей 1% уменьшают окно вдвое. Включите 5 ГГц или подключитесь по Ethernet и повторите замер. Иногда причина в маршрутизаторе, а не в Azure-инстансе где-то на Нидерландах.
Что делать, если всё «плохо»
Соберите цифры: пинг, TTFB, стабильная/деградирующая скорость, потери через mtr. Для этого используйте mtr -rw <proxy_ip>. Если по пути 4+ хопов с потерями >2% — ищите другой сервер. Автоматический список прокси с метаданными (доступен в free-mtproto-proxies) по крайней мере позволяет быстро перебирать варианты, но никто на ваш лимит не подстроится.
Честный вывод: замер и диагностика занимают 10–15 минут. Большинство «медленных» прокси оказываются либо oversubscribed, либо просто деградировали из-за того, что их конфигурация давно не обновлялась под реальную нагрузку. Скорость через прокси никогда не сравнится со скоростью прямого соединения — потому что релей добавляет как минимум RTT и буферизацию. Но если вы не получаете хотя бы 5–10 МБ/с на хорошем «свежем» прокси с низким пингом — меняйте его без сомнений, иначе потратите вечер на бессмысленные поиски крайней точки в вашей сети.
