👻 ping-config: проверка узлов по-настоящему

Обычная проверка группы — HEAD к url. Её проходит и узел, который отвечает заголовками, но режется на теле (например, замирает после ~16–20 КБ). ping-config добавляет вторую проверку: после url ядро запрашивает destination, и узел жив, только если она ответила вовремя. Аналог burstObservatory.pingConfig из Xray.

proxy-groups:
  - name: auto
    type: url-test
    proxies: [node1, node2]
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    ping-config:
      destination: https://speed.cloudflare.com/__down?bytes=51200
      http-method: GET
      interval: 60s
      sampling: 1
      timeout: 3s
      connectivity: http://connectivitycheck.gstatic.com/generate_204

Поле	Что делает	По умолчанию
`destination`	адрес второй проверки	`url` группы
`http-method`	`HEAD` или `GET`; `GET` читает тело целиком (до 4 МиБ)	`HEAD`
`interval`	интервал проверок; `"15s"`, `"1m"` или число секунд; минимум 10 с	`interval` группы → 300 с
`sampling`	сколько раз за цикл проверяется каждый узел (1–32)	1
`timeout`	таймаут запроса к `destination`; `"3s"`, `"500ms"` или число миллисекунд	`timeout` группы → 5000 мс
`connectivity`	адрес прямой (DIRECT) проверки сети устройства	выключено

Работает в url-test, fallback, load-balance и smart. В select фоновых проверок нет — блок влияет только на ручные тесты.

Поле есть только в Prizrak-Core, в mihomo его нет.

Как проходит проверка

Задержка — как раньше: HEAD к url, с глобальным unified-delay. Цифры остаются в привычном масштабе.
Затем destination: узел жив, только если ответ 2xx/3xx пришёл за timeout, а при GET тело скачалось целиком. Обрыв, зависание на середине, ошибка — узел мёртв, даже если HEAD прошёл.
Если destination на том же адресе, что url, запрос идёт по тому же соединению; если сайт его закрыл — по новому. HEAD к самому url второй раз не отправляется.

Один профиль на url

ping-config привязан к url группы. Любая проверка этого url идёт по профилю: от любой группы, от health-check провайдера с тем же url, из API и приложений. Если у двух групп один url и разные блоки, действует блок группы, которая выше в конфиге; второй игнорируется с предупреждением в логе.

Расписание

На старте все узлы проверяются сразу.
Дальше цикл длится interval × sampling, и каждый узел проверяется sampling раз в случайные моменты цикла — не все разом. Одновременно не больше 10 проверок.
lazy и энергосбережение Prizrak-Box на телефоне соблюдаются, как у обычных проверок.
Узел, который есть в нескольких группах или провайдерах с тем же url, проверяется один раз, а не по разу от каждой.
Если узел только что проверили иначе (ручной тест, max-failed-times), один запуск пропускается.
max-failed-times запускает немедленную проверку — тоже по профилю.

`sampling`

1 — решение по последней проверке, как раньше.
> 1 — по окну из двух циклов: узел жив, если в окне есть хоть один успех; задержка — среднее успешных проверок.

`connectivity`

После неудачной проверки ядро делает один прямой запрос мимо VPN. Если сети нет, неудача не записывается — при обрыве Wi-Fi все узлы разом не станут мёртвыми. Ответ кэшируется на ~2 с.

API и приложения

testUrl группы остаётся обычным url, поэтому дашборды (zashboard и др.) и Prizrak-Box работают без изменений. В JSON группы появляется объект pingConfig, если для её url задан профиль.