Три недели смотрел, какие хостинги открываются из России: 403 и таймаут это не одно и то же

Я руковожу digital‑агентством в Израиле. Мы делаем сайты и рекламу, и клиенты регулярно спрашивают, где их сайт лучше разместить. Один из вопросов звучит так: «а этот хостинг вообще открывается у людей в России и на Украине?» Универсального ответа я не нашёл, поэтому решил не гадать, а измерить. С 6 октября 2026 года скрипт каждый день проверяет 17 адресов из девяти точек в шести странах и сохраняет результат в файл. В статье разбор первых трёх недель: сколько проверок прошло, как именно они заканчивались неудачей и чем отличаются отказы с кодом 403 от таймаутов.

Сразу о границах. Это не рейтинг хостингов и не оценка качества. Это срез того, как один внешний сервис проверки видит главные страницы сайтов. Что из этого следует и чего не следует, я разберу отдельно.

Как собирали данные

Источник: бесплатный сервис check‑host.net. Он принимает адрес и список своих узлов, с каждого узла делает HTTP‑запрос и возвращает результат: признак успеха, время ответа, код ответа и текст сообщения. Узлы расположены в разных странах, у каждого свой провайдер.

Я выбрал девять узлов:

• Россия: ru1, ru2, ru3

• Украина: ua1, ua3

• Казахстан: kz1

• Израиль: il1

• Германия: de1

• США: us1

В списке проверяемых адресов 17 штук: 16 хостингов и регистраторов (российские, украинские, казахстанский и международные) и контрольный google.com. Контроль нужен, чтобы отделить проблемы сайтов от проблем самого метода. Если контрольный адрес стабильно открывается отовсюду, значит, сам проверяющий работает и массовых сбоев нет.

Проверка запускается раз в сутки через GitHub Actions. Скрипт отправляет запрос, ждёт до минуты и сохраняет ответ в data/availability/ГГГГ‑ММ‑ДД.json. Весь скрипт приведён в конце статьи.

Что считаем успехом: сервис вернул признак ok. Что считаем отказом: всё остальное. Отказы я разложил на типы:

• 403: сервер ответил, но отказал в доступе;

• таймаут: ответа не дождались (в сообщении «Connection timed out»);

• сброс соединения: «Connection reset by peer» или «Broken pipe»;

• 502: ответ «Bad Gateway».

Что не вошло в расчёт

Данных за 19 дней набралось меньше, чем хотелось бы, и здесь важно быть честным.

Файлов за период 19, но три из них (21, 23 и 24 октября) пустые: сервис не вернул результатов ни по одному узлу. 18 и 19 октября файлов нет вообще. В итоге для расчёта осталось 16 дней. Ещё в файле за 26 октября часть узлов не ответила, эти строки я тоже отбросил.

Отдельно убрал 49 записей с сообщением «Too many open files». Это ошибка самого узла ua3 (у него закончились открытые соединения), к сайту она отношения не имеет. Они встречаются у разных хостингов и даже у google.com.

Без пустых результатов и ошибок узла осталось 2365 проверок, из них успешных 2026, то есть 86%. По России: 810 проверок, 599 успешных, 74%.

Адрес beget.com/ru я выношу отдельно, потому что он ломает любую статистику. Он не открылся ни с одного из девяти узлов ни разу, включая Германию и США. Отказы там двух типов: 502 и сброс соединения. Такая картина говорит скорее об ограничении метода, чем о недоступности: сайт отказывает именно этому проверяющему, откуда бы тот ни запрашивал. Выводов про доступность Beget для пользователей из этих данных сделать нельзя. В сводную таблицу я его оставил, чтобы это было видно, но в выводах не использую.

Ограничения метода

1. Один сервис проверки. Если check‑host.net или его узлы устроены специфически, это отражается на всех результатах сразу.

2. Один запрос на узел в сутки. Это очень разреженная выборка. Короткий сбой на несколько часов мы можем не увидеть, а случайный сбой в момент проверки можем принять за системный.

