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

Команды проверены на macOS 26 (curl 8.7.1) и Ubuntu 24.04 (curl 8.5.0, mtr 0.95, nginx 1.24). Замеры из российских сетей сделаны 11 октября 2026 года через открытую сеть точек проверки Globalping. Адрес сервера в примерах — 203.0.113.10, домен — example.com.

Что понадобится

  • Терминал на своём компьютере: в macOS и Linux всё нужное обычно есть, mtr ставится отдельно (sudo apt install mtr-tiny в Ubuntu, brew install mtr в macOS).
  • Доступ к серверу по SSH — для проверки со стороны сервера. Если входите по паролю, сначала настройте вход по ключу.
  • Возможность проверить с двух-трёх разных подключений: домашний интернет, мобильный, интернет в офисе.

Почему сайт на зарубежном сервере не открывается или тормозит из России

Расстояние и задержка

Сигнал в оптоволокне проходит около 200 км за миллисекунду, а реальный путь длиннее прямой линии. Поэтому время «туда и обратно» (RTT, round-trip time) от Москвы до Амстердама — около 35–45 мс, а из Новосибирска — 90–130 мс. Внутри Москвы оно укладывается в 1–10 мс.

Сама по себе задержка в 40 мс незаметна, но она умножается. Прежде чем браузер получит первый байт страницы, он делает несколько обменов: установка TCP-соединения, TLS-рукопожатие (в TLS 1.3 — один обмен, в TLS 1.2 — два), сам запрос. Это три-четыре RTT, то есть 120–160 мс только на ожидание сети. Если страница затем последовательно грузит скрипты, которые запрашивают API, которые обращаются к другим API, задержка складывается многократно.

Маршрут

Трафик идёт не по прямой, а по сетям провайдеров, которые договорились обмениваться трафиком. Из Санкт-Петербурга до Амстердама пакеты могут пройти через Стокгольм, из Самары — через Москву и Франкфурт. В наших замерах 11 октября до одного и того же сервера в Амстердаме RTT был 36 мс из Петербурга, 42 мс из Тулы и 98 мс из Самары: разница — в маршруте конкретного провайдера, а не в расстоянии. Поэтому проверка из одной точки ничего не говорит обо всех клиентах.

Замедление сетей отдельных хостеров

По данным Cloudflare (публикация от 26 июня 2025 года), с 9 июня 2025 года российские провайдеры — среди них Ростелеком, МегаФон, Вымпелком, МТС и МГТС — замедляют соединения к сайтам за Cloudflare: загружаются только первые 16 КБ каждого ресурса, после чего передача зависает. Это касается и HTTP/1.1, и HTTP/2, и HTTP/3. В той же публикации со ссылкой на сторонние отчёты названы Hetzner, DigitalOcean и OVH.

Признак такого замедления: TCP-соединение устанавливается быстро, первые килобайты приходят, а дальше скорость падает до нуля. Наши замеры 11 октября 2026 года показывают, что картина не стоит на месте: к тестовым файлам Hetzner в Хельсинки и Нюрнберге с 13 из 14 российских точек проверки TCP-соединение устанавливалось, а TLS-рукопожатие не завершалось за 15 секунд — даже первые байты не проходили. В это же время сервер Vultr в Амстердаме отвечал с тех же точек нормально.

На это владелец сервера повлиять не может: ограничение работает у провайдера клиента, а не на сервере. Решение одно — разместить сайт в сети, к которой такие ограничения не применяются, и проверить это до переезда.

DNS

Прежде чем подключиться, браузер узнаёт IP-адрес сайта. Задержка появляется, если DNS-серверы домена отвечают медленно или нестабильно, если после переезда у записи остался большой TTL (время, на которое ответ кешируется) и часть клиентов ходит на старый адрес. Отдельный случай — запись AAAA (IPv6-адрес), которая указывает на сервер, где IPv6 не работает: браузер сначала пробует IPv6, ждёт и только потом переключается на IPv4.

TLS

