My ISP Sucks
Пожаловаться

Открытая методика

Как мы ставим вердикт

Всё работает в браузере. Данные не уходят с устройства, пока вы не нажмёте Поделиться отчётом. Логика ниже полная — ничего не скрыто.

Почему это иначе?

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

Speedtest

My ISP Sucks

Один тест охватывает

Один близкий сервер

Один тест охватывает

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

Загрузка, отдача, пинг

Да

Загрузка, отдача, пинг

Да

Стриминг, игры, облако

Оценка по числу

Стриминг, игры, облако

Проверка самих сервисов

Что работает, а что нет

Не показано

Что работает, а что нет

Показано

Кто виноват

Не назван

Кто виноват

Wi‑Fi, провайдер или сервис

Можно отправить

Число

Можно отправить

Жалобу

Не связан с Ookla и Speedtest.

Запустить этот тест

1 · Что мы проверяем

Четыре слоя, от устройства наружу:

Локальный шлюз (preflight)

10 подряд HEAD к ближайшей точке Cloudflare (таймаут 600 мс). Считаем потери и джиттер. Если ≥ 2 таймаута или σ > 30 мс → путь нестабилен.

Узлы в стране (near)

AWS S3 в вашей стране (по country code геолокации IP). Низкий балл = проблема домашнего ISP или маршрутизации.

Международные узлы (far)

16 региональных AWS S3 по миру (С. Виргиния, Франкфурт, Токио, Сингапур…). Высокий балл при норме near = проблема международного шлюза.

Сервисы профиля (profile)

15–25 HEAD к сервисам профиля (стриминг / игры / tech). Ловит пиринг и блокировки, невидимые обычному ping.

2 · Оценка узлов

Каждый узел: балл от 0 (идеал) до 1 (сломан). Средние near и far считаются отдельно.

score = 0.7 × (packetLoss / 100)
      + 0.3 × clamp((actualMs − expectedMs) / (expectedMs × 3), 0, 1)

expectedMs = max(10, distanceKm / 50)   ← speed-of-light RTT baseline

Пример — Тель‑Авив → С. Виргиния (9 500 км)

expectedMs = max(10, 9 500 ÷ 50) = 190 ms

actualMs = 219 ms, packetLoss = 0 %

score = 0 + 0.3 × clamp((219 − 190) / (190 × 3), 0, 1) = 0.015 → здорово

nearScore < 0.25

Near: здоров

farScore > 0.35

Far: сработает правило 6

farScore > 0.45

Far: деградация (5b)

3 · Выброс сервиса

outlier if:  status = "fail"
         OR  status = "slow"  AND  latencyMs ≥ cohortMedian × 2.5

slow = probe latency above 1 000 ms
ok under that line is not an outlier

Пример

Netflix 95 ms ✓ YouTube 88 ms ✓ Twitch 1 240 ms

cohortMedian = 88 ms → 1 240 ≥ 88 × 2.5 (220) → Twitch — выброс

4 · Цепочка правил

Побеждает первое совпадение. DevTools → Console на странице результата — какие правила сработали.

1

Офлайн

connectivity = fail, and no other check reached the internet

→ down / local_issue

2

Нестабильный локальный путь

Wi-Fi or cellular AND (preflight unstable OR jitter > 40 ms) AND farScore < 0.40

→ local_issue

3

Сломан DNS

device is online AND dns = fail

→ isp_issue

4

Выброс одного сервиса

core healthy AND 1 ≤ outliers ≤ 40 % of services

→ service_issue

5

Большинство сервисов плохо

core healthy AND badServiceFraction ≥ 50 %

→ isp_issue (peering)

5b

Международный трафик режется

preflight loss = 0 AND nearScore < 0.25 AND farScore > 0.45 AND ≥ 3 far nodes

→ isp_issue (gateway)

6

Ядро / far деградировали

any test = fail OR farScore > 0.35

→ isp_issue

6b

Мягкая деградация

any test = warn (no harder rule fired)

→ local_issue or isp_issue (medium)

✓

Всё в порядке

→ healthy

5 · Выполнение тарифа

ratio = measuredDown / promisedDown

≥ 0.80  →  "As advertised"    ✓
≥ 0.50  →  "Underdelivering"  ~
 < 0.50  →  "Far below plan"   ✗

Только пометка в отчёте — вердикт виновника не меняет.

6 · Конфиденциальность

Все пробы в браузере. На сервер ничего не уходит, пока вы не нажмёте Поделиться отчётом.

В общей записи: вердикт, баллы, ISP, страна, тип связи. IP-адреса не хранятся.