3. Мало узлов. В России их три, на Украине два, в остальных странах по одному. Поведение одного узла нельзя считать поведением страны.

4. Проверяется только главная страница по HTTP‑запросу. Это не то же самое, что открыть сайт в браузере: нет JavaScript, нет cookie, у запроса другие заголовки.

5. Узлы проверки это серверы в дата‑центрах, а не домашний интернет или мобильная сеть. Обычный пользователь может видеть другое.

С этим фоном дальше цифры.

Результаты

Сводная таблица: доля успешных проверок в России, в остальных пяти странах вместе, медианное время ответа (только для успешных проверок) и типы отказов в России.

Рисунок 1. Доля успешных проверок по хостингам и странам.

Что видно сразу.

Контрольный google.com открылся все 100% раз (единственный сбой был ошибкой узла ua3 и в расчёт не вошёл). Значит, сам метод работает, и массовых проблем с проверяющим не было.

Российские хостинги из России открываются стабильно. Reg.ru, Selectel, Jino, FirstVDS, Sprinthost, SWEB дали 100% из всех трёх российских узлов. Это ожидаемо, но полезно иметь в виде контрольной группы.

Четыре международных адреса дают из России от 0 до 52%: Hostinger, Hetzner, Bluehost и DigitalOcean, а также украинский регистратор ukraine.com.ua. Из Казахстана, Израиля, Германии и США те же адреса открываются в 100% проверок (кроме Bluehost, об этом ниже).

Timeweb и один общий сбой. У обоих адресов Timeweb по 94% по всем странам. Причина проста: 8 октября оба адреса не открылись одновременно со всех девяти узлов. Это единичный день, и он выглядит как проблема на стороне самого Timeweb, а не как региональное ограничение, потому что она была и в Германии, и в США. Больше таймаутов у Timeweb не было.

Время ответа

Медианы времени ответа считались только по успешным проверкам. Поэтому у Hostinger для России медианы нет: ни одна проверка не прошла.

Российские хостинги из российских узлов отвечают быстро (Reg.ru 119 мс, Timeweb 99 и 140 мс, Selectel 139 мс), из остальных стран медленнее (Selectel 712 мс, Jino 742 мс, SWEB 966 мс). Это обычная география: чем дальше узел от дата‑центра, тем дольше путь. Международные хостинги дают обратную картину: DigitalOcean 108 мс из остальных стран и 146 мс из России, Hetzner 338 и 223 мс.

Здесь важно не переоценивать цифры. В России успешные проверки по Hetzner, DigitalOcean и Bluehost почти все пришли с одного узла ru3 (об этом ниже), так что «медиана по России» это фактически медиана одного узла.

Три российских узла видят мир по‑разному

Самое интересное в данных я заметил не сразу. Три российских узла отличаются друг от друга сильнее, чем кажется.

Рисунок 2. Результат проверки по дням на трёх российских узлах. Серые клетки: дни без данных.

Узел ru3 открывает Hetzner, DigitalOcean, Bluehost и ukraine.com.ua в 100% проверок, все 16 дней. Узлы ru1 и ru2 те же адреса открывают редко: Hetzner один раз из 32 проверок, ukraine.com.ua дважды из 32. А вот Hostinger с ru3 не открывается ни разу, и отказ всегда одинаковый, 403.

Почему узлы отличаются, мы не знаем. Можно предположить, что у них разные провайдеры или разные маршруты до этих хостингов, но это предположение, и данными оно не подтверждается. Единственное, что можно сказать уверенно: результат зависит от конкретного узла, а не от страны в целом. Одна проверка «из России» может дать зелёный результат, а соседняя красный.

Отсюда практический вывод для тех, кто сам делает такие замеры: одной точки на страну недостаточно, лучше три и больше, а в публикации надо показывать результат по узлам, а не только среднее.

Изменения по дням

Картина не была полностью стабильной.