Неполная цепочка сертификатов: часть браузеров достраивает её сама, скачивая промежуточный сертификат, — это лишние запросы, а некоторые клиенты просто выдают ошибку. Старые настройки без TLS 1.3 добавляют ещё один обмен к каждому новому соединению.

MTU

MTU — максимальный размер пакета на пути, обычно 1 500 байт; туннели и PPPoE уменьшают его. Если по пути пакет больше допустимого, а служебные сообщения ICMP «нужна фрагментация» где-то отфильтрованы, возникает «чёрная дыра»: соединение устанавливается, короткие ответы проходят, а первая полноразмерная порция данных теряется. Симптом похож на замедление, но обрыв случается на первых 1–2 КБ, а не на 16 КБ, и воспроизводится со всех сетей, у которых общий участок пути.

Сам сервер

Перегруженный процессор, медленная база данных или долгий ответ приложения выглядят снаружи так же: «сайт тормозит». Отличить их от сетевых причин помогает разбивка времени запроса — о ней в шаге 3.

Шаг 1. Проверить задержку и потери: ping

ping -c 20 example.com

Смотрите на последние строки. Пример вывода (снят не из России; example.com обслуживает CDN с узлом рядом с местом замера, поэтому задержка маленькая):

--- example.com ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.564/12.180/68.373/14.732 ms
  • packet loss больше 1–2 % — уже проблема: потерянные пакеты TCP отправляет заново, и страница грузится рывками.
  • avg — средняя задержка; сравните её с ориентирами выше. 40 мс из Москвы до Нидерландов — норма, 150 мс — повод смотреть маршрут.
  • Большая разница между min и max (разброс, stddev) — признак перегруженного участка. В примере минимум 4,5 мс, а максимум 68 мс: так часто выглядит загруженный Wi-Fi у самого проверяющего. Прежде чем искать проблему у хостера, повторите проверку по кабелю.

Если ответа нет совсем, это ещё не значит, что сервер недоступен: многие серверы и файрволы не отвечают на ping. Тогда переходите к шагам 2 и 3.

Шаг 2. Найти проблемный участок пути: mtr

mtr совмещает ping и traceroute: отправляет пакеты с растущим временем жизни и показывает статистику по каждому узлу пути.

mtr -rwzbc 100 example.com
  • -r — отчёт после завершения, -c 100 — 100 пакетов на каждый узел (около двух минут);
  • -w — не обрезать имена, -b — показывать и имена, и адреса, -z — номер автономной системы (AS — сеть отдельного провайдера).

Пример — реальный отчёт с домашнего подключения в Москве до сервера в Амстердаме, 11 октября 2026 года (Globalping, сокращено):

Host                                                          Loss%  Rcv    Avg  StDev
 1. AS9123  _gateway (217.198.9.1)                             0.0%   10    0.2    0.1
 2. AS???   10.66.36.1                                         0.0%   10    9.0    3.8
 3. AS???   10.255.3.1                                         0.0%   10 2161.2 1530.4
 4. AS???   10.255.1.58                                        0.0%   10    1.1    1.1
 5. AS8359  m9-cr04-hu0-6-0-7.msk.mts-internet.net             0.0%   10   11.9    0.1
 6. AS8359  a433-cr06-eth-trunk4.msk.mts-internet.net          0.0%   10   11.0    0.4
 7. AS8359  anc-cr02-eth-trunk21.299.ff.mts-internet.net      40.0%    6   37.4    0.3
 8. AS8359  tct-cr11-eth-trunk5.ams.mts-internet.net           0.0%   10   46.3    2.8
 9. AS???   80.249.212.38                                      0.0%   10   45.8    6.3
10. AS???   (waiting for reply)
11. AS???   (waiting for reply)
12. AS20473 173.199.112.244.vultrusercontent.com               0.0%   10   42.9    0.2
13. AS20473 ams-nl-ping.vultr.com (108.61.198.102)             0.0%   10   45.5    0.0

