Как на самом деле работает проверка задержки и какими должны быть interval, tolerance и lazy

Откуда берётся число миллисекунд рядом с каждым узлом? Почему оно так далеко от того, что показывает ping? И почему автоматическая группа постоянно переключается?

Здесь разбирается всё, что связано с проверкой задержки.

Это не ping, а полный HTTP-запрос

Шаги, которые проходит Clash:

С ping это принципиально разные вещи:

Так что Clash, показывающий 180 мс при ping в 60 мс, — это совершенно нормально: разница складывается из стоимости рукопожатия и участка от узла до целевого сайта.

unified-delay: сделать протоколы сравнимыми

Стоимость рукопожатия сильно зависит от протокола. Trojan (TLS) по природе стоит на один круговой путь больше, чем Shadowsocks (без TLS), а Hysteria2 поверх QUIC — вообще отдельная история.

Сравнивать сырые итоги нечестно по отношению к части протоколов. Включите:

unified-delay: true

Ядро измеряет рукопожатие дважды, вычитает неизбежную стоимость протокола и оставляет только сравнимую часть.

Три ключевых параметра

- name: "♻️ Авто"
  type: url-test
  proxies: [...]
  url: "http://www.gstatic.com/generate_204"
  interval: 300
  tolerance: 50
  lazy: true
  timeout: 5000
  max-failed-times: 5

interval: как часто проверять

tolerance: самый важный и самый упускаемый

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

Рекомендации:

• Задержки узлов в основном ниже 100 мс → tolerance: 30
• В основном 100–300 мс → tolerance: 50
• Сильный разброс → tolerance: 100

lazy: не проверять в простое

lazy: true

С этим параметром группа пропускает проверку, когда через неё сейчас не идёт трафик.

Плюсы: экономит энергию, экономит трафик, избавляет от бессмысленных соединений. Особенно заметно на ноутбуках и телефонах.

Минус: вернувшись к группе, первый выбор может опираться на устаревшие данные, пока не отработает один круг проверки.

В повседневности включайте.

timeout и max-failed-times

timeout: 5000            # таймаут одной проверки, в миллисекундах
max-failed-times: 5      # сколько подряд неудач, чтобы счесть узел мёртвым

Слишком маленький timeout записывает медленные узлы в нерабочие; слишком большой растягивает каждый круг. 5000 мс — разумное значение.

Выбор тестового URL

У стандартного http://www.gstatic.com/generate_204 два свойства: он возвращает пустой 204 (данных почти не передаётся) и развёрнут на глобальной CDN.

Альтернативы:

Низкая задержка ≠ высокая скорость

Это то, что нуждается в прояснении больше всего.

url-test измеряет только задержку. Выдержит ли узел тяжёлый трафик, можно узнать, только реально что-нибудь скачав.

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

Полезная схема: многоуровневая проверка

proxy-groups:
  # основная группа: низкий допуск, частые проверки, погоня за отзывчивостью
  - name: "⚡ Отзывчивая"
    type: url-test
    include-all: true
    filter: "(?i)HK|Hong|JP|Japan"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 30
    lazy: true

  # тяжёлый трафик: высокий допуск, мало переключений, чтобы загрузки не рвались
  - name: "📦 Объёмная передача"
    type: fallback
    include-all: true
    filter: "(?i)IPLC|dedicated|premium"
    interval: 600

  # страховка: лишь бы работало
  - name: "🛡 Подстраховка"
    type: fallback
    include-all: true
    interval: 900

Почему для объёмной передачи fallback, а не url-test: при загрузке или просмотре видео самое неприятное — смена узла посреди процесса: соединение рвётся, прогресс теряется. fallback меняет узел только когда текущий действительно умер, и это заметно устойчивее.

Как правильно проверять вручную

Значок молнии в интерфейсе прогоняет один круг для текущей группы. Несколько оговорок:

Запуск проверки через API

Полезно при написании скриптов:

# проверить один узел
curl "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=http%3A%2F%2Fwww.gstatic.com%2Fgenerate_204" \
  -H "Authorization: Bearer ваш-secret"

# проверить всю группу
curl "http://127.0.0.1:9090/group/%E2%99%BB%EF%B8%8F%20Auto/delay?timeout=5000&url=..." \
  -H "Authorization: Bearer ваш-secret"

Имена групп с пробелами или эмодзи нужно кодировать в URL.

Коротко

• Измеряется полный круговой путь до целевого сайта через узел, а это не то же самое, что ping
• Всегда задавайте tolerance; 50 — хорошая отправная точка, без него группа мечется
• Ставьте 300 для interval; заметно меньше — и можно нарваться на антифрод провайдера
• Оставляйте lazy включённым, чтобы экономить энергию и трафик
• Включайте unified-delay, чтобы узлы на разных протоколах были сравнимы
• Задержка ничего не говорит о пропускной способности — для больших передач берите fallback, а не url-test

Смотрите также: пять типов proxy-groups и именование узлов и автоматическая группировка.

Смежные документы

Основы конфигурации Структура YAML в конфигурации Clash — за что отвечает каждое из восьми полей верхнего уровня

Конфигурация Clash / Mihomo разобрана сверху донизу — порты, режим, DNS, proxies, proxy-groups, rules и rule-providers — плюс минимальная рабочая конфигурация, которую можно вставить как есть.

2026-08-021184 слов3 мин чтения

Основы конфигурации Пять типов proxy-groups — select, url-test, fallback, load-balance и relay

Что каждая группа политик делает на самом деле, когда её применять, какие параметры важны, плюс готовая структура групп и опции include-all и filter из Mihomo.

2026-07-291200 слов3 мин чтения

Основы конфигурации Расширение подписки через Merge, чтобы ваши правки переживали обновления

Правка скачанного конфига откатывается при следующем обновлении. Как устроен расширенный конфиг Clash Verge: синтаксис prepend/append/override, порядок слияния и набор полезных фрагментов.

2026-07-091021 слов2 мин чтения