Hostinger. До 16 октября узлы ru1 и ru2 получали таймаут или сброс соединения. С 17 октября ru1 стал получать 403, а ru2 в большинстве дней тоже. Узел ru3 получал 403 с первого дня. То есть в течение периода запрос стал доходить до сервера, и сервер начал отвечать явным отказом. В результате доля успешных проверок из России осталась нулевой, но тип отказа изменился.

DigitalOcean и Bluehost. До середины октября ru1 и ru2 почти всегда получали таймаут. С 17 октября у DigitalOcean и с 20 октября у Bluehost узел ru1 начал открывать сайты почти каждый раз, а ru2 открывал нерегулярно (DigitalOcean 4 раза из 16). Это не обязательно улучшение: при одной проверке в сутки трудно отличить изменение условий от случайных колебаний.

Hetzner. До 25 октября включительно ru1 и ru2 дают таймаут. 25 октября ru1 один раз открыл сайт, 26 октября снова таймаут.

ukraine.com.ua. Всего два дня за 16, когда один из узлов ru1 или ru2 получил ответ (9 и 14 октября).

Bluehost и Namecheap с Украины. Похожая картина есть и на Украине: Bluehost и Namecheap отдали 403 на узле ua3 (Bluehost 13 раз, Namecheap 14), тогда как второй украинский узел ua1 открывает те же сайты без проблем. Страны здесь нет: отказ идёт с одного узла, а не со всей Украины.

Рисунок 3. Чем заканчиваются неудачные проверки из России.

403 или таймаут: в чём разница

Это самый частый вопрос, когда видишь красные клетки. Данные позволяют сказать вот что.

403 Forbidden означает, что запрос дошёл до сервера (или до устройства перед ним), прочитан и получил отказ. Время ответа при этом очень маленькое. В наших данных медиана для 403 около 125 миллисекунд: ответ пришёл быстро, никто ничего не ждал. Сервер знает, что вы обращаетесь, и сам решил не отдавать страницу. Решение принимал кто‑то на стороне сайта: фильтр, защитный сервис, правило на сервере. Почему именно он так решил, по ответу сказать нельзя. Это может быть правило по стране, по адресу узла, по заголовкам запроса или по частоте обращений.

Таймаут означает совсем другое: ответа не пришло. Медиана времени у таймаутов около 16 секунд, то есть это время ожидания, после которого проверяющий сдался. Причин может быть много: запрос не дошёл, сервер не ответил, ответ потерялся по дороге. По одному таймауту невозможно сказать, кто виноват: сайт, сеть где‑то по пути или сам проверяющий.

Для практики из этого следует:

• 403 стоит разбирать на стороне сайта: смотреть, какие правила и защиты включены, как выглядит ответ, что в заголовках. Достаточно повторить запрос с другого адреса и сравнить.

• Таймаут надо проверять сетевыми инструментами: traceroute, повторный запрос с другого узла, замер в разное время суток. Одного таймаута недостаточно ни для какого вывода.

• Если один и тот же адрес выдаёт 403 из одной точки и таймаут из соседней, это не противоречие: это две разные ситуации на двух разных путях.

Именно такую смесь мы видим у Hostinger в России: ru3 всегда получает 403, ru1 и ru2 до 16 октября получали таймаут и сброс соединения, а после 17 октября начали получать 403.

Что мы не можем сказать: почему так происходит. Вывод «из‑за санкций» или «из‑за блокировок» не следует из этих данных: мы не видим ни причины отказа, ни того, кто принял решение. Любая версия причины без дополнительной проверки (запросы другим способом, с другими заголовками, из других сетей, письмо в поддержку хостинга) остаётся догадкой.

Что делать с этим на практике

Если вы выбираете хостинг для проекта, у которого есть аудитория в России, то один раз открыть сайт у себя недостаточно. Проверьте главную страницу хостинга с нескольких узлов в разные дни и сравните результаты. Если несколько узлов дают разный результат, это повод выяснять причину, а не делать вывод по одной зелёной или красной клетке.