Как это читать:

  • Главное — последняя строка. Здесь 0 % потерь и 45 мс: путь в порядке.
  • Потери на промежуточном узле, которые не доходят до конца, — не проблема. На узле 7 видно 40 %, но на следующих узлах потерь нет. Маршрутизаторы отвечают на служебные пакеты в последнюю очередь и часто ограничивают число ответов — сам транзитный трафик при этом идёт нормально.
  • То же с задержкой. 2 161 мс на узле 3 и 1 мс на узле 4 означают, что узел 3 медленно отвечает на служебные пакеты, а не задерживает трафик.
  • Проблема — там, где потери или рост задержки начинаются и сохраняются до последней строки. Например, 0 % до узла 7, а начиная с него 15 % на каждом узле и на сервере.
  • Скачок задержки между соседними узлами показывает, где трафик проходит большое расстояние. Здесь между узлами 6 и 7 задержка выросла с 11 до 37 мс: трафик покинул Москву (msk в именах узлов 5 и 6) и к узлу 8 дошёл до Амстердама (ams в имени). Имена узлов провайдеры дают по своим правилам, но коды городов в них встречаются часто.
  • (waiting for reply) — узел не отвечает на служебные пакеты. Если следующие узлы отвечают, это нормально.

Если на пути фильтруют ICMP, запустите mtr через TCP на порт сайта — так пакеты проходят тем же путём, что и запросы браузера:

sudo mtr -rwzbc 100 --tcp --port 443 example.com

Если mtr нет, подойдёт обычный traceroute -n example.com (в режиме TCP — sudo traceroute -T -p 443 example.com в Linux). Он делает по три замера на узел, поэтому потери по нему оценить нельзя — только путь и задержку. В Windows аналоги — tracert и pathping.

Отчёт mtr стоит сохранить: если проблема на стороне хостера, его попросят в поддержке.

Шаг 3. Разложить время запроса: curl -w

curl умеет показывать, сколько заняла каждая стадия запроса:

curl -o /dev/null -s -w 'DNS:          %{time_namelookup}\nTCP:          %{time_connect}\nTLS:          %{time_appconnect}\nПервый байт:  %{time_starttransfer}\nВсего:        %{time_total}\nКод ответа:   %{http_code}\n' https://example.com/

Пример вывода (снят не из России, показывает формат):

DNS:          0.176510
TCP:          0.184813
TLS:          0.212104
Первый байт:  0.336023
Всего:        0.336657
Код ответа:   200

Все значения в секундах и отсчитываются от начала запроса, поэтому длительность стадии — разница соседних строк:

Строка Что значит Если величина большая
time_namelookup Получен IP-адрес Медленные DNS-серверы домена или резолвер провайдера
time_connect − time_namelookup TCP-рукопожатие ≈ один RTT Расстояние или плохой маршрут — смотрите mtr
time_appconnect − time_connect TLS-рукопожатие Должно быть 1–2 RTT. Секунды — проблема с TLS или обрыв соединения в пути. Для http:// всегда 0
time_starttransfer − time_appconnect Сервер готовит ответ Медленное приложение или база данных. Сеть тут почти ни при чём
time_total − time_starttransfer Передача тела ответа Низкая скорость канала, потери или замедление

Чтобы сравнить IPv4 и IPv6, добавьте ключ -4 или -6. Если по -6 запрос висит, а по -4 проходит быстро — запись AAAA указывает на неработающий IPv6.

Так выглядели эти стадии с точки проверки Globalping в Москве 11 октября 2026 года. Здесь уже длительность каждой стадии, а не время от начала, в миллисекундах:

Сервер TCP-рукопожатие TLS-рукопожатие Ожидание первого байта
Vultr, Амстердам 45 48 62
Selectel, Санкт-Петербург 11 30 23
Hetzner, Нюрнберг 48 не завершилось за 15 с —

TCP-соединение с Hetzner установилось так же быстро, как с Vultr, но дальше данные не пошли. Так выглядит ограничение в пути, а не проблема сервера: сервер не может «не ответить на TLS» только для части клиентов.

Сертификат и цепочку можно проверить отдельно:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Команда покажет, на какое имя выдан сертификат, кем и до какой даты он действует. Полноту цепочки удобно проверить онлайн-сервисами вроде SSL Labs.

