Автопереключение между входами в Xray: observatory, balancer и проверка через туннель

Почему пинга недостаточно

Через CDN соединение может устанавливаться, а данные — не идти: TLS до узла CDN проходит, а дальше узел отвечает ошибкой или рвёт поток. Пинг до CDN-домена (или TCP-проверка) такой маршрут считает живым.

Надёжный признак — настоящий HTTP-запрос через весь туннель: от клиента через CDN-вход, шлюз и ноду до внешнего сайта. Если запрос к generate_204 вернулся — маршрут рабочий целиком.

Схема: outbound-ы, observatory, balancer

1. Outbound на каждый маршрут. Для каждого сервера — по outbound на каждый вход, с понятными тегами: cw-de-entry2, cw-de-entry1 и т. д.
2. Observatory периодически проверяет каждый outbound запросом через него.
3. Balancer выбирает outbound по результатам проверки.
4. Routing отправляет трафик не в конкретный outbound, а в balancer.

Пример конфига

"burstObservatory": {
  "subjectSelector": ["cw-"],
  "pingConfig": {
    "destination": "https://www.gstatic.com/generate_204",
    "interval": "30s",
    "sampling": 3,
    "timeout": "5s"
  }
},
"routing": {
  "balancers": [
    {
      "tag": "cw-balancer",
      "selector": ["cw-"],
      "strategy": { "type": "leastPing" },
      "fallbackTag": "cw-de-entry2"
    }
  ],
  "rules": [
    { "type": "field", "network": "tcp,udp", "balancerTag": "cw-balancer" }
  ]
}

• subjectSelector и selector выбирают outbound-ы по префиксу тега.
• burstObservatory делает несколько проб (sampling) — устойчивее к единичным потерям, чем обычный observatory.
• fallbackTag — вход, на который уходить, если проверки не прошли нигде. Ставьте самый надёжный.
• Вместо leastPing можно взять leastLoad с ограничением maxRTT (например, 1500ms): тогда маршруты медленнее порога не выбираются вовсе.

Частые ошибки

• Слишком частые пробы. interval 5–10 секунд на десятке outbound-ов у тысяч абонентов — это заметная нагрузка и лишний трафик. 30–60 секунд достаточно.
• Проба через DNS, который недоступен в белых списках. Если домены входов резолвятся через 1.1.1.1, проверка будет падать на мобильном интернете не из-за маршрута, а из-за DNS — см. разбор про DNS в режиме белых списков.
• Проба на «тяжёлый» URL. Используйте лёгкий ответ без тела, вроде generate_204, а не главную страницу сайта.
• Нет fallbackTag. Если все пробы упали (например, кратковременно пропала сеть), без fallback balancer может не выбрать ничего.