И обратное: не принимайте красные клетки за приговор. Беглый взгляд на Рисунок 1 легко подсказывает «Hostinger недоступен в России», но по данным видно лишь, что три конкретных узла в течение трёх недель получали отказ или таймаут.

Как повторить

Скрипт ниже весь. Нужен Node.js 18 или новее (используется встроенный fetch), других зависимостей нет. Сервис check‑host.net имеет собственные лимиты на частоту запросов, поэтому между адресами скрипт делает паузу. Запускайте не чаще раза в сутки.

// Daily availability snapshot of hosting providers' main sites from several countries via check-host.net.
// Writes data/availability/YYYY-MM-DD.json.
import fs from "node:fs";
import path from "node:path";

const HOSTS = [
  "https://www.hostinger.com", "https://www.reg.ru", "https://timeweb.com", "https://timeweb.cloud",
  "https://beget.com/ru", "https://sprinthost.ru", "https://sweb.ru", "https://jino.ru",
  "https://firstvds.ru", "https://selectel.ru", "https://www.hetzner.com", "https://www.digitalocean.com",
  "https://www.namecheap.com", "https://www.bluehost.com", "https://www.ps.kz", "https://www.ukraine.com.ua",
  "https://www.google.com",
];
const NODES = ["ru1", "ru2", "ru3", "ua1", "ua3", "kz1", "il1", "de1", "us1"].map((n) => `${n}.node.check-host.net`);
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const get = async (url) => (await fetch(url, { headers: { Accept: "application/json" } })).json();

async function check(host) {
  const q = new URLSearchParams([["host", host], ...NODES.map((n) => ["node", n])]);
  const { request_id } = await get(`https://check-host.net/check-http?${q}`);
  let res = {};
  for (let i = 0; i < 6; i++) {
    await sleep(10000);
    res = await get(`https://check-host.net/check-result/${request_id}`);
    if (Object.values(res).every((v) => v !== null)) break;
  }
  const out = {};
  for (const node of NODES) {
    const r = res[node];
    const short = node.split(".")[0];
    if (!r || !r[0]) { out[short] = { ok: null, note: "no result" }; continue; }
    const [ok, time, msg, code] = r[0];
    out[short] = { ok: ok === 1, time: time == null ? null : Number(time), code: code ?? null, msg: msg ?? null };
  }
  return out;
}

const date = new Date().toISOString().slice(0, 10);
const results = {};
for (const host of HOSTS) {
  try { results[host] = await check(host); } catch (e) { results[host] = { error: String(e) }; }
  await sleep(3000);
}
const dir = path.join(process.cwd(), "data", "availability");
fs.mkdirSync(dir, { recursive: true });
fs.writeFileSync(path.join(dir, `${date}.json`), JSON.stringify({ date, checkedAt: new Date().toISOString(), nodes: NODES, results }, null, 1));
console.log(`Saved ${date}: ${Object.keys(results).length} hosts`);

Запуск: сохраните как availability‑check.mjs и выполните node availability-check.mjs. Результат появится в папке data/availability. Для ежедневного запуска проще всего workflow в GitHub Actions по расписанию (cron) с коммитом файла обратно в репозиторий: так за несколько недель накапливается ряд данных.

Чтобы посчитать долю успешных проверок, прочитайте все файлы, отбросьте записи с ok равным null (нет результата) и сообщения «Too many open files», затем для каждой пары «адрес и страна» поделите число записей с ok равным true на общее число оставшихся. Время ответа в файле хранится в секундах.

Что дальше

Следующий шаг для меня очевиден: добавить больше узлов в каждой стране, запускать проверку несколько раз в сутки и дополнить HTTP‑запрос второй проверкой, которая показывает, где именно обрывается соединение. Тогда различие между 403 и таймаутом можно будет рассматривать не по косвенным признакам, а по конкретному месту в цепочке. Если у вас есть опыт таких замеров, напишите в комментариях, какие узлы и сервисы вы используете и как отделяете проблему сайта от проблемы проверяющего.