Шаг 4. Скачать большой файл: проверка на обрыв после 16 КБ

Маленькая страница может загрузиться полностью даже при замедлении — она меньше 16 КБ. Поэтому положите на сервер файл побольше и скачайте его. На сервере с nginx:

sudo dd if=/dev/urandom of=/var/www/html/test-10mb.bin bs=1M count=10 status=none

С компьютера, который проверяете:

curl -o /dev/null --max-time 60 --speed-limit 1 --speed-time 10 \
  -w 'Получено: %{size_download} байт за %{time_total} с, код %{http_code}\n' \
  https://example.com/test-10mb.bin

--speed-limit 1 --speed-time 10 прерывает загрузку, если 10 секунд подряд не пришло ни байта, — curl не будет висеть бесконечно.

Нормальный результат — файл пришёл целиком (пример с тестовым файлом в Амстердаме):

Получено: 10485760 байт за 15.385756 с, код 206

Зависание выглядит так (мы смоделировали его локальным сервером, который отдаёт 16 КБ и замолкает):

curl: (28) Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds
Получено: 16384 байт за 16.059793 с, код 200

Ошибка 28 и 15–20 КБ полученных данных — характерный признак ограничения в пути. Если обрыв происходит на 1–2 КБ — проверьте MTU (ниже). Если файл приходит целиком, но медленно, — смотрите потери в mtr.

Проверка MTU в Linux — пакет 1 472 байта плюс 28 байт заголовков дают ровно 1 500, -M do запрещает фрагментацию:

ping -c 3 -M do -s 1472 203.0.113.10

В macOS то же делает ping -c 3 -D -s 1472 203.0.113.10. Если такие пакеты теряются, а с -s 1200 проходят, — на пути MTU меньше 1 500. Узнать его точно поможет tracepath -n 203.0.113.10 в Linux: он печатает pmtu для каждого участка.

После проверки удалите тестовый файл: sudo rm /var/www/html/test-10mb.bin.

Шаг 5. Проверить доступность сервера из России из разных сетей

Одна проверка показывает путь только от одного провайдера. Повторите шаги 3 и 4:

  • с домашнего интернета;
  • с мобильного интернета — раздайте его с телефона на ноутбук, или запустите curl на телефоне в терминале вроде Termux;
  • попросите коллег или знакомых в других городах и у других провайдеров.

На проверяющем устройстве не должно быть прокси и программ, которые перенаправляют трафик, — иначе вы измерите путь от промежуточного узла, а не от провайдера.

Если своих точек мало, помогут бесплатные сервисы с точками в России:

  • Globalping — ping, mtr, traceroute, DNS и HTTP-запрос с выбором страны, города и провайдера. Среди российских точек есть подключения домашних провайдеров.
  • Check-host.net — ping, проверка TCP-порта и HTTP; российские точки в Москве и Санкт-Петербурге.

Учтите ограничение: HTTP-проверка таких сервисов скачивает только начало ответа (у Globalping — около 10 КБ), поэтому обрыв на 16 КБ они не покажут. Зато хорошо видно, проходит ли TLS-рукопожатие и сколько оно длится. Точки в дата-центрах тоже не всегда ведут себя как домашний интернет — итоговое слово за проверкой с реальных подключений.

Шаг 6. Посмотреть со стороны сервера

Состояние соединений: ss

На сервере во время медленной загрузки:

ss -tin state established '( sport = :443 )'

Для каждого соединения клиента выводится строка с параметрами TCP. Полезные поля:

  • rtt:45.2/3.1 — задержка до клиента и её разброс в миллисекундах;
  • retrans:0/12 — сколько пакетов отправлено повторно; растущее второе число означает потери в пути;
  • bytes_acked — сколько байт клиент подтвердил. Если у соединений из России оно застывает около 16 000, а unacked и retrans растут — данные уходят, но до клиента не доходят;
  • cwnd — окно отправки; если оно остаётся маленьким, сервер не может разогнаться из-за потерь.

Журнал nginx: время и полнота ответа

Стандартный журнал nginx не показывает, сколько длился запрос и был ли ответ отправлен полностью. Добавьте свой формат:

sudo tee /etc/nginx/conf.d/timing.conf > /dev/null <<'EOF'
log_format timing '$remote_addr [$time_local] "$request" $status '
                  'sent=$body_bytes_sent rt=$request_time done=$request_completion ua="$http_user_agent"';
access_log /var/log/nginx/timing.log timing;
EOF
sudo nginx -t && sudo systemctl reload nginx

Это второй журнал рядом с обычным, основной не меняется. $request_time — время обработки запроса в секундах, $request_completion — OK, если ответ отправлен полностью, и пусто, если нет. Пример двух записей — полной и прерванной:

127.0.0.1 [11/Oct/2026:10:57:18 +0000] "GET /big.bin HTTP/1.1" 200 sent=20000000 rt=0.055 done=OK ua="curl/8.5.0"
127.0.0.1 [11/Oct/2026:10:57:21 +0000] "GET /big.bin HTTP/1.1" 200 sent=2653937 rt=2.010 done= ua="curl/8.5.0"

Обратите внимание: код ответа в обоих случаях 200 — по нему одному обрыв не заметить. Код 499 означает, что клиент закрыл соединение раньше, чем nginx начал отвечать.

Неполные ответы и запросы дольше 5 секунд:

grep 'done= ' /var/log/nginx/timing.log | tail -n 20
awk '{for (i = 1; i <= NF; i++) if ($i ~ /^rt=/) { split($i, a, "="); if (a[2] > 5) print }}' /var/log/nginx/timing.log

Если такие записи идут в основном с адресов российских провайдеров, а sent у них держится около 16 000 байт, причина — в пути до этих провайдеров. Если медленные запросы есть у всех клиентов и rt большой даже для коротких ответов — ищите проблему в приложении.

Как понять причину: сводная таблица

Что видно Вероятная причина Что делать
Высокий ping, mtr без потерь, всё работает, но не мгновенно Расстояние Сократить число обменов: HTTP/2, TLS 1.3, кеширование, меньше последовательных запросов. Для аудитории в России — сервер ближе
mtr: потери начинаются с какого-то узла и держатся до конца Перегруженный участок или плохой маршрут Сохранить отчёт mtr, написать хостеру; при проблеме у провайдера клиента — ему
Большой time_namelookup DNS Проверить DNS-серверы домена: dig example.com NS, время ответа — в строке Query time вывода dig example.com
-6 висит, -4 работает Сломанный IPv6 Настроить IPv6 на сервере или удалить запись AAAA
TCP быстро, TLS не завершается Ограничение в пути или ошибка TLS Проверить сертификат через openssl; если с ним всё в порядке и с зарубежных сетей сайт работает — ограничение у провайдеров
Большой разрыв между TLS и первым байтом Медленное приложение Профилировать приложение и базу данных
Загрузка обрывается на 15–20 КБ, только из российских сетей Замедление сети хостера На сервере не исправить. Переезд в другую сеть
Обрыв на 1–2 КБ, из разных сетей MTU Проверить ping -M do, tracepath; разрешить ICMP «fragmentation needed» в файрволе
Медленно только в определённые часы Перегрузка канала в часы пик Повторить mtr вечером и днём, сравнить

Что может исправить хостер, а что нет

Может:

  • выбрать сеть и площадку, к которым из России нет ограничений, и проверять это с российских подключений до запуска и после;
  • следить за качеством маршрутов к крупным российским провайдерам и обращаться к вышестоящим операторам, если путь деградировал;
  • помочь с диагностикой: сделать замеры со своей стороны, посмотреть отчёт mtr;
  • перенести сервер в другую сеть или локацию.

Не может:

  • изменить решения российских провайдеров о замедлении тех или иных сетей;
  • обойти физику: от Москвы до Амстердама около 2 150 км по прямой, даже идеальный кабель по прямой дал бы RTT около 22 мс, а реальные маршруты дают 35–45 мс;
  • исправить медленное приложение или проблемы на стороне конкретного клиента — например, загруженный Wi-Fi.

Что дальше